这本书一开始就介绍了作者所在的一个糟糕的环境，面临着极大的挑战。后续就讲述了他是怎么在这样的一个糟糕的环境中处理好问题的。

问题一：紧急事故

现象：出现了线上事故，导致小时工的工资无法正确发放。

解决&反思：

• 找原因：这个紧急事故的发生是因为有一些变更没有任何确认直接上到生产。
• 思考如何避免此类事情再发生：考虑重新制定变更流程。

问题二：人员没有带宽

现象：团队的工作内容混乱、每个人手上都有很多工作，没有带宽可以做更多的事情。
解决：

• 可视化工作量，要清楚：
  （1）工作需求：列出所有工作任务
  （2）工作进度：清楚当前成员正在做什么、工作时长是多少
  （3）优先等级：充分理解业务目标和需求，更好的理解哪些是重要的工作，从而来理清工作的优先级
  （4）当前可用资源：清楚以后才能知道要多少新人手
• 减少项目积压
  （1）剔除一些无用的项目
  （2）调整开发和部署流程，以一种有意义的、系统化的方式，加固并保护应用程序和生产基础设施，减少故障维修工作
• 思考如何减少返工
  （1）返工意味着到最终交付的时长增长
  （2）考虑缩短反馈环路来减少返工

最终期望达到的目标是：
对于计划内的工作，建立一条迅速的、可预测的、持续的工作流来向业务部门交付价值。
对于计划外的工作，降低这些工作的影响和破坏。

问题二：瓶颈问题

现象：整个项目交给运维的时间只剩下一周，但是发现所有运维的工作都围绕着一位关键人员展开，这位人员就成了约束点。

解决&反思：

• 整理这位关键人员的所有工作内容，尽可能把别人可以做的工作转接给其余人员。
• 能自动化的一些工作内容自动化进行。
• 培养其他人员，使得能够承接关键人员手上的工作。
• 当识别出瓶颈以后，要尽可能去解决瓶颈的带宽问题。

以上是一些问题的解决方式和过程中的思考，但是看完整本书，发现自始至终都围绕着“三步工作法”展开。

三步工作法

第一工作法

第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。

帮助理解如何建立一个“工作从开发部门移向IT运维部门”的快速工作流。

• 这条工作流是迅速的、可预测的、持续不断的。
• 要弄清楚如何控制当前部门的工作导入量，并且要确保绝大多少人员都只能投放在为整个系统的目标所服务的工作上，而不只是为一个部门的目标服务。
• 使用可视化工作管理工具（看板）。
• 理解工作流，清楚该工作流的约束点是哪些。

关于约束点：
- 确认约束点，对于非约束点的任何改进都是幻觉。
- 利用约束点。不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等待，要专注于当前部门最高优先级的的工作。
- 把约束点置于次要地位，根据约束点来制定工作节奏。
- 把约束点提升到新的水平。
- 找下一个约束点。

• 清楚流程中的工作中心有哪些，并且哪些工作中心回成为约束点。

每个工作中心都由四种东西组成：机器、人员、方法、以及测评。 人员是被要求执行预定义步骤的人，根据依照工作方法所执行步骤的结果来进行测评。

做法：持续构建、持续集成以及持续部署，按需创建幻觉，严控半成品，以及构建起能够顺利变更的安全系统和组织。

第二工作法

第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快的发现和修复问题。这样我们就能在所需之处获取或嵌入知识，从源头上保证质量。

缩短并且放大反馈环路，从源头上解决质量问题，避免返工，用来根除计划外工作。

可视化等待时间，知道工作在何时在谁那里排队了多久、或者返工。
等待时间 = （忙碌百分比）/（空闲百分比）, 可见当资源使用率超过80%时，等待时间回直线上升。

image.png

做法：

• 在pipeline构建或测试失败时，停下来。
• 每日都在进行的持续改进日常工作。
• 创建快速的自动化测试套件，保证代码是可以部署的。
• 在开发和运维之间建立共同的目标和共同解决问题的机制。
• 建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定的运行，以及是否达到客户的目标。

第三工作法

第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。

建立文化，例如鼓励探索；从失败中吸取教训；能够理解反复的实践是精通工作的先决条件。

改进日常工作比开展日常工作更重要。不断给系统施加压力、从而不断强化习惯并加以改进。

关于信任：

• 信任缺失：不愿在团队中显示弱点。
• 惧怕冲突：在充满激情的建设性辩论中寻求和谐的假象。
• 缺乏诚意：假意与团队的决策达成一致，形成模凌两可的公司氛围。
• 回避问责：面对员工的失职行为，逃避追责，降低了工作标准。
• 忽视结果：对个人成就、地位和自我价值的关注超过了团队成功的关注。

做法：营造一种勇于创新、敢于冒险以及高信任度的文化，把至少20%的开发和运维周期划给非功能性需求并不断鼓励进行改进。

精益理论包括降低批量规模、减少半成品、缩短反馈回路。
信任度高的小团队，加上小的批量规模以及更小的、更频繁的软件发布，能够极大的提高开发部门的生产能力。