浪费是业务兴盛的最大威胁 | 如何消除价值流中的困境和浪费？

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

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

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

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

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

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

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

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

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

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

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

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

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