下载掌阅APP，畅读海量书库
立即打开
研发的度量，不应该基于绩效处罚，阻碍创新，而是应该帮助团队自我改进，这需要各个关键角色的自发推动和积极支持。本章会从传统度量的局限性开始剖析，重点阐述如何基于敏捷设计度量指标，让质量管理者的工作更加适应敏捷研发，并借助敏捷度量体系高效推动团队的健康运作。
在传统技术行业，质量管理是一个专业的独立角色，它代表管理层，起到了重要的过程量化和纪律督促作用。但是在敏捷研发时代，专职的质量管理人员经常走到了研发效能的对立面，尽管做得很辛苦，但频频被吐槽，缺乏成就感。
一线质量管理者，在很多公司简称为QA（质量保障工程师），很多企业把测试工程师也统一称为QA，本书中的QA特指不进行测试技术实施的质量管理人员。质量管理和测试技术工程师本质上都属于质量角色，甚至可能来自同一个团队。
在研发规模比较庞大的组织中，专职QA通常承担了下列重要工作内容：
❑向技术高管汇报当期主要质量风险、质量数据趋势、质量改进措施的进展。
❑针对线上事故组织回溯，落实整改措施。宣导事故定级或纪律审计措施，公布奖惩结果。
❑年度质量规划，确认质量改进专题和落地到业务的责任人，确认考核指标，组织相应主题培训或部门宣导。
❑推动质量过程关键指标的量化和定期晾晒，对告警数据进行提醒。
我曾经长时间从事QA工作以及QA组的组建，也和行业中各知名公司的QA有过深入交流。在敏捷转型大潮下，我感觉QA的职业发展道路是容易迷失的，从业者普遍缺乏价值成就感。具体表现在以下几个困惑。
QA到底向谁负责
QA应该对技术高管负责，还是对一线团队负责？
很多情况下，QA被高管招聘进来的初衷是通过研发效率和质量数据的分析，及时暴露一线团队的风险短板，找到可以立即改进的切入点，同时能够建立上行下效的质量规范，定期自省。
但是，QA的日常工作模式是与一线成员沟通，甚至深入团队的关键会议中，分析问题案例并向上汇报。
一线团队出于本能是不希望暴露失误被高管批评的。而QA因人力非常有限（不承担具体技术实现工作，团队预算通常很少），不能紧跟一线项目，不太可能提前给出具体的预警建议，帮助团队尽早规避风险。与此同时，QA因为要提取考核数据和保障汇报材料的准确性，还会让一线团队投入一定的人力支持。时间一长，一线团队对QA的负面看法就会愈发明显，他们不能从支持工作中受益，还容易被高管批评（有时甚至会背锅），因此对QA的支持和评价就会逐步走低。
另一个维度，如果QA把主要精力投入到团队协同支援上，重视团队感受，那在高管眼里，可能就形成“质量规划和呈现能力不足”“不能暴露尖锐问题”的看法。
QA的推动成果（指标体系、流程规范），是促进了敏捷，还是阻碍了敏捷
QA的各项推动成果最终会通过监控指标体系、规范流程梳理、内部审计等方式固化下来，所谓“没有规矩，不能成方圆”。成果越宏大，度量管理成本越高。团队会因此产生什么变化？是真正降低了运营风险，还是研发氛围更保守，交付更低速了？
很多时候，员工评价是后者，运营事故还是会不断发生，但是团队为了质量规范达标，投入了相当多的“额外精力”。
我经历过这样一个敏捷项目转型案例，某研发团队自发启动敏捷变革（包含专业的DevOps平台建设），高管提出QA能加入协助，于是QA组就主导输出了一系列效能度量标准要求（非常庞大的指标体系，超过50项度量要求），强力推动该研发团队去落实。这本身就违反了敏捷原则，敏捷转型应该是团队自组织的，内驱改进现有问题，让交付更顺畅，而不是为了向高管汇报庞杂的标准化成果。这种规则强加式的安排，很容易引发研发团队的反感，最终影响转型目标的达成。
QA的工作，是否可以由自动化平台替代
强调技术驱动的团队，希望所有的过程质量和可预警的风险都能够通过工具平台自动化呈现和推动，这样效率确实是很高的。但是QA策划和汇报的质量体系的各个要素，不一定都能自动化获取，原因是有些要素需要主观综合判断，也有些要素需要人工录入元数据，为了达成向上汇报的要求，研发人员需要投入相当的人员精力，以满足质量分析的“准确”。
在这个越来越强调自动化质量治理的时代，QA对自身职业发展也产生了担忧。研发人员自主完善质量监控自动化，显然是更高效的，不需要咨询所谓“质量督导”角色。除非，QA有非常深厚的软件工程量化能力。
QA经常成为流程中尴尬的二传手角色
团队很容易默认QA是规范流程的协调制定者和守护者，所以一旦引入了新的流程，就习惯把QA纳入流程把关环节。QA莫名其妙成为流程中的审批者，却起不了特别作用。
实际上，QA人数通常非常少，不可能深入到每个项目的研发测试过程中，不具备对具体需求的质量风险判断力。强行放入一个把关角色反而会成为流程的瓶颈，导致拖沓。
优秀QA应该能制定出充分防范风险，同时让成本尽量低（简洁）的共识流程，并且自己要能脱离其中，参与到下一类急需改进的任务中。
在敏捷研发时代，QA会有这么多的郁闷和自我怀疑，本质上还是因为质量组织和质量观发生了显著的变化。
传统行业的质量管理源自20世纪初的 泰勒科学管理理论 ，当年这是提高生产效率的有效手段。它强调管理者事先做好计划，建立明确的量化的工作规范，开创了精细化管理的先河。传统行业会把质量控制作为一个独立于业务生产的关键部门，它和生产及销售同等重要，质量部门把计划和执行分离，对执行动作不规范的部门及人员进行偏惩罚性的纠正，因此质量人员普遍让人感觉缺乏建设性，“和生产人员不是一伙的”。
与之对应，敏捷研发的质量观推崇的是精益生产的质量管理模式，借鉴丰田公司的 TPS（丰田生产制度） 精髓，其本质是没有单独的质量组织， 整个组织就是质量组织 。每个人都要为整个生产线负责，一旦发生问题就要“ 拉绳 ”把流水线停下来，检查质量问题，立即改进。软件持续交付流水线就是参考这种模式。
严格管控规范的传统质量管理，对比敏捷精益的质量管理模式，体现在软件研发的质量文化上，会有什么鲜明的不同呢？
强调规范文档与弱化文档
传统QA管控团队的撒手锏就是一切用书面记录下来，强调规范化，带来的文档处理成本很高。而敏捷质量模式则是重沟通、轻文档。文档也可以是辅助交流的生动工具，但不会使用过于死板的形式。团队内部写文档更多是为了知识沉淀，在测试方面确保理解场景即可。只有要交付外部客户时才会对文档做规范处理。
严格约束角色的权限与高度信任的管理
因为质量管控的权力大，“以质量和安全为名”会给日常操作流程的成本层层加码，却没有人大胆做质量控制的减法。所以传统研发公司就会呈现出“缺乏信任”的氛围，很多并非那么保密的资料却要申请权限，对合作方员工防范严格，进一步造成协同办公的高成本，但少有人公开质疑这点。
敏捷团队应该拥有高度信任的氛围，设置规范的主要目的不是“限制权限”，而是鼓励明智地授权，让集体交付价值最大化，避免短期冲动冲破健康运营的“护栏”。
各司其职与One Team
传统的软件度量，因为是建立在“准确追责”的基础上，很容易导致各个角色只关注自己的分内之事，害怕被高管关注到“短板”。个体的聚焦反而暴露了团队缺乏互相补位的不足。遗漏到线上的事故，往往不是需求测试不充分，而是跨子领域的协同场景缺乏看护。
敏捷推崇的自组织形式就是One Team，这并不是要求人人都是全栈高手，而是指每个人不但擅长自己的专业领域，而且能在关键时刻互相补位提醒风险。One Team会带给成员更好的安全感，也会让团队成员更有勇气探索尝试。
红黑榜扣分与团队集体负责制
传统质量管控因为要强调令行禁止的纪律，会习惯性地建立惩罚型度量机制，比如红黑榜，出现一次跟进不及时，则扣除绩效分，多了会影响奖金回报。这种比较压抑的氛围在崇尚自主风格的新生代员工中不能起到提高效率的作用，反而会导致优秀人才的批量流失。
敏捷的One Team追求集体共担质量风险，形成内部公认的“纪律”。就算需要提醒负面现象，通常也是通过有趣的方式去“惩罚”，如站会迟到的处罚：俯卧撑、买下午茶、表演舞蹈等。
在回报激励上，One Team首先是看一线团队的整体交付价值大小来分配利益的，辅以成员间和客户的认可度评价，而对内部单一岗位的产出指标度量并不是给回报排序的决定因素。
威权管理者与仆从管理者
在传统质量管控的导向下，研发团队的经理会被强化威权，成为研发人员的“法官”。领导提出了技术意见或者不太合理的评价，员工通常不太敢反驳。这种氛围会导致研发风险被滞后发现，员工也不敢提出对现状的大胆变革，因为没有人保证发起变革就一定会有正向数据，甚至度量变革的指标还会在一段时间内明显下降。
曾有一个部门负责人对我说，“你看，部门有几百号人，如果我不能让大家聚焦在最核心目标的达成率上，那对公司而言是多大的资源浪费啊！”而我的回应则是，对于这么庞大的团队，如果以领导的意志为指挥棒，以死板的年初考核指标为准绳，那领导个人决策能力就会成为团队发展的瓶颈，这才会形成真正的浪费。人才因为不敢认领新的挑战而让自己的才能被埋没，从而大规模离职。
敏捷研发时代，谁能保证年初定的目标和考核指标到了年底还是最合理的？这本身就是违反敏捷价值观的做法。
敏捷价值观强调的是领导要么成为明智的干系人，在团队之外提供资源和建议，但领导的意见仅供团队参考，团队应该自主运作；要么成为团队的“ 仆从领导 ”，关心团队当前运作的主要困难，并第一时间寻求解决之道，为员工排忧解难。
质量至上与有损发布
在质量至上的“理所应当”之下，可能会掩盖研发行为的低效短板，容忍自动化技术停滞不前。比如，有一个VIP客户向手机测试领导反馈了一个第三方游戏的机型适配问题，后面制定的改进措施是人工测试员增加三倍，并覆盖五倍于目前适配测试覆盖的第三方游戏数量，以降低客户投诉率。这就是典型的不计成本的“提升质量”。平均每款游戏的测试力度是下降了，总成本支出却大涨了，这样真的能给公司带来质量团队的价值吗？显然不会，顾客不会为了手机适配测试买单，当市场经营形势不利时甚至可能带来“测试大裁员”。
总之，提升质量却不考虑成本，就是在“耍流氓”。我们首先需要看看哪些质量提升活动是值得投资的。
那“有损发布”又是什么概念？
既然敏捷研发的目的是尽快交付用户价值，我们就不能保证所有缺陷都消灭掉才能发布，团队应该集体决策，在发布时间（价值变现时刻）和品质满意度上取得平衡。
很多产品都会确立发布质量标准及衡量指标，但是这些标准不一定是基于用户价值视角的，而是依赖一定的专家经验。针对不同的产品发展阶段、不同的需求优先级，我们其实可以探索灵活的标准，在局部场景降低测试力度，或者允许产品带有一部分缺陷上线。如图4-1所示，比如创新型产品，我们允许其带有更多的非核心体验上线，试探市场的反应，迅速确定发力方向。
图4-1 产品特征四象限
如果核心产品到了关键发布期之前仍然遗留了较多的缺陷，那么我们应该集中力量处理必须修复的关键缺陷，这部分的质量标准不应降低。但是非关键缺陷在后期可以只记录不处理，以免在验证不充分的情形下引入更危险的新缺陷。
另外，我们也可以从不同产品的业务特征来看有损发布，例如：
❑ UGC类产品 ，对性能要求高，但是对准确性要求不高，发布质量的重点在于展示快，但是画面显示内容可以有一些问题（有损）。
❑ 电子商务产品 ，对页面响应性能要求也高，最终交易结果要让顾客满意，但是处理中间过程可以有一定的等待时间（有损）。
❑ 金融产品 ，处理响应速度可以稍慢（有损），但是展示的金额数据要与预期绝对一致，不能有差错。
我们继续聊聊为什么看着挺好的度量指标，在实际考核工程师绩效时常常起了负面效果？
从本能上，工程师会遵循经济学的规律。 没有任何一个单一简单的指标经得起各种推敲 ，聪明的工程师一定有办法把它变成“ 虚荣指标 ”——看着很好看，但是没有起到促进效益的作用。尤其当我们把度量指标和绩效挂钩时，它很容易被人扭曲成让人误导的解释，以便获得更多的利益。
下面是我经历过的几个因质量度量引发负面效果的例子。
考核测试工程师的缺陷定级准确性
某大型公司会严格考核工程师提交缺陷的级别准确性，背景是不同的缺陷级别的处理优先级不同，有限的开发人力只能在发布日之前保证处理一部分高级别缺陷。因此QA会对执行测试的初级工程师进行定级标准培训，并对其结果加以考核。如何判断定级是否准确呢？以开发人员在修复缺陷时的判断为主。
这个场景存在的问题是，虽然定级有指导模型，但是不同权重因素的交织（如影响用户范围、频率、营销里程碑，重复发生的情况，领导关注，品牌和安全等），使得总有部分缺陷的严重程度是无法达成共识的。从测试人员的角度（希望缺陷被修复）来看，希望采纳更高的定级规则；而从疲于修复缺陷的开发人员的角度来看，利用各种不可能被事先约定的理由来降低缺陷级别就成了更佳选择，尤其是有些缺陷不容易重现，开发人员就更有动力阻止缺陷的升级。
此外，如果定级被认为不准，会影响绩效，那么测试人员在看到一个疑似缺陷或难以复现的缺陷时，他会不会选择不提交数据库呢？当然是可能的，因为很难有确凿证据证明这是个明白无误的缺陷。更有甚者，开发人员会单方面解释这是“用户的误解”，产品就是这么设计的，解释一下就好了。定级准确率度量会进一步阻止测试人员据理力争和澄清到底的意愿。
度量各模块导致的事故数量和级别，并进行处罚
如果我们对一年来所有的线上事故进行盘点，按照引入故障的根因模块进行排序，会发现越是关键的中枢模块，排序越靠前。也就是说，如果按照事故引入数量和级别来处罚，那么越是公司的核心架构师，被处罚得越狠。
因为组织结构决定软件风险，核心的中枢模块往往会由最厉害的工程师来设计和维护，长此以往，只有他最精通这个超复杂模块的内部和关联模块的交互逻辑，也只有他能快速解决问题（当然这种状态对组织来说并不健康）。复杂业务逻辑链条和涉及大量模块调用的产品出故障的概率最高。因此，以故障数量和级别来处罚这个资深员工，显然是不合理的。
测试用例的自动化率
这也是技术部门最常见的考核指标，度量所有用例中实现了自动化的比率，确认考核结果的方式就是看自动化平台的指标呈现。
作为初期的自动化建设牵引，这个指标是有一定正向价值的，但是随着团队越来越成熟，这个指标的价值就不一定正向了。
本书一直在强调，自动化不是灵丹妙药，不是越多越好，而是看自动化的目的是什么，执行和维护的成本有多高。
现有的用例中，如果很多是面向用户验收的场景，可能随着产品变更而变化很大，是不是都要做成自动化并长期维护（矫正）呢？另外，越涉及完整交互链条和视觉验证的业务，自动化成本越高。何况很多老用例的设计都已经过时了，价值很低但是数量庞大，如果纳入自动化目标将得不偿失。
工程师有多种方法对自动化平台的指标进行突击，比如强行硬编码，或者在快考核时再录制修改脚本，这些自动化并不能在研发过程中起到持续保障作用。
通过用例发现的缺陷数量（或用例缺陷密度）
从强化用例设计的有效性来说，这个指标从表面上看是有积极作用的。但是关注用例的缺陷密度，有可能阻止测试人员动态地探索需求的边界，通过用例数量限制了思路发挥，得不偿失。
有些公司使用这个指标，更多是为了节省测试人力，希望降低用例数量后，能以更少的人力发现数量尽量多的缺陷，但是这是一厢情愿的想法，因为用例和缺陷之间没有等比例的关联度。从逻辑而言，历史重灾区（破旧功能模块）遗留的缺陷更多，但这个指标是否导致测试人员聚集于此，而忽视了“非高危模块”的风险呢？
同理，度量开发人员的“代码量”以及“代码缺陷密度”也有类似的负面效应，因为对代码量进行“注水”太容易了。建议用交付的故事价值点数除以投入周期来决定开发的人均交付价值大小。
综上所述，依赖度量指标考核工程师绩效经常很不靠谱，建议仅将指标作为某个客观事实，供管理者参考。
那什么样的数据更适合用来作为绩效参考呢？基于敏捷理念，我觉得这些反馈更有价值：特性交付的整体效果、质量评价、特性团队的评价、直属经理与之共事的评价、专业能力建设等。绩效管理要考虑的内容很多，本书就不再展开了。
我们即使有机会为真正拥抱敏捷的研发团队进行质量度量，而且被度量的人员也没有作弊行为，那设计出来的度量指标就一定满足预期效果吗？显然不是的，度量指标设计并不容易，经常会踩入一系列误区。
误区一 ，认为度量没有成本。
实际上，度量是有成本的，而且成本可能相当高，分析如下。
❑设计度量指标和评审指标的成本。别忘了，度量涉及项目越广，参与评审互动的人就越多，成本也就越高。
❑准确人工填写或者自动化实现采集指标的成本。
❑被度量的团队规模可能很大，相关的培训宣导、检查、分析、汇报的成本可能会很高。
正因为被卷入的人很多，涉及各团队的职责考察，如果度量指标容易被误解，还会带来一系列解释和争论成本。
误区二 ，度量是QA部门的事，其他角色配合提供数据就好。
基于敏捷原则，质量度量不是专属QA的职责，而是项目全员的职责。
曾经有测试团队希望招聘一个专职的初级QA，接手大量缺陷的具体分析，输出改进计划，这样测试人员就可以专心做测试任务了。本质上，这是违背质量内建要义的。产生该缺陷的开发人员以及发现该缺陷的测试人员，是最应该从缺陷剖析中受益的，感受也最深，而不是接受外部新手的事后分析观点。其他度量指标场景也是类似道理。
项目成员如果坚持认为度量动作与自己无关，必然导致质量改进的措施难以落地。
误区三 ，度量通常会关联处罚。
上节也提到，度量应该就事论事，提醒当事人深入分析，有则改之，不应该直接得出对人的批评结论。如果一说度量就联想到处罚，会让大家消极对待度量，并掩饰不良数据的后果。
误区四 ，既要传统的质量度量体系，也要实施敏捷度量。
传统的严格管控型度量体系会产生越来越多的考核指标，但是很多指标并不能鼓励敏捷提效。有些团队因为被传统度量考核的负担压制久了，失去了挖掘新的减负“指示器”的勇气。
既然我们决定轻装上阵，那应当暂时放下习以为常的指标，重新思考哪些指标真正能促进产品尽早、小批量地交付给用户。度量不是工作的目标，而是改进工作的参考指南。
4.1节列举了传统度量的问题和对于度量的种种误解，在本节，我们将结合敏捷理念的深入理解，看看应该如何设计基于敏捷的度量指标体系。
面向敏捷团队，度量工作要能真正被支持，推动大家往前跑，其体系应该具备这样一些特质。
公开性和简洁性： 在公开的区域，用醒目的格式，让大家一眼就看清楚，字面意思能自解释，这样才能被所有成员关注。尽量减小记忆负担和实施成本。
有效性和可靠性： 指标要有用，且在长时间内靠谱。当大家发现指标异常并采取行动时，如果有较大概率发现是误报，会打击大家关注这些指标的意愿。
优先全局指标： 度量首先要聚焦在牵引全局成功的指标上。局部指标是当全局指标出现风险时，再进行拆解分析的。在项目整体视图中，要避免过多的局部指标数据干扰成员的判断。
谁度量，谁受益： 为了让度量投入能健康持续地进行，参与贡献数据的角色一定要有明确的收益，比如通过度量能提升自己的能力，能挖掘出自己的盲区，有利于获得更好的认可。如果参与度量只是为了让QA完成汇报任务，甚至还会因为自己度量的数据被老板批评，这种体验是难以持续支撑度量效果的。
尽可能自动化度量： 既然度量是长期持续的行为，且耗费成本，肯定应该尽量自动化进行。但是确实有一些关键指标的元数据不是自动产生的，此时可以依托众包平台或者问卷调研平台的录入数据，实现及时自动呈现。
趋势可能比数值更重要： 很多指标的动态趋势可能比静态数值更应该引起重视，对此工程师不应该只停留在对数值大小的监控预警，而是应该关注一定时间周期内的趋势（突增突降，连续多次增或降）监控预警。比如每日新报告缺陷的趋势，每日完成故事点数的趋势（燃尽图）。趋势图也能反映哪个测试阶段被“卡”住了，急需采取紧急动作。
实验性： 既然敏捷原则就是快速试错，不断改进。那么把度量指标认为是“权威”和“必备的考核目标”的看法，显然与敏捷原则背道而驰。即使团队对度量指标的价值和定义达成了共识，也需要在实践中观察是否合理或精准。可以考虑对指标进行一段时期灰度实验或者AB测试，挑选出更符合团队实际情况的改进指南指标。
以上是度量指标本身应该具有的特性，如果从整个度量指标的体系设计的内容分层来看，自上而下可以分为下面三个层次，围绕不同的层次和受众去呈现关键指标。
1） 面向商业组织层面的度量。
组织，尤其高级管理者，关注的是经营的成功，因此度量整体效益（利润和成本）、规模增长速度、用户满意度和NPS指数这几类指标一定是最重要的，代表团队现在是否健康，未来是否有更多商业机会，是否受市场欢迎。
针对组织的度量比较敏感，会受到组织结构和利益角色的挑战，应当基于高层的支持，聚焦在市场客观反馈的北极星指标（唯一关键指标）。
2） 面向具体产品层面的度量。
这个层面的度量是关注具体产品项目交付的效益和口碑，是否达成既定目标。比如需求交付周期、发布频率、项目成本、产品体验关键指标、线上缺陷、投诉率和解决率等。这个层面的度量指标需要产品人员和技术人员达成一致，共同关注，共同改进。
产品整体性度量指标最好能被进一步拆解，便于团队分模块识别可改进的抓手，同时避免遗漏。
对于不太熟悉的新产品或新价值领域，也可以先选取一个达成共识的单一重要指标，在深刻理解和应用之后，再不断扩展指标的覆盖范围或相关类型。
3） 面向研发能力层面的度量。
这个层面的度量通常是实时呈现的研发质量及效率指标，可以立刻采取具体的改进行动。比如日构建次数、单元测试通过率、接口测试覆盖率、App崩溃率、首页流畅度等。
这些年来，很多公司言必称效能，但是大家对“效能”这个新词与“敏捷”这个老词的理解是含糊不清的，它们是同一个意思吗？
本人拙见，敏捷是原则、价值观和方法论指导框架，效能是衡量研发产出效益的客观数据结果。敏捷是内功，效能是表象。正确坚定地实践敏捷方法，应该逐步带来效能的明显提升；但反之则不然，效能指标提升，不一定代表我们采纳了正确的敏捷措施，需要进一步分析。
针对整个软件生命周期，我见过形形色色的度量指标KPI，其中有不少是“伪敏捷”的，会让团队走向“虚假繁荣”，对于“短期成功”的原因一知半解。有些指标是需要组合分析才能识别风险究竟在哪里的。
本节不会给出整个生命周期推荐的完整指标清单，每个团队可以有自己的自主风格和不同成熟度阶段，但是我会结合个人心得，推荐一些追求敏捷的团队可以好好挖掘的指标。
需求分析阶段
基于第3章测试左移到需求阶段的知识，我们如何通过度量手段，保障高效的需求分析措施顺利落地？
完成需求评审后，推荐在研发管理平台录入以下度量指标，以便团队迭代回顾和改进。
❑ 需求评审的问题拦截数或拦截率 （需求评审阶段发现的问题，占整个研发周期发现问题的比重）：在需求研讨阶段发现的问题越多越好，这意味着大量的无效开发和测试会被节省下来，也标志着技术和产品的研讨是非常高效的。
❑ 需求验收测试用例数和覆盖率 ：在需求评审阶段，如果团队对每个需求都明确了验收标准和合适数量的验收用例，就对驱动开发进行高质量的代码实践提供了保障（这个保障在团队中已达成共识），避免了开发目标跑偏，同时保障了交付的最基本质量。既然有验收测试用例，证明需求的可测性就不是问题。
❑ 需求平均大小（颗粒度） ：每个需求的平均大小（故事点）处于合适的值，按照经验，小批量需求的平均开发量为2～3人天，测试验证就会非常及时。
❑ 需求评审效率 ，即 需求开发预估时长/需求评审时长 。注意，效率太高或太低都不是好事，都值得改进。如果太高，可能反映了需求评审会的讨论不充分，有悖于“磨刀不误砍柴工”的质量左移原则。如果太低，可能反映了需求逻辑没有经过事先的充分思考，需要先小范围交流和打磨，再进入团队集体评审，节约团队时间。相似的指标还有需求评审通过率，我们同样不追求需求评审要一次通过，而是更多地关注需求评审不通过的原因是不是缺乏可测性描述。
❑ 需求文档完整度 。我们可以在需求规格文档（PRD）的模板中加入“可测性分析”需要的关键技术信息（具体可以参考第8章），这样有利于开发和测试人员提高设计质量，尽可能减少后期返工和浪费。因此技术团队可以针对关键信息的缺失来给出PRD的“完整度”分数，常见的关键信息有需求背景，市场和竞品分析，业务目标/价值，业务流程图，需求功能清单和描述，性能/安全/数据要求，对外依赖关系，需求限制说明，等等。
注意，敏捷不追求重文档，对于大家都清楚的信息，即使PRD文档没有说明，也可以认为是完整的。
开发设计与编码阶段
开发团队的管理者理应重视工程实践中的质量和速度，尽可能降低工程师操作的烦琐程度，提高编码阶段和单元测试阶段的发现问题的效率，尽可能让工程师处于“心流”之中（即沉浸式研发）。那么如下的指标就凸显了其重要性。
❑ 开发中断时长和次数 ：在整个开发周期，开发被迭代无关事项打扰的次数和时间。管理者或者教练应该尽可能让开发有持续的思考和编码时间，进入高效率的工作状态。
❑ 需求测试验收一次通过率 ：有多少个需求开发提测后，是一次性通过测试的？这个比例越高，说明开发和测试互相流转缺陷状态和回归任务的消耗成本越低，也说明开发侧质量很靠谱。
❑ 单元测试代码覆盖率 ：对于单测，应该追求核心代码的被覆盖率达到一定比例，新增和存量覆盖率可以有一定差别，比如增量代码覆盖率在80%以上，存量代码覆盖率在50%以上（仅供参考）。此外，持续测试中的单测通过率应该要求90%以上甚至100%。
❑ 代码评审通过率 ：默认提交主干的代码都需要通过代码评审，有明确的签署人，评审改进意见入库。代码评审的基础除了要求大家对业务有深刻理解，也需要大家对代码规范达成共识，这一方面QA可以做较多的推动培训和审计工作。
❑ 代码扫描阻塞（Block）问题数量及解决率 ：针对有效的代码扫描问题（非误报），开发团队可以设置门禁规则，提高扫描出阻塞型问题的解决率，追求尽量短的处理时长，避免人员经常忽视，导致技术债越来越多。相似的指标还有代码扫描重要（Major）问题的数量及解决率。
❑ 代码圈复杂度和代码重复率 ：这两项指标是比较简单、直接的可改进项，代码圈复杂度会带来可测性的极速下降，以及逻辑理解难度的快速增加，相对于代码缺陷密度更有指向性。代码缺陷密度和测试能力及业务结构都有密切关系，难以横向对比判断。代码重复率说明代码重构方面存在不足，可以借此进行简洁代码的改造。
❑ 崩溃（Crash）率和ANR（Application Not Responding，应用响应超时）率 ：挑选这两个质量指标作为开发改进的重点，原因是它们具有通用性（所有业务都不能容忍这个值过大），明示了代码质量的严重显性问题（用户的感知非常强烈），自动监控工具和分析定位工具也高度成熟。从经验上说，开发团队的基础素养可以在对崩溃率的修复态度上体现出来。
❑ 联调人力成本 ：如第3章所述，如果接口定义和异常设计的水平高，联调的成本就会大幅下降。对于复杂的软件系统，调用链路的长度、跨域响应的数量、基础服务的稳定性、单个微服务的质量，都会影响联调的成本。因此，缩短该成本的努力，也是完善架构设计细节的过程，其回报也是值得的。
测试阶段
测试管理者首先要关注测试环境的可用性，方便、稳定、随时可以进入测试，其次要关注自动化框架的强大整合能力，对于手工测试的提效和复盘也不可或缺。敏捷测试需要的“测试左移”实践则是管理者应该修炼的方向。下面这些关键指标有利于测试管理者始终把控关注重心。
❑ 测试环境准备时长和测试环境恢复时长 ：测试环境是阻碍测试效率提升的老大难问题，耗时多的地方有两个，一是环境准备时间通常很烦人，耗时占比惊人，二是环境不稳定，经常需要停下来重启或者寻找故障所在。如果这类度量数据总是不理想，技术团队就需要停下来进行专项治理了。高效能团队的环境的分配、准备和恢复都应该是高度自动化的，不需要使用者操心。
❑ 重复执行手工用例占比 ：虽然我们并不追求测试自动化率越高越好，但是手工测试的“完全”重复执行是值得警惕的效能洼地。当我们识别出这一块用例集后，就需要思考自动化它们的成本是否值得，未来是否仍然会频繁地执行它（比如用例场景是否高度确定）。
❑ 测试独占周期 ：有些公司把这个指标定义为从开发提测到收到首次测试完成报告的时间。还有些公司把它定义为从开发提测到测试阶段彻底完成的时间。不管如何定义，这个时间都指示了测试阶段应如何缩短开发人员的“反馈”周期，也驱动测试人员尽量“左移”质量准备工作，并充分利用好自动化工具。从经验上判断，如果迭代中的测试独占时间超过了开发独占时间的一半，那我们就需要关注哪些环节存在效率改进或“左移”的空间，比如测试设计耗时过长，或者多种测试任务可以并行。
❑ 系统测试缺陷占比 ：系统测试是迭代用户故事均完成测试后，整个产品进行的全面测试，以通过上线前的所有质量保障环节。如果每个用户故事都提前进行了充分测试和修复，到系统测试阶段能发现的问题就会大幅下降。显然，这个比例越低，产品发布的风险就越低，测试左移就越成功。当然，我们也可以只度量严重级别以上的缺陷。我看到不少公司都用系统测试缺陷总数来考核测试人员绩效，发现缺陷越多，绩效越高，这显然是违反敏捷价值观的。
❑ 平均缺陷发现耗时 ：缺陷被发现的时间减去缺陷被引入的时间，缺陷发现时间越短，说明测试敏捷度越高，左移效果越佳。从这个耗时分析“为什么问题没有被尽早发现”，可以提炼出不少针对性的敏捷改善动作。同理，还有 平均缺陷解决耗时 （从缺陷报告到缺陷确认修复的时间）可以用来推动开发人员提高解决问题的速度。缺陷的整个生命周期在研发管理系统中都有状态变更的时间记录，只要及时更新状态，我们就可以审视这个最关键质量处理过程的效率。
❑ 版本遗留缺陷DI值 ：完成测试时，还有多少有效缺陷没有被修复，DI值是否可控（即缺陷按优先级加权后的总数，比如阻塞缺陷算10分，严重缺陷算3分，普通缺陷算1分，轻微缺陷算0.1分）。正常情况下，阻塞缺陷只有被修复或者被缓解（即部分修复以致降低严重等级），才能进入待发布阶段。
迭代整体指标
敏捷研发以迭代为周期进行，我们可以根据业务形态和发布成本，决定是只完成用户故事，还是将其发布上线。因此，从迭代的角度来看效能指标，可以重点关注下面这些内容。
❑ 迭代实际交付需求总点数和偏差率 ：迭代完成的所有需求的点数大小，与迭代计划评审时估算的本迭代应完成故事点数进行对比，看看有多少需求没能完成。分析没有完成的原因，以及团队估算在哪里出现了误判。
❑ 迭代无关活动时长占比 ：回顾本迭代中，哪些活动是和迭代计划需求无关的，一定比例内是正常的，总有一些外部事件要处理，但是活动占比高的话可以分析其“干扰”所在。敏捷研发的要求是每个人的工作应专注在特性团队内。
❑ 迭代等待时长 ：可以拆解为需求待评审时长、需求（已完成评审）待开发时长、需求（已完成单元测试）待联调时长、需求（已完成联调和开发自测）待测试时长、需求（已完成测试）待发布时长。如果能够度量出各个阶段的“等待”时长，就可以知道哪里存在拖延的现象，进而针对性地进行优化。
❑ 持续部署效率（耗时和成功率） ：为了确保迭代成果能随时可测或可发布，就需要将其（联同配置脚本）自动化部署到测试环境、预发布环境或正式环境。关注部署自动化流水线的效率，解决部署过程中出现的阻塞错误，可以保障研发迭代的交付效率。
发布和运营阶段
在发布和运营阶段出现任何问题时，应对法则都是“唯快不破”，尽量预防故障，尽早识别故障，尽快恢复服务，降低损失。以下指标是关键的指示器。
❑ MTBF（Mean Time Between Failure） ：让连续稳定工作时间最大化。
❑ MTTR（Mean Time To Recover） ：让故障恢复时间最小化。
❑ 发布活动健康指标 ，包括：
■发布频率是否健康，发布成功的频率应该符合应对市场竞争的预期。
■发布异常次数和发布回滚次数，分析异常原因和改进措施，这个考核指标非常关键。
■发布过程耗时，这个耗时应尽可能缩短，以降低发布成本。
■灰度发布相关指标，如是否满足灰度计划，及时发布到了正确的灰度用户范围，采集到了反馈数据。
❑ 故障响应时间：针对线上故障的应急响应能力，是否达到标准要求。
❑ 业务线上监控指标 ：针对业务的每个核心服务，都可以监控调用总量、调用成功率、QPS。针对调用异常情况，可以进一步监控错误码Top N ，围绕主要错误发生的数量和频率发起告警和处理。围绕业务健康度的核心指标，可以放到线上监控的实时仪表盘上，如订单量和交易金额，以便团队可以共同关注业务的异常波动。关键数据（尤其是资金数据）正确性监控，其重要性不亚于核心服务健康度的监控。
最后，当需求真正发布上线后，我们如何通过复盘度量需求是否达成设计预期？
我们可以定期组织对已上线需求进行复盘，在研发管理系统中及时填入相应度量数据（推荐如下指标），方便团队对需求“是否实现了预期目标（价值）”进行反思和改进，SM、PO和技术负责人都应参加。
❑ 需求交付时长 。这是团队收到用户需求到交付用户需求的总耗时，也是产品的效能“北极星”指标。可以拆解一下，需求交付时长=需求分析时长+需求开发时长（包括开发、测试、部署上线等阶段），团队通过复盘分析，可以判断具体哪一个子阶段的耗时过高。
❑ 需求复盘率 ，即进行了复盘分析的需求占所有发布需求的比例。因为需求的来源类型多样，很多小体验需求和缺陷修复等变更不需要投入太多复盘精力，但是复盘率体现了我们愿意投入多少精力进行需求目标闭环的改进。
❑ 需求目标达成率 ，复盘时给出是否达成预期目标的定论，针对未达成目标的需求进行进一步反思，未来如何改进。预期目标可以强制要求在核心需求的PRD中给出SMART的描述，包括上线时间、衡量什么业务数据，以及何时衡量。
第1章提到了对测试团队的自我诊断，本章前面的内容都是从项目敏捷维度来度量的，那如何针对团队整体敏捷状态进行更精准的评估呢？只有找准团队敏捷短板的指示器，才能找对自我提升的好策略，持续实施正确的敏捷动作。
这里先介绍一下敏捷成熟度模型（Agile Maturity Model，AMM），它是由ThoughtWorks公司提出的一套评估组织现状、设定改进目标、监控持续改进和度量敏捷成效的模型。该模型分为6个度量维度，即需求、测试、代码集体所有、协作、保障和治理、简单性，给每个维度的可观察现象或行为进行打分，用雷达图等方式可视化呈现。
敏捷成熟度模型是团队的一面镜子，用于评估和识别团队当前的优劣势。围绕设定的敏捷成熟度目标设立基线，定制适合本团队敏捷现状的可视化仪表盘，帮助大家聚焦迭代改进的路径，最终目的是培养出一个能自组织提高效能的团队，同时打造出有竞争力的产品。
敏捷成熟度模型以团队为核心来整体评估现状，关注三个视角 ——管理、产品和技术 ，评估结果可以分为五个级别。
❑入门级：团队刚刚接触敏捷理论，实践动作不规范，团队有指定角色，但还处于磨合中。
❑基础级：团队已有了良好的迭代节奏，能够在完成每个迭代的过程中通过回顾，持续微改进。
❑规范级：团队已掌握了基础的完整敏捷实践理论（在产品、技术和管理层面），能在实践中保持严格的敏捷纪律，有稳定的持续交付节奏。
❑成熟级：团队敏捷过程已经非常成熟，能够良好地响应各种市场变化和用户变化。
❑卓越级：团队有能力发明新的技术和实践，解决各种未曾遇到过的阻碍和低效难题。
整个敏捷成熟度的可调查问题众多，大部分要点在前面各章的敏捷关注中都有相关阐述，对应每个级别都有相应的评分区间，便于单项打分，最后汇总分数判断团队的整体敏捷度级别。
对于“是否一贯做到”的行为调查类型，可以按频率来选择答案，比如一贯如此（90%以上场合能做到），经常（60%～90%场合做到），有时（30%～60%场合做到），很少（30%以下）；也可以由团队具体定义不同级别应匹配的行为频率。
本书尽量少给具体的定级数字，以免被读者当成行业共识的衡量方案。不同团队有不同的业务类型、发展阶段和文化特征，会导致其优先采纳的敏捷措施差异很大。
下面尝试从这三个视角提供系列调查问题，让读者有一个整体印象，这些问题也是对本书前几章知识的精华回顾。读者可以参考它们来制定团队自己的成熟度调查问卷，也可以针对局部敏捷实践范围进行成熟度的度量改进，牵引出下一阶段如何提升的具体路径。但要避免僵化的指标考核，避免它成为团队间绩效比拼的工具。在第15章我们还会呈现这套思路，分别针对工程效能和精益需求设计来设计更具体、更聚焦的成熟度调查问卷。
管理视角评估的敏捷成熟度体现在 自治理团队、沟通协同、快速响应 等方面。推荐的评估问题有：
❑是否具备跨职能的全功能特性团队（产品、开发、测试等），所有人是否全职参与迭代？全功能特性团队的规模是多少？推荐7～11人作为最佳规模。
❑团队所有成员是否随时可以顺畅交流？能否随时面对面交流，是否因为异地办公导致内部问题响应不及时？
❑团队和产品经理能否遵循迭代日历节奏，按时完整地进行各项关键迭代活动？每个特性团队是否有制定合理的迭代日历？迭代周期是否在2～4周内，且能固定保持？
❑团队各种会议是否富有成效，议程准备充分且聚焦，不拖堂，参与度积极？是否总是有清晰的会议纪要，达成指导下一步行动的成果。
❑团队各个角色的业务目标是否一致，每个迭代的目标是否明确，能否共担责任？团队是否承诺共同为质量负责，而不是个人对问题负责？
❑团队是否有效利用了看板机制，把各种管理信息透明化，能随时检视和调整？包括产品规划路线图、发版计划、迭代风险和改进事项。SM是否在站会后更新了看板信息，记录了阻碍和风险，并在会后对其跟进，确保阻碍被移除？
❑团队是否共同估算工作量大小并承诺迭代工作范围，不会受到领导或外部专家的影响？团队根据自身实际情况和历史迭代速率制定可行的迭代计划，能否做到既不过度承诺，又不过于保守？团队是否已经形成持续改进的文化，制定了切实可行的改进措施，并明确了关键责任人？
❑团队的人员稳定性是否良好？团队的氛围是否灵活且积极，能够应对外部冲突？每个成员能否感受到自己的工作是有价值的，内部满意度高？
❑对于大型团队（由多个敏捷特性团队组成），是否存在高效机制（如Scrum of Scrums）在多个团队中例行协调，保证干系人参加，成功管理关联特性的依赖和风险，对齐发布计划并成功实施？
❑特性团队或大型敏捷团队是否有例行的交流分享，及时传播重要的经验教训（每两周至少分享一次）？有价值的信息（产品、技术、过程等）能否及时有效地沉淀下来，而不是靠口头交流，成员获取信息非常方便？团队是否及时运用项目协作工具，准确更新项目信息？
❑团队是否有明确的DoR、DoD定义并形成共识？产品需求进入迭代开发之前是否满足了DoR？迭代内所有计划应完成的故事（考虑风险影响因素之后）是否都能达到DoD（通过了集成和验收测试）？
❑团队能否有意识地控制每个成员的并行工作量，避免频繁在多个任务中切换？
产品视角评估的敏捷成熟度体现在 关注用户、价值驱动、可持续发展 等方面。推荐的评估问题有：
❑产品人员是否准时参加团队敏捷实践活动，例如需求梳理会议、站会、桌面检查、迭代结果演示和迭代回顾会议等？
❑产品经理是否通过用户故事的形式来定义需求，并给出详细的验收标准？用户故事是否总是符合INVEST原则？团队是否能清晰呈现用户使用产品的历程（比如使用故事地图等方式），让业务和开发对需求场景的理解能够准确对齐？
❑产品团队是否维护并及时更新了所有未完成工作的产品待办清单？其中包含新特性、优化特性、遗留缺陷和技术类故事等工作，并全部进行了排序。清单上的事项是否具备“越近越细，越远越粗”的特性？
❑近期的用户故事是否都已经拆分到了适合迭代开发的颗粒度（5人天以内）？
❑产品设计是否为涉及界面的功能准备了原型（DoR的条件之一）？原型验证阶段是否引入典型用户参与，获得真实可信的反馈？
❑团队能否在迭代中尽早将完成的故事展示给产品经理和干系人（尤其是客户），搜集反馈并进行调整。
❑新版本软件的发布周期是多久（从进入需求到全量发布）？
❑团队能否持续围绕产品愿景和目标，关注市场和竞品的情况？整个团队成员是否被清晰地传达了产品的愿景和可量化的目标？持续将洞察结果转化到产品规划和设计中，基于可量化的成功衡量标准进行监控并形成提升闭环，则可以获得高分评价。
❑团队是否已对目标用户进行清晰的分类和画像，对用户行为进行系统理解，针对其特征进行针对性的需求分析？能够具体阐述清楚服务对象和场景化的用户旅程，描述如何解决他们的诉求，能带来什么收益，并在整个研发工作中进行关联考虑，则可以获得高分评价。
❑团队是否会通过定性研究识别机会点以及背后的动机，将洞察结果注入产品改造过程中？是否会通过定量研究，通过采集用户行为和反馈数据，为产品假设提供数据论证，以便调整后继发展策略？
❑团队是否有完整的需求价值评估维度，能进行合理的需求拆解和优先级综合排序？对新需求是否有清晰的MVP定义和发布规划，能够及早验证想法？
❑团队是否整合了内外部所有的用户反馈渠道，且触达最终用户的成本足够低？能否尽早审核用户反馈并正确分类，将反馈数据的处理过程形成高效闭环？
技术视角评估的敏捷成熟度体现在 设计简单、持续交付、质量保障 等方面。推荐的评估问题有：
❑是否存在知识和技能的单点瓶颈（即缺乏其他人备份）？团队各个职能可以互相备份技能，不会因为人员缺席导致进度被阻塞。
❑TL和团队是否针对所有技术故事的验收标准达成一致？应完整覆盖业务关心的功能、非功能性需求、业务规则和范围。
❑在实际编码之前，测试人员是否已经完成对完整测试场景的第一轮分析和设计？测试人员是否与开发人员对用户故事的测试场景达成了共识，避免理解歧义导致的返工？
❑开发人员在转测试之前，是否已给测试以及产品人员进行了当面演示（按照验收标准和验收测试场景）？
❑团队是否建立了例行的代码评审机制，并保证评审发现的问题能修复？最好的情况是，每天都有例行代码评审，但花费时间可控（1h以内）。记录内容以共享知识为主，且记录的问题能回溯。
❑团队是否有经验丰富的架构师或者技术负责人作为特性团队的成员，参加团队关键研发活动，传递技术经验，并独立交付任务？包括贡献核心代码及评审把关，识别技术债务，优化测试策略，跟踪质量内建指标，推广合适的前沿技术，在技术风险和方案落实上和PO达成一致计划。如果架构师把精力过多投入到其他工作（人员管理、任务分工、非技术会议等），则评分会降低。架构师在代码方面的贡献应包括框架搭建或引入、技术难点攻关、核心业务逻辑实现、代码简洁化封装和风格一致化。
❑团队是否在新特性进入开发之前就完成了技术方案的概要设计？概要设计评审重点关注外部依赖、组件模型、数据结构和性能等因素，尽早识别技术风险。所有故事都能确认技术方案并归档。
❑产品与外部相关系统的依赖关系梳理完毕，能够独立编译、测试和升级。相关系统包括后台相关服务、第三方接口、调用公共框架和公共组件等。
❑配置管理是否统一，包括被测应用代码、单元测试、自动化测试脚本、数据库操作脚本和环境自动配置脚本，均存放在统一源代码库中？存放的目录应合理，保证一次性成功提交。
敏捷团队从转型初始期到完全成熟期的发展并不是一蹴而就的。除了理解成熟度评估指标，敏捷团队也要分阶段把控提升的侧重点，逐步向高成熟度靠拢。
那么，在不同的发展阶段，敏捷转型应该关注的达成状态应该是什么样子？为此，我们应该做到的最重要的事情有哪几件？我们简单划分为三个阶段来阐述。
第一阶段，敏捷准备期（迭代1正式开始之前）
在敏捷真正启动运作之前，务必要关注这几件准备事项的落实：
❑划分好特性团队，规模适中，明确全职角色，尤其是铁三角（PO、SM、TL）的人员。
❑完成团队的敏捷基础知识和流程的导入培训。
❑PO和TL带领团队清晰同步产品的愿景和中长期目标，梳理本产品和基础系统或其他产品的依赖关系，以及可能的重大风险。
❑团队协同工作的相关工具、平台、物资到位，比如研发全生命周期的工作平台和数据看板、知识库、物理看板、团队公共空间的各种信息布置等。
❑通过对历史的回顾，盘点之前的主要问题，明确可落实的改进行动项。
❑团队共创协同工作的准则，包括DoR、DoD规则，准入准出流程规则等。
第二阶段，敏捷启动初期（迭代1开始的多个迭代，时间约3 ～ 6个月）
正式启动的前期，目标是确保团队运作的规则形成，逐步养成迭代中的好习惯。
❑基于产品愿景，PO给出未来半年的路线图，包括里程碑。团队充分理解后，确认未来几个月的迭代交付和发布计划，保障交付效果可量化。
❑PO创建了产品待办事项，整体梳理了产品需求列表，与团队进行了优先级排期和细化。TL也带团队梳理了能支撑技术架构和预研的技术故事。
❑迭代目标清晰，能够成功发布1～2个MVP版本，尽早验收价值。
❑基本测试策略和质量基线明确，并能逐步按计划落实单元测试和自动化测试等。
❑针对团队情况，确认代码管理和分支策略，成功搭建持续集成流水线。
❑团队搭建了适合自己的可视化看板，建立了关键指标度量的仪表盘。
❑每次发布后能梳理分析遗留Bug并制定修复计划，也梳理了技术债偿还计划。
❑能高效进行每日站会，能让工作项及时流动。
第三阶段，敏捷稳定成熟期（6个月以后）
敏捷运行稳定，开始逐步向着更高效、更成熟的组织形态稳步迈进。
❑形成稳定的发版节奏，团队对迭代速率的预测准确，验收标准严格落实。
❑定期更新团队学习成长计划，每个迭代结束都能做真诚的自我剖析，并准确找到下一阶段的改进痛点。团队能够形成产品业务全面视图，及时更新知识共享库。
❑所有用户故事都能进行充分的质量内建活动。需求颗粒度大小适中且流转顺利。
❑交付过程中的阻碍风险能够在极短时间被识别和处理。
❑干系人可以通过看板准确获取团队所有关键信息。团队成员能够被持续激励，主动协作。
本章从质量保障工程师的困惑说起。传统研发度量体系一直有比较大的局限性，在敏捷团队中推动度量常常缺乏成就感。质量控制如果作为独立处罚型部门，难以产生推动质量内建的文化。基于敏捷价值观，我们需要重新梳理敏捷度量指标的价值牵引，警惕伪敏捷的虚假繁荣因素，让投入敏捷度量的成员能够真正获益。本章也推荐了整个研发生命周期各阶段的核心敏捷度量指标，介绍了基于团队敏捷成熟度模型的评估方案，从管理、技术和产品三个维度梳理出敏捷要点进行问卷评分，但每个团队还是应该根据自己的敏捷阶段和现状挑选合适的驱动指标。
看完了本章的论述，QA可能还是会困惑，未来自己的具体工作风格该如何转变，以满足敏捷团队日益发展的需求，避免成为不大受成员欢迎的“监工”？难道自己的价值就是输出一系列度量指标并给出度量治理报告吗？
不用担心，本书第15章会给出思考的答案。