DevOps流动原则的实践之--限制在制品数量

制造业的日常工作通常是由定期（如每天、每周）生成的生产计划决定的，根据客户订单、交货日期、零件库存等条件，确定执行哪些任务。但技术工作通常是动态的——尤其是存在共享服务的情况下，团队必须要同时满足很多利益干系人的需求，这导致临时安排控制了日常工作。

 

紧急的工作可能会来自于各种渠道，譬如工单系统、宕机告警、电子邮件、电话、即时通信的消息或管理层决定的事件。生产中断在制造业里很显眼，且代价极高，当正进行中的工作戛然而止时，所有的半成品都将报废，然后再启动一批新作业。这种高昂的代价，让人们不希望中断频繁发生。

 

但是技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，即便它对生产效率的影响比制造业更甚。例如，将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本。

研究表明，即便是完成简单任务，如将各种几何形状分类，当同时执行多个任务时，效率也会显著降低。从认知上看，技术价值流中的工作，显然要比分类几何形状复杂得多，所以多任务会导致更长的处理时间。

当使用看板管理工作时，可以限制多任务的出现，例如对看板的每一列或每个工作中心设置在制品数量的限制，并把卡片数量的上限标记在每一列上。

横跨需求、开发、测试、预生产和生产的看板示例

 

例如，将测试工作的在制品数量上限设置为3。当测试队列中已有3张卡片时，除非某张卡片完成了，或将3张中的一张退回到前一个队列（左侧的那一列），否则禁止添加新卡片。另外，在把一项工作用卡片的形式显示在看板上之前，任何与之相关的工作都不能开展，这强调了任何工作都必须可视化。

 

控制队列的长度（即在制品数）是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一——对于大多数的工作条目而言，在它们完成以前，其实并无法预测到底需要多长时间。”

通过限制在制品数，还能更容易地发现工作中的阻碍。例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。虽然进行一项新工作（即“干点什么总比什么都不干强”）可能很诱人，但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。

 

实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，造成了很多优先级冲突问题。

正如《看板方法：科技企业渐进变革成功之道》的作者David J.Anderson所说：“停止开始，开始结束。”

 

以上来源《DevOps实践指南》

翰德恩洞见：限制在制品需要改变长期以来研发和运维人员堆积在制品的工作习惯。在制品限制有以下作用：

 

1) 限制在制品，会让特性的交付周期缩短。

2) 交付周期缩短，会让产品质量的反馈周期、以及用户或客户的反馈周期缩短，对业务的响应变快。

3) 当质量的反馈周期缩短后，在同样的时间内从测试和线上返回开发的缺陷会减少，从而产品质量有所提升。

4) 从测试和线上返回开发的缺陷减少，在团队的Backlog里排队的缺陷就会减少，让在制品有所降低。

5) 用户或客户的反馈周期缩短后，那些未经验证的无用的、或低价值的需求也会减少，间接地影响了在制品的降低。

6) 产品的质量提高，同时对业务响应变快，必然影响用户或客户对产品的满意度有所提升。

好的实践，起步容易，但是贵在遇到困难时能够坚持。坚持限制在制品数量，能够触发以上一连串的良性循环。