Lean Software Development, Part 2: Eliminate Waste

消灭浪费是Lean的第一原则，要消灭浪费，首先就要找到浪费。《Lean Software Development》中提供了一种Value Stream Map的工具，就是把整个流程用图表示出来，从而轻松的找出那些Non-value Add的部分，也就是浪费。有兴趣的可以去看看，这里说一下软件开发中最常见的七种浪费。

 

1. 未完成的任务（Partially done work） 

未完成的工作需要占用资源，容易发生变化，甚至被废弃。其次，任何事情，如果停下隔一段时间再重新开始，每个人都会觉得有点生疏。即使自己写的代码，过了几个礼拜去读，也会需要重新花时间理解，这段时间也是一种浪费。有时候，未完成的工作还会妨碍到其他人的工作。软件开发中，这类浪费包括未编码实现的文档，未编译通过、未同步以及未测试的代码，未发布的代码等等。

现在软件开发时都会使用版本控制工具，很多人都经历过同步时发生冲突或者同步后发现代码无法编译的情况，这就是未同步的代码造成的浪费。未测试的代码会产生潜在的缺陷（Defect，也是七种浪费之一），缺陷越晚发现，修正它就会花费更多的代价。为了减少未同步和未测试的代码，可以使用测试驱动开发、单元测试、持续集成等方法；为了减少未发布的代码，Lean个Agile都推荐快速交付。

未完成的任务不但是一种浪费，而且也是很大的风险。 

2. 多余的功能（Extra features）

很多软件开发者包括我，都曾经有过这样的冲动，要把某个功能加到当前的软件中去。但在实施之前，请务必仔细考虑，这个功能是否立即需要，如果不是，那这就是一种浪费。软件其实也是遵循80/20原则的，用户在80%的时间里一般只使用20%的功能。而在商业中，时间往往是决定一个产品成败的因素，在最短的时间里完成这20%的功能然后发布，有时对某个软件甚至是生死攸关的。

在很多Agile方法中都有User Story这个东西，然后客户代表和开发人员会对这些User Story评估并排定优先级，每个版本都从优先级最高的User Story开始做起。这样就可以最小化多余的功能了。

3. 重新学习（Relearning）

十有八九的人都碰到过这样的事，碰到了一个问题，于是去网上搜索、去问人、甚至去论坛或者专家组发帖提问，自己再不断的尝试，花了大量的精力，终于解决了。于是长吁了一口气，然后就继续往下干了。过了一段时间，又出现了同样的问题，虽然知道自己解决过这个问题，但就是想不出来当初是怎么解决的，虽然懊恼不已但也不得不重复了一遍原先做过的事。有时候是其他人也碰到了同样的问题，也是一种浪费。因此，需要一个好的方法来记录知识、共享知识。

有人可能会想，把所有东西都记录下来不就行了？结果写下来的文档根本就没人看，问题依然存在，还造成了更多的浪费。有时候，简单的往往是最有效的，比如依靠更多的交流产生所谓的“Tacit Knowledge”，对一些重要的东西再集中记录（比如在Wiki上），可能会更有效。

4. 工作交接（Handoff）

在工作交接时，有一些知识是很难传递的。通常每一次工作交接都会丢掉一半的知识，比如在瀑布模型中，分析人员写完一个需求文档交给设计人员， 设计人员写一个设计文档给编码人员，编码人员再编码交给测试人员，到这里就只剩下1/8的知识了。所以有必要减少交接的次数，交接时也尽量使用面对面的交流，可以采用一些模拟的方法尽可能的传递更多的知识。

5. 工作转换（task switching）

软件开发是需要集中精力的工作。《人件》上说过，程序员需要15分钟才能进入工作状态，如果被打断，即使只是1分钟，也需要再花费15分钟才能再把脑子装满工作的上下文信息，从而再次进入工作状态。因此程序员需要一个安静的工作环境，才能最高效的工作。很多人也提倡安静时间这个概念，比如早上10到12点，所有人都呆在自己座位上，把手机铃声关掉，没有会议，没有电话，专心工作。只可惜我现在的工作环境离安静差太远了……

有些公司可能会让员工同时参加两个甚至项目，每天不断的切换，一会儿写这个项目的代码，一会儿参加那个项目的会议，这样的结果往往是两个事情都做不好。应该尽量减少这种情况，让员工在一定时间段内专心的做好一件事。

6. 延迟（Delay）

各种各样的延迟在项目进行过程中可谓无所不在。项目要高层批准，有延迟；分配人员，有延迟；出了问题去解决问题，有延迟；等待一个必要的组件，有延迟……

在我做过的项目里，通常最大的延迟就是和国外（日本或者美国）同行之间交流的延迟了。一般情况下我们都是写邮件给国外同行，如果是日本的话，即使很快收到回信，但还需要进行翻译，这样几个来回，浪费的时间还是很可观的。如果美国，因为时差的关系，我们的工作时间是完全不重叠的，即使有时美国同行会晚上在IM上进行一些交流，主要沟通方法也还是邮件。基本上今天发出的邮件，第二天才会收到回信。当然，对于个人来时，有时候乐的有这么一段空闲；但对项目来说这绝对是一种浪费。

7. 缺陷（Defects）

学过软件过程的都知道，缺陷应该尽早发现并修正，越晚修正，所需的代价就越大。假设在需求阶段发现一个缺陷并修正的代价为1，那么到设计阶段再修正它的代价可能就是10，到了编码测试阶段就是100，如果发布了之后才发现，那就不仅仅是修正的代价的问题了，因为此时产品的客户满意度或者名声已经收到了损害。

减少缺陷，除了依靠优秀的分析、设计以及编码外，最重要的就是测试了。测试不是用来发现缺陷，而是用来预防缺陷的。要预防缺陷，那测试的自动化就是非常重要的了。再通过测试驱动等方法，使的有缺陷的代码根本就不会进入到产品中去。在这里，测试其实已经不仅仅是测试了，而且也是设计或者说Specification，单元测试相当于详细设计，接收测试相当于功能测试。

上面7种浪费有些其实是互相关联的，比如为测试的代码会产生缺陷，重新学习和工作交接会场生延迟。

 

最后要说说造成浪费的一个重要因素：复杂性（Complexity）。上面提到的浪费，本质上都是由复杂性造成的，组织的复杂性，流程的复杂性，设计的复杂性等。所以消灭浪费最重要的一个原则就是KISS（Keep it simple, stupid!）。不但要简单，而且要简单的刚刚好，这是需要很深的功力的