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

问题一：紧急事故

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

解决&反思：

问题二：人员没有带宽

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

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

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

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

解决&反思：

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

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

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

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

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

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

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

image.png

做法：

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

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

关于信任：

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

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