知行合一:實現價值驅動的敏捷和精益開發 知行合一:实现价值驱动的敏捷和精益开发

《知行合一 實現價值驅動的敏捷和精益開發》是作者幾十年從事軟件工程教學、咨詢和研究的一個總結，它從軟件產品開發的“軟”“易變”“非線性增長復雜度”“創新”等特點入手，系統討論了軟件工程自身的特殊性，清楚揭示了我們遵循幾十年的借鑒傳統行業開發模式的方法不能高效匹配軟件開發，導致軟件工程成為低效工程領域的原因。本書系統探討了從瀑布模式到敏捷模式轉型的成功實踐，在特定企業環境下讓敏捷在組織、團隊、項目中落地，並使其價值最大化，擺脫常見的“形似神不似”的敏捷實施。本書關於CMMI和敏捷開發模式結合的內容對國內眾多的CMMI企業有很好的現實意義，二者的互補性使其結合彌補了各自的不足，使企業能更好地提升其開發過程的能力。

如何將新一代精益開發的原則、實踐移植到軟件開發中的內容是本書另一個亮點。各類軟件組織的管理人員、技術人員、質量控制人員和過程改進人員都可以從《知行合一 實現價值驅動的敏捷和精益開發》中獲得所需的知識，《知行合一 實現價值驅動的敏捷和精益開發》也可以作為高校軟件工程相關課程的教材。

叢斌博士

早年畢業於南京大學，1984年公派留學去了美國，分別在杜克大學和德州大學獲得碩士和博士學位。目前是美國加州州立大學軟件工程終身教授，領導建立了全美排名前列的軟件工程碩士學位課程。發表過100多篇論文，解決過一些經典的算法問題。

作為國際知名的計算機和算法專家，叢斌博士也是CMMI研究院第一批高成熟度主任評估師、講師之一。在產品開發體系建設及改進、敏捷和精益開發、質量控制及CMMI模型驅動改進等方面有豐富的理論知識及實戰經驗，曾為國內外許多知名企業，如雷神、華為等提供過軟件開發方面的諮詢、培訓和評估。曾入選1997年國際IT名人錄，也是加州州立大學富勒頓分校工學院2011年度傑出教授。

第一部分神形兼備的敏捷開發模式

 

第1章從“先知後行”到“知行合一”——從傳統開發模式到敏捷開發模式2 

1.1重新審視項目成功的標準3 

1.1.1傳統的三要素不一定能客觀度量項目的成功與否3 

1.1.2新的項目管理鐵三角5 

1.1.3敏捷讓我們實現價值驅動管理8 

1.2重新審視瀑布模式為代表的傳統開發方法9 

1.2.1來自製造業的接力式開發模式9 

1.2.2瀑布開發模式的不合理之處11 

1.3複雜軟件項目的共性：需求的不確定及技術的不確定11 

1.3.1客戶對自己真正需要的產品需要一個認識的過程12 

1.3.2實現每個客戶需求都有代價，但不是每個需求都有價值13 

1.3.3技術平台的不確定性14 

1.3.4團隊一開始不了解自己的效率15 

1.3.5傳統方法不能高效解決這些不確定性帶來的問題15 

1.4從“先知後行”到“知行合一” 16 

1.4.1知行合一是自然的結論16 

1.4.2敏捷就是在開發中 習、成長、調整和完善18 

1.4.3敏捷是實現價值驅動管理的好方法19 

兩個團隊的故事20 

 

第2章敏捷開發方法——摸著石頭過河的智慧24 

2.1經常被錯誤解讀的敏捷宣言及敏捷原則25

2.1.1敏捷宣言是價值宣言25 

2.1.2敏捷的12原則背後的故事26 

2.2敏捷開發架構與Scrum：調整中增量開發31 

2.2.1敏捷開發架構31 

2.2.2用一分鐘來解釋一下Scrum以及Scrum中的3個角色、3個文檔和5個會議34 

2.2.3敏捷框架下看Scrum 38 

2.2.4 Scrum和極限編程的結合使用38 

2.3 Scrum是一個實現敏捷價值及原則的開發管理架構39 

2.3.1 Scrum讓敏捷價值的實現變得自然39 

2.3.2 Scrum是敏捷原則的具體體現40 

一個團隊的兩個故事40 

 

第3章形神兼具——實現敏捷的核心價值43 

3.1形似神不似的Scrum實施44 

3.1.1 Scrum不能保證解決問題，但能保證暴露問題44 

3.1.2沒有本地化的適配，敏捷過程很難落地生根45 

3.1.3不要因為錯誤的原因引入Scrum，要明確引入敏捷的目的45 

3.2使用Scrum的藝術46 

3.2.1 Scrum中的自我管理及實現方式46 

3.2.2管理者從監控型到服務型的轉變48 

3.2.3追求問題的解決而不是最佳解決 案49 

3.2.4對工程人員能力提升及自律的要求50 

3.2.5 Scrum實踐的互補，完整的Scrum才最有價值51

3.3極限編程是Scrum最好的伙伴54 

3.3.1技術債務：Scrum的殺手55 

3.3.2極限編程的4個核心價值55 

3.3.3極限編程的原則57 

3.3.4極限編程的4個核心工程活動58 

3.3.5極限編程的12條實踐59 

3.3.6極限編程+Scrum：1+1>2 60 

3.4引入Scrum等敏捷方法是一場需要勇氣的變革61 

3.4.1精益組織與敏捷團隊62 

3.4. 2管理者的勇氣：做有遠見的智慧型領導者63 

3.4.3工程人員的勇氣：合奏與獨奏65 

3.4.4過程改進人員的勇氣：找到你的定位65 

3.5變革之路：從瀑布模式到敏捷模式的轉化66 

3.5.1瀑布模式到敏捷模式中人和組織的轉化66 

3.5.2瀑布模式到敏捷模式中企業文化及習慣的轉化67 

3.5.3瀑布模式到敏捷模式的轉化過程68 

兩個團隊的故事69 

 

第二部分建立以Scrum為框架的軟件開發管理體系

 

第4章布好自己的局——確定Scrum中的角色、文檔和活動76 

4.1敏捷轉型的佈局規劃76 

4.2建立自己的敏捷過程7 6 

4.2.1建立一個端到端的敏捷過程77 

4.2.2進入Scrum迭代的準備過程79 

4.2.3敏捷迭代過程及驗證過程80

4.2.4敏捷的改進過程82 

4.2.5選擇敏捷實踐82 

4.3確定Scrum的角色84 

4.3.1豬和雞合作創業的對話85 

4.3.2選擇Scrum產品經理85 

4.3.3選擇Scrum過程經理88 

4.3. 4選擇Scrum團隊成員90 

4.3.5架構師在Scrum團隊中的定位91 

4.3.6 Scrum of Scrum （大敏捷項目的管理）的安排92 

4.3.7 Scrum中的共享團隊資源95 

4.4敏捷過程對文檔的要求95 

4.4.1文檔的價值及應用95 

4.4.2敏捷文檔製作指南96 

4.4.3敏捷過程的需求文檔97 

4.4.4敏捷環境下的工程文檔99 

4.4.5必要的維護文檔99 

4.4.6敏捷（Scrum）的管理文檔100 

4.5建立一個成熟的Scrum過程100 

4.5.1什麼是成熟的敏捷過程101 

4.5.2保證敏捷過程的執行力101 

4.5.3保證敏捷過程的改進力102 

4.6敏捷工具102 

兩個敏捷角色的故事103 

 

第5章迭代管理亦有道——執行Scrum項目管理106 

5.1應對變化的敏捷計劃：波浪式的版本規劃106 

5.1.1掌握你的團隊速率107

5.1.2允許項目需求範圍有一定的靈活性109 

5.1.3遵循“最小有市場價值”原則制訂產品版本計劃111 

5.1.4制訂第一個版本計劃112 

5.2 Scrum迭代中的管理：頻繁反饋，及時調整114 

5.2.1細化版本需求列表中的用戶故事：準備好下一輪迭代的工作114 

5.2.2計劃下一輪迭代116 

5.2.3開好每日站立會議117 

5.2.4展示團隊的迭代成果：開好迭代評審會議119 

5.2.5不斷完善Scrum過程：開好迭代回顧會議120 

5.3建立、維護你的敏捷島122 

5.3.1迭代任務狀態板塊122 

5.3.2其他信息板塊125 

5.3.3白板是最有效的溝通方式128 

5.4 Scrum中的風險管理129 

5.4.1軟件項目的5大風險來源129 

5.4.2把握你的進度風險130 

5.4.3把握好需求使之自然完善而不是遍地蔓生131 

5.4 .4建立一個T字型能力團隊緩解團隊不穩定風險132 

5.4.5建立維護好產品規格132 

5.4.6克服低效率風險的幾個法寶133 

兩個團隊的故事134 

 

第6章把 握好敏捷的度——敏捷工程及質量控制實踐139 

6.1再議技術債務139 

6.1.1技術債務的來源140

6.1.2管理技術債務140 

6.1.3減少技術債務的實踐142 

6.1.4減少技術債務的具體步驟143 

6.1.5技術債務的度量144 

6.2敏捷中的需求開發及管理145 

6.2.1敏捷四級產品計劃146 

6.2.2用戶類型的識別過程146 

6.2.3建立維護典型用戶檔案148 

6.2.4從用例到用戶故事148 

6.2.5貫穿整個開發過程中的需求澄清：串講及反串講149 

6.3敏捷中的設計和開發150 

6.3.1簡明設計原則151 

6.3.2設計決策的時機153 

6.3.3再議程序開發中的代碼重構154 

6.3.4敏捷中的評審156 

6.4敏捷中的測試157 

6.4.1測試驅動開發的價值及方法158 

6.4.2持續集成：提高開發效率的重要保證158 

6.4.3敏捷測試策略及方法160 

6.4.4讓發現的缺陷的價值最大化162 

6.5健康迭代比速度更重要163 

兩個團隊的故事165 

 

第三部分CMMI框架下的敏捷實施

 

第7章盲人摸象——關於敏捷和CMMI的錯誤偏見170 

7.1來自兩個陣營的偏見170 

7.2 CMMI的核心和 值172

7.3 CMMI+敏捷：解決軟件開發問題之匙175 

7.4來自敏捷宣言起草者及CMMI作者的最新聲音178 

敏捷和CMMI的故事180 

 

第8章建立敏捷的保護網——CMMI架構下的敏捷實施187 

8.1從使用角度看CMMI 187 

8.1.1一個產品開發最佳實踐的集合187 

8.1.2 CMMI的4條主線188 

8.1.3正確解讀CMMI評估190 

8.1.4 CMMI對工作產品（文檔）的要求191 

8.2完善Scrum實現CMMI項目管理的要求192 

8.2.1需求管理和“Scrum+極限編程” 193 

8.2.2項目計劃和“Scrum+極限編程” 194 

8.2.3項目監督與控制和“Scrum+極限編程” 195 

8.2.4供方協議管理和“Scrum+極限編程” 196 

8.2.5集成項目管理和“Scrum+極限編程” 197 

8.2.6風險管理和“Scrum+極限編程” 198 

8.3用敏捷實踐實現CMMI工程活動的要求199 

8.3.1需求開發和“Scrum+極限編程” 199 

8.3.2技術解決方案和“Scrum+極限編程” 201 

8.3.3產品集成和“Scrum+極限編程” 202 

8.3.4驗證和“Scru m+極限編程” 203 

8.3.5確認和“Scrum+極限編程” 205

8.4用敏捷手段實現CMMI支持活動的要求206 

8.4.1敏捷環境下的過程與產品質量保證206 

8.4.2敏捷環境下的配置管理210 

8.4.3敏捷環境下的度量與分析212 

8.4.4敏捷環境下的決策分析與解決214 

8.5敏捷環境下實現CMMI過程管理的要求215 

8.5.1敏捷環境下的組織級過程關注215 

8.5.2敏捷環境下的組織級過程定義217 

8.5.3 Scrum環境下的組織級培訓218 

8.6敏捷環境下實現CMMI高成熟度的要求219 

8.6.1敏捷下的量化管理：QPPO、基線及模型（OPP和QPM） 219 

8.6.2敏捷環境下過程優化管理：CAR和OPM 221 

8.7敏捷環境下的CMMI評估應關注的兩個問題224 

8.7.1實施選擇還是模型要求224 

8.7.2理解模型的目的225 

敏捷環境下的兩個CMMI實施和評估故事226 

 

第四部分新一代精益軟件工程

 

第9章敏捷不是解決軟件開發問題的銀彈232 

9.1再議軟件過程的特殊性233 

9.1.1軟件過程公理233 

9.1.2軟件過程體系應追求的 值235 

9.2敏捷的局限及挑戰236 

9.2.1如何儘早獲取有價值的用戶反饋236

9.2.2如何設計軟件架構支持快速迭代開發237 

9.2.3缺乏具體有效方法實現敏捷原則238 

9.2.4忽略了開發中的等待隊列238 

9.2.5忽略了開發過程中的變異管理239 

9.3有效軟件開發借鑒之源及應具備的特點239 

9.3.1軟件開發借鑒之源239 

9.3.2有效軟件開發模式應具備的特點240 

 

第10章軟件開發的新模式——新一代精益軟件工程242 

10.1初級軟件精益開發模式：看板方法243 

10.2精益軟件開發框架244 

10.3用經濟指標指導軟件開發245 

10.4用基本隊列理論、統計方法管理軟件開發過程247 

10.4.1管理好軟件開發中的等待隊列問題248 

10.4.2軟件開發過程中變異量的管理251 

10.5兩個關鍵關注點254 

10.5.1控制好軟件批量開發規模255 

10.5.2控制好軟件開發隊列的WIP個數256 

10.6精益管理控制實踐257 

10.6.1在充滿不確定的環境下，盡可能保持流暢的軟件開發通道257 

10.6.2充分、及時、有效地利 開發過程中的反饋信息259 

10.6.3軟件開發中集中與分散協調控制機制260 

10.7實踐出真知262

參考文獻264