精益产品开发：原则、方法与实施

在人类与AI共存的移动互联网时代，VUCA特性（易变、不确定、复杂和模糊），如何充分运用精益思想与看板实践，在注重资源效率的同时提升流动效率？为此，本书开创性地提出一个行之有效的、适用于软件开发领域的“精益产品开发体系”（Lean Product Development）。作为国内*本敏捷精益软件产品开发原创作品，《精益产品开发》凝聚着作者十几年落地实施经验，从原则、方法和实施三个层面梳理和阐述精益敏捷开发体系，主题覆盖需求管理、过程改进、质量提升、团队建设、DevOps落地过程中所涉及的关键要素，案例来自华为、招行、平安以及多家互联网新创企业的一线实践。 

全书共25 章，分成三个部分，分别介绍了精益产品开发的原则、方法和实施。原则部分，从精益及敏捷产品开发的目标入手，梳理了敏捷和精益思想的来龙去脉和具体的实践框架，构建了系统和完整的精益产品开发体系。方法部分，以作者在华为、招商银行、平安科技以及数家互联网创业公司的大量成功案例为基础，详细介绍了这些案例背景、应用细节以及背后的原理和方法，构建了坚实、系统和可应用的实践方法体系。实施部分继续以真实案例为基础，总结了完备的精益产品开发实施路径，涵盖了需求管理、过程改进、质量提升、团队建设、DevOps 落地等实施中的重点要素。
本书适合所有准备实施或正在实施敏捷和精益方法以及希望改善组织价值交付效率、质量、灵活性以及产品创新能力的团队阅读与参考。

何勉拥有17年IT从业经验，先后担任过开发工程师、架构师、项目经理、部门经理等角色。他曾是宽带接入产品的项目经理，负责向全球交付主要的软硬件版本，同时还担任过300多人的软件开发部门负责人。何勉是国内早的精益产品开发实践者之一，作为咨询顾问，他先后在华为、招商银行、平安科技等公司负责引入精益产品开发方法，并加以全面推广和实施。他为多家新创公司打造过精益产品开发和创新方法，并帮助它们取得了业务上的成功突破。何勉目前专注于产品开发和产品设计及创新这两个方向的探索和实践，帮助组织提升能力，使其顺畅、高质量地交付有用的价值。他的个人公众号“精益产品开发和设计”（微信号LeanAction）很受欢迎。关注该公众号，可以持续获取作者的*分享并参与互动和交流。

目录

第Ⅰ部分　精益产品开发的原则

第1 章
从传统向敏捷软件开发的演进 ……………3

传统软件开发方式面临的挑战 ……………..3

从传统到敏捷 ………5

理解敏捷必须回归业务视角 ………………..6

敏捷产品开发的业务目标一：更早地交付价值 ………….7

敏捷产品开发的业务目标二：灵活地应对变化 ………….9

敏捷实践体系 …….10

第 2 章　精益产品开发的核心原则（上）：聚焦价值流动效率……………15

聚焦用户价值端到端的流动 ………………15

从资源效率到流动效率 …………………….20

协调多个团队才能提升流动效率 ………..22

第 3 章　精益产品开发的核心原则（下）：探索和发现有用的价值……..27

做一个能卖出去的产品 …………………….27

开发、测量和认知循环 …………………….29

从传统的产品定义方法到精益创业……..30

精益创业实践集合 32

第 4 章　精益思想和精益产品开发实践体系……35

精益思想的来龙去脉………………………..35

精益的三个层面….39

精益产品开发实践体系 …………………….41

第 5 章　经典天文学演进对产品开发方法学的启示 …………….49

经典天文学的三个里程碑………………….49

经典天文学演化过程给产品开发的启示.54

尊重历史，更要面向未来………………….56

第Ⅱ部分　精益产品开发的方法

第 6 章　看板方法和看板实践体系………………..61

看板方法的起源….61

看板形成拉式生产方式带来的收益……..64

产品开发中的看板方法 …………………….65

第 7 章　可视化价值流动（上）：案例………….75

案例背景介绍 …….76

初始的看板系统设计………………………..76

看板系统的重新设计………………………..77

案例总结 …………..79

第 8 章　可视化价值流动（下）：看板系统建模……………….83

看板系统设计的原则和步骤 ………………83

步骤一：分析价值流动过程 ………………84

步骤二：选取可视化设计元素……………87

步骤三：建模价值流动 …………………….94

第 9 章　显式化流程规则..97

组织并明确流程规则………………………..98

团队共同拥有规则 …………………………102

持续改进流程规则 …………………………103

第 10 章　控制在制品数量（上）：为什么要控制 …………….107

束水攻沙 …………107

产品开发中的在制品 ………………………110

在制品带来的问题 …………………………113

第 11 章　控制在制品数量（中）：控制什么 .117

暂缓开始、聚焦完成 ………………………117

以用户价值为单位控制在制品数量 ……118

控制而不仅仅是限制 ………………………119

第 12 章　控制在制品数量（下）：如何控制 ..123

湖水岩石效应 …..123

限制在制品的原则 …………………………124

限制在制品的常见形式 …………………..125

确定初始限制值 ..126

第 13 章　管理价值流动（上）：看板站会 …..129

站会的目标 ………130

站会的组织形式 ..130

站会重点关注的信息 ………………………131

站会过程 …………132

第 14 章　管理价值流动（中）：就绪队列填充 ……………….135

什么是就绪队列和就绪队列填充 ………136

建立就绪队列填充的节奏 ………………..137

组织就绪队列填充 …………………………140

第 15 章　管理价值流动（下）：发布规划会议 ……………….145

发布规划会议的内容和节奏 …………….145

部署和发布应该是两个不同的概念 ……147

解耦部署和发布 ..148

特性开关 ………..150

完美的敏捷愿景 ..152

第 16 章　建立反馈，持续改进（上）：定性反馈和改进 ….155

如何建立良好的反馈 ………………………156

关于顺畅程度的反馈 ………………………157

关于质量的反馈 ..159

将改进落实为具体行动 …………………..160

第 17 章　建立反馈，持续改进（下）：定量的综合反馈和改进………..163

累积流图 …………163

控制图 168

前置时间分布图 ..170

第 18 章　看板方法的规模化应用 ……………….173

融合两个看板系统 …………………………173

连接多个看板系统 …………………………175

向上下游拓展看板系统 …………………..177

层次化看板系统 ..178

第Ⅲ部分　精益产品开发的实施

第 19 章　实施精益产品开发，提高价值交付能力 …………….185

衡量和评价组织的交付能力 …………….185

流动效率和资源效率的关系 …………….186

从资源效率入手的改进无法持续 ………187

打破组织效率改进的困局 ………………..188

第 20 章　精益和敏捷需求：精益产品开发的源头 …………….199

在问题域分解需求 …………………………199

找到真正的问题 ..201

从问题到解决方案的进一步分解：影响地图 ………….204

挖掘、组织和规划需求：用户故事地图 ………………..208

端到端的需求流动 …………………………210

第 21 章　精益质量改进 .213

产品开发中的质量模型 …………………..213

实施精益质量改进的前提 ………………..217

落实精益质量改进的步骤 ………………..219

第 22 章　打造高效的自组织团队 ……………….227

自组织困难的根源 …………………………227

打开团队自组织的密码 …………………..229

自组织是管理提升的结果 ………………..232

第 23 章　对 Scrum 的洞察，以及 Scrum 和看板方法的比较 ……………237

Scrum 活动设计 .238

Scrum 角色选择 .241

对比 Scrum 和看板方法 ………………….242

第 24 章　实施 DevOps 的实践原则 ……………245

基础原则 …………246

实施原则 …………250

支撑原则 …………256

第 25 章　在具体上下文中实施精益产品开发 ..261

对产品交付过程的抽象 …………………..261

实施精益产品开发的步骤 ………………..262

精益产品开发实施中的基础和持续性的工作 ………….266

附录一　生成精益度量图表的模板工具 ………..269

附录二　物理看板和电子看板的比较及常见电子看板工具介绍 ………….273

附录三　精益产品开发相关图书推荐 …………..277

后记……………279

前言：新常态下的精益产品开发和创新

2008 年，我开始在自己的产品开发部门尝试敏捷实践，当时这样做是前卫的，有争议的。9 年后的今天，大部分组织争论的焦点不再是要不要变得更敏捷，而是“如何才能做到”，后者从来都是个难题。

10 年间，敏捷实践不断完善，但实施难度却变大了。不是我们的进步不够快，而是现实要求越来越高。移动互联网技术改变了我们的生活，对各个行业的冲击更加剧烈。新的商业模式和技术革新不断涌现，新入者随时有机会脱颖而出，传统的优势厂商则随时面临巨大的挑战。

美国军方曾经用四个特性来概括冷战后的世界：易变 (Volatility)；不确定 (Uncertainty)；复杂 (Complexity)；模糊 (Ambiguity)。它们的首字母合在一起是 VUCA，“VUCA World”在 20 世纪 90 年代是常用的军事术语，用以形容全球政治和军事格局。21 世纪以来， VUCA 被更多用于形容商业格局和企业所处的生态，成为我们当下移动互联时代和即将到来的机器智能时代的注脚。

在 VUCA 的世界中，黑天鹅和跨界打劫司空见惯。胜出者的共同特点是拥有快速反应和把握机会的能力以及系统化的试错、创新和价值创造能力。拥有这些能力就有机会快速上位，反之则随时可能被淘汰出局。而随着信息技术向纵深的发展，再传统的行业也不可能置身事外，这是企业运营和产品开发面临的“新常态”。

面对新常态，人们不再怀疑敏捷的必要性，而且要求的更多。产品的持续创新事关生死，产品开发部门不应该再被看成组织内部的成本中心，而是要成为价值探索、发现、创造和验证的创新中心，是企业的核心竞争力所在。

今天我们讲敏捷与 10 多年前相比，对它的要求发生了根本改变。 2001 年《敏捷宣言》发布时，针对的是软件开发，所以它的全称是《敏捷软件开发宣言》， 17 位起草人也全部是软件开发专家，宣言的本质是寻求更好的软件开发方法，强调了软件开发中的有效沟通、迭代交付和灵活应变。上图是宣言的内容，它引领了软件开发方法学的思潮，直到今天仍旧在发挥重要的作用，但今天我们再讲敏捷，要求有了以下本质上的提高。

我们尊崇“个体和互动”，更要“连接和打通组织的各个职能，以确保协调一致的行动”。

我们尊崇“可工作的软件”，更要“聚焦端到端的价值流动，以快速、灵活和持续地交付真实的客户价值”。

我们尊崇“客户合作”，更要“与客户建立共同目标，以化业务成果”。

我们尊崇“响应变化”，更要“有计划和系统地主动试错，以支持有效地学习和创新”。

“一致行动，快速、灵活和持续地交付真实的客户价值，化业务成果，有效地学习和创新”，这是新常态对产品开发组织的敏捷性要求。与这一要求相对应， 10 年间我们看到了另一个显著的变化——精益思想和实践被广泛和深入地应用在产品开发当中，无处不在。

•
精益成为几乎所有规模化敏捷框架（如 SAFe、LeSS 等）背后的重要方法学支撑。

•
精益看板方法得到越来越广泛的应用，为敏捷变革和提升组织交付能力提供了新的路径。

•
精益创业成为热点，精益创业理念和实践开始被广泛接受和实施。

• DevOps 实践开始普及，而精益价值流动的思想在 DevOps 实践体系中扮演了重要的角色。 2016 年下半年，我开始在自己的公众号“精益产品开发和设计”（微信号LeanAction）发文，总结精益设计和精益看板方法实践，受到了圈内圈外超出预期的关注，很多朋友从这些文章开始实施精益开发方法，我几乎每天都能收到不同形式的反馈。有

的甚至成立学习小组，每周学习一篇文章，坚持了数月。这让我决定更系统地总结精益产品开发实践，终形成今天您手上的这本书。

本书的目的是为组织的精益和敏捷实施和提升提供原则、方法和实施步骤的有效指引，帮助企业打造移动互联网时代的产品交付和创新能力。它的适用范围涵盖几个人的创业团队到华为与招行这样的大型组织。

写作本书时，我对自己有三个要求：其一，所有实践都必须有真实案例支持；其二，所有案例都必须来自本人的实践；其三，只选取那些被证明有效且易于实施的实践。

本书案例全部来自华为、招商银行、平安科技、上海爱数软件以及几家创业公司，作者与这些公司都有两年以上持续而深入的合作。

本书适合的读者

本书适合以下读者：

•
希望开始实施精益或敏捷开发的组织或项目管理人员

•
已经实施敏捷和精益开发，但遇到困难和阻力的组织或项目管理人员

•
已经实施敏捷和精益开发，希望进一步深化和拓展的组织或项目管理人员

•
希望了解精益和敏捷产品开发方法和实践的产品开发从业人员

•
希望提高产品开发交付和创新能力的各类角色

如何阅读本书

本书分成三部分，分别介绍精益产品开发的原则、方法和实施。

第 I 部分“精益产品开发的原则”介绍敏捷和精益开发的目标、思想和原则，并由这些原则出发，构建完整的精益产品开发实践体系。

第 II 部分“精益产品开发的方法”介绍看板方法实践体系，用看板方法来承载组织的交付流程和价值交付能力的持续改进。

第 III 部分“精益产品开发的实施”将从破解资源效率和流动效率的悖论出发，介绍精益产品开发的实施步骤，并详细介绍需求管理、质量改进、团队管理等方面的实践和实施。在这一部分，我还请到了两位大咖分享他们的的洞见和实践。其中，吕毅分享了关于 Scrum 的洞见，并比较了 Scrum 和看板方法，王津银分享了 DevOps 的实施原则。他们两位在各自的领域都是国内的实践者和专家。

本书三个部分具备一定的连贯性，同时也可以独立存在。大家可以根据自己的需要和兴趣有重点地阅读或作为备查。但是，我个人认为从头阅读收获会更大。

评论

第1 章  从传统向敏捷软件开发的演进在产品开发中，“敏捷”和“精益”这一对热词如影随形。精益产品开发离不开对敏捷软件开发的深入理解，所以我们的精益之旅也将从敏捷软件开发开始。本章讲述软件开发从传统进化到敏捷背后的业务动因以及敏捷软件开发实践体系。传统软件开发方式面临的挑战传统软件开发方法是与软件工程的概念一同诞生的（图1-1）。1968 年，北约（NATO）召开全球届以“软件工程”命名的会议，这次会议通常被视为软件工程诞生的标志。会议上提出了“软件危机”的概念。随着软件复杂度的不断提高，软件项目普遍出现预算超支、质量低、性能差、不符合实际需求和延期等问题，造成所谓的“软件危机”。图1-1　传统开发方法的产生历程当时，业界普遍认为，软件行业应该借鉴工程领域的经验，“系统地应用工程管理方法”，以此来应对软件危机。这是软件工程诞生的背景，在这一思路下产生的软件开发方法就是传统软件开发方法。它们共同的特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。相比作坊式的开发，传统方法开发方法进步明显。它让产品开发有矩可循，让项目和产品的成功可以重复，让组织的能力可以被评估，这些当然是好的。图1-1 是传统开发方法的大致发展历程，到了上世纪90 年代初，CMMI 和PMI 项目管理知识体系[1] 成为传统产品开发管理方法的典型代表。然而，传统方法并没有从根本上解决软件危机，软件项目的失败率依然居高不下，甚至越来越糟糕。在这方面被引用得多的是Standish Group 定期发布的IT 项目报告[2]，该报告在1994 年次发布时的数据显示，项目成功比例只有16%，有31% 在发布前就被“砍掉”，剩下的53% 平均超出了预算189%。人们认识到，遵循严格生命周期的概念，把开发分割为顺序阶段构成的过程，实施起来不现实，造成了以下直接的危害。• 希望通过对各个阶段设置关卡，严格控制，以期更早地发现问题，却滞后了集成和测试，让错误的发现延迟到后，这是很多项目失败的根源。• 希望一开始就能设定完整和正确的需求，这对软件产品越来越不可能，因为用户也不知道或说不清楚自己想要什么。事实上，对需求的挖掘和理解，应该是一个持续的过程，需要不断的反馈。• 把成功定义为“遵循初的计划和范围”。为了确保项目的“成功”而避免或拒绝进行合理的变更，却忽略了“达成商业目标才是真正的成功”。这已经成为业务成功的一个严重障碍。另一方面，传统产品开发方法强调控制，所以一旦流程出现问题，自然的应对就是进一步加强管控，流程本身有自我复杂化的趋势，反而会压制关键软件开发人员的主观能动性。面对以上问题，对传统软件开发方法的反思，几乎与其本身一样悠久。比如，瀑布模型的提出者Wiston Royce 1970 年在他的论文[3] 中，只是把瀑布模型作为一个理论模型提出，并警告人们它不适合用来进行大型软件开发。在论文的后半部分，Royce 提出了一个包含原型和各阶段之间反馈的修正模型。遗憾的是，业界当时渴望的是一种建构式工程方法，瀑布模型迎合了这一要求，导致反对瀑布模型的Royce 反倒被业界称为“瀑布模型之父”。至于Royce 的忠告，也只有等到30 年后敏捷运动兴起时才又被人们重新提起。从传统到敏捷面对传统软件工程方法的现实问题，一批轻量级的软件开发方法陆续涌现（图1-2），它们共同的特点是遵循演进和迭代的模型。其中，上世纪90 年代出现的Scrum 和极限编程在实践上为成功，它们都是迭代和增量的软件开发框架。两者的区别是，Scrum只包含管理实践，而极限编程同时涵盖工程和管理实践。图1-2　敏捷产生和发展的历程上世纪90 年代，另一个主要变化是PC 软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，使小型开发项目蓬勃发展，同时互联网应用和开源社区也在此时兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用越来越明显。这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，促使源自全面质量管理体系的CMM/CMMI 在这一时间迅速繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到新的可能。敏捷运动这时呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。2001 年2 月，17 位轻量级软件工程方法的代表人物齐聚美国犹他州的雪鸟滑雪胜地，在两天的会议之后，发布了对后来产生巨大影响的《敏捷软件开发宣言》[4]，如图1-3所示，敏捷宣言陈述了他们共同认可的软件开发方法理念，同样重要的是，他们找到“敏捷”这个词来总领这些理念。敏捷概念在2001 年出现，可谓适逢其时。当时一方面，传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展好的助推剂。很快，敏捷成为一场运动，被迅速推广和应用。