谈谈精益（下篇）——看板系统

此文是《谈谈精益（上篇）——Lean Manufacturing》的续篇。

先说说精益软件开发

制造业的成功，已经证明了精益思想的强大。非常自然地，软件行业的从业者，也希望能够汲取精益的理念，来消除软件开发中存在的浪费，从而能够成功的交付客户价值，获得更高的软件成功率。这其中的先驱者，当属Mary and Tom Poppendieck夫妇。他们出了一本书，名字就是《Lean Software Development》，内容则是如何将精益思想落地于软件行业中，来影响现有软件开发行业的形势。

这里，我们参考制造业的DOTWIMP，来思考对应软件行业的DOTWIMP。希望通过这些原则，来具体指导如何精益地做软件开发——消除浪费（Eliminate Waste）

Defect (Defect)

软件行业中的缺陷，是一个非常普遍的概念。代码或者系统中任何与预期不符的情况，都可以称为缺陷。很明显，缺陷是一种不为客户带来价值，反而会造成巨大浪费的事物。发现缺陷，会造成QA的工作量，修复缺陷，会带来开发的重复工作。根据Lean的原则，我们需要从根本上去除缺陷的产生，而不是事后花费成本修补。并且，当我们捕捉到一个未覆盖的缺陷时，我们需要发现缺陷背后的根本原因，从而保证这个缺陷不会再次出现，不会引入重复的浪费。

单元测试和集成测试，就是保证代码从一开始不引入缺陷的实践之一。诚然，自测试代码中的测试部分，本身确实对于客户来说，没有价值，也是一种浪费。但是，这种开发级别引入的浪费，是为了避免后期更大的浪费出现。在软件开发的开发部署流程中，一个缺陷越晚被发现，定位并修复的成本会越高，也就意味着浪费会更大。

Extra features (Over-production)

作为开发，总是抑制不住冲动，希望软件不仅能够满足当下的需求，当未来有新的需求出现时，也能成功应对。但是，额外的需求功能，也是一种浪费，因为它没有对客户产生价值，但仍需要开发人员花费成本维护和测试。

埃里克莱斯是《精益创业》一书的作者，书中说到：

最大的浪费是构建没人在乎的东西。

做一个能卖出去的产品，而不是卖一个做出来的产品。

Handoff 交接 (Transportation)

任何曾工作在瀑布软件开发方式下的人都对“交接”这个词印象深刻。BA在写好一个很大的需求文档之后，交接给架构师；架构师在做好设计并完成设计文档之后，交接给开发团队；开发写完代码之后，交接给QA团队。在每次交接的过程中，知识不可能全部传下去，会丢失相当一部分。这样，开发人员脑子中的需求，和BA的理解可能大相径庭。

这就是为什么敏捷团队和SCRUM都倡导全功能团队：团队中应包含各个角色，BA、DEV、QA、PM、UX。这样避免了交接带来的浪费，促进了不同角色之间知识的充分分享。

Delay (Wait)

项目进行中任何拖延，都是一种浪费。比如当团队某成员提出一个问题，而能够回答这个问题的人并不能轻易的被找到的时候，这时候Delay产生了，从而浪费也产生了。

Partially completed work (Inventory)

从BA开始准备一个Story的需求描述，到最后达到能够达到上线的状态，中间过程中的Story都被看做是未完成的工作。除非上线，否则不论Story处于任何状态，都没有为客户产生价值。未完成的工作，还有可能推迟了发现问题的时间。

Task Switching (Motion)

没人什么事情比让一个人同时做多件事，更能降低一个人的效率的了。当开发人员同时做好几个Story的时候，频繁的切换上下文，会造成额外的消耗，但并不增加任何价值。提高效率的最好办法，就是集中精力解决一个问题，然后再解决下一个问题。

Unneeded processes (Processes)

你有没有曾经遭遇过这样的经历，为了对生产环境做出一点微小的环境改变，但需要经历一个漫长的审批过程，等待好几个人的签字？很多公司都有这样冗长的机制，并且经历过的人都知道，为了完成一点点的改变，过程是多么的痛苦。这种不必要的流程，没有为客户增加过多的价值，但是却引入了相当大的浪费。

什么是看板方法

看板方法是用于管理软件开发流程的新技术。看板方法源自丰田的“及时生产”（JIT=just-in-time）系统（在前文中我对JIT解释如下：Just-In-Time努力将生产过程中每一步的库存量尽量降到最低，最好为0。换句话说，这意味着只需要在合适的时间、合适的地点，提供适量的原材料。去除库存带来很多好处：不仅可以节省成本，还去除了商品被废弃或者损坏，久置的可能性。）

一个软件开发的流程可以看作是一段自来水管道，特性需求从一端进入，经过开发的软件从另一端涌现出来。

在管道内部，存在着各种各样的工序，我们先假设一个最为简单的阶段性流程：

分析需求->开发代码->测试软件运行正常

在管道中的瓶颈会限制工作的流动。管道的整体吞吐量被限制为瓶颈的吞吐量。用我们的开发管道为例：如果测试人员每周只能测试5个特性，而开发人员和分析人员每周能够生产10个特性，整个管道的吞吐量就只有每周5个特性，因为测试人员扮演了瓶颈角色。如果分析人员和开发人员不知道测试人员是瓶颈，那么测试人员的待办工作就会越堆积越多。

影响就是前置时间增加。并且，就如同库存一样：位于管道中的工作会套牢投入的资金、产生与市场的距离、库存中的产品（交付特性）会随着时间逐渐失去价值。

看板系统

如果我们知道哪里有瓶颈，我们就能够重新部署资源来解除它。我们怎样才能知道在已知流程中哪里是瓶颈呢？当我们知道了瓶颈后会采取哪些措施呢？

《看板方法》一书中对看板系统的定义是这样的：

看板（或卡片）的数量，等价于系统设置（核定）的流通能力。一张卡片与一个工作项关联。每张卡片都充当一种信号机制。只有获得一张自由卡片后，才可以开始新的工作项。这张卡片与该工作项关联在一起，跟随工作项在整个系统中一起流转。当自由卡片没有剩余时，就不能开始额外的工作。任何新到达的工作项必须在队列中等待，直到可以获得新的自由卡片。有了自由卡片，队列中的新工作项就又可以启动。

看板方法背后有两条基础性的原则：

仅当有可用产能时才通过信号卡传递机制来拉动工作的流动

只有系统具备了处理的能力才能拉入新工作项，而不是基于需求将工作项推入系统中。

另外一条是：

限制在制品的数量

恰当的设置能力阈值，拉动系统就不会出现过载现象。

思考——如何设置WIP

根据某些研究和经验观察，每个知识工作者同时在2个工作项上工作是最优的。同时考虑影响因素很多，比如说一些突发的情况，或者说团队的成熟度情况，通常来说，我们将在制品限额设为每个人或者每个结对2个工作项。

在选择WIP数值上，并没有什么魔法公式。这个数值是通过试验观察不断调整的，我们可以先选择一个数值，然后观察这个数值是否能很好地工作。WIP数值本身不是最重要的，在价值流中添加WIP限制带来一种积极的压力：这种积极的压力迫使大家去面对软件交付过程中的存在问题，并思考如何改进。

举个例子

下面的看板展示了这样一种情况：开发人员(Dev)和业务分析师(BA)正被阻止开展任何新工作（因为QA堆积的待办工作项已经超过了限制的在制品数量），这种情况会持续直到测试人员(QA)空出了一个卡片位置并将下一个工作项拉到测试步骤中。

这时Dev和BA会开始寻找能够帮助测试人员减轻负担的方法。例如，BA可以帮忙测试，Dev开始进行自动化测试等等。

一旦QA完成了一个特性的测试，就会将卡片移走，并且在Testing->Ongoing列中空闲出一个卡片位置。

Testing->Ongoing列中空出来的位置可以用Development->Done列中的一个卡片补充进来。这时Development->Ongoing列就会空闲出一个卡片位置，下一张卡片就可以从Analysis列中拉进来。

前置时间(Lead Time)是指在当前迭代完成的用户故事中，从需求进入IPM至需求交付的耗时，Lead Time通常用作改善流动的重要衡量标准——减少Lead Time就是减少等待的时间，加速价值的流动。

写在最后：

看板是一种方法，它能够为我们提供：

可视化的工作流，展示工作项的进度视图

平衡需求能力，识别瓶颈

看板代表了精益的思维范式：每个团队的情况不同，每个看板也会不一样。尊重他人，持续改善的思想是一样的，我们重视通过不断地思考，频繁且可靠地交付高质量软件，帮助团队在能力和组织成熟度方面得到不断地提升。