精益开发与看板方法

李智桦    著

李  淳  审校

清华大学出版社

北京

前    言

精益软件开发不同于一般的敏捷开发方法，它是属于文化层面的改革，它没有特定的方法或流程，有的只是产品开发的概念及原则，非常适合主管层级的敏捷开发思想。精益软件开发没有具体的开发方法，它只有指导原则，乍看之下很像励志的书籍，但它的影响却远远胜过所有的开发方法，因为它将直接影响企业的文化，这一点就比其他开发方法的影响要深远多了。无需讶异它的威力，因为它来自丰田产品系统 TPS（Toyota Production System）。

“精益软件开发”没有规定实务性的做法，而是描述了更重要的实际流程定义、原则及价值观。原因是它一直认为很难有一种方法能够完全做到“敏捷”，而“原则”则具有较高的普遍性，因此一直到波彭迪克夫妇（Mary 和 Tom Poppendieck）的《精益软件开发工具》（Lean Software Development：An Agile Toolkit）一书出版，才有了比较明确的七大原则，就是我们所熟悉的消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、嵌入完整性、着眼整体等精益软件开发的七原则。

本书要描述的是在精益软件开发里独树一格的“广告牌方法”（Kanban Method），它是 2005 年由安德森（David J. Anderson）所创的一种渐进式的流程控制方法，它所依据的正是这七大精益原则。我把精益软件原则的说明放在开始的第一章，是希望读者能“由头到尾”体验在真实的情境下，如何依据这七个原则来做决定，让它成为你实施精益软件开发时的宗旨，而不至于失去敏捷的初衷。

真正引起我想写这本书的原因是，因为 Scrum 在迭代的任务板（Task board）上描述得太少了，实施 Scrum 的团队往往没有把任务板上的字段跟实际开发时的工作流程做正确的对照，以至于常常有各说各话的现象，也就是说任务板没有反应出正确的状况。当第一次看到广告牌方法的时候，我就立刻在自己所教的 Scrum 课程中将实施广告牌的方法隐含进来。说真的，这两个理论真是契合，我常常在课程中完全不提到广告牌方法，只是采用它绘制价值流程及半成品限额的理论，就成功地让广告牌方法运用在 Scrum 的开发流程中，学员们可能从头到尾都没有意识到我们正在实行广告牌方法。这一点果然如安德森所言，它是一种渐进式的改革方法没错！而且，实行广告牌方法所受到的阻力要比实施其他敏捷方法少很多，而且成效更佳，如果你怀疑的话，欢迎你继续往后看。

李智桦 

推荐序1

活用敏捷及精益观念──大有用途，并不只限于在软件项目中使用！

敏捷及精益的议题这几年来快速地兴起，然而这些观念及方法不只是应用在软件开发上，现在也跨界了，例如目前热门的精益创业（Lean Startup），用敏捷及精益的方式及精神进行新创事业，在软件这个行业，我自己也是程序开发出身，曾经担任系统分析及项目经理，目前从事的是产品营销及技术推广工作，也在向不同领域的软件团队推广敏捷及精益开发，当我愈是深入了解敏捷的精神，愈是深深觉得人人都应该有敏捷及精益的观念，不只是开发者及RD应该了解，包括营销、支持部门及管理层主管若也能有敏捷的观念，工作上应更能得心应手。另一个跨界应用是敏捷营销（Agile Marketing），早已有营销界的达人应用敏捷规划方法来执行营销计划，有兴趣者可自行上网找到相关数据。因此，当听说李智桦老师打算写一本关于精益及看板方法的书籍，将其多年的实践经验分享给软件研发的伙伴们时，我着实感到兴奋！

你可能也听过这些名词，比如敏捷（Agile）、精益（Lean）、看板（Kanban）等，有些人第一次听到这些名词可能以为又是什么伟大的管理方法，其实敏捷及精益是非常注重实用性的，也不是只能照本宣科套用到每一个团队中，但一些共通的精神及观念构成了所谓的中心思想或敏捷思维，比如下面的例子。

l   认知市场及需求会不断地变动
第一次听李智桦老师（Ruddy）演讲关于敏捷及精益开发时，开门见山就提到这个观念。你是否曾经与使用者（user）谈谈，辛苦做完系统分析，但上线后他们却认为这不是自己想要的呢？这是软件工程中老生常谈的话题，工程师常常抱怨“客户又改需求了。”“这不是上次访谈中确认的规格吗？为什么又要改了？”然而一个真正有敏捷精神及心态的专业工作者，应该反过来先认清“需求”是会不断地变动的，因为这个世界、技术、你的竞争对手、市场一直在变化，你无法冻结它，该做的是在可变动的范围保留一定的弹性，并且设定执行的优先级。

l   精益思维中所谓的“减少浪费”
按照精益原则，任何不能为客户增加价值的行为即是浪费，以软件开发项目为例，“没有必要的功能或需求”是很明显的浪费。常常听到一些案例，研发团队自己觉得这个功能很酷，用户一定很想要这个功能。但这些需求真的都是必要的吗？若你不能列出需求的优先级（Priority），很容易就落入这样的处境。要很清楚你的用户之行为，什么功能／需求是对他们最有价值的，设定正确的优先级，或是建立更精简的使用流程，自然就能少做无谓的功夫，减少浪费，本书中“消除浪费”这一节，很值得所有知识工作者阅读！

l   使用者参与并尽早取得反馈
这点是软件开发团队常常忽略的，关在办公室或实验室中“想象”使用者的需求，或是由工程师的观点，自己认为使用者要什么，这并不是好的做法，你应该定期产出软件，让用户尽早验证这些功能是否满足需求，让用户或是数据反馈你哪些是重要的功能、哪些功能不好，或是从中观察使用者的操作经验，使软件能够在下一个周期持续改善。

包括微软自身的研发团队，也已渐渐地迈向敏捷及精益开发以迎向快速变化的移动及云端时代，微软的团队开发平台 Team Foundation Server或是云端版 Visual Studio Online，也都已内建了敏捷开发 Agile/Scrum及 Kanban（看板）等方法所需的相关工具，例如 Backlog Management、Sprint Planning Tool、Agile Portfolio Management、Task board 及 Kanban board 等，也提供了开发团队所需的基础服务，例如版本控制、测试管理、Issue Tracking、CI（Continuous Integration）& Build等。更好的是，这些工具 .NET、Java、Web/HTML、iOS、Android、Windows等各种技术开发团队都可以使用!

李智桦老师（Ruddy）在软件开发领域已有多年的实践经验，他对信息及软件应用开发的热情更是令人佩服，包括新兴的移动及云端开发技术的研究，更是投入很多精力，近年来更是投入于敏捷、精益及看板方法的推广并担任讲师，本书可以让更多人了解这些软件开发及项目管理的实践方法并应用在工作领域上，值得阅读！

吴典璋（Dann Wu）

台湾微软开发工具及平台推广处资深产品营销经理

推荐序2

在我多年敏捷咨询过程中，经常需要进场拯救那些将Scrum实施成小瀑布的项目，这些项目结局，往往比大瀑布还差，基本上都是一个套路：开会、加班、裸奔、上线、崩溃，有些项目我们救回来了，有些则是积重难返。软件研发是一个复杂系统，任何一种试图避重就轻，组合“最佳实践”，就宣称自己是万灵药的方法（框架），都只是另一个形式的成功学而已。

精益看板方法则不同，他承认软件研发的复杂性，他认为没有最优，只有目前最适合。软件研发的本质是信息加工和流动的过程，精益看板方法让团队利用可视化方式观察信息流动过程，让团队学会利用这些信息来自主决策，逐步改善拥堵，加速流动。本书是一个非常好的看板方法入门读物，对精益软件开发源流、看板方法思想根源都进行了深入阐述，同时本书还大力着墨介绍了个人看板，一种我大力推荐的个人生产力提升工作方式。

我国正进入一个“大众创业、万众创新”时代，目前“风口论、产品论”盛行，到处有人教你如何马上找到风口，打造爆款，这又是一种新时代成功学。在这时，我们恰恰更需要精益思想，快速交付，快速验证，快速试错才是王道，风口是摸索出来的，产品是打磨出来的，别指望一击得手。相信这本书会帮助大家打造一个更快速的产品交付流程，读者还需要结合精益创业、精益度量分析、精益客户开发等方法，才能很好地在这个创新海洋里面畅游。

吴穹（Adam Wu）

平安科技首席外部敏捷顾问

国内第一位看板专业教练（KCP）

致   谢

谢谢为了陪我写完这本书而喝过十多家台北咖啡店的老婆淑华，这也是书的封面为何采用咖啡印记的原因，它是我们共同的永恒回忆。

还要感谢孩子体谅父母亲专心工作时给他们带来的不便，我们永远爱你们：孟蓁、玉扬、孟哲、瀞萱及裕嘉。还有家里年纪渐大的狗，知世，请继续叫吧！

目    录

第1章  精益软件开发    1

1-1  精益的由来    2

1-2  精益软件开发    3

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

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

1-3-2  增强学习（Amplify learning）    11

1-3-3  尽量延迟决策（Decide as late as possible）    14

1-3-4  尽快交付（Deliver as fast as possible）    17

1-3-5  授权团队（Empower the team）    20

1-3-6  嵌入完整性（Build integrity in）    22

1-3-7  着眼整体（See the whole）    25

1-4  结论    27

第2章  看板方法    29

2-1  看板的由来    30

2-2  何为“看板方法”    30

2-3  看板方法四大基本原则（Foundational Principles）    32

2-3-1  原则1：从既有的流程开始    32

2-3-2  原则2：同意持续增量、渐进的变化    34

2-3-3  原则3：尊重当前的流程、角色、职责和头衔    36

2-3-4  原则4：鼓励在各个层级上发挥务实性领导行为    37

2-3-5  四大基本原则的意义    38

2-4  为何要使用看板方法    39

2-5  哪些地方可以运用看板方法    45

2-6  结论    48

第3章  看板方法的六大核心实践    49

3-1  可视化目前的工作流程    50

3-2  限制半成品（WIP）数量    58

3-2-1  利特尔法则    59

3-2-2  多任务是不好的？看板方法如何处理多任务    61

3-2-3  怎么样的数值才会让人满意呢    63

3-2-4  根据请求的多寡分配产能    64

3-3  管理工作流程    65

3-4  让规则明确    69

3-5  落实反馈循环    71

3-6  由协作改善，经实验演进    72

3-7  结论    75

第4章  如何实施看板方法    79

4-1  看板墙的设计    80

4-1-1  三个基本元素    80

4-1-2  顺序处理状态 VS. 并行处理状态    81

4-1-3  工作项目的属性    84

4-1-4  加入 WIP 限额    86

4-2  Scrum 运作模式的看板墙设计    91

4-2-1  将看板方法融入 Scrum 的开发过程    91

4-2-2  在 Scrum 中运用看板    92

4-3  看板一日游    94

4-3-1  看板一日游 1/12 说明    94

4-3-2  看板一日游 2/12 说明    96

4-3-3  看板一日游 3/12 说明    98

4-3-4  看板一日游 4/12 说明    99

4-3-5  看板一日游 5/12 说明    99

4-3-6  看板一日游 6/12 说明    100

4-3-7  看板一日游 7/12 说明    101

4-3-8  看板一日游 8/12 说明    102

4-3-9  看板一日游 9/12 说明    103

4-3-10  看板一日游 10/12 说明    103

4-3-11  看板一日游 11/12 说明    104

4-3-12  看板一日游 12/12 说明    105

4-4  运行看板方法的简单规范    106

4-5  结论    111

第5章  个人看板：类项目管理    113

5-1  个人看板    114

5-2  制作第一个个人看板    115

5-2-1  可视化    116

5-2-2  设定 WIP 限额    119

5-2-3  看板管理：开始运行拉动系统    120

5-3  个人看板与软件开发：类项目管理    124

5-3-1  项目的范围    124

5-3-2  建立个人看板    125

5-3-3  个人看板一日游    127

5-3-4  另类的个人看板    137

5-4  结论    140

第6章  个人看板与生活：让生活与工作相得益彰    143

6-1  开始使用看板    144

6-2  生活与效能    148

6-2-1  消除浪费    149

6-2-2  梦想与目标    150

6-3  个人看板进阶    156

6-4  结论    157

第7章  预测未来：减少变异性，增加可预测度    161

7-1  系统思考    163

7-2  内部变异    167

7-3  外部变异    174

7-4  结论    177

第8章  持续改进    179

8-1  看板方法的问题管理    181

8-2  运用看板方法自然形成简单的团体规范    183

8-3  没有银弹（No Silver Bullet）    186

附录    189

附录A  精益咖啡    190

附录B  Scrum But 和 Kanban But 194

附录C  用户故事图谱：对付需求模糊的好帮手    199

附录D  敏捷开发需要哪些文件    203