网站建设心得500字,帮人家做网站能赚多少钱,策划案,做个网站的价格一个令人震惊的事实是连生产率这种常见度量数据都没有一个简单的定义。连我们日常经常用到的公式#xff1a;生产率工作产品/工作量#xff08;工作产品可以是代码行#xff0c;功能点#xff0c;也可以是任何可以计数的东西#xff0c;比如文档页数#xff09;都是错误的… 一个令人震惊的事实是连生产率这种常见度量数据都没有一个简单的定义。连我们日常经常用到的公式生产率工作产品/工作量工作产品可以是代码行功能点也可以是任何可以计数的东西比如文档页数都是错误的。 如果你正常尝试使用生产率做度量那么至少应该先分为下面两种度量数据。 注意下面的例子为了便于理解使用的是代码行但实际上这两个概念是IFPUG国际功能点用户组对功能点计数时做的分类。 应用类数据 Application Type 下面这段对话将产生一个应用类度量数据 A“这个软件有多少代码行” B“等我数一下……10000行”。 A“多少人天开发出来的” B“大约100人天吧” A“那么生产率10000行/100人天100行/人天” 这种生产率是按一个应用Application这个词汇的来历的静态规模度量产生的生产率过一段时间会发生戏剧性的变化 三个月后…… B“我们又修改了一些代码增加了一些代码但是也删除了一些代码” A“哦” B“多投入了100人天不过现在还是10000行。” A“那么现在的总生产率是10000行/200人天50行/人天如果只算二期么……0我也帮不了你了” B“好吧……二期算是白忙一场” 开发类数据 Development Type A“这个软件有多少代码行” B“一共有两期……等我数一下……第一期100人天开发了10000行……第二期也是100人天增加2500行删除2500行修改5000行”。 A“那么一期生产率10000行/100人天100行/人天” B“二期呢” A“二期生产率增加2500删除2500修改5000/100人天10000行/100人天100行/人天” B“yeah!“ A”不过也有的体系说二期生产率增加2500删除2500/2修改5000/100人天8750行/100人天87.5行/人天 B”啊“ A”等下……还有体系说二期生产率增加2500删除2500/4修改5000/2/100人天……这个你自己算吧。“ B”好吧总算比白忙一场好。“ 如何使用 场景一计划与绩效考核开发类数据 由于增删改都要花费工作量所以用开发类数据做计划和考核更加公平一些。 不过一般采用功能点更加合理一些比如在重构中极有可能删除大段的代码我们曾经在15分钟左右把4000行代码重构为55行功能不变而实际上应用的变化并不大。如果用这种外界客户高层难以感受到的“变化”来做度量元很难得到认同。 三种体系增删改权值相同或/2或/2/4选择哪个好呢 我也不知道因为这三种体系都有人在用。我的建议是 1. 如果刚刚开始做度量 随便选择一个方法就好了但是请记录下原始数据。 也就是说要记住有多少新增多少删除多少修改。 2. 数据积累比较多了 请按三种方法都计算一次然后对比一下计算结果和实际工作量的相关系数相关系数日后会科普一下Excel表里变有这个函数CORREL(B1:G1,B2:G2相关系数越高表明用这种方法做估算更接近事实。 度量分析没有“理论上哪个最好”只有数据本人才有发言权。 或者说度量分析的本质就是消除各种理论的主观性、片面性、理想化把发言权留给数据本身。所以自己做数据分析是免不了的事情。 场景二需求变更控制 不过不论有多少理由一个软件只修改、删除功能而不增加功能都不是一个正常的事情。 过多修改功能表明需求分析最初做的不好而删除功能则表明做了过多的无用功能。 为了约束团队防止他们把“改软件”当作工作需要定期监控两者的比值应用类/开发类如果这个数据不断下降表明大家都在修改之前的功能很久没有大量增加功能了。 在小而美的产品研发中修改功能可能是一个常态但这不能作为开始可以不深入思考“最佳功能”的理由。 在项目开发尤其是外包项目中只修改而不增加功能是一个灾难因为客户多数时候不会为修改功能付费他们认为这是因为乙方未能深入分析需求造成的。 场景三编码有效性 也就是用多少代码能实现多少功能的问题编码有效性越高则所需代码越少。日后有详细文章描述 当然这里的“功能”指国际标准功能点度量出来的功能而不是我们平时所说的“个人理解不同规模也不同”的那种直觉功能。 在这种场景中应该使用编码有效性总代码行/总功能点数总代码行/应用类功能点数。 比如在之前那个例子中第二期代码行可能还是10000行但是如果功能点增加了那么编码有效性实际上增高了。 完整示例 下面是一个功能点、代码行、编码有效性、应用类、开发类数据的完整应用场景。 A“这个软件有多少代码行和功能点” B“一共有两期……等我数一下……第一期100人天开发了10000行200功能点……第二期也是100人天增加2500行删除2500行修改5000行增加50功能点删除20功能点修改30功能点”。 A“那么一期代码行生产率10000行/100人天100行/人天功能点生产率200功能点/100人天2功能点/人天” B“二期呢” A“二期生产率增加2500删除2500修改5000/100人天10000行/100人天100行/人天功能点生产率增50删20改30功能点/100人天100功能点/100人天1功能点/人天”暂时只用第一种增删改权值算法 B“哪期项目做得快呢“ A“从代码行看一样从功能点看一期项目快一倍。” B“以哪个为准好呢” A“功能点好比较容易给客户和领导交代” B“二期真烂。” A“也未必你们的编码有效率提升了。” B“怎么讲” A“二期完成后不是二期开发本身整个产品还是10000行功能点却增加为300你们现在的代码效率已经达到10000/30033行/功能点了越低越好一期是10000/20050” B“生产率降低编码有效性提高……怎么做整体评价呢” A“生产率提高是终极目标不过编码有效性的提升有利于未来的生产率和质量的提升。所以现在总体评价是生产率下降了未来要看你们以后是否能真正发挥编码有效率的优势了。” 怎么样如果是我如果能写一个由数字组成的项目报告我才不会写一大堆模棱两可的文字呢。
