敏捷度量——一项缺失的实践？

Tom Gilb 和 Lindsey Brodie 最近写了一篇文章，两位作者都认为敏捷方法有一个很大的缺陷——缺少量化机制。 他们认为产品质量可以用量化的分析结果来表示，并提出了一种新的过程，名为 PLanguage。这种过程看上去和 Scrum 很像，但是其中多了一步精确度量。他们的想法是正确的吗？像 Scrum 和 XP 这样的敏捷方法需要精确度量吗？

在《敏捷方法中的问题：鼓励量化分析的原则与价值》一文中，Gilb 和 Brodie 说到:

敏捷软件方法（由敏捷联盟 2006 年提出）在所开发的软件的性能量化方面（质量需求，资源节约和工作量范围的指标）投入的关注是远远不够的。尤其是常常也没有量化数据来向投资方证明该项目有足够的理由可以得到投资（商业利益的指标，诸如业务扩展，更高的服务质量和财务上的节约）。也就是说，这些项目无法直接控制用户和股东的收益的交付，从而也无法控制在得到主要收益的同时所相应付出的成本。用另外的话说，如果你没法评估量化后的需求，那么你也就没法得到合适的预算来完成项目。

这项声明根本无法对那些有着敏捷方法实践经验的人有什么影响，因为在他们的理论核心中，敏捷方法是内省（Inspect）和自适应（Adapt）的方法。内省也暗含了度量。但是它却没有明确的说明来描述怎样进行度量，应该度量些什么。Gilb 和 Brodie 没有明确地阐述如何进行度量，但是他们给出了一个对需求进行量化的实际例子。

另一方面，来自 InfoQ 的 Deborah Hartmann 也和 Robin Dymond 一起写了一篇文章，名为《正确的敏捷度量：使用指标和分析学来交付商业价值》，他们在文中同样提出了度量的重要性，并提出了一种比较好的度量候选方案：

1. 确认并强调精益和敏捷原则的重要性。
2. 对结果而不是产出进行度量。
3. 跟随迹象而不是数字。
4. 范围限定在一组比较少的指标和分析结果的集合中。
5. 容易收集。
6. 它的背景和比较重要的变量应该被揭示出来，而不是被隐藏。
7. 为有意义的对话提供信息来源。
8. 频繁和定期提供反馈。
9. 可以度量价值（产品）或是过程。
10. 强调“足够好”的质量。

作者所持的这种我们必须进行持续度量并对度量结果做出响应的观点，即使是从元过程（meta-process）的角度来看也是正确的。在《Patterns of Agile Practice Adoption: The Technical Cluster》一书中，作者告诉我们，要决定采用何种敏捷实践之前，我们必须首先明确想要通过采用敏捷实践来提升哪些业务价值，然后：

对于每一个要实现的业务价值，你要找出至少一种可以度量其进展的方法。也就是说，如果你需要通过实现一种敏捷实践来提升特定的业务价值，那么你就要进行周期性地检查特定的指标来保证这项实践是有效的。这种指标不必是定量的，只要能定性就可以了，让它越简单越好。比如说，如果你要对降低的成本进行度量，那么可以采用在一个主要版本的发布过程中所花费的时间作为一个简单（而粗略）的指标。

我们必须要周期性地对开发过程进行度量，来判断我们所采用的实践是否正在帮助我们达成目标。

值得注意的是，这些资料没有一个告诉我们如何如何进行度量，度量应该是什么样子的。这是当然的了，因为这是要看具体情况的！当我们那些正在实施敏捷的人把度量看作是他们工作的组成部分时，Gilb 和 Brodie 却把度量看作是敏捷所缺失的一项内容，这让人心中不爽。正如当我们知道我们是在严格的纪律下进行开发时，外界却把敏捷看作是“牛仔式编程”，这两种情况是否相似呢？

查看英文原文： Agile Measurement - A Missing Practice?