《敏捷商業分析與計畫：從戰略規劃到持續交付價值》是2023年清華大學出版社出版的圖書。
基本介紹
- 中文名：敏捷商業分析與計畫：從戰略規劃到持續交付價值
- 作者：霍華德·波德斯瓦(Howard Podeswa)
- 譯者：周子衿
- 出版時間：2023年7月
- 出版社：清華大學出版社
- ISBN：9787302626022
- 開本：24 開
- 裝幀：平裝-膠訂
內容簡介,作者簡介,圖書目錄,
內容簡介
《敏捷商業分析與計畫：從戰略規劃到持續交付價值》通過貫穿全書的一個敏捷分析與計畫全景圖和一個循序漸近的案例學習來展示商業分析和敏捷方法緊密結合從最開始的戰略規劃到最後持續交付價值。讀者可以在本書的指導下進行敏捷分析與計畫，幫助組織靈活地應對快速變化的商業環境。 《敏捷商業分析與計畫：從戰略規劃到持續交付價值》適合產品負責人、產品/ 項目集經理、商業分析師、需求工程師和項目經理閱讀與參考，也是商業分析相關認證考試的備考指南，還可以幫助讀者培養和提升敏捷分析與計畫能力。
作者簡介
霍華德·波德斯瓦(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 什麼是MVP247
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 BPMN309
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 逐步地規模化MVP395
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 用決策表分析業務規則和AC468
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–alpha583
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/CD612
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
