新書推薦：
《
万有引力书系 海洋女王 里斯本的历史
》
售價：HK$
89.7
《
周易大全
》
售價：HK$
147.2
《
元和十四年 ： 大唐中兴与沉沦的十字路口
》
售價：HK$
79.4
《
思考的技术：珍藏版
》
售價：HK$
90.9
《
琥珀之夏（《镜之孤城》作者、推理小说家辻村深月新长篇；能治愈童年创伤的，也许唯有长大成人的自己）
》
售價：HK$
59.8
《
流人系列02：亡狮
》
售價：HK$
90.9
《
希腊小史
》
售價：HK$
112.7
《
中国古代的谣言与谶语
》
售價：HK$
112.7
|
| 編輯推薦： |
针对希望培养和提升敏捷分析与计划能力的产品负责人、产品经理/项目集经理、商业分析师、需求工程师与项目经理，本书提供了一个全景式的敏捷行动路线图和一个贯穿全书的案例。作者作为业内享有盛名的咨询顾问，不仅熟悉传统的商业分析工具，还精通主流敏捷框架及相关技术实践，比如ATDD、BDD、DevOps、CI/CD、Kanban、Scrum、SAFe、XP、精益思想、精益创业、场景化市场细分以及颠覆式创新理论等。
通过本书，读者可以了解和掌握卡诺分析、最小可行产品(MVP)、最小可市场化特性 (MMF)、故事地图、产品路线图、客户旅程图、价值流图、技术预研和DoR（就绪定义）等用于高效执行敏捷分析与计划的工具。
|
| 內容簡介： |
|
《敏捷商业分析与计划：从战略规划到持续交付价值》通过贯穿全书的一个敏捷分析与计划全景图和一个循序渐近的案例学习来展示商业分析和敏捷方法紧密结合从最开始的战略规划到最后持续交付价值。读者可以在本书的指导下进行敏捷分析与计划，帮助组织灵活地应对快速变化的商业环境。 《敏捷商业分析与计划：从战略规划到持续交付价值》适合产品负责人、产品/ 项目集经理、商业分析师、需求工程师和项目经理阅读与参考，也是商业分析相关认证考试的备考指南，还可以帮助读者培养和提升敏捷分析与计划能力。
|
| 關於作者： |
霍华德·波德斯瓦(Howard Podeswa)
过去二十多年，霍华德一直致力于敏捷分析与计划优化实践，为全球各地的私营/上市公司以及高等院校设计和提供敏捷与商业分析培训课程。他涉及的行业很广，包括电信、银行、政府服务、户外用品、保险和医疗保健等，服务过的客户有国际标准化组织（ISO）、穆迪、梅奥医学中心、加拿大研科公司、道明银行、莱博科、美国食品和药物管理局（FDA）、贝尔加拿大公司、美国REI集团和美国波士顿大学等。霍华德还是另外两本书的作者，主题涉及商业分析和UML。
周子衿
本科期间多次入选“院长优等生名单”，主修商业分析，曾经运用数据模型和R语言帮助某企业在半年内实现了十倍的业务增长。奉行深思笃行的做事原则，有志于通过技术途径和感性思维来探寻商业价值与人文精神的平衡。代表译作有《游戏项目管理与敏捷开发》《高质量用户体验》《敏捷商业分析与计划：从战略规划到持续交付价值》以及《人工智能与用户体验：以人为本的设计》。
|
| 目錄：
|
第1 章 敏捷分析与计划的艺术 001
1.1 目标 002
1.2 关于艺术和敏捷商业分析 002
1.3 我在一家稳定的大公司工作，敏不敏捷和我有什么关系呢 006
1.4 故事1：与我无关 009
1.5 故事2：坏脾气的客户 012
1.6 小结 013
1.7 下一个主题 013
第2 章 敏捷分析与计划及其价值主张 015
2.1 目标 016
2.2 什么是敏捷分析与计划 016
2.3 商业分析师指的是哪些人 017
2.4 为什么要做敏捷分析与计划 018
2.5 敏捷与商业分析的平行发展简史 019
2.5.1 商业分析简史 020
2.5.2 敏捷开发简史 020
2.6 针对同一个问题的两种诊断 021
2.7 商业分析的诊断 022
2.8 商业分析简史 022
2.9 来自敏捷的诊断 025
2.10 敏捷的历史 026
2.11 敏捷团队为什么要具备高效商业分析能力 027
2.12 小结 028
2.13 下一个主题 028
第3 章 敏捷分析与计划基础 031
3.1 目标 032
3.2 《敏捷宣言》对商业分析的意义 032
3.2.1 《敏捷宣言》 032
3.2.2 第一个价值观对分析的影响 033
3.2.3 第二个价值观对分析的影响 033
3.2.4 第三个价值观对分析的影响 033
3.2.5 第四个价值观对分析的影响 033
3.3 12 大原则对商业分析的意义 033
3.4 实践、标准和框架 035
3.4.1 商业分析标准 035
3.4.2 与需求相关的术语 037
3.4.3 敏捷计划 047
3.4.4 敏捷框架 049
3.5 敏捷角色与商业分析师概述 066
3.5.1 产品负责人的BA 职责 067
3.5.2 敏捷团队分析师 067
3.5.3 Scrum Master 的BA 职责 068
3.5.4 代理用户 068
3.5.5 产品推动者（总监）的BA 职责 068
3.5.6 教练 069
3.5.7 在什么情况下建议使用专职商业分析师 069
3.5.8 商业分析师提供需求领导力 070
3.5.9 商业分析师和商业系统分析师的区别 071
3.6 敏捷商业分析师的软技能 071
3.6.1 将潜意识转为有意识 071
3.6.2 好奇心 072
3.6.3 变革的推动者 072
3.6.4 政治智慧 072
3.6.5 与难缠的人合作愉快 072
3.6.6 谈判技巧 072
3.6.7 引导能力 072
3.6.8 适应能力 073
3.6.9 勇于提出问题 073
3.6.10 幽默感 073
3.7 13 大关键敏捷分析实践及其与瀑布的区别 073
3.7.1 能力而非角色 073
3.7.2 引导师而非信使 073
3.7.3 拥抱需求变更 074
3.7.4 与开发人员是协作关系，而不是合同关系 074
3.7.5 准时（JIT）需求分析 074
3.7.6 对话而非文档 074
3.7.7 示例规范：验收测试驱动的开发 074
3.7.8 小型需求单位 074
3.7.9 功能的垂直切片 074
3.7.10 轻量级工具 075
3.7.11 商业分析师和商业干系人参与整个开发生命周期 075
3.7.12 混合使用传统BA 和敏捷BA 工具 075
3.7.13 聚焦于当下 075
3.8 敏捷商业分析的经验法则 075
3.9 小结 076
3.10 接下来的主题 076
第4 章 跨敏捷开发生命周期的分析与计划活动 079
4.1 目标 082
4.2 敏捷分析与计划地图概述 082
4.3 区域 083
4.4 通道 083
4.5 三幕故事 084
4.6 第一幕：短通道 085
4.6.1 初步准备和计划 085
4.6.2 填充待办事项列表 086
4.6.3 日常活动 088
4.6.4 特性收尾：为GA 做准备 089
4.6.5 季度开端，迭代开端 089
4.6.6 迭代收尾 089
4.6.7 季度收尾 089
4.7 第二幕：长通道 089
4.8 第三幕：大型通道 090
4.8.1 规模化组织 090
4.8.2 规模化的季度计划 091
4.8.3 规模化的迭代计划 091
4.8.4 日常的计划与分析 091
4.8.5 迭代收尾 091
4.8.6 季度收尾 092
4.9 小结 092
4.10 下一个主题 092
第5 章 组织的准备工作 093
5.1 目标 096
5.2 本章在全景图中的位置 096
5.3 什么是启动和计划 096
5.4 预先应该花多长时间进行启动和计划 097
5.4.1 预期风险越大，越需要进行预先计划 097
5.4.2 前事不忘，后事之师7 097
5.5 目标一致性模型 098
5.5.1 差异化象限（右上角） 099
5.5.2 均势象限（右下角） 099
5.5.3 合作伙伴象限（左上角） 100
5.5.4 无人在意象限（左下角） 100
5.6 准备基础设施 100
5.6.1 从手工测试过渡到自动测试 101
5.6.2 构建和发布过程自动化的时机 103
5.7 组织开发团队 103
5.7.1 组建敏捷团队的准则 104
5.7.2 围绕价值进行组织 105
5.7.3 特性团队与通用团队 107
5.7.4 扩展团队 107
5.7.5 为什么按能力组织团队对企业不利 108
5.8 管理干系人对敏捷开发的期望 109
5.8.1 推迟需求就是拒绝需求的负面期望 109
5.8.2 对生产力的期望 110
5.9 准备好客户与开发者的关系 111
5.9.1 客户权利和责任法案 111
5.9.2 开发人员的权利和责任法案 112
5.10 敏捷财务计划 113
5.10.1 衡量成功 113
5.10.2 以发现为导向的财务计划 113
5.11 让营销和分销团队做好准备 114
5.12 准备好渠道和供应链 115
5.13 准备好公司治理和合规审查 115
5.13.1 挑战合规假设 115
5.13.2 设计流程后再进行合规审查 116
5.13.3 专注于目标，而不是手段 116
5.13.4 一次性实验 116
5.14 为资源需求的增加做准备 117
5.15 让企业为敏捷开发做准备 117
5.15.1 敏捷流畅度模型 118
5.15.2 团队的过渡 119
5.15.3 企业层面的过渡 120
5.15.4 过渡的时间线 122
5.15.5 沟通计划 122
5.15.6 敏捷企业过渡团队 123
5.16 确定组织的准备情况 123
5.17 小结 124
5.18 下一个主题 125
第6 章 过程的准备工作 127
6.1 目标 130
6.2 本章在全景图中的位置 130
6.3 过程的准备工作 130
6.4 根据环境调整敏捷实践 130
6.4.1 敏捷开发的成本 131
6.4.2 敏捷开发的收益 131
6.4.3 寻找成本和收益的最佳平衡点 131
6.4.4 确定框架 134
6.5 调整流程 135
6.5.1 商业分析信息工件和事件 135
6.5.2 敏捷BA 信息工件的检查清单 135
6.5.3 定义需求类型 136
6.5.4 调整待办事项列表的需求 137
6.5.5 确定需求颗粒度 140
6.5.6 追踪需求和其他配置项目 142
6.5.7 设置过程参数 147
6.6 使用价值流图优化过程 159
6.7 确定过程的准备程度 160
6.8 小结 160
6.9 下一个主题 161
第7 章 设定愿景 163
7.1 目标 166
7.2 本章在全景图中的位置 166
7.3 产品愿景设定和史诗的准备工作概览 166
7.3.1 产品愿景示例及其重要性 167
7.3.2 愿景设定检查清单 168
7.3.3 初步识别干系人 168
7.3.4 引导技巧 168
7.4 根本原因分析 169
7.4.1 五问法 170
7.4.2 因果图 174
7.4.3 因果树状图 178
7.5 指定一个产品或史诗 184
7.6 问题或机会陈述 184
7.7 产品画像 187
7.8 拟定产品和史诗愿景宣言 188
7.8.1 产品愿景宣言 189
7.8.2 史诗愿景宣言 189
7.8.3 优秀的产品和史诗愿景宣言所具备的特征 189
7.8.4 愿景与使命宣言 190
7.9 干系人分析和参与 192
7.9.1 识别和分析干系人 192
7.9.2 计划干系人的合作 193
7.9.3 计划干系人的沟通 195
7.9.4 引导并持续开展参与和分析 195
7.10 分析业务目标和经营目标 198
7.10.1 将基于情况的市场细分作为业务目标和经营目标的基础 198
7.10.2 在故事范式中表示业务目标和经营目标 199
7.11 分析信念飞跃式假设 202
7.11.1 什么是精益创业 202
7.11.2 什么是信念飞跃式假设 202
7.11.3 价值假设 203
7.11.4 增长假设 203
7.11.5 确定度量标准 204
7.11.6 以发现为导向的计划中的假设 206
7.11.7 预设检查清单 206
7.11.8 使用里程碑计划表来计划预设测试 207
7.12 小结 209
7.13 下一个主题 209
第8 章 填充待办事项列表：发现并对特性进行分级 211
8.1 目标 214
8.2 本章在全景图中的位置 214
8.3 概述：填充待办事项列表 214
8.3.1 定义：史诗和故事 214
8.3.2 应该预先填充多少个特性 215
8.3.3 邀请谁来参加填充待办事项列表的工作 215
8.4 用基于场景的市场细分来探索特性 216
8.5 发现初始特性的其他方法 216
8.6 特性的独立性 217
8.7 使用“角色– 特性– 原因”模板来表述史诗和特性 217
8.8 阐明涌现的特性 218
8.9 特性的物理表现形式 218
8.10 特性属性 219
8.11 用卡诺分析法确定客户和用户价值 220
8.11.1 选择目标特性 220
8.11.2 选择客户 220
8.11.3 创建问题 221
8.11.4 创建原型 221
8.11.5 内部测试调查问卷 222
8.11.6 进行调查 222
8.11.7 对特性进行分级 222
8.11.8 解读卡诺等级 224
8.11.9 满意度与满足度图 225
8.11.10 愉悦的自然衰减（及相反情况） 226
8.11.11 连续分析 226
8.12 对待办事项列表中的史诗和特性进行排序 229
8.12.1 确定延迟成本 229
8.12.2 确定WSJF 230
8.12.3 确定优先级的相关提示 230
8.13 编写特性验收标准 233
8.14 分析非功能性需求和约束 233
8.14.1 NFR 是否会被列入待办事项列表？ 234
8.14.2 NFR 和约束检查清单 234
8.15 小结 237
8.16 下一个主题 237
第9 章 长期敏捷计划 239
9.1 目标 242
9.2 本章在全景图中的位置 242
9.3 长期计划、史诗计划和MVP 概述 242
9.4 全能计划 243
9.4.1 第一阶段：制定大胆的目标 244
9.4.2 第二阶段：创建详细计划 245
9.4.3 第三阶段：交付速赢 245
9.4.4 业务分析师对成功的全部潜能计划的贡献 245
9.5 使用MVP 来验证计划背后的假设 247
9.5.1 概述 247
9.5.2 什么是MVP 247
9.5.3 MVP 过程 248
9.6 有效实施MVP 的能力 249
9.6.1 技术能力 250
9.6.2 部署和交付方法 251
9.6.3 部署选项和潜在的问题 253
9.7 产品路线图概述 259
9.8 规划中期阶段 261
9.8.1 确定中期时间表 261
9.8.2 拟定临时目标和目的 262
9.8.3 确定假设和度量标准 262
9.8.4 确定事件和里程碑 263
9.8.5 确定特性 263
9.9 在较短的计划范围中使用产品路线图 268
9.10 小结 268
9.11 下一个主题 268
第10 章 季度和特性的准备工作 271
10.1 目标 274
10.2 本章在全景图中的位置 274
10.3 特性概述 274
10.4 特性准备的好处 276
10.5 特性的准备活动 276
10.6 特性准备的时间安排 278
10.7 评估准备情况 278
10.8 准备工作的核算：任务和探针 279
10.9 阐明特性及其验收标准 280
10.9.1 阐明史诗验收标准 281
10.9.2 阐明特性验收标准 281
10.9.3 分析师的贡献 282
10.9.4 在Triad 会议中分析AC 282
10.9.5 用BDD Gherkin 语法阐明AC 283
10.9.6 为端到端工作流指定UAT 284
10.10 背景分析 285
10.11 干系人分析 285
10.12 角色分析 285
10.12.1 用户角色的历史 286
10.12.2 用户角色示例 287
10.12.3 创建用户角色 288
10.12.4 记录用户角色 289
10.12.5 使用用户角色 291
10.13 旅程、流程和价值流图的概述 294
10.14 旅程地图 295
10.14.1 客户旅程地图的概述 296
10.14.2 客户旅程地图：抵押贷款案例 297
10.14.3 旅程地图的组成部分 297
10.14.4 使用旅程地图 301
10.14.5 旅程地图的更多信息 305
10.15 价值流图 305
10.16 业务流程建模 307
10.16.1 将过程参与者聚集在一起 307
10.16.2 什么情况下需要流程建模 308
10.16.3 截图并不能代表流程模型 308
10.16.4 根据目的做恰到好处的分析 309
10.16.5 包含以及不包含泳道的模型 309
10.16.6 BPMN 309
10.17 用例建模 319
10.17.1 用例建模示例：索赔 320
10.17.2 用例模型的元素 321
10.18 用户角色建模研讨会 321
10.19 回顾架构 329
10.19.1 环境图 330
10.19.2 UML 协作图 331
10.19.3 数据流图 331
10.19.4 架构（方块）图 333
10.20 小结 337
10.21 下一个主题 337
第11 章 季度和特性计划 339
11.1 目标 342
11.2 本章在全景图中的位置 342
11.3 季度计划的概述 342
11.4 基于流程的特性计划简述 343
11.5 在哪些情况下建议或不建议进行这种计划 343
11.6 在哪种情况下使用季度计划与基于流程的特性计划 344
11.7 如何进行敏捷季度计划 345
11.7.1 创造拥抱变革的文化 345
11.7.2 依据数据做出决策 346
11.7.3 指定结果，而不是产出 346
11.7.4 把计划看作是一种假设，而不是一个合同 346
11.8 XP 的计划游戏指南 347
11.8.1 计划游戏概述 347
11.8.2 角色概述 347
11.8.3 计划原则概述 348
11.9 季度计划：时间安排方面的考虑 350
11.10 计划活动的准备工作 350
11.10.1 验证进入条件 350
11.10.2 准备邀请名单 351
11.10.3 确定计划范围 351
11.10.4 准备输入和可交付成果 352
11.10.5 逐步完善特性和验收标准 352
11.11 计划议题（议程） 353
11.11.1 综述 354
11.11.2 探索 357
11.11.3 承诺 369
11.11.4 计划回顾 376
11.12 在季度开始后评审季度计划 380
11.12.1 迭代开始时 380
11.12.2 速度修正 380
11.12.3 新特性 381
11.12.4 计划被废弃 381
11.13 小结 381
11.14 下一个主题 381
第12 章 MVP 和故事地图 383
12.1 目标 386
12.2 本章在全景图中的位置 386
12.3 MVP 和故事地图：这些工具是如何相辅相成的 386
12.4 MVP 计划 386
12.4.1 什么是MVP 387
12.4.2 MVP 案例学习：Trint 387
12.4.3 MVP 实验的场所 389
12.4.4 MVP 类型 390
12.4.5 MVP 的迭代过程 394
12.4.6 转向 395
12.4.7 逐步地规模化MVP 395
12.4.8 使用MVP 来建立MMP 396
12.5 故事地图 397
12.5.1 杰夫·巴顿的故事地图 397
12.5.2 故事地图的好处 398
12.5.3 剖析故事地图 399
12.5.4 地图中的依赖关系 401
12.5.5 故事地图示例 401
12.5.6 在地图上编写故事时的注意事项 403
12.5.7 构建脊柱 403
12.5.8 构建肋骨 410
12.5.9 其他形式的故事地图 418
12.6 小结 420
12.7 下一个主题 421
第13 章 故事的准备工作 423
13.1 目标 426
13.2 本章在全景图中的位置 426
13.3 故事准备概述 426
13.4 故事的基本原理 427
13.4.1 什么是故事 427
13.4.2 替代术语 427
13.4.3 规模分类法 428
13.4.4 名称里有什么 429
13.4.5 用户故事示例 429
13.5 故事的3C 430
13.5.1 卡片 430
13.5.2 对话 430
13.5.3 确认 431
13.6 谁对用户故事负责 431
13.6.1 故事由谁来写 431
13.6.2 分析师的附加价值 432
13.6.3 Triad 框架 432
13.7 实体形式的故事与电子形式的故事 436
13.8 为故事属性指定值 437
13.9 撰写故事描述 437
13.9.1 在什么情况下应使用（以及不应使用）故事模板 437
13.9.2 “角色– 特性– 原因”模板 438
13.10 指定故事的接受标准 441
13.10.1 故事验收标准示例 441
13.10.2 由谁来编写验收标准？ 442
13.10.3 何时创建和更新验收标准 443
13.10.4 以实例说明问题 443
13.10.5 验收标准的范围应该有多大 445
13.10.6 每个故事有多少条验收标准？ 445
13.10.7 格式良好的验收标准的特点 445
13.10.8 涌现式验收标准 447
13.10.9 使用行为驱动开发（BDD）Gherkin 格式 447
13.10.10 由谁在何时测试验收标准？ 448
13.11 不属于用户故事的故事 449
13.11.1 什么是探针或使能故事 449
13.11.2 功能探针 451
13.11.3 技术探针 454
13.11.4 bug 修复故事 455
13.12 编写高质量故事的指导性原则 455
13.12.1 投资 456
13.12.2 INVEST IN CRUD 456
13.13 拆分故事的模式 457
13.13.1 如何使用这些模式 457
13.13.2 突破僵局 457
13.13.3 模式 458
13.14 用决策表分析业务规则和AC 468
13.14.1 行为性业务规则 470
13.14.2 决策表示例 470
13.14.3 决策表的优势 471
13.14.4 如何使用决策表获取规则 472
13.15 小结 476
13.16 下一个主题 476
第14 章 迭代和故事计划 479
14.1 目标 482
14.2 本章在全景图中的位置 482
14.3 迭代和故事计划概述 482
14.4 与会人员 483
14.5 时间 484
14.6 迭代计划的投入 484
14.7 迭代计划的可交付成果 484
14.7.1 迭代目标和迭代待办事项列表 484
14.7.2 开发者任务板 485
14.7.3 增量 485
14.8 计划的规则 486
14.9 第1 部分：预测将完成的任务 486
14.9.1 更新 486
14.9.2 预测产能 487
14.9.3 评审就绪定义和完成的定义 488
14.9.4 拟定迭代目标 488
14.9.5 讨论故事 489
14.9.6 预测将被交付的故事 490
14.10 第2 部分：计划实施 490
14.10.1 应该邀请PO 参与第2 部分吗 490
14.10.2 对第2 部分的概述 491
14.10.3 第2 部分的步骤 491
14.11 设置看板 498
14.12 扩展迭代计划 503
14.13 特性预览会议 503
14.13.1 特性预览的目标 503
14.13.2 时间安排方面的考虑 503
14.13.3 为什么要提前两个迭代 504
14.14 小结 504
14.15 下一个主题 504
第15 章 滚动式分析和准备：日常活动 507
15.1 目标 510
15.2 本章在全景图中的位置 510
15.3 滚动分析的概述 510
15.3.1 敏捷分析师的一天 511
15.3.2 分析任务概述 512
15.4 更新任务进度 513
15.5 Traid 指导性原则 513
15.6 可以对开发者任务采取的行动 513
15.7 监控进展 514
15.7.1 每日站会 514
15.7.2 跟进会议 517
15.7.3 更新开发者任务板 517
15.7.4 更新看板 518
15.7.5 用每日燃尽图监控进度 522
15.7.6 燃起图 530
15.7.7 应该使用燃尽图还是燃起图？ 531
15.7.8 累积流程图 532
15.8 故事测试和检查（分析– 编码– 构建– 测试） 535
15.8.1 “分析– 编码– 构建– 测试”周期概述 536
15.8.2 验证价值 537
15.9 在迭代过程中管理范围变更 541
15.9.1 当进度低于或高于预期时 542
15.9.2 当PO 想在迭代开始后添加故事时 542
15.10 更新商业分析文档 542
15.10.1 保留的故事 543
15.10.2 特性文档：按照特性，而不是按照故事来组织 544
15.10.3 更新用例模型 544
15.10.4 其他分析文档 553
15.10.5 追踪分析工件 553
15.11 对接下来的史诗、特性和故事的持续分析 556
15.11.1 应该在准备工作上花多长时间 556
15.11.2 滚动式准备分析概述 556
15.11.3 特性的准备工作 557
15.11.4 故事的准备工作 558
15.11.5 剪枝和排序 559
15.12 迭代结束时的进度核算 560
15.12.1 核算未完成的故事 560
15.12.2 当一个迭代被取消时的进度核算 561
15.13 迭代评审会议 561
15.13.1 输入和可交付成果 562
15.13.2 主题/ 议程 563
15.13.3 迭代评审会议—预测和跟踪进展的工件 564
15.14 迭代回顾会议 566
15.14.1 时间安排方面的考虑 566
15.14.2 参会人 566
15.14.3 输入和可交付成果 567
15.14.4 主题 567
15.14.5 迭代回顾游戏 569
15.15 小结 574
15.16 下一个主题 574
第16 章 发布产品 577
16.1 目标 580
16.2 本章在全景图中的位置 580
16.3 使故事进入已完成阶段 580
16.4 向市场发布：时间安排方面的考虑 581
16.5 确定发布的阶段 582
16.5.1 Pre–alpha 583
16.5.2 Alpha 测试 584
16.5.3 Beta 测试 584
16.5.4 正式发布 586
16.6 季度（发布）回顾会议 590
16.6.1 主持准则 591
16.6.2 准备时间线 593
16.6.3 季度回顾会议演练 594
16.7 “转向或继续”会议 596
16.7.1 以数据为参考，而不是以数据为导向 596
16.7.2 时间安排方面的考虑 596
16.7.3 参会人 596
16.7.4 “转向或继续”会议演练 597
16.8 小结 599
16.9 下一个主题 600
第17 章 规模化敏捷 601
17.1 目标 604
17.2 本章在全景图中的位置 604
17.3 为什么需要规模化的敏捷方法 604
17.3.1 为什么规模化敏捷团队是相互依赖的 605
17.3.2 产品的复杂性 606
17.3.3 共享组件 606
17.4 计划：选择支持团队间协作的方法 607
17.4.1 对两种方法的回顾 607
17.4.2 在前端应该使用哪种方法 607
17.4.3 分析师对规模化计划和实施所做的贡献 610
17.5 持续交付：持续、安全、可持续地规模化交付软件 610
17.5.1 测试– 构建– 部署步骤中的自动化 611
17.5.2 DevOps 与CI/CD 612
17.5.3 测试驱动开发 615
17.5.4 ATDD 和BDD 615
17.6 规模化的敏捷文化：创建支持规模化创新的文化 616
17.6.1 有效的敏捷领导力 617
17.6.2 把质量放在首位 618
17.6.3 消除筒仓，促进合作 619
17.6.4 培养快速学习的文化 619
17.7 规模化待办事项列表 619
17.7.1 概览 619
17.7.2 一个顶层产品 620
17.7.3 多个子产品 621
17.7.4 一个产品级PO 621
17.7.5 完整产品层次中的唯一一个待办事项列表 621
17.7.6 多个团队待办事项列表 622
17.7.7 特性团队 622
17.7.8 组件团队 622
17.7.9 一个完成的定义（DoD） 623
17.8 规模化敏捷组织 623
17.8.1 按照子产品和产品区域进行规模化：MyChatBot 案例学习 623
17.8.2 规模化PO 角色 625
17.8.3 投资组合和项目结构 626
17.8.4 组建特性团队 629
17.8.5 扩展团队 630
17.8.6 组件团队 630
17.8.7 能力小组 630
17.8.8 产品负责人委员会 632
17.8.9 用户特别小组 634
17.8.10 发布管理团队 635
17.9 规模化敏捷过程 635
17.9.1 规模化敏捷框架 635
17.9.2 规模化活动和事件概览 637
17.9.3 初始准备 639
17.9.4 规模化的季度和特性计划 640
17.9.5 规模化迭代（冲刺）计划会议 651
17.9.6 大规模迭代计划 654
17.9.7 特性预览 656
17.9.8 集成会议 656
17.9.9 日常检查 656
17.9.10 Scrum of Scrums（SoS） 657
17.9.11 产品负责人委员会的会议 658
17.9.12 规模化（季度）特性准备（多个团队） 660
17.9.13 团队层次的故事准备 663
17.9.14 用户特别小组的会议 664
17.9.15 规模化迭代评审或特性评审会议 664
17.9.16 规模化迭代回顾会议 665
17.9.17 规模化的季度/ 特性回顾会议 669
17.9.18 开放空间 670
17.9.19 Traid 673
17.10 敏捷需求管理软件工具 673
17.11 支持团队间协作的轻量级工具 674
17.12 规模化敏捷中的潜在问题和挑战 675
17.12.1 非集中式团队的准则 675
17.12.2 与瀑布团队合作的指导性原则 677
17.12.3 无法频繁且可靠地进行部署 678
17.12.4 反复出现的集成错误和依赖性问题 678
17.12.5 优先级的冲突 678
17.12.6 业务资源不足 679
17.13 小结 680
17.14 下一个主题 680
第18 章 实现企业的敏捷性 685
18.1 目标 688
18.2 本章在全景图中的位置 688
18.3 企业的敏捷性 689
18.3.1 定义敏捷企业 689
18.3.2 为什么需要敏捷企业 689
18.3.3 商业分析的贡献 690
18.3.4 企业敏捷性的驱动力 690
18.3.5 监管严格的行业的敏捷性 691
18.4 基础实践 691
18.4.1 精益创业/MVP 692
18.4.2 全能计划 692
18.4.3 基于情况的市场细分 693
18.4.4 颠覆性创新 693
18.5 概述开发创新产品的敏捷过程 693
18.6 敏捷企业文化 695
18.6.1 企业文化的定义 695
18.6.2 敏捷企业文化的定义 695
18.7 敏捷企业文化的原则和实践概述 696
18.8 应用敏捷实践的三项原则 697
18.8.1 根据情况调整方法 697
18.8.2 保护创新岛屿 706
18.8.3 积极投资企业敏捷性 710
18.9 敏捷企业文化的13 项实践 712
18.9.1 迭代实验（快速失败） 712
18.9.2 拥抱变革 715
18.9.3 加速 716
18.9.4 同理心 717
18.9.5 负责任的拖延（最后责任时刻） 721
18.9.6 分布式权力 722
18.9.7 让实际做事的人估计付出 725
18.9.8 协作 726
18.9.9 致力于结果，而不是产出 729
18.9.10 透明性 729
18.9.11 打破筒仓 729
18.9.12 以数据为依据的创新 735
18.9.13 监视近似和低端市场 736
18.10 敏捷财务计划 738
18.10.1 实物期权 738
18.10.2 以发现为导向的计划 739
18.11 小结 739
附录A 745
附录B 763
参考资料 775
|
| 內容試閱：
|
齿刚则折，舌柔则存。
—孔子
本书旨在协助企业培养和提升可靠而又敏捷的商业分析与计划能力，进而帮助企业更灵活、高效地应对快速变化的商业环境。在本书的定义中，敏捷分析与计划是组织必须具备的基本能力，涉及对企业或其任何方面（包括文化、组织结构、流程和产品）进行审视，了解在高度重视适应性、灵活性、持续创新和价值交付的情况下哪些需要改变以及什么时候需要改变，才能取得较为理想的结果。为了获得这样的能力，必须完成的关键活动包括分析产品面向的对象（干系人）、定义需求、确定交付时间以及预估成本和资源。
我为什么要写这本书
多年以来，在为IT 组织提供咨询服务的过程中，我注意到一点：从事敏捷分析与计划的人员一直在寻求一本能够用来指导其日常工作的实用参考书。目前，关于这一主题的书已经为此提供了一个基本的框架。例如国际商业分析协会（IIBA）与敏捷联盟联合出版的《BABOK 指南之敏捷模块》，书中概括了如何在不同的计划范围内应用各种技术和指导原则。项目管理协会（PMI）的《敏捷实践指南》从项目负责人和项目团队的角度提供了一个有价值的概述。还有一些基础书籍为该学科领域的特定主题提供了详细的指导，例如《DevOps 实践指南》（Humble，et al.2018）、《敏捷软件开发：用户故事实战》（Cohn，2004）以及针对特定框架的一些文献（如《Scrum 指南》）。但我也注意到，市场上还缺少用于进阶的书籍。我意识到，几乎没有任何出版物能将这方面的基础技术联系起来并为读者提供足够具体的指导，使他们可以在工作场景中真正落地实践。我写这本书的目的是填补这个空白，所以在书中提供了可操作的建议，并以具体的例子为支撑，说明如何在不同场景下使用和调整敏捷实践。
本书提供了强大的工具、技术、例子、图表、模板、检查清单和其他辅助工具（数量多达175 个），因而足以整合成为大多数商业分析从业人员或产品负责人的工具箱。书中综合了主流敏捷框架下的《商业分析与计划》指导原则，提炼了我在过去二三十年中与敏捷团队合作的经验和教训。回首过去，我也犯过不少错误，套用诺贝尔文学奖得主萨缪尔·贝克特的话来说：“不断尝试，失败。没关系，再来。再失败，失败也是一种进步。”一路走来，我明白了哪些方法和措施有效以及哪些无效。这本书包含了我从错误中汲取到的教训，以免大家盲目地去试错。
本书提供的指导意见来自我与多位合作伙伴多年来的集体智慧，他们是我的同事或客户，分别来自REI Co-op、Covance、LabCorp、美国食品药品监督管理局（FDA）、财险公司、多伦多道明银行、蒙特利尔银行、罗杰斯通讯集团、研科和加拿大抵押和住房公司等。感谢他们信任我并与我分享他们的经验和教训，使我能够传承这份善意并分享给大家。
敏捷分析与计划的重点是改善与客户/ 用户的沟通，使企业能预测并有效地应对客户在习惯和行为上的变化—即使是在极端不确定的情况下。在我的记忆中，任何时候都不像今天这样觉得这样做的重要性。当我刚完成这本书的时候，新冠疫情还在全球肆虐，此时的一切—如此平凡到伟大—似乎都变得不再那么确定。在这些变化结束后，会是什么样子？我们是会团结起来还是会进一步分裂？从现实世界到网上生活的转变真的是不可逆的吗？远程工作会成为常态吗？远程学习和网上购物又如何呢？这个时代面临巨大的挑战，但也是一个重塑自我的良机。我希望这本书能帮助你和你所在的组织在这个令人难以置信的乌卡或巴尼时代—以及即将到来的“新常态”—驾驭这些变化，适应甚至借此机会进一步繁荣和壮大！
跨敏捷框架的最新指导
这是我针对商业分析而写的第三本书。我之前写的两本书描述了如何在迭代开发生命周期中进行商业分析。看到这两本书在全球范围内取得成功（包括西班牙语版和葡萄牙语版以及介绍UML 的那本书第2 版的发行），我非常高兴。如果你喜欢那几本书，那么我有理由相信你也会喜欢自己手上拿着的这本。不过，从我第一次出书以来，已经发生了很多变化。本书让我回到自己似曾相识的地方，不同的是，加入了我对当今最成功的主流敏捷分析框架与实践的新的见解，具体涉及的主题如下：
? DevOps
? SAFe
? 看板
? Scrum
? 精益软件开发
? 精益创业和最小可行产品（MVP）
? 用户故事与极限编程（XP）
? 持续集成/ 持续交付（CI/CD）
? 测试驱动开发（TDD）、验收测试驱动开发（ATDD）和行为驱动开发（BDD）
? 全部潜能计划
? 发现驱动型计划
? 基于应用场景的市场细分
? 敏捷流畅度模型
此外，本书还与以下专业认证指南是一致的：
? PMI：Agile Practice Guide
? IIBA：Agile Extension to the BABOK Guide v2
? PMI：Business Analysis Practice Guide
? IIBA: BABOK v3：A Guide to Business Analysis Body of Knowledge
本书的特色
和其他许多指南不同，本书包含的资源相当丰富，足以帮助大家执行有效的敏捷分析与计划。
? 详尽的指导：这本实用手册明确指出该做什么以及如何去做。
? 与商业分析相结合：大多数关于敏捷分析的书只关注敏捷技术，而忽略了有价值的商业分析技术应该如何运用，比如业务规则分析和流程建模。本书讨论了如何将传统的分析技术无缝接入到敏捷过程中，以提高敏捷团队的生产力。
? 对敏捷方法和框架进行全面的覆盖：本书结合了当前主流敏捷框架下的最佳实践，包括精益、SAFe、看板和Scrum，力求帮助大家在敏捷环境中实现效率最优化。
? 基于经验的指导：本书基于我与公司和团队合作多年过程中改进敏捷分析与计划的经验，目的是大家留意哪些有效以及哪些时候有效，虽然我参考了现在最有效的敏捷框架，但具体指导上实际并不特别受制于任何框架。
? 基于应用场景的及时学习：开发生命周期各个阶段要用到的技术和指南，书中都有及时的讲述，你将从中学会需要掌握哪些东西并知道其应用场景和时机。
? 广泛的工作辅助工具：本书包括有价值的工作辅助工具（数量超过175 个），旨在帮助大家加深理解和提高工作效率。
－ 用于创建分析与计划工件的具体例子和模板，例如产品愿景宣言、产品路线图、故事地图、史诗、特性、探针、故事和验收标准
－ 大量用例图和示意图
－ 会议议程和其他辅助工具
－ 检查清单
? 一个贯穿全书的端到端案例学习：该案例旨在帮助大家理解敏捷开发生命周期中各个步骤和工件是如何相互促进的。
此外，本书“实锤”验证了商业分析在敏捷组织中具有极高的价值—结合传统商业分析和敏捷分析与计划，可以打造出一个又一个更高效的敏捷团队。
敏捷分析与计划对企业的重要性
我们知道，采用敏捷方法后，很多组织获得了显著的收益。例如，与行业平均水平（QSM）相比，项目完成时间快了37%，1 生产率提高了16%。2 我们还知道，敏捷组织可以通过提高分析与计划能力来极大地提高项目成功率。3 Business Analysis Benchmark 报告4 指出，从能力成熟度最低（1 级）的42% 提高到成熟度最高（4 级）的91%，敏捷组织的项目成功率高出一倍多。另外，报告还发现，即使是成熟度水平的小幅提高，也会产生重大的影响。例如，从2 级到2.5 级，会使敏捷组织的成功率从62% 上升到74%。更多详情可参见第2 章。
组织在拥有高效敏捷分析与计划能力后，可以解决以下问题。
? 由于事先没有充分了解需求而导致的返工。
? 由于团队计划和协调不力而导致的延误。
? 由于工作在整个生产周期中没有得到很好的优先排序而导致的团队生产力低下。
? 对干系人的期望管理不到位。
? 资源不足以及产品负责人加班过度。
? 由于企业文化问题没有得到适当解决而导致敏捷开发难以实现规模化。
现在，大家都意识到，敏捷分析与计划可以有效解决这些问题和其他更多的问题。拥有传统商业分析经验的组织正在提升其敏捷能力，并将其视为有价值的贡献因子。与此同时，那些刚开始敏捷之旅且没有强大商业分析能力的初创技术公司，现在也在逐步引入商业分析能力。随着这些公司日趋成熟，他们会发现，由于业务领域和产品底层架构日益复杂，这两种技能的结合变得尤为重要。
企业若能具备高效的敏捷分析与计划能力，将拥有以下好处。
? 预测客户需求的能力得以提升：敏捷分析师运用丰富的技术来深入了解客户。根因分析和基于情境的市场细分，可以用来确定客户的基本需求及其问题的根源。卡诺分析可以帮助企业预测客户会接受哪些产品特性。MVP 测试可以揭示拟议的哪些特性对客户最有价值，对假设进行验证可以充分利用有限的开发资源。
? 提高变革管理能力：敏捷分析可以提高团队感知和应变能力并在此过程中做出适当的调整。
? 有效计划的能力：有助于组织有效地进行短期计划和长期计划，无论是在极端不确定的情况下，还是在已知确定的情况下。
? 缩短上市时间：之所以有助于缩短上市时间，是因为敏捷分析将开发工作集中在一组最小的高价值特性上，并随着时间的推移进一步评估和优化特性。
? 基于数据来做决策：通过使用精益创业的MVP 流程、A/B 测试和可行的指标，敏捷分析与计划实践有助于增强团队基于数据来做决策的能力。
? 减少返工和延误：敏捷分析减少了返工和不必要的延误，因为在正确的时间进行了正确的商业分析。
? 提高团队的生产力：之所以能提高生产力，是因为团队总是在做对整个产品而言价值最高的任务。
? 提高干系人的参与度：在整个生命周期中，干系人都在参与渐进的滚动式分析过程，参与度更高。
? 产品负责人的支持：有了完善的敏捷分析能力，产品负责人可以及时得到必要的支持，从而有效地完成工作。敏捷分析与计划人员负责团队的需求并与团队进行日常的沟通，如此一来产品负责人便能够专注于该角色（面向外交付价值）。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
