《DevOps实践指南》：软件中的八大浪费

消除价值流中的困境和浪费

丰田生产系统的先驱之一新乡重夫认为，浪费是业务兴盛的最大威胁——精益中对浪费的常用定义是“使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为”。他定义了制造业里7种主要的浪费类型：库存、过量生产、过度加工、运输、等待、移动和缺陷。

现代化的精益理念解释道：“消除浪费”会有点贬义和不近人情的意味，我们的目标其实是想通过持续的学习来破除日常工作中的困境，从而更好地实现组织的目标。在本书的后续内容里，“浪费”一词意味着这个更具现代感的定义，因为它更符合DevOps所期望的理想境界。

Mary和Tom Poppendieck在Implementing Lean Software Development:From Concept to Cash一书中描述道：浪费和困境是软件开发过程中导致交付延迟的主要因素。

下面是该书中描述的关于浪费和困境的部分类型。

半成品：它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待QA审核或服务器管理员审核的工单）。部分完成的工作会逐渐地过期，随着时间的推移最终失去了价值。

额外工序：在交付过程中执行的、并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文档，或是对输出结果做出的并不增值的评审或审批。额外工序不仅增加了处理的工作量，还增加了前置时间。

额外功能：在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”）。额外功能增加了功能测试和管理的复杂度和工作量。

任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换，并管理工作之间的依赖关系，这会在价值流中耗费额外的工作量和时间。

等待：由于资源的竞争而在工作之间产生了等待，这将增加周期时间，延迟了向客户交付价值。

移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分。

缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认。缺陷的产生和被检测出来的时间间隔越长，解决问题就越困难。

非标准或手动操作：需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置。理想情况下，任何依赖运维团队手动完成的操作，都应该配置成自动化的、按需提供的，或者是自助服务。

填坑侠：为了实现组织的目标，不得不把有些人和团队置于不太合理的处境，这甚至会成为他们的家常便饭（如半夜两点生产环境出现事故，连夜给软件版本提交了上百个工单）。

我们的目标是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标。

​