持续交付-度量原则

文章内容摘录于《持续交付2.0》书籍，用于学习备忘，如有侵权联系删除。

度量原则

“如果不能度量，就无法改进。”一个世纪前，现代管理学之父彼得.德鲁克曾经说过“you can't manage what you can't measure(你无法管理你不能衡量的事情)”。这句话的意思是除非成功被定义，并且被追踪，否则你无法知道自己是否成功。由此可见，度量对企业精英管理的重要性。而在组织改进的过程中，我们同样需要手机度量数据，来衡量我们的进步。

然而，作为管理者，我们也必须承认，在日常工作当中，仍旧有一些我们现在还无法度量但必须进行管理的事情，尤其是在一个高度不确定的环境当中。这是讨论度量原则的一个前提。

度量指标的4类属性

度量指标分为引领性指标、滞后性指标、可观测性指标和可行动性指标。下面就来分别介绍一下。

1、引领性指标与滞后性指标

引领性指标是指那些对达成预定目标有重要作用的指标。通常，一个好的因良性指标有一下两个基本特点：他具有预见性；第二，团队成员可以影响这些指标。

滞后性指标是指那些为了达成最重要目标的跟踪性指标，如销售收入、利润率、市场份额、客户满意度等研究分析都属于滞后性指标。当你得到这些结果的时候，导致这些结果的事情早已结束，你得到的都是历史性结果数据。

例如，在其他因素相同的情况下，假如软件质量与性能越好，则软件的市场竞争力越强，客户就越愿意为之买单，软件销售量就会越高。对于软件销售这件事情，软件销售量就是一个滞后性指标，而软件质量与性能就是一个引领性指标。我们可以通过优化软件性能，提升软件质量来影响软件销售量，但无法确保一定达成软件销售量这一滞后性指标。

企业的终极后验性指标是客户价值，相对于这一滞后性指标来说，其他指标均可认为是引领性指标。

2、可观测性指标与可行动性指标

可观测性指标是指可以被客户监测到，但无法通过直接行动来改变的指标。可行动性指标是指在能力可触达范围内，通过团队努力，可以设法直接改变的指标。

例如，前行代码缺陷率就是一种可观测性指标。我们无法以非常直接的方式来改变它，只能通过更全面的质量保障互动（写出高质量的代码、做更加完整的测试等活动）来影响这一指标。

代码规范符合度、代码圈复杂度、重复代码率既是可观测性指标，也是可行动性指标，因为团队可以直接通过修改代码来直接影响和改变这些指标，但无法确保一定达成“千行代码缺陷率”这一后验性指标。

“DevOps状态报告2017”指出，衡量IT高绩效组织的4个度量项分别是发布频率、发布周期、MTBF/MTTR、吞吐量。其中，发布频率是指软件部署并运行与生产环境的频率，例如，Facebook手机APP每周发布一次。该报告中发布周期是指从代码提交到发布之间的时间周期。MTBF，全称是Mean Time Between Failure，平均失效间隔。就是新的产品在规定的工作环境条件下从开始工作到出现第一个故障的时间的平均值。MTTR的全称是Mean Time To Repair，即平均恢复时间，指从故障出现到恢复之间的时间周期。吞吐量是指在给定时间段内系统完成的交付物数量。

如下图所示，假如将上述4个度量项作为滞后性指标的话，那么编译速度、测试时长、部署效率等指标则可能是达成这些目标的引领性指标。我们可以推断，从滞后性指标触发，一级一级地向前推导，可以发现很多可行性的引领性指标。需要注意的是，指标之间的关联影响可能还存在时间延迟效应，即对某一度量指标的改善，需要经过一段时间才能在其关联度量指标上有所体现。并且，指标链条越长，可预测性越低。

度量的目标是改善

我们可以通过设法管理过程指标来改善我们的工作过程，并将最终的效果与我们期望的结果指标对比，从而发现改进是否有效，并判断是否需要改变改进方向，还是继续向前。但是，过程指标离终极结果指标越远，对终极结果的影响作用就越不明确，其贡献越不直接。

因此，我们需要不断依据反馈的度量结果做出分析后再确定改进的方向，是继续向前，还是另寻他法。度量是一柄双刃剑，对可行动性的过程指标来说，“你衡量什么，就会得到什么”，但并不一定是以你想要的方式达成的。例如，当度量单元测试覆盖率时，工程师可以通过写出无用的单元测试（如没有断言），达成单元测试覆盖率指标，但是这种测试覆盖率已没有任何意义。因此，管理者要记住，度量的目的是为了组织改善。如果达不到度量的目的，则要么改用其他度量项，那么做好管理工作。