问分析小组及个别成员表现-RUP

EN

就像你说的--用数字来判断人，如果没有经过常识和其他因素的锻炼的话，结果几乎总是很糟糕。

就我个人而言，我不喜欢像你所描述的那样的效率指标。如果一个人花了40个小时，修复了20个bug，而另一个人花了50个小时，修复了20个bug，这真的有关系吗?如果每周都修复了20个错误，那么如果两者都是薪水的话，这有关系吗？另外，如果某个人设法在30小时内修复了20个bug，而他却在这样做时消耗了他人的20小时时间，那么这个“效率较低”的人完全独自工作，而他的工作总是为其他人节省时间，这更好还是更糟。

我看过以下内容，并粗略地考虑了给团队带来了多少净值：

发展计量学

• 每个人在一个阶段或版本中完成的功能有多少个。在瀑布中，我将分阶段完成这个阶段--高层次设计、详细设计、代码/单元测试--在敏捷中，它将通过sprint来实现。我通常对小、中或大的特征有一种普遍的感觉。当我使用后知后觉时，我使用的是特性的大小，而不是当我们开始的时候我认为它的大小。
• 每个人有多少次获得了一个在他们身上生长的特性？有些人在管理范围方面比其他人好。每个人偶尔都会得到一个无法控制的问题特性，但是有些人似乎有一个不断增长的特性问题。如果每10个功能中有9个功能从小到大，对于一个人来说，我就开始研究这个人是否存在控制范围的问题。

如果可能的话，我会说，不惜一切代价，避免进入每个开发人员的SLOC。这不仅是一个时间消沉，因为它真的很难搞清楚在许多复杂的项目-它也是衡量错误的东西。1优雅的代码行值100行草率行，不同的特性将需要不同的方法。每个开发人员的SLOC几乎总是将您推向“更多”=“更好”的立场，但事实并非如此。在很多情况下，我想知道的是，开发人员采用了我们已经拥有的代码，并让它用最少的返工和新开发来做一些新的事情--这就是从长远来看将成为一个伟大的产品的原因--这就是被SLOC标准搞砸的人--优雅地添加到代码库中需要花费大量的时间，如果你做得对，在这个过程中只需要增加很少的代码行。

Bug

就我个人而言，我认为我持有更多关于bug的度量标准，而不是开发指标。Bug可以制造产品，也可以破坏产品，所以我想知道：

• 我们正在用尽可能少的努力找到尽可能多的错误。
• 当bug被修复时，它们不会引入新的bug，而这些bug必须被发现并修复。
• 当我们在产品中添加功能时，我们会尽可能少地向产品引入bug。
• 这个产品的任何部分都是深奥的，只有一个人能修复那里的漏洞。

从这一点，我看：

• 修正平均值--最好是按错误类型--而不是单个平均值。一个人只会修垒球，很容易看到虫子吗？只有一个人能修复他所在区域的虫子吗？是不是有人花了很长时间来修复看似简单的虫子？是坏的还是好的？有时候，花的时间最长的人也是那些有明显缺陷修复后错误的人，因为他清理了一整片原本会有另外10只虫子消失的地方……
• 错误修复拒绝率-谁得到了很多返回的错误，因为他们声称已经修复了，但随后的测试显示，错误没有修复？
• 错误的代码区域？-几乎总是有一个问题区域，而且您几乎总是知道它在哪里，但是检查您的度量标准，看看它是否真的是bug最多的区域。这些bug来自哪里，最常见的bug类型是什么？这是在逐个案例的基础上更多地查看bug，并查看是否有任何bug是开发人员在测试阶段之前应该/可能已经处理过的。

我强烈建议您尽可能地将度量集中在产品上，而不是在开发人员身上。这样更容易从工具中挖掘出度量标准，因为您的CM和bug管理系统关心的是您的产品，而不是您的人员。它迫使你在回顾开发人员时做一些解释--在任何时候，当你从一个数字到一个人，你需要做什么--这个数字真正反映了什么?这是一个人的问题，还是工作方式的问题？