《Scrum精髓：敏捷转型指南》—WIP

WIP

WIP（work in process）指的是已经开始但尚未完成的工作。在产品开发过程中，必须识别出WIP并进行妥善管理。下面四个敏捷原则与这个主题相关。

l  批量大小要经济合理。

l  识别并管理库存资源以达到良好的流动。

l  关注闲置工作，而非闲置人员。

l  考虑延期成本。

批量大小要经济合理

计划驱动的顺序开发过程的另一个核心理念是，倾向于将相同类型的工作分批汇集到一个独立阶段中执行。我将这种方法称为“整体推进”，即在开始后续活动之前，必须先全部完成当前阶段的所有事情（或者大体完成所有事情）。比如，在分析阶段创建全部需求。接下来把批量需求移动设计阶段。因为产生的是一套完整的需求，所以在这个例子中，批量大小是100%。

之所以采取“整体推进”方法，在一种程度上是因为相信以前制造业的规模经济原则适用于产品开发。这个原则认为在增加生产数量（批量大小）时，生产单件产品的成本会随之下降。所以，顺序开发的理念是，大批量的产品开发也能实现规模经济。

在Scrum中，我们支持这个观点：虽然规模经济的思想已经成为制造业的基本原则，但把它生搬硬套到产品开发中，会造成重大的经济危害。

在产品开发中采用小批量的方式，这听起来有违直觉，但实际上好处多多。Reinertsen深入探讨了批量大小的问题，表3.2包含的是他对小批量好处的部分描述（Reinertsen 2009b）。

如果小批量比大批量好，是不是说明批量大小就应该是1，也即一次只处理一个需求，做完所有活动后准备交付给客户？有人将这个过程称为“单件流程”。正如本书后文所述，在某些情况下批量大小为“1”可能还行，但是把“一个”作为目标，对工作流和总体经济来说，充其量也只是局部最优。

好  处

描  述

减少周期时间

批量较小时，等待处理的工作也较少，意味着等待时间不会太长。因此，工作完成得更快

减少工作的变动

想象一下，在一个餐馆中，顾客零散地进进出出（在餐馆里良好流动）。现在再想象一下，从一辆大型观光巴士走下来一大批顾客（大批量），对餐馆中的人流有什么影响呢？

加速反馈

小批量有利于加快快速反馈，能够最小化错误影响

减少风险

小批量意味着受变更影响的库存更少。小批量失败的可能性也更小（10个工件比5个工件的失败风险更大）

降低管理成本

大批量工作有管理成本——例如，维护3000个条目比30个条目，需要更多的精力

积极性和紧迫性提高

小批量能够让人更专注，更有责任意识。与大批量相比，在处理小批量时，更容易理解拖延和失败的后果

降低成本，减少计划延期

如果在使用大批量时出错，成本和时间安排上都会出现大范围的错误。使用小批量工作，则不会错得太离谱

识别并管理库存以达到良好的流动

在本章中，我一直在提醒大家，制造业不同于软件开发，所以应当采取不同的方法。不过，制造业倒是有一个值得软件开发行业借鉴的教训，只可惜常常被忽视。这个教训就是库存（也称为“WIP”、“流程中的产品”、“半成品”和“在制品”）的高成本。精益产品开发社区早在很多年前就懂得WIP的重要性（Mary and Tom Poppendieck，2003；Reinertsen 2009b），Scrum团队也接受这个观点。

制造商对库存及其含义有敏锐的认识。他们怎么可能不知道呢？等着处理的存货在地板上很快码成堆。库存不仅实实在在看得见，财务上也相当明显。随便问一问一个工厂的首席财务官，问他工厂中有多少库存或是上个月的库存变化情况，他都能给你一个确切的答案。

能干的制造商绝不会坐视库存大量积压不管。工厂库房里等着组装成产品的零件在财务账簿上是有折旧率的。更糟糕的是，如果我们已经买好一卡车零件，产品设计却发生了变化，会出现什么情况呢？该如何处理这些零件？或许可以对这些零件进行返工，使其适应新的设计。或者更糟糕一点，这些零件再也用不上了，只能丢弃。又或者，为了不浪费已购买的零件，我们决定维持原有设计（即便采用新设计才是正确选择），冒着产品满意度降低的风险，继续使用这些零件？

显然，在我们守着大量库存的时候如果事情有变，就会导致一种或多种形式的浪费。为了最小化风险，能干的制造商采用一种经济合理的方法管理库存——手头保留一部分库存，但通过实行准时供给的库存管理方式，只留合理的库存数量。

一般情况下，软件开发企业根本意识不到自己是有WIP的。问题部分来源于这样的事实：在产品开发过程中处理的知识资产与厂房地板上的零件不一样，它们是不可见的。知识资产，比如磁盘上的代码、文件柜里的文档或者墙上的可视化白板，不会那么让人操心。

在财务上，产品开发过程中的库存通常也不可见。随便问一个软件开发企业的首席财务官，问他们公司有多少库存，他可能会疑惑地看着你，然后回答说：“没有。”财务团队会跟踪产品开发过程其他方面的度量数据，却不大可能跟踪这种产品开发库存。

糟糕的是，库存（WIP）刚好正是产品开发过程中需要管理的关键变量，这在传统产品开发方式中往往被忽视。前面在讨论批量大小时曾经说过，传统开发方式中，批量大小设置得相当大（通常为100%），实际上倾向于制造大量库存。在软件产品开发中，如果出现大量WIP，后果是很严重的，它会严重影响前面所介绍的变更成本曲线（参见图3.9）。

即将开始开发时，确实需要有一些需求，但并不需要全部需求。如果太多，在需求发生变化时很可能造成库存浪费。但另一方面，如果需求库存不足，又会破坏工作的快速流动，这也是一种浪费。Scrum的目标是合理地平衡适量库存和过多库存之间的关系。

我们还要认识到，需求只是产品开发中的一种库存。在产品开发过程中，很多地方，很多时间都有WIP。这些库存也需要我们积极主动地识别和管理。

关注闲置工作，而非闲置人员

在Scrum中，我们深信闲置工作（idle work）比人员（idle worker）更浪费，经济危害也更大。闲置工作指的是有些工作我们想做却由于其他事情的阻碍而无法做（例如构建或者测试）。这种停顿也许是因为必须等另一个团队完成之后才轮到我们做。又或者我们要做的工作太多而无法同时完成。在这种情况下，一部分工作就会处于停顿状态，得等我们空了才能继续。另一方面，人员空闲，指的是员工有能力做更多工作但当前并没有100%投入。

很多软件开发企业更关注如何消除闲置人员所造成的浪费，而非闲置工作所造成的浪费。例如，传统上认为，如果受聘为测试人员，就希望你把100%的时间都用来测试。如果投入测试的时间少于100%，就造成了浪费（你本来可以做测试，现在却闲着）。为了避免出现这种问题，我就得给你找更多测试工作——也许是把你分配到多个项目中——目的是人尽其用，达到100%的利用率。

遗憾的是，这种方法在降低了一种浪费（人员空闲浪费）的同时却增加了另外一种浪费（工作停顿所造成的浪费）。而且在大多数时候，工作停顿所产生的成本远远高于人员空闲所产生的成本。我们来探究一下具体原因。

为了清楚说明这个问题，让我们把“让人100%连轴转”（保持人员100%忙碌）这个策略应用于奥运会4×100米接力赛。如果采取这种策略，接力赛看上去就太低效了。我出钱让人跑，结果他们却只有1/4的时间在跑，剩下的时间干嘛呢？站着等。呃，这可不行！我付的可是100%的薪水，所以他们理当100%的时间都在跑。在没有拿到接力棒时，让他们原地跑或在旁边的跑道跑另外一场比赛呗！这样的话，他们就是100%的时间都在跑啦！

当然，我们都知道，让队员100%连轴转并不能赢得接力赛的金牌。只有拿着接力棒第一个冲过终点，他们才能赢得金牌。所以，这里的重点是借鉴的 “看好接力棒，而不是队员”（Larman and Vodde，2009）。在产品开发情境中，接力棒停留于地上，相当于工作已经准备妥当却因为需要等待必要资源而停顿下来。接力棒都在地上，怎么能赢得比赛（交付产品）？！（我真的很喜欢接力棒和赛跑者这个比喻，因为它非常好地诠释了我们应该观察工作而非人这个道理。但是，像任何其他比喻一样，它也有局限性。在这个比喻中，像接力赛一样的工作交接方法恰好也是传统顺序开发的特质，这是应当避免的！）

同时，每个人都知道让人力资源100%连轴忙的后果是什么。如果借鉴排队论中的一幅图，就可以看出力争达到100%资源使用率所造成的显著危害（参见图3.15）。

有计算机的人都理解这幅图。如果计算机在100%（处理器和内存完全使用）的状态下运行状况如何？计算机开始剧烈波动，每个作业都会变慢。换句话说，计算机希望做更多事情，但实际完成的高成效工作却更少。一旦进入这个状态，就很难摆脱困境（可能得终止作业或重启机器）。如果使用率保持在80%左右，计算机的效率会更高一些。在图3.15中，队列大小相当于延期，延期则相当于地上的接力棒。

一旦使用率增高，停滞不前的工作（延期的工作）就会呈指数级增长。闲置工作可能非常昂贵，成本往往高出闲置人员所涉及的成本很多倍（参见下一节延期成本的例子）。所以，在Scrum中，我们敏锐地认识到：需要找出工作流的瓶颈并集中精力消除它，相较于努力让每个人都100%连轴转，这样做更加经济合理。

考虑延期成本

延期成本是工作延期或里程碑延期达成所产生的财务成本。图3.15表明，随着处理能力利用率的增加，队列大小和延期也增加。因此，在降低闲置人员浪费的同时（通过增加他们的使用率），也增加了与闲置工作相关的浪费（在队列中等待服务的工作）。使用延期成本，我们可以算出哪种浪费的经济危害更大。

不幸的是，85%的组织都没有对延期成本进行量化（Reinertsen 2009b）。而且，大多数开发组织都意识不到还有正在排队等待处理的工作和积压下来的工作（库存），综合考虑这两个事实，就容易明白他们的默认行为是聚焦于消除闲置人员所造成的可见浪费。

有一个简单的例子可以说明闲置工作所涉及的成本为什么一般都高于闲置人员的成本。思考这个问题：是在开发工作第一天就给团队分配文档工程师，还是等到开发结束时再分配？表3.3对这两种选择进行了比较（也可以考虑其他选择）。

尽管不是100%需要，但我们还是假设为这个产品分配一个全年全职文档工程师。这样一来，相较于在产品“万事俱备，只欠文档”再安排他参与工作两个月，增加的成本是7.5万美元（可以视为闲置人员所涉及的浪费）。

参数

值

工作持续时间（有全职文档工程师）

12个月

工作持续时间（到最后“只差文档”时再分配文档工程师）

14个月

到最后再完成文档的周期成本

2个月

每个月的延迟成本

25万美元

总计延期成本

50万美元

文档工程师一年的总负担成本

9万美元

文档工程师每个月的总负担成本

7500美元

全职文档工程师的成本

9万美元

到最后再分配时文档工程师的成本

1.5万美元

全职文档工程师的额外成本

7.5万美元

如果到最后再分配文档工程师完成所有文档工作，全职工作两个月就够了，但产品交付日期也会延迟两个月。如果是这样，我们按生命周期利润计算得出延迟成本为50万美元（生命周期利润指的是产品在整个生命周期内的总利润。在本例中，利润减少了50万美元）。

在这个例子中，闲置人员所涉及的成本是7.5万美元，而闲置工作停顿所涉及的成本是50万美元。如果我们重点优化文档工程师的使用率，实际上也只是做到对产品整体的经济情况进行局部优化。在产品开发过程中，我们会持续面临这种权衡；要想做出经济合理的决定，延期成本是一个需要考虑的、最重要的变量。

软件开发 制造

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。