《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（二） 组织机制

《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（二） 组织机制

组织机制是一个复杂课题，书中仅仅讨论持续交付所需的文化，以及建立文化的四步法。关于组织架构、人才结构、激励机制等内容被略去，不得不说是一个遗憾，当然我想更多的是篇幅所限，不得已而为之。

组织文化塑造四步法

书中列举了几个企业组织的四步法，但大同小异，这里我以谷歌工程师的质量文化为例，

1. 第一步:定义想要做的事情

• 提高代码质量，减少生产问题，减少手工测试工作量，快速发布软件。

2. 第二步:定义期望的做事方法

• 开发团队编写自动化测试。
• 主动运行自动化测试用例。
• 做代码评审。

3. 第三步:提供相应的培训

• 在公司范围内组织代码设计与自动化测试培训。
• 为每个团队指派自动化测试教练，帮助团队提高自动化测试技能。

4. 第四步:做些必需的事情来强化那些行为

• 建立团队测试认证机制（test certified mechanism），共分3个大级别，12个子级，用于评估每个软件产品团队的测试成熟度。通过每个季度统计各级别上的团队数量分布，来评估自动化测试文化在公司内部的进展程度。
• 建立自动化测试组（ test group）和测试教练组（test mentor），帮助团队提升自动化测试能力。
• 建立代码评审资质证书。
• 代码合入版本仓库之前强制做代码评审。
• 代码评审之前，必须运行自动化测试用例，并提交报告给代码评审者。

当然，这4步并不是非常容易的，谷歌的执行过程也花费了4年的时间，其中还有很多非常具体的细节，书中并没有展开讨论。

行动原则

行动原则有3个，分别是“价值导向，快速验证，持续学习”。

价值导向

所有人都会一致同意，“我们做事情时，应该价值导向”。然而，这却是在工作中经常被忽视的一点，也是最难判断的一点。因为我们每天有太多的事情要做。为了能够早一点儿完成所有任务，我们常常忘记思考完成这些任务的最终目的，以及它与目标之间的关系。为了能够做出正确的判断我们应该时常强迫自己停下来，花一些时间，认真思考一下我们手头上正在做的事情是否仍旧具有价值，是否仍旧最有价值。之所以难以判断，是由于组织中每个人的背景与经历各不相同，对外部市场环境的感知也各不相同，对于同一个工作场所带来的价值感也会有所不同。因此，当我们讨论“价值”时，应该限定于一定的业务上下文，避免离题太远。同时，在讨论时应该尽量提供完整的上下文，并聆听他人的方案与建议。
即便进行了充分的沟通与讨论，面对同一个问题的多种解决方案，我们可能也无法达成一致意见。此时，我们可以采用行动原则的第二原则，即“快速验证”。

快速验证

在高度不确定的环境中，并不是所有的方案都能很容易提前对其价值进行准确判断因此我们需要快速验证。通过快速实施，得到真实反馈，从而做出决策。在一个安全的工作环境中，只要我们能够主动拥抱“快速验证”原则，充分发挥员工的主观能动性，就可以找到很多快速试验方案。
对于与组织管理相关的改进，也可以使用快速验证方式。例如，针对具体问题，选择不同的试点团队进行快速实施，根据团队实际运行效果进行调优、验证。

持续学习

我们无法保证每个决策都是正确的。团队应当将每一次反馈作为一次学习的机会，结合从中学习到的新知识，总结成功经验或失败教训。除了通过业务试验产生的业务结果对业务领域进行深入了解和学习，还要保持对做事过程的学习与反思，不断优化工作流程，提升各环节的效率。
对于团队日常工作过程的学习与反思，有两种常见的方式，一是定期回顾，二是事件复盘机制。

关于持续学习，我认为是比较重要的，所以我重点介绍下持续学习。

定期回顾

定期回顾是指每隔一定周期，团队主动安排一次会议，共同讨论在过去的这个周期内，团队在协作过程中的优点与不足，并讨论相应的对策，以便在后续的工作中能够保持优点，改进不足，持续取得进步。回顾会议结束后，应该有改进措施与计划，并能够跟踪执行结果。同时，不要制订过多的改进项，以免落入“反复提出，反复执行，没有实际进展”的境况。

复盘机制

复盘机制通常是指针对发生的问题进行分析，其目的是避免相同问题重复出现。首先要针对问题发生的前后进行信息收集与整理确定问题的严重程度，理解问题发生的过程（对于疑难问题，可能还需要在事故后进行线下模拟测试，甚至线上测试，以复现问题和寻找原因）。然后进行根因分析，最后总结经验，制订改进措施与计划，并能够跟踪执行结果。对于根本原因分析，需要注意以下几点。

1. 放松心态，开放共享。
2. 分清“因”和“果”。
3. 五问法，鼓励多问“为什么”。
4. 发挥群体智慧。
5. 不要停于表面，而要寻找深层次原因。
6. 对答案进行求证。

对于每一次复盘，都应该详细记录和总结，作为知识在企业中全员共享。只有这样，才能收益最大化。

在以上两种学习方式中，都应该运用“系统思考”方法。简单来说，就是对事情全面思考，不能仅是就事论事，而是把想要获得的结果、实现该结果的过程、过程优化以及对未来的影响等一系列问题作为一个整体系统进行研究。在传统的思维模式中，人们假设因与果之间是线性作用的，即“因”产生“果”；但在系统思考中，因与果并不是绝对的，因与果之间有可能是环形互动的，即“因”产生“果”，此“果”又成为他“果”之“因”，甚至成为“因”之“因”。

度量原则

作为管理者，如果无法度量，很显然你也无法有效率的进行改进。所以，我们也必须有度量原则。度量指标可以分为4类属性，分别是引领性指标、滞后性指标、可观测性指标和可行动性指标。

1. 引领性指标与滞后性指标
   引领性指标是指那些对达成预定目标有着重要作用的指标。通常，一个好的引领性指标有以下两个基本特点:第一，它具有预见性；第二，团队成员可以影响这些指标。

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

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

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

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

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

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

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