书评与访谈：Software Development Metrics

《Software Development Metrics》的作者是 Dave Nicolette ，这本书对如何使用度量指标来跟踪和指导软件开发进行了探讨。它解释了不同的开发方法和过程模型，比如传统的基于瀑布式或者迭代敏捷软件开发，是如何影响度量指标的选择和使用的。本书还对一些可以用于指导工作和管理改进的度量指标进行了描述。

本书的某些章节可以在出版商的《Software Development Metrics》书评专页上免费下载。

InfoQ 有幸采访了 Nicolette，主要涉及度量指标服务的目的，在软件开发中使用度量指标，度量开发速率以跟踪团队的改进，度量团队的情绪，防止度量指标的误用以及向敏捷团队和利益相关者推荐用于交付价值的度量指标。

InfoQ：是什么使您决定写一本关于软件开发度量指标的书？

Dave Nicolette：这个答案太长，我想大家不太愿意阅读：

（1）我认为度量指标对于及早发现交付风险是绝对有必要的；（2）我发现度量指标是痛苦、枯燥的；（3）我观察到，大多数参与软件交付的人不知道哪些需要度量或者不知道他们收集回来的数据能够做什么。

对于（1）和（2），我希望找到简约、实用的度量方法，这种方法不会占用我太多的宝贵时间就可以及早发现交付风险。对于（3），我希望帮助人们发现度量指标，并且这种度量指标很容易理解，而且在他们自己的工作环境中很有用。

详细的答案是：

我不能说在那时我就意识到了，但是在我职业生涯早期的某一时刻，我注意到：项目中或者项目后，人们在过程后期盲目地交付风险，然而那时这些问题可能已经不可修复。他们尝试了各种评估、预测、规划和跟踪工作的方法，但是在游戏的后期，仍然会有一些不愉快的意外发生。

在随后的几年当中，作为一名顾问或者教练，为软件交付组织工作时，我发现几乎没有人理解为了及早发现新兴的交付风险，以便有时间处理风险应该度量什么。他们小心地收集数据，但是在交付过程的后期，他们又再次盲目了。如今，几乎在我所访问的每个组织中现实情况仍然如此。

我观察到两种一般行为模式，这两种模式让这种问题更加严重。

首先，许多项目经理热衷于某种软件工具。他们喜欢在查询、图表和图形数据中使用这种工具的特性。但是他们却忽略了他们跟踪的数据的意义和价值。他们生成的输出是如此密集地挤满了数据，以至于结果都是噪音并且毫无信息。然后他们在过程后期盲目地交付风险。在企业中我经常看到人们使用企业化的项目管理工具，这种工具为配置、查询和制图，提供了多种选择。

其次，有人认为度量指标本身就很有趣，而不是把它看成一种必须，这种人倾向于从数学和统计学的角度处理这个问题。他们喜欢数学，他们甚至倾向于将问题复杂化……虽然他们自己并不认为他们的方法很复杂。而不是数学家或者统计学家的普通人发现这个方法令人晕头转向，他们不能很好地使用这种方法。所以他们在过程后期盲目地交付风险。

2009 年我在“agile” conference 上发表了关于度量指标的演讲。房间又小又热，并且我崭新的笔记本电池在 30 分钟后也耗尽了。我使用互动挂图继续我的演讲。房间里人满为患，甚至有人站在门口和大厅里。尽管存在这些问题，但是当我结束演讲的时候，人们并没有离开。他们想获得更多的信息。他们询问了具体情况等等。但是我不得不给下一位演讲者腾出房间。

我跟许多用户群都有过类似的经历，比如 PMI 和 APLN。人们渴望拥有有用的、简单的和实用的度量指标。坦率说，我一直认为这件事相当枯燥，因此我对人们表现出来的浓厚的兴趣很是惊讶。

所以，有一天，我想以书本的形式编辑一些这方面的信息可能是有用的。现在，这本书已经出版了，我们将会发现它的作用到底有多大。这本书内容精简，因为编辑们友好地删除了我大部分的闲话，并认为这是对读者应尽的义务。剩下的都是朴实无华的信息，目标是实用。

InfoQ：在您看来，度量指标服务的目的是什么？

Nicolette：在软件交付的环境下，我认为有两个理由需要进行度量。

首先，我们需要知道工作是否按照我们的预期或者计划发展。我们能够越早发现变化，就越有机会适应变化，减少时间和金钱的损失。我称其为“指导（steering）”工作。究竟如何指导则取决于组织的文化，管理风格，项目的驱动力，工作的性质，和其它一些因素。但是，无论你如何操作，你都需要客观的数据，以便决定用哪种方法指导。

其次，我们需要知道我们改进交付的努力是一种帮助还是破坏。在软件领域有一个广泛的共识，不断地审视我们的交付流程，并寻找改进的机会是一个很好的主意。如果我可以不严谨地使用某个术语，这有点类似于 Hawthorne Effect，在人们积极改变他们的过程中，感觉好像情况正在改进。在现实中，除非我们将实际性能与改进目标进行比较，否则我们不会知道我们的改变是否是改进。

InfoQ：在这本书中您为不同的开发方法、过程模型和交付模型探索了度量指标的使用。您能否解释一下，为什么这些东西对度量指标很重要？

Nicolette：这又回到了我对实用主义和简单度量指标的偏爱，它们服务一个或者两个目的——指导和跟踪改进。许多人尝试应用，相信他们正在应用，或者简单误用了某种软件交付框架或者其它。他们使用那种框架推荐的度量指标，但是那些度量指标可能是基于某种假设，在特定组织内它们是没有关联的。雪上加霜的是，当人们使用某种不熟悉的方法时，他们并不倾向于用完美的技巧应用这种方法。他们做事的方式可能渲染出推荐的度量指标毫无意义。

出于这个原因，剥开流行术语闪亮的外层，审视组织内实际工作流程就显得非常的重要。然后他们可以度量真正发生了什么，而不是认为或者希望发生什么。否则，他们可以期待在过程的后期盲目地交付风险。

我提出的用于评估工作流程的模型，旨在在一个给定的组织环境下识别出有意义的因素，这样人们可以度量实际情况。例如，有很多自称自己是“敏捷”的组织，但是实际上却以传统的方式执行软件交付工作。但是这几乎不能给他们跟踪度量指标带来一点好处，比如开发速率和可运行的经过测试的特征（running tested features），因为像提供有意义的数字这种活动根本不会发生。

同样，如果提供的是“连续测试版”的产品，或者组织正在使用精益创业方法对客户需求进行导向目标追踪，那就没有预定义的“结束日期。”因为它根本就不是一个项目。在这种情况下，像“迄今为止完成的比例范围”这种度量指标绝对毫无意义。

InfoQ：您能否解释一下，如何使用度量指标跟踪和管理交付目标的进度，比如“可运行的经过测试的特征”？

Nicolette：当然可以! 跟大多数度量指标一样，RTF 是基于组织内工作流程的假设。它假设（1）一种自适应方法，（2）至少在测试环境中可以投入生产的特征可以用于增量交付，（3）自动检查定期运行的代码。

使用自适应开发时可能没有预定义的、固定的范围；我们努力实现客户明确的业务功能，除非有足够的特征支持那些功能。客户决定何时的解决方案够好，以及何时他们不希望进一步在优化上花费更多的投资。通过增量交付，和迄今为止已经完成了的特征，我们可以随时“上线”。通过自动检查，当我们破坏了以前一直正常工作的特征时，我们能够立即知道。因此它给了我们随时“上线”的自信。

在那样的环境中，RTF 有利于跟踪进度。通过显示客户明确了的业务功能的开发进度，它能够支持自适应开发，并且不需要对规划范围 100% 的预确认。在任意给定时间内，通过显示有多少特征可以投入生产，它能够支持增量交付。但是如果没有自动检查，它就没有意义，因为在那种情况下，任何已经完成特征可以投入生产准备的声明只是一种一厢情愿想法。

现在，我们来考虑传统软件交付过程。在我们对定义范围没有 100% 明确之前，我们不应该开始开发工作。交付可能分阶段或者版本，或者它可以是“大爆炸”式。在代码被写入之前没有需要检查的内容。正因为这些原因，RTF 对传统开发毫无意义且无用。

像其它度量指标一样，当 RTF 有用时它就有用，当它没用时它也没用。你可以对任何度量指标进行同样的评估——理解这种假设基于何种条件，看看这些假设在你组织内是否成立。当你这么做时，它有益于忽略所有的流行术语，正视现实。但是现实不会躲闪，所以这并不意味着你必须这么做。

InfoQ：大多数敏捷团队都会度量它们的开发速率，以便了解他们能够交付多少。但是，开发速率也可用来度量某个团队的改进。您能够解释一下如何度量吗？

Nicolette：好吧。开发速率是基于某种假设的另一个度量指标。它取决于（1）有时间限制的过程模型，和（2）至少在测试环境中可以投入生产的特征可以用于增量交付。假如这些假设成立，那么开发速率对短期计划就是有用的，并且可以为燃尽图积累经验数据，而燃尽图又可以揭露新兴的交付风险。所以，当工作按一定方式完成时，开发速率就有益于指导。

但是根据我的经验，开发速率有点不太稳定，因此不能用于跟踪改进。原因有三点。

首先，团队的改进工作包括迭代时限长度的改变或者完全抛弃某个定时模式。而任何一种改变都会使得新的开发速率观测值与历史值对比的结果失去意义。

其次，当团队对某个问题领域、解决方案的技术和协同合作越来越熟练时，交付某个给定大小的用户故事花费的时间可能比项目初期预算要少。发生这种情况时，团队往往会就调整用户故事的相对大小达成某种默契。在迭代 5 中，团队可能考虑用一定数量的工作量来表示故事的大小，比如点数 3。而点数 3 在迭代 15 中比在迭代 5 中包含的工作量要多。这种情况很正常，并且不是团队某个有意识的决定。虽然看上去，在迭代 15 和迭代 5 中，团队交付了同样数量的故事点，但是实际上，在迭代 15 中，他们的交付性能得到了提升。

第三，许多企业都在尝试“敏捷”方法，但是他们没有完全“明白”这种方法。管理者对开发速率设置明确的要求这是很正常的。有时，为了完成开发速率目标，管理者甚至会要求团队“全速前进”。开发速率是实际交付性能的一个经验观测值。当我们设置开发速率目标时，我们就会完全破坏度量指标。它就会彻底失去意义。在那种环境下，它就不能用来跟踪改进。非常不幸的是，这种情况非常常见。

所以，使用开发速率跟踪改进时，必须保证某些事情在整个度量期间的一致性：（1）迭代长度必须一致；（2）相对大小必须一致；（3）管理层必须不能设置开发速率目标。但是要保证这些事情在任何时间周期内保持一致是不太可能的。所以，我不建议使用开发速率来跟踪改进。我觉得周期时间是一个可行的替代方案，它几乎给出了同样的信息，并且对过程模型、大小和评估实践或者目标设定不敏感，

InfoQ：有很多度量指标可以用于度量团队的情绪，比如你在书中描述的情绪震动图或者幸福指数。您能分享一些团队使用这些度量指标的案例吗？

Nicolette：我不确定如何援引各个团队作为案例，但是我可以分享一些总体情况。

我亲眼所见表情日历能够为新成立的协作型团队提供帮助。当他们发展到激荡阶段和规范阶段的时候（每个 Tuckman 发展阶段），我发现一个迹象，每个团队成员的普遍情绪帮助他们保持正确的行为。例如，如果我不认识 Joe，并且 Joe 在工作室对我很无礼，那么我可能认为 Joe 这个人很粗鲁。我对 Joe 进一步的认识也会打上粗鲁的色彩标签。但是，如果那天早上 Joe 在日历上贴上了皱眉的表情，那么我就会认为他的无礼只是他对生活中某件事的反应，与工作无关；这没什么大不了，明天将会是新的一天。

它为什么重要？因为当他们相处愉快的时候以及当他们普遍有一个好的士气的时候，人们的工作效率往往更高。了解团队每个成员的情绪状态，可以避免因为我们反应过度或者我们对某人脱离环境，基于其少量行为的基础上建立的假设而造成的紧张，尤其是当我们对这个人不了解的时候。如果我脑子里整天一直想着“Joe 到底怎么了？”这个问题，那么我将无法正常工作。当团队到达执行阶段的时候，他们一般也就不需要表情日历了。

表情日历同样可以暴露组织问题。书中提到的 Omega Wolf 模式就是个恰当的例子。不管团队其他成员情绪如何，即使团队的某个成员看上去总是很消极，它也不能代表那个人是一个令人沮丧的人。更多的时候，它是系统和组织问题的征兆。即使我们解雇了这个闷闷不乐的成员，很快又会有人填充这个角色，因为这不是个人的问题。这跟工作环境有关，它加强了对这种行为的需求。它有点类似某种形式的安全阀，能够使团队其他成员正常工作。 正确的纠正措施应该是改变组织参数，使其减少对 Omega Wolf 模式的需求。 因此，当机械措施不能发挥作用时，情绪措施可以揭露这类问题。

团队在每天的同一时间更新他们的情绪，这样情绪震动图就可以跟表情日历一样为团队成员提供帮助。在这种情况下，它仅仅以不同的形式提供了表情日历一样的信息。但是我到目前为止看到的所有情况都是，团队将情绪震动图当作回顾性的工具使用。他们回望过去，凭记忆填充他们的情绪。我观察到结果往往会受到迭代成果和最先发布结果的团队成员的强烈影响。如果事情结果令人满意，那么人们就会认为他们的情绪一直都是积极向上的。所以我不建议使用这种度量指标，因为它是不可靠或者具有误导性的。

健康和幸福的指数是我从一个客户公司的 ScrumMaster 那里学来的，它可以产生一个有趣的效果。它常常被当作回顾工具使用。有时，团队成员对某次迭代成果不满意，不是因为成果很差，而是因为迭代很困难。同样，相反的情况也会发生。健康和幸福指数将观察到的交付性能（健康）与感知性能（幸福）进行比较。它可以缩小感知和现实之间的差距。

我看到过进入回顾情绪低落的团队，在熬过健康和幸福练习之后，他们意识到毕竟他们已经完成了一些非常好的东西。他们对迭代不满意，是因为他们将全部时间都用在了清除前进道路上的阻碍，解决疑难问题上面。

同样，我也看到过进入回顾情绪高涨的团队：他们感觉自己是宇宙的主宰，不料由于某些原因，发现他们交付的工作是不完整的——由于对第三方的依赖，他们从来没有集成过他们的代码；他们的用户故事实际上只是用户故事伪装成的工作任务，对客户没有一点价值；等等。度量指标可以帮助团队学会专注重要事情，学会识别当他们建立假设时，应该考虑当时的难点，而不是他们工作的业务成果。

InfoQ：您能否解释一下度量指标是如何被误用的？有没有什么措施可以预防这种情况？

Nicolette：真不知道从哪说起。我认为本书至少有三分之一的内容都在讨论度量指标应用的反模式。本书的灵感来自一项观察：人们习惯度量错误的事情或者是以错误的方式度量正确的事情。度量指标的误用是常规，不是例外。

将度量指标看成一种工具。要从工具中获得价值，你需要完成两件事：首先，为任务选择一个合适的工具。第二，正确使用工具。如果我需要拧上一个螺丝钉，锤子就是一个错误的工具。如果我使用螺丝起子，但是我用把手猛击螺丝钉的头部，那就是选择了正确的工具但是方法是错误的。

同样，经验法则也适用于度量指标。比如开发速率。很多时候，团队告诉我他们之所以跟踪开发速率，是因为管理层让他们“使用敏捷”，而“敏捷”说“跟踪开发速率。”（总的来说，我还没有在宣言中找到这种说法。）但是在每次迭代中，他们没有交付潜在的可发布的解决方案增量。他们甚至没能实现端到端的特征。不夸张地说，他们没有开发速率。他们计算某事，并将它绘制成图，但是这不是开发速率。砰，砰，砰。他们不能用这种度量指标预测事情，除非我们预测到在过程后期，他们将会盲目地提交风险。

我也见过将开发速率以相反的方式滥用。团队将传统项目的工作分块化，假装执行“迭代”，并使用开发速率作为“迄今为止完成的比例范围”的代理。但是这根本不是开发速率，这仅仅是跟踪工作的完成情况。为了保持进度，管理层期望每次迭代都能够完成一定的工作量。团队为了避免陷入麻烦，只能赌博这些数字。这导致了可预测的结果：他们在过程后期盲目地交付风险。

任何你能够说得出来的度量指标可能有几十个，甚至几百个类似的例子。总体根源是因为人们试图度量出根本没有发生的事情，因为他们认为它们应该发生。

InfoQ：您是否有推荐使用的度量指标，敏捷团队可以用这些指标交付价值？

Nicolette：简要回答“没有。”我不是很喜欢“敏捷团队”这个术语。我觉得“敏捷”是一个学术流派，它为自适应软件开发提供了大量卓越的想法。但是，自适应开发的完成，没有必要遵循“敏捷”，并且有效“敏捷”开发可以通过其他学术流派获知，比如精益思想和系统思想。“敏捷”方法可以而且经常被应用到传统项目。这也是为什么许多团队贴上“敏捷”标签，而他们并不“敏捷”。所以，在某种意义上它是一个神奇的字眼。我欣赏 Harry Potter，但是，你知道的。

事实上，我试图在书中明确一点：人们应该无视流行术语，而是弄明白在他们组织内，真正的工作流程到底是什么。这是选择合适的度量指标的基础，而不是那些在当时碰巧起作用的魔术字眼。来年，又会有一套新的魔术字眼，但是软件仍然是软件。

InfoQ：敏捷团队中的管理者和其它利益相关者在处理类似问题时，他们可以使用相同的度量指标吗，还是应该使用不同的？

Nicolette：出于指导的目的，软件交付团队中所有直接利益相关者的利益是一致的。所以我的答案是“是的”，他们可以通过同样的数字看到同样的信息，达成共同的理解，并一起讨论整改措施。但是正如问题所陈述的一样，它不仅仅限用于“敏捷团队”。它适用所有的软件交付团队。

当谈到与改进相关的度量指标时，我不推荐跟团队以外的任何人共享数字。因为在大多数的组织内部，存在着很高的风险，管理层通过这些度量指标给团队带来麻烦（即使是出发点意图是好的）。团队获知他们改进工作的最好办法是跟踪改进的度量指标。一旦团队通过某种度量指标跟踪到他们已经实现了性能改进目标，他们就不必继续跟踪这一度量指标了。

你在出版商网站购买本书时，使用代码“sdmiq40”可以享受40% 的折扣。

关于作者

Dave Nicolette自 1977 年就加入了软件行业，从事过各种角色。近年来，他主要从事在团队和组织层面担任敏捷和精益教练。

查看英文原文： Q&A and Book Review of Software Development Metrics