消除浪费？消除延时！ | 精益软件开发系列 | Agilean学院出品

weixin_45977872

于 2015-09-21 07:53:08 发布

阅读量167

点赞数

原文链接：http://www.netobjectives.com/blogs/differences-between-lean-manufacturing-and-lean-software-development

版权

本文编译自Alan Shalloway名为《精益制造与精益软件开发的不同》的博文，由Agilean李淳编译。

精益源自制造业，然而在软件开发中，精益的有效性却问题颇多。我们的实践证明，精益对于软件依然重要。本文包括如下内容：

精益的基本范式的变迁，以及为何精益更适用于软件
在实施过程中，物理世界与软件世界有何不同

精益基本范式的变迁

精益构建于戴明的系统思维和管理风格之上。精益的缔造者大野耐一曾说，他在戴明的成果之上增添了两种概念：一种对“即时制”和“自働化”的专注。

即时制（Just-In-Time） 基本意味着，即时满足紧后步骤的需要。在软件中，即时制则意味着在准备好进行设计前，不需要太早定义需求；在准备好写代码之前，不需要太早进行设计。敏捷则通过小批量甚至像XP中那样看似同时处理不同任务体现即时制。随着这一基本范式的变迁，我们的关注点从人和机器的生产力迁移到了时间和工作流程上。换言之，我们的关注点不再是试图尽可能提高工作中每个环节（或每个人）的生产力，我们关注于消除步骤之间的延时。即时制可以通过小批量开展工作并以拉动同步流程的方式得以实现。

自働化（Autonomation）意味着有人值守的自动化。本质上讲，当出现某个错误时，工作就会停止流动，之后就需要一名人员进行一步一步跟踪，看看发生了什么，并对系统进行改进。

较物理世界，这两个概念甚至更适用于软件开发。原因是，如果不使用“即时制”，工作环节之间就会发生工作积压并发生延迟，从而增加了未完工作的数量，即便未发生错误（比如bug）也是如此。当发生错误时，这些延迟就显著造成额外的工作。试想，一个bug产生时立即被检测出，修复需要多少时间。相比在早期发现，如果过了几周才检测到，即便bug并未从开发团队逃逸，也需要更多的时间才能修复。换言之，相比构建物理世界中的产品，软件中的即时制节约得多。

在实施过程中，物理世界与软件世界有何不同

“消除浪费”是精益的口头禅。在物理世界中，人们能看到多种形式的浪费：

车间中堆积各种物料
手上囤积的库存尚无需加工
四处悬挂着等待修复的残次品
工作的数量正在增加

不幸的是，在软件世界中，这些全都是隐形的，至少不能直接被看到。“消除浪费”这句口头禅变成了一句听起来不错但实则没有什么指导意义的空话。幸运的是，通过专注于对工作流程中的延迟进行跟踪，就能够看到这些浪费。实际上，软件开发中的所有浪费都原则下面这几种延时：

从得到信息到使用信息之间的延时（比如，很久前的需求）
从制造某个错误到发现这个错误之间的延时（比如，编码和测试间隔很长时间）
从发现某个错误到修复这个错误之间的延时（实际上是第1类的变种）
等待某人提供信息
等待将手头工作交接给下一位人员
由于其他事分散了我们的注意力而造成工作流程中断

延时有个显著的特征，通过记录排队长度与延时的关系，就能够被轻易看到。如果我们创建了一个工作流程白板（看板墙），并用它来明确地描述我们的工作，那么，通过让排队长度大于原本的长度，我们就能看到工作流中的延时。因此，如同“消除浪费”之于物理世界，在软件世界中，则应该“消除延时”。

物理世界中的某些事物不能照搬到软件世界中

在我看来，正如前面所述，物理世界的精益并不完全适用于软件世界。物理世界中，精益对时间的关注在软件中成为了新范式，其适用性是原来的10至100倍以上。然而，物理世界中的某些事物不能照搬。最明显的可能就是单件流（One-Piece Flow）。在一整套低变异性的制造流水线上，单件流是可以做到的。而在软件世界中，单件流通常是馊主意。如果软件的变异性刺痛了团队，试图使软件达到低变异性无可非议，实际上软件本应如此设计和构建。但是，如果试图消除正在构建中的软件的变异性，新产品本应具备的风险就会被规避，那么很明显是不会得到好的业务结果的。