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

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

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

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

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

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

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

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

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

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

实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，造成了很多优先级冲突问题。正如《看板方法：科技企业渐进变革成功之道》的作者David J.Anderson所说：“停止开始，开始结束。”

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

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

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

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

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

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

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