度量这个话题很早就想写点什么，但这个话题非常庞大总是觉得自己对它思考的不够深入，直到最近参与了几个与度量有关的事，一边做一边思考之后有了不少新的想法觉得可以拿出来和大家一起探讨一下，所以今天这篇文章我们就围绕度量展开，特别是在基层组织中如何进行度量以及如何让度量变得更有意义。
苟日新，日日新，又日新
先从一个老生常谈的问题开始，我们为什么要做度量？如果在基层组织中进行调查，通常这个问题会得到下面类似的答案：
- 不知道有啥用，但是上级要求我整理的，我就整理呗，反正是给上级看的；
- 想关注一些数据，特别想知道大家都是怎么工作的，了解一下数据代表的当前水平能不能达到规范要求，展示出来就有压力；
- 有了数据积累就能分析改进的有效或成长的发生，数据中蕴藏了无限的可能性；
这三种回答实际上没有对错，只是反映了度量不同认识的阶段而已。我们都知道数据可以定量地说明事物的状态并且能够在某种程度上预测事物的变化，但关键在于什么样的数据才能真实地反映事物的特征，因而当我们不知道什么样的数据（或者没有意识到）能够说明问题时，通常会引用外部的参考及指导，而且大部分是外部强制指定的指标，这就是第一种回答的境遇。这时数据的生产者并不使用数据，也不会分辨数据的价值或者准确与否。
慢慢地，当我们了解了外部选择这样指标的含义并开始学着像外部一样去观察这些数据后，我们就逐渐开始迷恋上追逐外部的标准，我们认为确保事情的一些指标在达到标准就能够实现尽在掌控，为了实现这一点还会配套奖惩措施，导致数据生产者特别纠结这些数据是否达标及相关的利益是否受损，由此甚至会带来效果的畸变。如同第二种回答的境遇，传递压力并要求受影响者达成期望的指标，这是一种“尺子”的使用方式并且是大多数团队能够达到并停留的方式。
“控制”给人造成的心理暗示是围绕着静态目标而行动；而“改进”则将动态的目标植入人们的思维模式——《精益软件度量》
数据的奥妙在于单个数据可以表达静态结果，而大量数据却能反映动态过程，并可以通过特征的拟合来佐证外部行为作用过程的影响。当结果能够达成，关注过程有助于更容易达成结果（效率、质量）；当结果不能达成，关注过程有助于发现阻碍结果达成的因素，因此可以说关注过程总是有用的，这就是第三种回答的由来。从关注结果到关注过程，这才是度量能够大放异彩的方式——把度量当作“镜子”，度量不是目的，而是手段。
度量能够提供信息帮助我们了解我们在哪，与目标的距离多少，在朝哪个方向前进，前进的快慢程度等，所以度量就是组织达成业务目标的仪表盘和导航仪。
天下没有免费的午餐
无论是团队还是项目在做实际的度量时都喜欢说一句话“唉，那个谁，快把那个XXXX（此处省略一万字）数据整理下，我XXX时要看”。按照这句话理解度量应该是一件很容易很轻松就能搞定的活动，实际情况究竟是不是这样呢？既然度量大致上要做采集分类与研判评估这样两件事，那就让我们来看看这样两件事的成本如何而来。
研发团队的日常就是在制造大量数据，包括看得见和看不见的，很多数据隐藏在各种活动和场景中，比如说：一个简单的提交代码就包含了常见的代码行数、UT覆盖率以及提交次数、修复问题分类，甚至还能深入到代码的风格、技能水平等数据；而一个普通的故障修订就包含故障处理时长、验证时长、故障成因、故障关联的需求，故障解决方案等数据。上面描述的还只是已经被确认有用的数据（实际上也只是很小的一部分），而未知的部分更是看不到边沿，这些数据还不是已经摆在桌面上的制成品，每一次的搜集都是需要围绕目标预先建立数据的模型。早期各种各样的报表就是搜集数据的手段，现在虽然有了自动化工具但是要搜集的数据更复杂，往往需要很深入的分析才能从场景和活动中实现剥离和提取。搜集之后还有更加复杂的分析、研判、评估和汇报，这又是一次建模的过程依然需要围绕目标运转，还得依赖各种统计理论与实践方法，只要任何一个环节做不到位都产生不了预期效果。
凡事贵在专，事成于精专——曾国藩
显然，要做到上面的一切需要投入不少时间与人力（这其实是最最昂贵的投入），除此之外还会有工具和基础设施的投入。既然成本如此的高昂，那么在度量这件事就应该慎重，俗话说好钢用在刀刃上就是这么个理，在最有价值的方向上建立度量体系好过漫无目的地建立一个大而全的度量体系。然而实际上大而全的度量体系不止一次地出现在我的视线中，这一点非常让人头痛，使用这样的度量只有两种可能：
- 对于改进缺乏自我觉察
- 根本没有使用度量，度量体系不过是个“皇帝的新装”
To be or not to be, that's a question
通常来说产品或交付对基层组织总有这么几类期望：价值、效率、质量和能力。如果基层团队按它们去全部展开恐怕又会得到一个大而全的度量体系，既然上面讲到度量应当关注改进并且应当选择高价值的目标，那么对于基层组织来说什么样的“标靶”也比不上从弱项着眼，瞄准自身的痛点去建立度量跟踪，比方说团队复盘分析发现研发过程中的大部分返工问题都是由于需求传递与理解不一致造成的，针对这个问题团队提出了“通过结构化的描述（如MFQ）来澄清和分析需求，过程中至少包含测试专家、业务专家及研发核心参与”这样一个改进措施。那么度量体系就应当在讨论改进措施如何验收时一并进行考虑，比较直观的指标可以是返工任务数量（或者返工消耗的小时数）、返工的原因（这里应当是具体的返工原因，便于后续的分类分析），辅助指标可以考虑结构化描述修订次数及原因或者需求实例化交互次数与讨论问题种类（这是帮助评估结构化描述是否存在缺陷和遗漏，以及研发人员经常关注问题，从而进一步改进该措施的实施细节）。最后还要确定度量数据研判周期，因为团队特性以迭代为周期所以度量数据至少应观察3个迭代以上。
有了数据之后就要分析（通常会采用横向或纵向比较）数据结果是否能够验证我们的预期，在上面的例子中指标数据可以比较直观的反映采用改进措施之后的效果，但要注意这里还有一个陷阱就是要思考数据的可靠性，因为我们都知道团队的迭代是滚动前进的不会再退回来重做一遍之前相同的需求也很难遇上特性相同的需求，也就是说上个迭代出现了大量返工的特性在下个迭代并不会遇上，反而可能会遇上一个对于团队来说驾轻就熟甚至无需结构化描述也不会出现返工，所以当数据出现了显著变化时还需要思考是否真的是改进措施带来的变化，否则太容易“浅尝辄止”。
流水不腐，户枢不蠹，动也
在有针对性地选择度量指标后，随着时间的推移团队的度量指标会累积的越来越多，或者团队的目标发生了迁移或者变化，原有的指标已经不再对团队发挥作用反而成为了资源的浪费，演进团队度量体系就是必不可少的了。因为前面讲到度量的成本是相当那个高昂的而团队的资源是相对有限的，因此团队增加指标时，一定要记住审视已有的指标，思考是否存在可以删减，保持资源的投入回报维持在一个合理的水平上。
度量要做团队持续改进的助推器而不是累赘，现在很多团队对度量有不小的抵触，认为它不仅加重了工作负担还破坏了团队的气氛（比如相当致命的加班时间排行），很大原因是制定了错误的目标，在错误的道路上不停努力哪有不疲惫和厌烦的道理。要让度量成为真正的助推器就要结合团队的目标是什么，弱项是什么，痛点是什么，而且不要贪多争取用度量一次彻底地改变一个，这样才会让度量在团队中变得有意义。
这篇文章和大家探讨的只是团队度量的很小一部分，如果想要了解更多的度量知识，推荐阅读一下《精益软件度量》，相信大家会有更深入的收获。
