敏捷的度量指标

今天在Linkedin上看到大家讨论如何定义和衡量敏捷转型的程度时，发现了以下这篇Esther Derby（《门后的秘密》一书的作者之一）所写的文章，简单挑要点翻译出来与各位分享。其中【译者注：】就是我加的本人的理解和说明。

==============================

我们经常听到这样的问题“我们公司/组织目前处于敏捷转型的那一个阶段或步骤了？” 【译者注：是否有一种类似CMMI 一样的度量指标来度量敏捷的程度？如何知道敏捷转型的目标在哪里？】

我经常建议这些公司的经理们去跟踪以下的三个指标，通过这些指标的趋势来了解他们的组织是否朝着正确的方向前进。

1、开发工作vs.缺陷修复的时间比率，有多少时间人们在开发有价值的新功能对有多少时间人们在修复缺陷？而这些缺陷就是第一次没有做正确的事情。如果你能够找出这些修复缺陷工作的源头并能施加相关的措施使之工作量能够降低些，那么你将会得到比较好的效率提升。敏捷方法能够找出一些用于修复缺陷的原因，但是不能找出所有的原因。【译者注：话说一次性将事情做好的成本是最低的，修bug 就是还过去欠下的‘债’，敏捷中推荐的测试驱动开发方法就是希望把项目后期的修bug时间降到0】

2、周期时间，需要多长时间能够将想法变成有价值的产品交付到客户手中？敏捷方法能够在交付阶段起作用，但是如果在上游对的产品计划阶段和发布阶段出问题了，你可能就不能看的相应的提高，除非你能够发掘这些问题，同样也包括开发流程的问题。【译者注：周期时间在《持续交付》一书也被反复提及，这个指标能够衡量整个组织的交付能力和效率，而不仅仅是软件开发阶段、过程。】

3、流入到产品中的bug数量，这是一个表明修复缺陷工作的直接度量指标，它表明了相关的开发流程质量指标正在提升与否。
这些每个度量指标，它的趋势才是重要的，而不是它们的绝对数值。这些趋势能够告诉你相关的提高措施是否真的起效果了，请记住，大部分改变是 需要一定时间后才能看到效果的。如果采取措施一个月内没有看到变化，也许并不是意味你采取了错误动作而需要改变方向。如果长久都看不到相应的趋势变化，那么需要对开发领域需要仔细的分析，看看到底发生了什么，同时也需要看看这个组织系统的其他方面。因为在相互关联、影响的复杂系统中很少有一个原由对应一个结果的发生，一些所衡量的趋势也许并不与你采取的措施相关呢。
......

这些有用的度量指标只是给予你一个发现问题的窗口，和查看你的措施是否起效果的途径。这些指标对应的数字并无好坏之分，它们只是相关信息中体现出来的一些信号，这些信号将促使你去发现、调查出其系统的真正原因。

原文链接：Metrics for Agile

【译者注：回顾到我目前所参与的这些项目，我觉得除了上面的这三个指标外，另外两个指标更加重要：项目及时上线率、项目目标的达成率，前者衡量整个产品的开发阶段是否可计划和可控；后者是衡量项目的商业价值是否被实现，如果没有那么对应的原因在哪？】