李智桦，在软件开发领域已有多年的实践经验，他对信息及软件应用开发的热情和投入令人佩服，包括新兴的行动及云端开发技术的研究，近年来投身于敏捷、精益及看板方法的推广并担任讲师，本书可以让更多人了解这些软件开发及项目管理的实用方法并应用于工作领域之中，值得阅读！
　　拥有超过30年的软件开发工作资历。从早期的大型银行系统到近年来专注于微软各项新技术的研究，是微软Windows Azure云端及其他新开发技术的指定讲师，担任多届TechDay、TechED等大型研讨会主场演讲。过去是资深的开发人员、大型系统及企业的总架构师，有长期同时带领多个团队的ScrumMaster大型项目经验。他对信息技术的热诚及坚持，至今仍对新技术的动手实操不遗余力，是少数拥有如此丰富资历、能讲、能教、随时能上手的信息界老兵。

　　李淳  Certified Scrum Master、Certified Scrum Product Owner，曾先后在用友、易车等公司任程序员、研发经理、架构师、产品经理，敏捷和精益倡导者，团队敏捷转型实践者，公众号“互联网plus管理新范式”（iPlusLeadership）维护人。代表译著有《软件需求（第3版）》

　　第1章
　　精益软件开发
　　1-1  精益的由来
　　“精益”（Lean）这个词汇是约翰?克拉夫西克（John Krafcik）1988年在他的一篇文章 里率先提出来的，但他所称的精益制造（Lean production），指的是制造业的精益理论，而软件界的精益（Lean）则称为精益软件开发（Lean Software Development），它源自于波彭迪克夫妇（Mary Poppendieck 和 Tom Poppendieck）在 2003 年的著作《精益软件开发工具》（Lean Software Development：An Agile Toolkit），书中阐述了精益软件开发的七大原则，精益属于敏捷开发的成员之一。
　　敏捷软件开发（Agile software development）是从 1990 年代开始逐渐取代传统开发方法的一些新型软件开发方法，是一种应对快速变化需求的软件开发能力。相对于传统开发方法，敏捷软件开发最大的差异在采用迭代式的开发模式，而不是一次定江山的瀑布式开发模式，以及接受客户对需求合理的变更（让客户对需求做出不同优先等级的区分，并尽力去满足它）。
　　敏捷（Agile）一词起源于 2001 年初，敏捷方法发起者和实践者在美国犹他州雪鸟滑雪圣地的一次聚会，有 17 位当代软件代表人物共同签署了敏捷宣言，并成立了敏捷联盟。但在此之前，早在 1991 年麻省理工学院出版的“改变世界的机器”（The Machine That Changed the World）研究报告中，就已经把日本丰田公司的丰田生产方式系统（TPS）归纳成为一套精益生产（Lean Production）方法。
　　严格来说，精益（Lean）比敏捷（Agile）要早诞生许多年，但现在拥戴精益的人士也已经加入了敏捷联盟的阵营（见图1-1），虽然他们依然遵循着精益精神的七大原则而不是敏捷的四大宣言和十二项原则，但实质上他们都共同拥护敏捷式的开发方法及精益精神，二者并无抵触。
　　图1-1  敏捷伞下的两大阵营
　　1-2  精益软件开发
　　精益软件开发并没有具体的开发方法或步骤，而是一堆原则，原因是它认为没有所谓的最佳实践。“原则”具有较广泛的普遍性，能指导对某一学科的思考和领悟，而“实践”则是为执行原则而采取的实际措施，需要针对某一领域进行调整，尤其必须考虑到具体实施的环境。精益软件开发是由软件开发领导者，例如软件开发部经理、项目经理和技术领导者，而不是一般程序开发人员所创设的思想工具。
　　因为精益软件开发没有具体的实行方法，这会让你觉得它只是一些原则和教条，执行起来应该是最简单的，影响也不大，即便做错了也是无害。如果这么想的话就错了，因为“原则”所影响的是企业的文化层面，比起单纯的开发方法影响大得多了。
　　依照图1-2的区分，右边第二位隶属于精益开发体系下的看板方法（Kanban），是距离胡作非为（Do Whatever，“胡来”，也就是完全没有规范）最接近的敏捷开发方法。越往右侧的开发方法就表示规范越少，我们称为轻量级（light weight）的软件开发方法，越往左边的开发方法则是规范越多，相对于轻量级的开发方法有较多的约束，我们称为重量级（heavy weight）的开发方法，例如RUP（Rational Unified Process，统一软件开发过程）。
　　本章的主旨在于阐述如何将精益的精神由原则转换为适用于特定环境下的敏捷实践。说得更精确些，就是针对七大原则加以实践的诠释，目标是看板系统，尤其是依靠经验法则换来的经验知识 。
　　图1-2  依照规范的多寡由左至右排列各种开发方法
　　图1-3  在精益网络的时代，充斥着各式各样的对象
　　如图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 分钟的专心工作，这一点请参考蕃茄工作法 。
　　如何识别浪费？
　　丰田生产系统的策划人之一新乡重夫（Shigeo Shingo），他首创制造业的七种浪费类型，而波彭迪克夫妇则将它转换成软件业的七大浪费类型，对照如下表所示。
　　制造业七大浪费    软件业七大浪费
　　1    库存    半成品、部分完成的工作（Partially Done Work）
　　2    额外过程    额外过程（Extra Processes）
　　3    生产过剩    多余功能（Extra Features）
　　4    运输    任务调换（Task Switching）
　　5    等待    等待（Waiting）
　　6    移动    移动（Motion）
　　7    缺陷    缺陷（Defects）
　　判别是否浪费十分重要，它是你避免浪费的基础。接下来的说明虽然看起来冗长，但请务必读完，每个项目的最后会括号说明相对于看板方法的运用手法，譬如你不知道该如何建立看板的垂直字段或调整 WIP（半成品）值，即可参考以下的几条原则，将它们作为依据。
　　……

第1章  精益软件开发    1
1-1  精益的由来    2
1-2  精益软件开发    3
1-3  精益软件开发七大原则    5
1-4  结论    27
第2章  看板方法    29
2-1  看板的由来    30
2-2  何为“看板方法”    30
2-3  看板方法四大基本原则（Foundational Principles）    32
2-4  为何要使用看板方法    39
2-5  哪些地方可以运用看板方法    45
2-6  结论    48
第3章  看板方法的六大核心实践    49
3-1  可视化目前的工作流程    50
3-2  限制半成品（WIP）数量    58
3-3  管理工作流程    65
3-4  让规则明确    69
3-5  落实反馈循环    71
3-6  由协作改善，经实验演进    72
3-7  结论    75
第4章  如何实施看板方法    79
4-1  看板墙的设计    80
4-2  Scrum 运作模式的看板墙设计    91
4-3  看板一日游    94
4-4  运行看板方法的简单规范    106
4-5  结论    111
第5章  个人看板：类项目管理    113
5-1  个人看板    114
5-2  制作第一个个人看板    115
5-3  个人看板与软件开发：类项目管理    124
5-4  结论    140
第6章  个人看板与生活：让生活与工作相得益彰    143
6-1  开始使用看板    144
6-2  生活与效能    148
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