《精益开发与看板方法》—1-3 精益软件开发七大原则

1-3  精益软件开发七大原则

以下为精益软件开发的七大原则：

1. 消除浪费（Eliminate waste）

2. 增强学习（Amplify learning）

3. 尽量延迟决策（Decide as late as possible）

4. 尽快交付（Deliver as fast as possible）

5. 授权团队（Empower the team）

6. 嵌入完整性（Build integrity in）

7. 着眼整体（See the whole）

乍看之下，你可能觉得这些原则感觉上像口号一样，真的有用吗？让我告诉你，当你在绘制看板时（也就是将你的工作流程放到看板上成为一个或多个垂直字段时），你所依据的便是对这几条原则的了解程度。如果你觉得很陌生的话，下次改变看板外观时，一边看着这些行列一边思索是否需要改善哪里？改的原因是什么？想达成哪一条原则？多练习几次就熟了。记得一次只改善一个地方就好，这样比较容易看出是哪个异动所造成的结果，这一点跟改 bug 是一样的，一次同时修改好几个地方，就搞不清楚谁才是真正的元凶！

 1-3-1  消除浪费（Eliminate waste）

何谓浪费？凡是对客户或产品不具备提升任何价值的行为，基本上都是一种浪费！

Bug 是第一大浪费

程序开发人员最大的浪费，便是在开发工作时制造一大堆 bug，然后再费尽心力把它解决掉。有趣的是，解决这些 bug 之后还能获得相当的充实感！反倒是很少有人会回过头来检讨这些 bug 实际上都是自己所造成的。会有这些 bug 产生，其实是软件的复杂性所造成的，是我们把程序写复杂了。而如何减少 bug 呢？就是想办法把程序写简单一点，只有很简单的程序，bug 才会相对减少。如果程序复杂了，最后便只能靠测试来守住质量，这一点也间接说明开发和测试实际上是一体两面，开发者必须负起减少 bug 的第一线任务，因为它才是最大的浪费。

现在的程序开发工作太复杂了

开发软件最重要的是知道要做什么，然后去做，就这样简单！

但经过岁月不断的累积之后，我们把这个过程变复杂了。是那些有智慧的学者不断地把经验奉献出来，针对各种不同问题提出解答（设计模式便是这样诞生的），智者怕我们重蹈覆辙便想办法把经验积累下来，原意是为了照顾后进，结果却是把开发工作越弄越复杂（HTML 的演进史就是这个缩影）。十年前的软件开发项目，经过十年后规格并没有太大改变，但我们却可以把它弄得越来越有学问，看起来越专业，专业到必须有相当的学习过程才足以开发十年前就能做到的事！程序在执行速度上变快了，但是在质量这一点上却始终没有太大的提升，原因是我们把自己弄复杂了，我们一再地把开发程序的门槛弄高了，而复杂所带来的最大罪恶便是浪费，所以消除浪费便成为近代工程师要学习的第一要务。

“简单”是对付 bug 的有效法则

想要减少 bug，就是把程序弄简单些让自己随时都能看得懂。开发软件时，bug 总是自动在过程中被隐含进来。通常，一知半解写程序是制造bug的最大元凶，这种 bug 最难以检测出来，再来则是逻辑思维被打断也是在写程序时很容易产生bug的时候。所以在进行工作分解时，最重要的是“简单化”，简单是减少 bug 的最佳处方。话虽如此，但很多时候软件开发就是这么复杂，该如何是好呢？

“错误的估算”便是一个简单不下来的原因。千万不要在没有做适度的拆解问题（工作项目）下进行时程的预估，因为那完全是在猜猜看！猜是人类最糟糕的预估了，最少也要有参考依据（有参考依据可以让预估准确许多，例如找到可以比较的案例），但是必须经过拆解成为较小的工作单元，参考才足以成立。所以在减少浪费的前提下，“先拆解再简单化”是开工之前（或是进行工时预估前）的必备动作，正确的拆解可以避开那些不必要的复杂性干扰。

项目经理（PM）习惯向开发人员要求预估需要多少开发时间，想借助工程师每个人的预估，然后合计起来，以得到团队的整体开发时程（当然再加上一点自己习惯性的保险时间）。这是一种将项目分解成多个区块，然后针对各个区块进行预估的作法。这样所估出来的工时乍看之下是会比较准确，但是却忽略了工程师本身所估算的数据本来就是基于一种猜测得来的数值，根本上就已经不准确了。所以，虽然已经经过拆解，但这是基于工程师个人的猜测而来，当然就没有太大的意义。

什么样的估算才比较准确呢？老实说，只有进行一段时间，有更深一层的了解后再来估算自然会准确许多。这种较准确的估算通常发生在项目进行五分之一到三分之一之间，这是一件耐人寻味的事，此时工程师对项目的把握度就可以大幅提升，这个时候的预估就可以接近于“承诺”了。

工程师的承诺与预估

项目开始时工程师无从参考比较，此时的工时估算应该只能说是猜测；一旦项目开始进行后，随着对项目的了解增加，通常工程师在开发工作进行到五分之一到三分之一之间，由于对任务越来越熟悉，自然就可以做比较有把握的预估，这个时候的估算就可以称之为“承诺”。

写程序想要减少 bug，专注（Focus）是最有效的良方。这里讨论的专注是指“短时间”的专注，而不是废寝忘食、长时间疯狂做某一件事的专注。短时间指的是 25 分钟的专心工作，这一点请参考蕃茄工作法[1]。

如何识别浪费？

丰田生产系统的策划人之一新乡重夫（Shigeo Shingo），他首创制造业的七种浪费类型，而波彭迪克夫妇则将它转换成软件业的七大浪费类型，对照如下表所示。

判别是否浪费十分重要，它是你避免浪费的基础。接下来的说明虽然看起来冗长，但请务必读完，每个项目的最后会括号说明相对于看板方法的运用手法，譬如你不知道该如何建立看板的垂直字段或调整 WIP（半成品）值，即可参考以下的几条原则，将它们作为依据。

l   部分完成的工作
“半成品”的英文是 Work-In-Process（WIP），虽然翻译成“在制品”看起来比较贴切，但我偏好采用“半成品”这个字眼。所谓“部分完成的工作”，它是一种***，一个随时可能会失效的功能，因为它有可能还没上场就被换掉了（原因是你提前做了）。另外是太早做可靠度就差一些，虽然你可能用单元测试来保证它的输入和输出值，但在还没有经过整合之前，没有人可以保证它是好的，所以就投资报酬率而言，它是最不理想的半成品。在团队开发流程中，尝试把半成品控制在最小范围内是最理想的状态，也是减少浪费的好方法。（对看板方法而言，可以用来限制WIP值，产生盈余时间[2]或是看到瓶颈所在，这一点可以通过累积流程图来进行观察）

l   额外过程
文档工作是一种最有争议的额外过程，它会消耗资源，降低反应速度，还会隐藏风险；但相对的它可以让客户签字表态，或是取得变更许可，或是便于追踪。几乎所有的软件交接都需要文件，但是基本上它是不会产生增值的，所以也是一种浪费，但若是基于需求上的工作，则可以把它视为是一种增值。请注意，好文件应该保持简洁、具有概念性、便于做交接。（盈余时间最适合用来写文档，工程师要学会把文件交给自己做）

l   多余功能
有句古老的名言：“当你新增功能时，也同时新增了 bug”，意思是尽量减少不必要的功能！一般的程序设计师总以为突发奇想的功能是一个不错的想法，为了未雨绸缪就自作主张把它加进来了，老实告诉你这是最不好的做法，记得，只有在有必要的时候才新增功能，任何一段不需要的程序代码都是一种浪费，千万要懂得抵抗自以为能够有先知卓见这种未雨绸缪能力的诱惑。（额外的程序代码将会挤占半成品的数量限制，通过累积流程图可以很清楚地界定它的影响）

l   任务调换
多任务是一种浪费[3]，给员工同时间分配多种工作是项目产生浪费的一个根源。软件开发人员每次在转换工作时都会浪费大量的调换时间，因为他必须调整思路以便投入新的任务流程。当然，若是你同时参与多个开发团队，自然会造成更多的停顿，从而引起更多的任务调换而浪费更多时间。（限制WIP值就是为了减少这种浪费）

l   等待
在团队进行协同开发时最浪费的可能就是等待。有时候等待上级或第三方的响应，例如：等待电子邮件的回函或通知，这种必然存在而且无法改变的过程，就是一种浪费。（这种必然的等待可以在看板上增加一个垂直字段特别来处理它，如此可以让我们更明确知道现在的状态？）

l   移动
当开发人员遭遇无法立刻处理的问题而需要他人协助时，他需要移动多少距离才能找到问题的答案？是立即就能得到解答？还是需要继续移动到其他房间要求其他人的协助呢？这就是一种浪费。当然人不是唯一会移动的，各类文件也会移动，尤其是测试文件的流程，也可能造成庞大的浪费。（这种事务型的开销，在看板上面表现得越明显，就越容易被纳入解决方案的考量）

l   缺陷
缺陷也常常被翻译成漏洞，是指在软件执行中因为程序本身有错误而造成的功能不正常、宕机、数据丢失、非正常中断等现象。缺陷（bug）所造成的影响，取决于它被发现的时间和它的大小，越早找到缺陷越好，在写需求的阶段就被测试人员发觉，是最好不过的。（文件审核有时可以帮助尽早找到缺陷）

能够尽早处理掉问题绝对胜于交给客户之后才发现，因此就有人发明，从一开始写程序就开始做测试的方法，称为“测试驱动开发（Test Driven Development，简称TDD），就是希望能尽早找到缺陷并即刻修复。类似的方法（ATDD、BDD等）大部分也都有自己的价值，也都在市场上占有一定的比重，但是软件界尚未找到一种足以被大部分程序设计人员完全接受的开发方法。所以借助频繁集成及发布是一种较容易受到客户肯定的行为，也是避免重大浪费的必要小浪费。

软件开发是一门艺术还是一门科学呢？由程序诞生的方式到我们除错解决缺陷的方式看来，艺术的成分还真是占据蛮大的比例，因此软件开发是一门工艺是目前比较被接受的一种说法。也就是说，我们很难完全不靠经验来开发软件，丰田式的生产方式对软件界而言仍是一种梦想，而我们也只能在类似的精益原则上尽量多学习和借鉴。

看到浪费

浪费只要看见了就容易改善。通过识别哪些行为是浪费，它们是如何造成浪费，可以让我们更容易看到真正的问题所在，也就能“消除浪费”。看板方法能让问题成为大家都知道并都看得见的事，如此便可以通过改善的方式（行为）来避免不必要的浪费，这是精益软件开发法的第一个原则。不浪费本来就很合理，但在运用上，由于软件开发有别于制造业，因此受争议之处特别多，宜视环境时时调整。图1-4是一个游戏开发公司的开发流程图，我们把大的开发步骤以及这些步骤所花的工作时间用时间轴画出来，就可以很容易看出对开发工作没有增值的部分，也就是浪费的地方。

图下方有两条时间轴表示浪费及增加价值的时间数值。上面一条是明确的时间值，下面一条则是指标式的示意图（图中用了两种不同的图示，目的在阐述数字大小代表的只是一个粗略值，在某些时候用比例来区分可能更合适些）。整个流程的统计结果显示在右侧，浪费的时间为 21.3 m（月），而真正拿来增值的工作是3.5 m（月），二个数字相除以后得到产出率为 14%。一旦通过分析让人们看见浪费的根源，通常就会开始产生一种想要改善的冲动，这便是可视化后的一种催化效益。

图1-4  游戏开发工作的流程图

软件是知识型的开发活动，对于浪费的界定比制造业复杂许多，所以请先判断它是“直接的浪费”或是“间接的浪费”。所谓“直接的浪费”指的是没有其他效益的活动，它纯粹就是浪费工时，我们很直觉地可以判断的浪费行为。“间接的浪费”是除了产生活动还有其他效益的活动，例如增加团队沟通协作的活动，我们便可以称它为间接浪费的工时。因此在我们考虑消除浪费的时候，间接浪费应该被排在最后，属于非必要时无须消除的范围，因为一旦消除间接的浪费活动，也就失去了它相对所产生的效益。