内 容 简 介

本书全面介绍了如何在敏捷环境中管理软件需求，全书共四部分24章。第I部分提出企业的敏捷需求全景图，针对项目团队、项目集和项目组合这三个级别，描述了一个整体的敏捷需求过程模型。第II部分描述一个简单的、轻量级的但同时又宽泛的模型，敏捷项目团队可以使用这个模型来管理需求。第III部分展示如何为需要多团队合作的复杂项目确定敏捷需求。第IV部分指导企业如何为大型的“专用系统”、应用套件和产品项目组合制定敏捷需求。

本书适合软件开发人员、测试人员、执行主管，项目/项目集经理、架构师和团队领导阅读和参考，可以帮助他们在敏捷转型过程中去除障碍，打造出优秀的软件产品。

 

 

前    言
对本书的介绍
在过去十年，敏捷运动向着更轻量、更敏捷的方法发展，已然成为自20世纪70年代瀑布模型出现以来对软件企业具有深远意义的最重要的变革。各种思想的融合加上一批实干家领袖，一些经过实践检验并取得成功的经验，证明了敏捷方法已经在“四个度量”上具有突出的优势，即：生产率、质量、员工士气和上市时间。
在过去五年中这些方法像病毒一样传播。在大型企业中，通常一开始是个别团队采纳各种方法中提倡的部分或全部的做法，从而使新倡仪开始得到贯彻。这些方法主要包括XP、Scrum、精益、看板（更晚一些）和各种混合变体。
不管怎样，随着对这些方法的运用扩散到企业级别，针对其基本方法的一连串扩展就是必须的，这样才能应对较大企业所遇到的在漫长开发过程、机构、应用范围和治理等方面的挑战。
其中敏捷需求工作所面临的挑战就比较严峻，其困难体现在要把团队敏捷性中一些基本、轻量的实践，包括产品待办事项、用户故事等，伸缩到满足企业的项目集和项目组合层面。举例来说，各种敏捷开发实践都引入、采用和增强了“用户故事”（起源自XP），作为表达应用需求的基本方式。而且，针对用户故事运用准时制的原则，可以提供更精益的方式，并帮助消除瀑布风格的许多陈旧做法，比如向开发团队强加的过于繁琐和束缚的需求规范。
虽然用户故事在观念上是强大的，但是用户故事本身不能提供一个充分或足够精益的框架，用以论证较大软件企业中项目团队、项目集和项目组合等组织层面的投资、系统级需求和验收测试。如何才能做到这一点？这正是本书的目的。
本书为编写和测试代码的敏捷项目团队提供了一系列标准的精益和敏捷需求子集，包括：敏捷需求工件的模型、相应的实践、建议的角色、组织模型。而且这种模型也可以伸缩到满足最大型软件企业的全面需要。
为什么要写本书
2000年的时候，我与Don Widrig一起出版了我的第一本书籍：《软件需求管理：统一方法》，这时我已担任软件开发管理的高级经理和企业经营者25年之久。2003年我们又出了本书的第二版：《软件需求管理：用例方法》，它们被认为是管理应用需求的权威书籍。这两本书销量不错，并被翻译成五种语言。更重要的是，许多个人、团队和公司告诉我，这些书籍帮助他们取得了更好的软件产出，而这一点始终都是我们的目标。
在接下来的几年里，我的注意力转向敏捷开发方法，我对这些创新方法的能量、运用这些方法所交付结果的质量和生产率以及它们激励和授权软件团队的方式感到越来越钦佩。虽然过去是在小型的团队环境中对这些方法进行研制和检验，构建大规模软件的挑战则是更有吸引力的谜题，这样的工作一部分是科学、一部分是艺术、一部分是工程、一部分是组织心理学。其结果是，我开始帮助一些较大企业采纳和改造这些方法，在这期间涉及的项目影响着数以百计甚至数以千计的软件从业人员。幸运的是利用一些扩展，就可以对这些方法伸缩来迎接挑战。基于这些经验，在2007年我出版了《可伸缩敏捷开发：企业级最佳实践》，这本书意在帮助较大企业实现敏捷开发的优势。
《可伸缩敏捷开发：企业级最佳实践》采取了更宽泛的软件方法视野，没有特别关注软件需求工作。尽管需求管理一直是许多敏捷团队的难题，但是组织和文化方面的挑战更为巨大，并且还需要处理的一系列新兴的敏捷技术实践。
在过去几年里，软件开发领域朝向精益思想的运动引起了我的兴趣，一部分原因是我过去有从事精益制造的背景。总的来说，精益思想为关于产品开发经济及其附属的软件开发的论证，提供了完整、有深厚理论依据的、严谨的框架。
后来我（和许多其他人）的思想进一步发展，我们开始把敏捷开发，尤其是大规模的敏捷方式，视为“精益思想的软件工业实例”。此外，精益思想的范围超出了软件开发的实验室，它还提供了工具来应对其他部门的变化，比如调度、IT、运销以及项目集和项目组合的管理。简而言之，精益思想为机构性的变革提供了更广泛的框架，它可以帮助我们处理这些较大的挑战，我是精益思想的爱好者。
精益关注的是价值流，并且为支持持续降低面市时间、加速价值交付以及消除浪费与迟钝，提供哲学思想、行为准则和工具，这是它的核心。如果软件企业采取精益的道路，将有助于优化它对需求的理解与实现，因为需求是价值流的独特载体，至少是最好的指标。
精益思想向我们重新演绎了一遍工作原理。再次强调，它有助于我们在敏捷的并且逐渐精益的软件开发范式中关注需求管理实践。这就是我撰写本书的原因。
我希望这本书能够帮助软件从业人员、项目团队、项目集和企业做出相应调整以采纳敏捷与精益实践，使他们可以为用户和干系人交付更好的解决方案，并且由此实现成功带来的个人和企业收益。
如何阅读本书
在这本书中，我会讲一个有点复杂的故事，也就是要以实用、直白、易于理解的方式，讨论如何应对敏捷企业所面临的软件需求管理挑战，无论是雇用几名开发人员构建单一产品的企业，还是雇用成千上万的软件从业人员、构建前所未见复杂系统的企业，都会面临这种挑战。
为此，本书内容分为四个部分，后面三个部分阐述了特殊的敏捷需求实践，其复杂程度和范围渐增。
第Ⅰ部分“概览：企业敏捷需求的全景图”
在第Ⅰ部分，我们介绍一个总体的过程模型，关于如何在项目团队、项目集和项目组合层面运用敏捷需求实践的“全景图”。
我们对软件方法进行了简单历史回顾，描述从瀑布到迭代和增量开发、到敏捷与精益的演化历程；而且介绍敏捷需求的全景图，这是一个关于组织、需求和过程的模型，可以用于团队，也可以伸缩到企业的全面需要。
然后是对这一模型的概述，并且例解如何把它用于团队的敏捷需求、项目集的敏捷需求和项目组合的敏捷需求。
这一部分的内容可以独立存在，它向你引进和介绍了敏捷需求有关的概念、术语和通用实践。
第Ⅱ部分“团队的敏捷需求”
在第Ⅱ部分，我们介绍了适合由敏捷团队用来管理需求的一个简单完备的模型。对这一部分模型被设计得尽可能轻量，不为敏捷团队增添任何不必要的复杂性和开销，这就是典型的敏捷方式。我们介绍了敏捷团队、用户故事、干系人、用户与用户表征、迭代、敏捷估算与速率、验收测试、产品负责人的作用，并在最后介绍了用于发现需求的一些方法。
如果你们团队正在采取敏捷方式，这一部分对敏捷需求的全面阐释正适合你。
第Ⅲ部分“项目集的敏捷需求”
第Ⅲ部分适用于那些涉及构建更复杂系统、经常要协调多支敏捷团队的机构。我们在全景图中进一步延伸，介绍其他一些需求工件、角色、组织结构和一些针对有关目标设计的可行做法。我们介绍了愿景、产品特性与系统特性、产品路线图、产品经理的作用、敏捷发布火车、发布计划、非功能性需求、需求分析技术，最后还包括了用例。
如果你是从事构建这种规模系统的开发人员、测试人员、经理、团队领导、QA、架构师、项目或项目集经理、开发总监，这部分内容正适合你。
第Ⅳ部分“项目组合的敏捷需求”
最后，第Ⅳ部分介绍需求实践的项目组合层面。在这一层面是希望指导企业构建不断增大的“超大型系统”、应用套件和项目组合，这些经常需要大量（20、50、100或更多）的敏捷项目团队的协调与合作。这一部分介绍一些其他的需求工件、角色、组织结构和针对有关目标设计的一些做法；介绍了在敏捷开发中大规模的系统级架构所发挥的作用；为论证这种系统如何以敏捷的方式演化并在必要时重新建构，我们引入了看板；我们还介绍了在项目组合与项目管理中的一些遗留的思维形式，并给出了相应的处理建议。在这一部分的最后一章，介绍投资主题和篇章，如何进行敏捷项目组合规划，后者也是我们的终极目标之一。
如果你是对项目组合、系统软件服务或IT应用进行管理投资的项目经理、开发总监、系统架构师、管理人员或项目组合经理，这一部分内容正好适合你。

 

目    录
第Ⅰ部分  概览：全景图
第1章  软件需求方法简史 3
1.1  背景：软件过程模型几十年 3
1.2  预言性的瀑布式过程 5
1.2.1  瀑布模型存在的问题 6
1.2.2  瀑布模型中的需求：铁三角 6
1.2.3  然而，瀑布模型仍然与我们同在 8
1.3  迭代式与增量式过程 9
1.3.1  螺旋模型 10
1.3.2  快速应用开发（RAD） 10
1.3.3  统一软件过程（RUP） 11
1.3.4  迭代式过程的需求管理 12
1.4  适应（敏捷）过程 13
1.4.1  敏捷宣言 13
1.4.2  极限编程（XP） 15
1.4.3  Scrum 16
1.5  敏捷需求管理从根本上不同 17
1.5.1  告别铁三角 18
1.5.2  敏捷通过增量式价值交付优化投资回报率 19
1.6  企业级适应性过程 21
1.7  精益软件运动简介 21
1.7.1  精益软件之屋 23
1.7.2  软件需求的系统视图 29
1.7.3  看板：另一种软件方法的兴起 30
1.8  小结 31
第2章  敏捷需求全景图 33
2.1  解读全景图 35
2.2  全景图：团队层面 36
2.2.1  敏捷团队 37
2.2.2  敏捷团队中的角色 38
2.2.3  迭代 40
2.2.4  用户故事与团队待办事项 41
2.3  全景图：项目集层面 42
2.3.1  发布和潜在可交付增量（PSI） 42
2.3.2  愿景、特性与项目集待办事项 43
2.3.3  制定发布计划 44
2.3.4  路线图 45
2.3.5  产品管理 45
2.4  全景图：项目组合层面 46
2.4.1  投资主题 47
2.4.2  篇章和项目组合待办事项 47
2.4.3  架构跑道 48
2.5  小结 48
第3章  团队的敏捷需求 49
3.1  介绍团队层面 49
3.1.1  为什么要讨论团队 49
3.1.2  消除职能筒仓 52
3.2  敏捷团队的角色与职责 53
3.2.1  产品负责人 53
3.2.2  Scrum/Agile Master 54
3.2.3  开发人员 54
3.2.4  测试人员 55
3.2.5  团队/项目集的其他角色 56
3.3  用户故事和团队待办事项 57
3.3.1  待办事项 57
3.3.2  用户故事 58
3.3.3  用户故事基础知识 59
3.3.4  任务 59
3.4  验收测试 60
3.5  单元测试 62
3.6  小结 63
第4章  项目集的敏捷需求 65
4.1  介绍项目集层面 65
4.2  组织大规模的敏捷团队 66
4.2.1  特性团队与组件团队 67
4.2.2  系统团队 73
4.2.3  发布管理团队 75
4.2.4  产品管理 76
4.3  愿景 76
4.4  特性 77
4.4.1  新特性构成项目集待办事项 78
4.4.2  特性的测试 79
4.5  非功能需求 80
4.5.1  非功能需求作为对待办事项的约束 80
4.5.2  测试非功能需求 81
4.6  敏捷发布火车 82
4.6.1  发布与潜在可交付增量 82
4.6.2  制定发布计划 83
4.7  路线图 84
4.8  小结 85
第5章  项目组合的敏捷需求 87
5.1  介绍项目组合层面 87
5.2  投资主题 88
5.3  项目组合管理团队 89
5.4  篇章和项目组合待办事项 90
5.5  篇章、特性和故事 91
5.6  架构跑道和架构篇章 92
5.6.1  实现架构篇章 94
5.6.2  架构跑道：项目组合、项目集和团队 94
5.7  小结 95
5.8  完整的企业需求管理信息模型 96
第Ⅱ部分  团队的敏捷需求
第6章  用户故事 103
6.1  概述 103
6.1.1  用户故事概述 104
6.1.2  用户故事帮助架起开发人员和客户之间的沟通桥梁 105
6.1.3  用户故事不是需求说明书 106
6.2  用户故事的形式 106
6.2.1  卡片、对话与确认 107
6.2.2  用户故事的语调 107
6.2.3  用户故事的细节 109
6.2.4  用户故事的验收标准 109
6.3  良好用户故事中的INVEST 110
6.3.1  独立性 110
6.3.2  可协商……而且经过协商 111
6.3.3  有价值 112
6.3.4  可估算 114
6.3.5  小型 114
6.3.6  可测试 116
6.4  分割用户故事 117
6.5  故事穿刺 120
6.5.1  技术穿刺和功能穿刺 120
6.5.2  对故事穿刺的指导原则 121
6.6  使用索引卡片建模故事 122
6.7  小结 123
第7章  干系人、用户表征和用户体验 125
7.1  干系人 125
7.1.1  系统干系人 126
7.1.2  项目干系人 126
7.1.3  干系人的声音：产品负责人 127
7.1.4  干系人的介入程度 127
7.1.5  打造干系人信任 128
7.1.6  干系人互动 128
7.2  识别干系人 129
7.2.1  识别项目干系人 129
7.2.2  识别系统干系人 130
7.2.3  系统干系人的分类 131
7.2.4  理解系统干系人的需求 132
7.2.5  干系人/产品负责人团队 132
7.3  用户表征 133
7.3.1  主要和次要用户表征 133
7.3.2  通过用户故事角色建模发现用户表征 133
7.4  敏捷与用户体验开发 136
7.4.1  用户体验的问题 136
7.4.2  用户界面开发的低保真选项 136
7.4.3  用户体验穿刺 137
7.4.4  用户体验集中开发 137
7.4.5  分布式、有治理的用户界面开发模型 138
7.5  小结 139
第8章  敏捷估算与速率 141
8.1  概述 141
8.1.1  有办法解决不合常理之处 142
8.1.2  目标是相同的：更可靠的估算 142
8.2  为什么要估算？估算的商业价值 143
8.3  估算范围与故事点 144
8.4  理解故事点：一个练习 145
8.4.1  练习部分1：相对估算 145
8.4.2  练习部分2：使用计划扑克估算实际工作 146
8.4.3  我们应该在估算上花多少时间 149
8.4.4  一则寓言的估算警示：故事中的故事 150
8.4.5  使用在线计划扑克进行分布式估算 151
8.5  一种替代技术：桌面相对估算 152
8.6  从范围估算到团队速率 153
8.7  关于相对估算模型的告诫 154
8.8  从速率到进度和成本 156
8.8.1  进度估算 156
8.8.2  成本估算 156
8.9  理想程序员人天估算法 157
8.10  一种混合模型 159
8.11  小结 160
第9章  迭代、待办事项、吞吐量和看板 161
9.1  迭代：敏捷的心跳 161
9.1.1  迭代长度 162
9.1.2  迭代模式：计划、执行、评审和回顾 163
9.1.3  团队待办事项 163
9.1.4  迭代计划 164
9.1.5  迭代承诺 166
9.1.6  执行迭代 170
9.1.7  追踪与调整 171
9.1.8  评审与回顾 174
9.1.9  特性预览 176
9.2  待办事项、精益与吞吐量 176
9.2.1  待办事项成熟度，精益和利特尔法则 178
9.2.2  博客故事：构造良好的产品待办事项是否会
降低团队的敏捷性 178
9.2.3  利特尔法则与敏捷团队的待办事项 179
9.2.4  运用利特尔法则提高敏捷性并缩减面市时间 180
9.2.5  读者的反响 183
9.2.6  通过控制待办事项的队列长度管理吞吐量 185
9.3  软件看板制度 187
9.3.1  看板制度的属性 187
9.3.2  看板的业务类别 188
9.4  小结 189
第10章  验收测试 191
10.1  在关于敏捷需求的书中为什么要讨论测试 191
10.2  敏捷测试概述 193
10.3  什么是验收测试 195
10.4  良好的故事验收测试的特征 196
10.4.1  它们测试的是良好的用户故事 197
10.4.2  它们是相对无歧义的并且测试所有场景 197
10.4.3  它们持久存在 198
10.5  验收测试驱动开发ATDD 198
10.6  验收测试模板 200
10.7  自动化验收测试 202
10.8  单元测试和组件测试 204
10.8.1  单元测试 205
10.8.2  组件测试 207
10.9  小结 207
第11章  产品负责人的作用 209
11.1  这是一个新角色吗 209
11.2  产品负责人和产品经理双重角色的观点 210
11.2.1  名称游戏：产品负责人的角色/头衔试验 214
11.2.2  我们的结论：采取双重角色 215
11.3  产品负责人在企业中的职责 216
11.3.1  管理待办事项 216
11.3.2  准时制故事细化 219
11.3.3  驱动迭代 221
11.3.4  技术债和价值流的问题 224
11.3.5  共同制定发布计划 226
11.4  优秀产品负责人的五种基本特质 227
11.5  与产品经理协作 229
11.6  产品负责人瓶颈：临时产品负责人、产品负责人代理、产品负责人团队 230
11.6.1  产品负责人代理 230
11.6.2  产品负责人团队 230
11.7  在企业中培养产品负责人角色 231
11.7.1  TradeStation科技公司 231
11.7.2  CSG Systems公司 232
11.7.3  Symbian软件有限公司 233
11.7.4  Discount Tire 233
11.8  小结 234
第12章  需求发现工具箱 235
12.1  需求工作坊 236
12.1.1  为工作坊做准备 237
12.1.2  设立议程 239
12.1.3  运行工作坊 239
12.2  头脑风暴 240
12.2.1  创意生成 241
12.2.2  创意收敛 243
12.2.3  创意的优先级排列 244
12.3  访谈与调查 246
12.3.1  与上下文无关的提问 247
12.3.2  有解决方案上下文的提问 247
12.3.3  真相时刻：访谈 248
12.3.4  汇总需求数据 248
12.3.5  对调查表的说明 249
12.4  用户体验原型 250
12.5  组建产品委员会 252
12.6  竞争性分析 253
12.7  客户变更请求系统 255
12.8  用例建模 256
12.9  小结 256
第Ⅲ部分  项目集的敏捷需求
第13章  愿景、特性和路线图 261
13.1  愿景 261
13.2  愿景的表达 262
13.2.1  愿景文档 262
13.2.2  高级数据表方式 263
13.2.3  初步新闻稿方式 264
13.2.4  “特性待办事项加简述”的方式 265
13.2.5  交流非功能需求（系统质量） 265
13.3  特性 265
13.4  估算特性 267
13.4.1  估算工作量 268
13.4.2  估算成本 269
13.4.3  估算开发时间 270
13.5  测试特性 270
13.6  特性的优先级排列 271
13.6.1  以价值/工作量表示ROI：第一种估算方式 272
13.6.2  价值/工作量的ROI方法有问题吗 273
13.6.3  基于延迟成本排列特性优先级 273
13.6.4  延迟成本（CoD）介绍 273
13.6.5  估算延迟成本 277
13.6.6  特性优先级排列估算矩阵 278
13.6.7  所有优先级都是本地的和临时的 279
13.6.8  实现差异化价值：客户满意度的Kano模型 280
13.7  路线图 282
13.8  小结 284
第14章  产品经理的作用 287
14.1  产品经理还是业务分析师 288
14.2  在产品导向型企业中产品经理的职责 288
14.3  在IT/IS工作间中此角色的业务职责 290
14.4  职责总结 291
14.5  在预备敏捷企业中产品管理的破灭阶段 292
14.5.1  阶段1：无比热情 293
14.5.2  阶段2：虚假的安全感 293
14.5.3  阶段3：猛然觉醒 293
14.5.4  阶段4：对期望的重置 294
14.5.5  阶段5：长久的不信任 294
14.5.6  退出长久的不信任 294
14.6  在敏捷企业中产品管理的演化 295
14.6.1  理解客户需要 295
14.6.2  文档要求 296
14.6.3  日程安排 296
14.6.4  需求优先级排列 297
14.6.5  验证需求 297
14.6.6  管理变更 298
14.6.7  评估状态 298
14.7  敏捷产品经理的职责 299
14.7.1  负责愿景和发布
待办事项 300
14.7.2  管理发布内容 302
14.7.3  维护路线图 306
14.7.4  打造有效的产品经理/产品负责人团队 307
14.8  小结 309
第15章  敏捷发布火车 311
15.1  介绍敏捷发布火车 312
15.1.1  敏捷发布火车的基本原理 313
15.1.2  敏捷发布火车的原则 315
15.2  推动战略对齐 316
15.3  使产品开发流制度化 317
15.4  设计敏捷发布火车 320
15.5  发布计划活动 321
15.6  追踪和管理发布 322
15.7  发布回顾 323
15.8  度量发布的可预测性 323
15.9  发布 325
15.9.1  按ART节拍发布 326
15.9.2  以低于ART节拍的频率发布 327
15.9.3  以高于ART节拍的频率发布 329
15.10  小结 330
第16章  制定发布计划 331
16.1  发布计划活动的准备 332
16.1.1  发布计划域 332
16.1.2  计划参会 332
16.1.3  发布计划活动的协调员 333
16.1.4  发布计划会议的准备检查表 334
16.2  发布计划活动第1天 334
16.2.1  开幕 336
16.2.2  商业场景 336
16.2.3  解决方案愿景 336
16.2.4  架构愿景 337
16.2.5  团队计划分组讨论Ⅰ 337
16.2.6  计划草案评审 339
16.2.7  经理复审与问题解决会议 341
16.3  发布计划活动第2天 341
16.3.1  开启 342
16.3.2  计划调整：统一战线 343
16.3.3  继续计划：团队计划分组讨论Ⅱ 343
16.3.4  确定发布目标 343
16.3.5  最终计划评审 345
16.3.6  处理风险和障碍 346
16.3.7  承诺 348
16.3.8  计划工作回顾 349
16.3.9  对团队的最后说明 350
16.4  延伸目标 350
16.5  小结 351
第17章  非功能需求 353
17.1  建模非功能需求 354
17.2  探索非功能需求 356
17.2.1  易用性 357
17.2.2  可靠性 358
17.2.3  性能 359
17.2.4  可支持性 359
17.2.5  设计约束 360
17.3  非功能需求的持久性 361
17.4  测试非功能需求 363
17.4.1  易用性 364
17.4.2  可靠性 365
17.4.3  安全性 365
17.4.4  性能 366
17.4.5  可支持性和设计约束 367
17.5  NFR说明书模板 367
17.6  小结 369
第18章  需求分析工具箱 371
18.1  活动图 373
18.2  样本报告 374
18.3  伪代码 375
18.4  决策表和决策树 375
18.5  有限状态机 377
18.6  消息序列图 379
18.7  实体-关系图 381
18.8  用例建模 382
18.9  小结 382
第19章  用例 383
19.1  用户故事和待办事项条目的问题 384
19.2  仍使用用例的五个良好理由 385
19.3  用例基础知识 386
19.3.1  用例参与者 387
19.3.2  用例结构 387
19.3.3  构建用例模型的分步骤指导 389
19.4  一个用例示例 392
19.5  运用用例 394
19.6  在敏捷需求模型中的用例 396
19.7  小结 396
第Ⅳ部分  项目组合的敏捷需求
第20章  敏捷架构 401
20.1  介绍全景图的项目组合层面 401
20.2  企业级系统中的系统架构 403
20.2.1  在敏捷中所有架构都可以涌现吗 404
20.2.2  需要有意图的架构 405
20.2.3  架构篇章的业务驱力 406
20.2.4  敏捷企业中系统架构师的作用 407
20.3  敏捷架构的八条原则 409
20.3.1  原则1：负责系统编码的团队也参与系统的设计 409
20.3.2  原则2：构建可工作的最简单架构 411
20.3.3  原则3：如果有疑问，把它编码或建模出来 411
20.3.4  原则4：他们构建它，他们测试它 414
20.3.5  原则5：系统越大，跑道越长 414
20.3.6  原则6：系统架构是角色协作 415
20.3.7  原则7：没有对创新的垄断 416
20.3.8  原则8：实现架构流 418
20.4  实现架构篇章 419
20.4.1  情况 A：篇章很大，可以增量实现，系统始终运行 419
20.4.2  情况 B：篇章很大，不能完全增量实现，系统偶尔暂停 420
20.4.3  情况C：篇章非常大，不能增量实现，系统仅在需要时运行，没有危害 421
20.5  分割架构篇章 422
20.6  小结 424
第21章  利用流机制重新架构 425
21.1  架构篇章看板制度 426
21.2  架构篇章看板制度概览 427
21.2.1  队列介绍 428
21.2.2  架构篇章的状态描述 429
21.3  漏斗：识别问题/解决方案的需求 431
21.3.1  新架构篇章的来源 431
21.3.2  活动：篇章分级 432
21.3.3  在制品限制 433
21.3.4  决策部门 433
21.4  待办事项 433
21.4.1  活动：基于节拍的评审、讨论和分级 433
21.4.2  优先级排列和分级制度 434
21.4.3  加权分级和决策准则 435
21.4.4  从过渡拉入分析队列 435
21.4.5  在制品限制 436
21.5  分析 436
21.5.1  活动 436
21.5.2  与开发部门协作 437
21.5.3  与业务部门的协作：解决方案管理、产品管理、业务分析师 438
21.5.4  在制品限制 438
21.5.5  架构篇章的商业案例模板 438
21.5.6  决策部门 439
21.6  实现 441
21.6.1  实现路径A：过渡到开发 441
21.6.2  实现路径B：组建新团队 442
21.6.3  实现路径C：开发工作外包 443
21.6.4  实现路径D：采购解决方案 443
21.6.5  在制品限制 444
21.7  小结 445
第22章  敏捷项目组合管理 447
22.1  项目组合管理 447
22.2  当敏捷团队遇到PMO：两条船驶入暗夜 449
22.3  遗留思维形式抑制企业敏捷性 450
22.4  在项目组合管理中的遗留思维形式 451
22.5  推动敏捷项目组合管理的八条建议 454
22.5.1  反思投资管理 455
22.5.2  反思变更管理 459
22.5.3  反思治理与监督 461
22.6  小结：继续敏捷项目组合的计划制定 466
第23章  投资主题、篇章和制定项目组合计划 467
23.1  投资主题 468
23.1.1  交流投资主题 469
23.1.2  为什么是投资主题的综合而不是待办事项优先级 470
23.2  篇章 470
23.2.1  子篇章 471
23.2.2  表达篇章 472
23.2.3  对篇章、特性和故事的鉴别 472
23.2.4  篇章的类型 474
23.3  业务篇章的识别与优先级排列：项目组合计划工作的看板制度 475
23.3.1  概览 475
23.3.2  状态图 476
23.3.3  漏斗：识别问题/解决方案的需求 478
23.3.4  待办事项 479
23.3.5  分析 482
23.3.6  实现 486
23.4  小结 486
第24章  结论 487
附录A  上下文无关的访谈 489
附录B  愿景文档模板 493
附录C  制定发布计划准备工作检查表 501
附录D  敏捷需求企业待办事项元模型 505
参考书目 507