测算团队，而不是个人

Michael Dubakov 的公司最近发布了 Target Process ——一个针对敏捷项目管理和生命周期的产品。作为对该产品用户的问题和要求的回应，Dubakov 对于敏捷项目中测算个人开发速率和个人估算准确率的活动提出了警告。他认为：由于已经有了针对团队的等价物，对于个人的测算标准和活动不但无法获取更多有价值的信息，而且有可能使得团队做出影响生产力和效率的行为。

在一篇 2007 年岁末的帖子中，Dubakov提出了关于敏捷团队希望测算个人开发速率的议题。他以两个开发人员——Ted 和 Jerry——为例说明：一系列的历史“个人开发速率”测算数据，对于团队未来的迭代规划以及团队的整体开发速率测算，没有任何帮助作用：

在一个迭代中，如果 Ted 完成了预估要花费 40 个小时的多个任务，而 Jerry 只完成了预估 25 个小时的多个任务，我们就可以说在该迭代中 Ted 的开发速率要更快。那么是不是意味着 Ted 是一个更快、更好的开发人员呢？不尽然。有无数原因可以解释 Jerry 为什么完成的任务量较少……好吧，那么多个迭代核算下来，两人的平均开发速率各是多少呢？令人惊讶的是，Jerry 的平均开发速率是每个迭代完成 54 个小时的工作量。天哪！Jerry 在上两周里怎么了？他的平均开发速率能够帮助我们制定准确的迭代计划吗？如果我们把团队的全部个人开发速率累加在一起，是不是可以帮我们制定更好的迭代计划呢？不行，因为我们已经有了“迭代开发速率（Iteration Velocity）”这个测量标准，而且它是不会发生变化的。

为了进一步说明他的观点，Dubakov 指出，针对个人进行测算这种行为，会对敏捷团队的理想运作目标造成两种危害：

1. 错误地关注个人的绩效，而不是团队的成果；这样会导致团队成员不愿意花费时间互相帮助
2. 倾向于注重个人工作的分配，而不是达成团队的承诺

受到 Michael 的观点和最近一个论坛讨论贴的激发，James Carr 很快就提醒大家开发速率的通常用法：

使用开发速率不是为了（评估）绩效……是要让客户更清晰准确地知道当前的迭代可以完成多少个功能“点数”。要牢记这一点。

最近的一个帖子中，Dubakov 回顾了这个话题，这次他加入了对于测算个人估算准确率这一活动的警告。他首先指出这个测量标准不具备可行性，除非做到以下两点：一、估算由个人给出；二、团队追踪记录所有任务的完成时间。正像敏捷社区反复强调的，这两个条件的主要问题在于它们都违反了敏捷的基本原则：促进团队合作以及让工作变得更简单。

为了例证测算个人估算准确率会导致的错误后果，Dubakov 又以假设的开发人员 Ted 为例：

我们可以计算 Ted 的全部任务分配和花费时间，并计算出下个迭代的估算准确率，假定为 0.7。 好，那我们又该如何使用这个测算标准呢？如果 Ted 估算这个迭代的任务要花费 60 个小时，就是说他将会实际花费 85 个小时，对时长为两周的迭代来说，他至少要加班 5 个小时。Ted 应该考虑这个因素，并从他的 ToDo 列表中去掉一些任务。如果 Ted 的估算准确率不变，这样做没有问题，可是真能这样理想吗？在现实中，Ted 的估算准确率从 0.5 到 0.9 浮动不等，在下个迭代中，准确率可能为 0.9，这样他就可以及时完成所有的工作。

InfoQ 的 Deborah Hartmann 进一步阐述了 Michael 的观点，她质疑任何针对基于时间的估算准确率进行测算的有效性，无论这样的测算是针对团队还是个人：

要计算这样的估算准确率，团队必须要耗费精力获得详细的“实际”工作小时数，我可从没有见过哪个敏捷实践倡议说要这样做。经典的“规划的工作计量单位”与“全部完成的工作计量单位”，是以对客户更有价值的工作单位——交付的工作（故事点数、理想工作小时数、香蕉等等）进行估算准确率测算的。 通过追踪实际工作小时数来追踪估算准确率，不能为团队提供更多有价值的信息，而且造成了一种新形式的浪费。我同意 Dubakov、Carr 和其他人的观点：对大多数团队来说，我认为这种测算毫无价值，而且很高兴看到：由于该观点的提出，它很快就从 TargetProcess 中移除掉了。此种负责任的改变，正是我们期待敏捷团队所展示出来的行为。

Dubakov、Carr 和 Hartmann 都同意：针对敏捷项目中个人开发速率和个人估算准确率进行测量活动，不但无法获取更多有价值的信息，而且有可能使得团队做出与敏捷核心思想相违背的行为。

查看英文原文： Measure Teams, Not Individuals