这是鼎叔的第一百一十五篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社）。

前文聊聊效能度量的作弊经济学 ，列举了传统度量的问题和对于度量的种种误解，让我们结合敏捷理念的深入理解，看看该如何设计基于敏捷的度量指标体系。

敏捷度量体系的特质

面向敏捷团队，度量工作要能真正被支持，推动大家往前跑，其体系应该具备这样一些特质。

公开性和简洁性：在公开的区域，用醒目的格式，让大家一眼就看就清楚，字面意思能自解释，这样才能被所有成员关注。记忆负担和实施成本可以尽量下降。

有效性和可靠性：指标要有用，且在长时间内靠谱。当大家发现指标异常并采取行动时，如果有较大概率发现是误报，会打击大家关注这些指标的意愿。

优先全局指标：度量首先要聚焦在牵引全局成功的指标上。局部指标是当全局指标出现风险时，再进行拆解分析的。在项目整体视图中，避免过多的局部指标数据干扰成员的判断。

谁度量，谁受益：为了让度量投入能健康持续的进行，参与贡献数据的角色一定要有明确的收益，比如通过度量能提升自己的能力，能挖掘出自己的盲区，有利于获得更好的认可。如果参与度量只是为了让 QA 能完成汇报任务，甚至还会因为自己度量的数据被老板批评，这种体验是难以持续支撑度量效果的。

尽可能自动化度量：既然度量是长期持续的行为，且耗费成本，肯定应该尽量自动化进行。但是确实有一些关键指标的元数据不是自动产生的，可以依托众包平台或者问卷调研平台的录入数据，实现及时的自动呈现。

趋势可能比数值更重要：很多指标的动态趋势可能比静态数值更应该引起重视，对此工程师不应该只停留在对大小的监控预警，而是应该实现一定时间周期内的趋势（突增突降，连续多次增或降）监控预警。比如每日新报告缺陷的趋势，每日完成故事点数的趋势（燃尽图）。趋势图也能看出哪个测试阶段被 “卡” 住了，急需采取紧急动作。

实验性：既然敏捷的原则就是快速试错，不断改进。那么把度量指标认为是 “权威” 和 “必备的考核目标” 的看法，显然和敏捷原则背道而驰的。即使团队对度量指标的价值和定义达成了共识，也需要在实践中观察是否合理或精准。可以考虑对指标进行一段时期灰度实验或者 AB 测试，挑选出更符合团队实际情况的改进指南指标。

以上是度量指标本身应该具有的特性。

度量指标体系的分层

如果从整个度量指标的体系设计的内容分层来看，至上而下可以分为下面三个层次，围绕不同的层次和受众去呈现关键指标。

一 面向商业组织层面的度量

组织，尤其高级管理者，关注的是经营的成功，因此度量整体效益（利润和成本），规模增长速度，用户满意度和 NPS 指数，这几类指标一定是最重要的，代表团队现在是否健康，未来是否有更多商业机会，是否受市场欢迎。

针对组织的度量比较敏感，会受到组织结构和利益角色的挑战，应当基于高层的支持，聚焦在市场客观反馈的北极星指标（即唯一关键指标）。

二 面向具体产品层面的度量

这个层面的度量是关注具体产品项目交付的效益和口碑，是否达成既定目标。比如需求交付周期、发布频率、项目成本、产品体验关键指标、线上缺陷、投诉率和解决率等等。这个层面的度量指标需要产品人员和技术人员达成一致，共同关注，共同改进。

产品整体性度量指标最好能被进一步拆解，便于团队分模块识别可改进的抓手，同时避免遗漏。

对于不太熟悉的新产品或新价值领域，也可以先选取一个达成共识的单一重要指标，在深刻理解和应用之后，不断扩展指标的覆盖范围或相关类型。

三 面向研发能力层面的度量

这块通常是实时呈现的研发质量及效率指标，可以立刻采取具体的改进行动。比如日构建次数、单元测试通过率、接口测试覆盖率、App 崩溃率、首页流畅度等。

“效能” 和 “敏捷” 的定义

这些年来，很多公司言必称效能，但是大家对 “效能” 这个新词与 “敏捷” 这个老词的理解是含糊不清的，它们是同一个意思么？

本人拙见，敏捷是原则、价值观和方法论指导框架，效能是衡量研发产出效益的客观数据结果。敏捷是内功，效能是表象。正确坚定地实践敏捷方法，应该逐步带来效能的明显提升；但反之则不然，效能指标提升，不一定代表我们采纳了正确的敏捷措施，需要进一步分析。

软件交付的北极星指标

需求交付效能的提升，是由两个闭环驱动的。左环由产品团队主导，决定做什么，为什么做，为谁做。右环由开发团队主导，实现怎么做。（参考《持续交付 2.0》一书）

左环往往是更漫长的，它有大量的调查，实验，选择和决策过程。如果要驱动产品团队提高左环的效率，需要强化 “精益需求实践方法论，见聊聊精益需求管理（合辑共九篇）”，提升产品和研发的敏捷设计能力。

研发团队更多是主导右环的顺利交付。

之前几篇文章也提到过（聊聊需求的工作量估算），对于一个产研团队而言，最关键的北极星指标就是需求交付周期（Lean Time），从明确产品的用户需求，到代码最终发布到用户手上。

我们可以把完整的需求交付周期拆分为三个串行的阶段：需求设计阶段，需求研发阶段，需求上线阶段。

需求设计阶段。从用户需求明确，到产品需求规格明确（PRD）。
用户需求一个是来自于业务侧，一般通过 BRD 规格文档梳理。另一个是来自于产品团队或者技术团队，来源可以是用户反馈和竞争力发展。

需求研发阶段。需求评审 + 开发设计 + 开发编码 + 开发自测 + 需求测试在联调环境通过
需求评审环节建议在需求研发阶段度量，因为澄清需求工作量和发布内容的取舍，就能让迭代交付时间可控。

需求发布阶段。包括 UAT 测试验收 + 灰度 + 全量发布
在行业中，对于不需要正式 UAT，发布成本极低的产品，这个阶段如果耗时很小，则不需要专门度量。

其中，作为技术部门可控的需求交付周期，是需求研发&发布阶段的总周期。如果业务风险大，UAT 和发布成本高，发布阶段的耗时长，就需要专项优化。

行业敏捷团队的需求研发周期推荐指标是 28 天（阿里巴巴集团推荐值），即在 4 周一个迭代内完成。杰出团队平均能在 18 天完成需求研发。

为什么选择这个北极星指标？

因为需求交付周期决定了最终用户满意度，而且它可以驱动其他所有的效能指标。

只要交付快起来，需求就会被合理拆解，质量风险就会下降，自动化建设、工程成熟度就会提升，流程就会优化。

北极星指标就意味着只有一个指标，指引所有人。目前暂时也没看到更有说服力的单一指标可以替代北极星指标的位置。

结语

针对整个软件生命周期，鼎叔见过形形色色的度量指标 KPI，其中有不少是 “伪敏捷” 的，会让团队走向 “虚假繁荣”，对于 “短期成功” 的原因一知半解。有些指标是需要组合分析，才能识别风险究竟在哪里。

鼎叔认为，每个团队可以有自己的自主风格和不同成熟度阶段。过段时间，本公众号会结合个人心得，推荐一些敏捷团队可以好好挖掘的拆解指标。