內 容 簡 介本書全面介紹了如何在敏捷環境中管理軟件需求，全書共四部分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
