敏捷度量指标争论又起

敏捷教练和咨询顾问们经常警告他们的客户：传统的度量指标，诸如收益价值、工作小时数、代码行数，以及代码测试覆盖率等都不能与敏捷项目很好地吻合。但是这样，客户们就会产生下面的问题：什么是好的敏捷度量指标？相对于坏的度量指标，怎么能提出好的度量指标？即使是好的度量指标，在某些环境里是否也会变得不再合适？

XP/Scrum 团队里面经典的度量指标自然是开发速率（Velocity），或者说团队在上一次迭代里面完成了多少开发工作？这个指标起初只是为了帮助团队更好地决定下一次迭代的计划工作量。然而，“开发速率是否可以度量团队的生产率，或者比较两个团队？”——这样的问题却屡见不鲜。 Hiren Doshi 指出开发速率这一参数是与具体团队相关的。另外，敏捷顾问 Peter Stevens 也质疑团队是否会因此在度量上耍花招：这个故事应该是 2 个点，还是 3 个点？这完全依赖于团队的判断。如果团队认为需要交付尽可能多的故事点数，那么他们显然会选择 3 个点，也许更多——5 个点。”

敏捷/ 精益教练 Dave Nicolette 警告大家设计拙劣的度量指标会导致低劣的产出结果。举例来说，如果业务上奖赏修复 bug 和救火的行为——人们就会因此去制造 bug，四处点火。

敏捷教练 Deborah Hartmann Press 和敏捷管理顾问 Robin Dymond 在他们的论文“ Appropriate Agile Measurement ”中给出了好的敏捷度量指标的几个启发性原则：

• 坚持并强化精益与敏捷原则
• 度量产出结果，而不是产量
• 追踪趋势，而不是数量
• 选取轻量的度量指标和“诊断”方法
• 易于收集
• 展示指标的上下文和重要的参数，而不是掩饰
• 促进有意义的讨论
• 度量价值（产品）或者流程
• 鼓励“足够好”的质量

那么，什么是好的敏捷度量指标？

Ron Jeffries 建议使用可工作的经过测试的特征数量（Running Tested Features，简写为 RTF，下同）：

1. 所需的软件被分解为给定名称的特征（需求、故事等），它们组成了需要交付的整个系统
2. 对于每个给定名称的特征，至少有一个或者多个自动化验收测试，（当它们都通过了），反映了特征已经全部完成
3. RTF 指标表示了项目在各个时刻有多少特征通过了各自的全部验收测试

Scrum 教练 Peter Hundermark 建议可工作的自动化测试数量（Running Automated Tests）也是度量指标：

在一定条件下，团队拥有更多的可工作的（即通过的）自动化测试，对于软件质量是一个积极的信号。但一旦超出某个水平，该项指标就将不再真实，但我们还没有遇到哪支团队达到了这一点。（我们倒希望遇到呢！）
…
根据小道消息，在 salesforce.com 向敏捷的大转变中，这项指标就是该公司使用的主要指标之一。

此外，他还提到了“进行中工作量”：

进行中的条目项（故事）是一种生产率指标。它旨在帮助团队跟踪他们的协作状态。在敏捷团队里，这表示对于整个团队而言，只要条件允许，就在单个工作条目上协作直到其“完成”。这样增加了产出率、质量和相互之间的学习，减少了直到 Sprint 结束时条目仍未完成的风险，那样导致了浪费。 跟踪每天有多少任务项处于“进行中”状态，能使团队的协作程度透明化。图表则以天为单位对进行中的故事进行跟踪。它反映出 Sprint 的不可预测性：它应该随着时间逐渐趋近于 1，一旦出现任何大于 2 的数值，Scrum Master 就该行动了。

最后，Deborah 和 Robin 提醒大家在设计指标的时候，不仅应该考虑何时使用，也要考虑何时停止使用，以及可能的利益博弈。

请参阅 InfoQ 之前相关报道： Metrics in an Agile World 和 Agile EVM 查看英文原文： What is a Good Agile Metric?