敏捷不仅有度量，度量还是敏捷项目非常重要的一部分，但敏捷度量和传统的度量存在很大的区别。敏捷度量不是以评估和考核为目的的，它是为了帮助团队拉通目标和行动、指导指定工作计划和任务、协助团队持续改进而发生的。
一提起度量，很多人可能会马上想到评估和考核，在很多人的工作经历里，这两个字如（YIN）影（HUN）随（BU）形（SAN），终于，这几年乘着“转型”的东风，很多组织开始实践敏捷，有人可能会想，敏捷拥抱变化、快速反应，推崇试错和迭代，面对如此不确定的场景，应该不会有以评估和考核为目的的各种度量了吧？
答案是又不是，“不是”的原因是敏捷不仅有度量，度量还是敏捷项目非常重要的一部分；“是”的原因是敏捷的度量和传统的度量存在很大的区别，敏捷度量不是单纯意义上的评估和考核。
下面通过4个问题带你揭秘敏捷度量的那些事
问题1：敏捷项目为什么要做度量（Why）？
回顾一下敏捷宣言：个体与交互优于流程和工具，可工作的软件优于面面俱到的文档，客户协作优于合同谈判，响应变化优于遵循计划，也就是说，尽管右项有其价值，我们更注重左项的价值。
深入理解一下敏捷宣言，不难看出，“个体和交互”是敏捷实施的方式（关注合作），“可工作的软件”是敏捷项目的交付物（目标导向），“客户协作”是服务提供的方式（公开透明），“响应变化”是追求灵活的反应机制（灵活机动）。
这几条宣言简单易理解，也被许多人认可，但事实胜于雄辩，在实际工作中，如何证实左项所注重的价值：关注合作、目标导向、公开透明、灵活机动，并尽可能的优化行为不断让敏捷的价值最大化呢？
这些就是度量要做的事情。
总的来说，度量能帮助敏捷项目做下面三件事情：
第一，拉通目标和行动
可工作的软件长什么样子，它具备什么功能，它为谁提供价值，采取什么样的行动能获得这些价值，这些都是敏捷团队需要回答的问题，敏捷团队不仅仅要知道问题的答案，为了快速实现目标，敏捷团队还需要定期评估行动的效果，为了拉通目标和行动，度量的引入能帮助团队及时纠偏，少走弯路，减少浪费。
第二，定位当下的位置，计划下阶段的任务
实际工作中，经常会有客户邀请我们的顾问评估一下他们的现状，他们基于现状做下一个阶段或者下一年度的计划，这样的诉求在接近季度末或者年底的时候尤其多。
正如人需要定期做体检一样，体检结果让我们对自己的身体状况有更好的了解，敏捷项目也需要定期的健康度评估，这些评估和度量的结果，除了揭示项目存在的问题，还能够帮助团队总结经验反思教训，从而更好的指导下一阶段的计划。
第三，改进，改进，改进
敏捷项目推崇持续改进，以更好的方式、更快的速度交付更优的价值，这是很多团队追求的目标，这个目标不是一蹴而就的，有的时候团队需要引入更好的工具，有的时候团队需要借鉴更丰富的经验，有的时候则依赖团队持续的成长。
敏捷项目引入工具和他人经验的过程也是不断试错的过程，在试错的过程中团队需要知道哪些改变是成功的，哪些是失败的，这个评估通常是通过度量来完成的，所以引入度量也是为了更好的改进。
一句话总结，敏捷项目通过度量来拉通目标和行动、指导团队制定工作计划和任务，并协助团队持续改进。
问题 2：敏捷项目度量什么（What）？
试想一下，如果敏捷项目是一个长方体的话，长方体的体积代表团队所要交付的目标，那么这个体积由什么来决定呢？
根据常识，长方体的长、宽、高决定了长方体的体积。
长度代表交付的速度，也叫交付的效能，长度越长，交付的效率越高，团队也就能更快的接近目标，实际工作中，我们经常听到的研发效能、测试效能、管理效能，cycle time（需求提出到上线所用的时间）等等，都和速度有关，这些指标决定了团队以多快的速度实现目标，这是度量中非常关键的指标。
宽度代表团队的能力，实际工作中，我们提到的测试质量，代码覆盖率，敏捷实践实施，持续集成和交付，统一配置管理，灰度发布，债务管理，松耦合架构，等等，和团队实践以及工具相关的指标都和能力有关，这些指标决定了团队能不能应对不确定性带来的挑战，能不能解决各种复杂、繁杂甚至混沌的问题，能不能做到持续优化和改进。
高度又叫深度，代表产品（软件）价值，实际工作中，我们做的需求价值分析、MVP拆分、产品愿景、优先级排序、价值验证等等，都是团队基于自己的经验展现出的对业务的理解，并在此基础之上准确无误的给出方案，交付客户期望的价值，这些指标决定了团队能不能基于自己深度的积累，精准的帮助客户实现目标，并且能在极少浪费的情况下实现目标。
以上三个维度决定了长方体的体积，但是一个成熟的敏捷项目，光有这三个维度还不够，因为这三个维度不能保证团队是健康的，我们还需要第四个维度的指标来度量团队（敏捷项目）的健康。
这个维度就如同我们给这个长方体上的颜色，是沮丧的灰色，焦虑的红色，抑郁的蓝色，还是生机勃勃的绿色？团队是什么成熟度，项目整体是否健康，这些也需要度量，常见的指标，比如，项目满足的财务指标，干系人管理，团队协作，团队成长，管理的透明化，成员的稳定性等等，敏捷团队健康度这个维度决定了团队能否长期稳定的以此种方式工作，团队能不能自我优化。
一句话总结，敏捷项目度量的是交付效能、团队能力和产品的价值，以及保证这这些目标能够达成的团队健康度。
问题 3：敏捷项目里面谁来做度量（Who）？
这个问题可以从Scrum 的 5 个核心价值观里找到答案：承诺、专注、开放、尊重、勇气。
这几个价值观指导着敏捷项目轻职权、重协作；轻命令、重自组织。
也因此，很多成熟的敏捷团队是自组织的，是在一种扁平文化下工作的团队，在这种团队里，无论是短周期的任务还是长周期的结果交付，团队共同承诺，共同行动，共同负责。
度量作为非常关键的任务之一，也是团队协同工作来完成的。
在这里，有几个小建议给到想做度量的敏捷团队：
第一个建议是，角色之间交叉度量。团队负责不代表不能有分工，如果团队自行组织度量的话，建议角色互换来度量，比如开发人员做价值交付维度的发起者，需求人员提供信息；测试人员做开发相关指标度量的发起者，开发人员输入信息，这样做能更好的保证度量的客观性，对团队来讲，也是一次不错的知识和经验分享的过程。
第二个建议是，引入外部的顾问来做度量。外部的顾问可以是其他团队的人员，也可以是独立的第三方顾问，这样做的好处除了保证度量的客观性，外部顾问还能带来更多的经验，甚至会把跨行业和领域的经验带给团队，帮助团队改进和优化，建设能力。这个方法实施的注意事项是，一定要保证两次度量的评价标准一致，否则会失去度量的价值。
第三个建议，无论是团队自组织做还是引入外部顾问，都需要全员参与。因为度量不仅是团队拉（XI）通（NAO）目标、明确任务、统一行动的机会，度量还能够帮助团队提高凝聚力。
一句话总结，敏捷项目的度量由团队共同承诺、共同行动和共同负责来完成。
问题 4：敏捷项目在什么时候做度量（When）？
这个问题如同问“我们通常什么时候做体检？”，答案无外乎几种：生病的时候；一段时间的专项锻炼或治疗之后（比如，3个月的体能）；例行的年度或者半年度体检。
敏捷项目度量也是。
第一种情况是项目在经历重大的事件之后，这里专指风险事件或者危机事件，团队需要集体反思、总结教训，这个时候项目需要做一次度量，找到那些把风险带给团队的指标，以此来寻找优化和解决问题的方法。
第二种情况是里程碑事件之后，或者一个关键的MVP 发布之后，团队积累了大量的经验，当然也有教训，这个时候也应该引入度量，评估一下和目标的差距，制定下个阶段的计划，带着经验继续优化和改进。
第三种情况就是周期性的度量，建议3-6个月，之所以选择这样一个周期，是因为少于3个月，很多持续性的行动还很难产出效果，长于6个月的话，某些行为具备了惯性，掉头的难度比较大，综合考虑，3-6个月是比较合适的周期，具体选择多长时间，由团队来决定。
一句话总结，敏捷项目除了例行的度量之外，在经历了大的危机、重大的里程碑事件之后也是执行度量、总结经验和教训来优化和改进的好时机。
有一句话是这样说的：“我们不能测量我们不能控制的东西”。敏捷度量亦是，敏捷度量无法帮助团队度量未知的东西，但如果团队想更好的了解自己和未知，或许它能够帮到你。
总结一下：敏捷不仅有度量，度量还是敏捷项目非常重要的一部分，但敏捷度量和传统的度量存在很大的区别，敏捷度量不是以评估和考核为目的的，它是为了帮助团队拉通目标和行动、指导指定工作计划和任务、协助团队持续改进而发生的。