《知行合一 實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)》是作者幾十年從事軟件工程教學(xué)、咨詢和研究的一個總結(jié),它從軟件產(chǎn)品開發(fā)的“軟”“易變”“非線性增長復(fù)雜度”“創(chuàng)新”等特點入手,系統(tǒng)討論了軟件工程自身的特殊性,清楚揭示了我們遵循幾十年的借鑒傳統(tǒng)行業(yè)開發(fā)模式的方法不能高效匹配軟件開發(fā),導(dǎo)致軟件工程成為低效工程領(lǐng)域的原因。本書系統(tǒng)探討了從瀑布模式到敏捷模式轉(zhuǎn)型的成功實踐,在特定企業(yè)環(huán)境下讓敏捷在組織、團(tuán)隊、項目中落地,并使其價值*大化,擺脫常見的“形似神不似”的敏捷實施。本書關(guān)于CMMI和敏捷開發(fā)模式結(jié)合的內(nèi)容對國內(nèi)眾多的CMMI企業(yè)有很好的現(xiàn)實意義,二者的互補性使其結(jié)合彌補了各自的不足,使企業(yè)能更好地提升其開發(fā)過程的能力。如何將新一代精益開發(fā)的原則、實踐移植到軟件開發(fā)中的內(nèi)容是本書另一個亮點。
各類軟件組織的管理人員、技術(shù)人員、質(zhì)量控制人員和過程改進(jìn)人員都可以從《知行合一 實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)》中獲得所需的知識,《知行合一 實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)》也可以作為高校軟件工程相關(guān)課程的教材。
無論是從大的框架角度、開發(fā)管理原則角度、具體實踐角度,還是企業(yè)實施效果角度,敏捷和精益在軟件實踐中都已經(jīng)形成了一套相對完整、具備指導(dǎo)意義、具備系統(tǒng)性的新一代軟件開發(fā)方法。
真正的敏捷和精益方法會時刻把握住軟件開發(fā)中核心的經(jīng)濟(jì)指標(biāo),避免盲目追求可能沒有價值的替代度量指標(biāo),這是走出“形似神不似”的敏捷和精益實施誤區(qū)的關(guān)鍵。
通過技術(shù)債務(wù)和質(zhì)量債務(wù)的管理,追求健康迭代而不是帶病迭代,敏捷和精益給我們帶來了新的質(zhì)量理念。
近年業(yè)界的經(jīng)驗證明,CMMI是敏捷開發(fā)的安全網(wǎng),二者高度互補。CMMI環(huán)境下的敏捷實施能夠更合理地平衡穩(wěn)定度和敏捷度,從而給我們帶來更大的價值。
支持創(chuàng)新的新一代精益開發(fā)方法完全可以移植到軟件產(chǎn)品開發(fā)中,其原則、實踐形成了精益軟件工程的核心內(nèi)容。它代表了軟件開發(fā)的明天。
“知行合一”是導(dǎo)入敏捷和精益的自然之路。每個軟件團(tuán)隊都有追求與眾不同的權(quán)利,而執(zhí)著找尋軟件開發(fā)之鑰的實踐者們的不斷努力才是完善敏捷和精益*重要的環(huán)節(jié)。
叢斌博士,早年畢業(yè)于南京大學(xué),1984年公派留學(xué)去了美國,分別在杜克大學(xué)和德州大學(xué)獲得碩士和博士學(xué)位。目前是美國加州州立大學(xué)軟件工程終身教授,領(lǐng)導(dǎo)建立了全美排名前列的軟件工程碩士學(xué)位課程。發(fā)表過100多篇論文,解決過一些經(jīng)典的算法問題。作為國際知名的計算機(jī)和算法專家,叢斌博士也是CMMI研究院第一批高成熟度主任評估師、講師之一。在產(chǎn)品開發(fā)體系建設(shè)及改進(jìn)、敏捷和精益開發(fā)、質(zhì)量控制及CMMI模型驅(qū)動改進(jìn)等方面有豐富的理論知識及實戰(zhàn)經(jīng)驗,曾為國內(nèi)外許多知名企業(yè),如雷神、華為等提供過軟件開發(fā)方面的咨詢、培訓(xùn)和評估。曾入選1997年國際IT名人錄,也是加州州立大學(xué)富勒頓分校工學(xué)院2011年度杰出教授。
目錄
第一部分 神形兼?zhèn)涞拿艚蓍_發(fā)模式
第1章 從“先知后行”到“知行合一”——從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式 2
1.1 重新審視項目成功的標(biāo)準(zhǔn) 3
1.1.1 傳統(tǒng)的三要素不一定能客觀度量項目的成功與否 3
1.1.2 新的項目管理鐵三角 5
1.1.3 敏捷讓我們實現(xiàn)價值驅(qū)動管理 8
1.2 重新審視瀑布模式為代表的傳統(tǒng)開發(fā)方法 9
1.2.1 來自制造業(yè)的接力式開發(fā)模式 9
1.2.2 瀑布開發(fā)模式的不合理之處 11
1.3 復(fù)雜軟件項目的共性:需求的不確定及技術(shù)的不確定 11
1.3.1 客戶對自己真正需要的產(chǎn)品需要一個認(rèn)識的過程 12
1.3.2 實現(xiàn)每個客戶需求都有代價,但不是每個需求都有價值 13
1.3.3 技術(shù)平臺的不確定性 14
1.3.4 團(tuán)隊一開始不了解自己的效率 15
1.3.5 傳統(tǒng)方法不能高效解決這些不確定性帶來的問題 15
1.4 從“先知后行”到“知行合一” 16
1.4.1 知行合一是自然的結(jié)論 16
1.4.2 敏捷就是在開發(fā)中學(xué)習(xí)、成長、調(diào)整和完善 18
1.4.3 敏捷是實現(xiàn)價值驅(qū)動管理的好方法 19
兩個團(tuán)隊的故事 20
第2章 敏捷開發(fā)方法——摸著石頭過河的智慧 24
2.1 經(jīng)常被錯誤解讀的敏捷宣言及敏捷原則 25
2.1.1 敏捷宣言是價值宣言 25
2.1.2 敏捷的12原則背后的故事 26
2.2 敏捷開發(fā)架構(gòu)與Scrum:調(diào)整中增量開發(fā) 31
2.2.1 敏捷開發(fā)架構(gòu) 31
2.2.2 用一分鐘來解釋一下Scrum以及Scrum中的3個角色、3個文檔和5個會議 34
2.2.3 敏捷框架下看Scrum 38
2.2.4 Scrum和極限編程的結(jié)合使用 38
2.3 Scrum是一個實現(xiàn)敏捷價值及原則的開發(fā)管理架構(gòu) 39
2.3.1 Scrum讓敏捷價值的實現(xiàn)變得自然 39
2.3.2 Scrum是敏捷原則的具體體現(xiàn) 40
一個團(tuán)隊的兩個故事 40
第3章 形神兼具——實現(xiàn)敏捷的核心價值 43
3.1 形似神不似的Scrum實施 44
3.1.1 Scrum不能保證解決問題,但能保證暴露問題 44
3.1.2 沒有本地化的適配,敏捷過程很難落地生根 45
3.1.3 不要因為錯誤的原因引入Scrum,要明確引入敏捷的目的 45
3.2 使用Scrum的藝術(shù) 46
3.2.1 Scrum中的自我管理及實現(xiàn)方式 46
3.2.2 管理者從監(jiān)控型到服務(wù)型的轉(zhuǎn)變 48
3.2.3 追求問題的解決而不是最佳解決方案 49
3.2.4 對工程人員能力提升及自律的要求 50
3.2.5 Scrum實踐的互補,完整的Scrum才最有價值 51
3.3 極限編程是Scrum最好的伙伴 54
3.3.1 技術(shù)債務(wù):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 精益組織與敏捷團(tuán)隊 62
3.4.2 管理者的勇氣:做有遠(yuǎn)見的智慧型領(lǐng)導(dǎo)者 63
3.4.3 工程人員的勇氣:合奏與獨奏 65
3.4.4 過程改進(jìn)人員的勇氣:找到你的定位 65
3.5 變革之路:從瀑布模式到敏捷模式的轉(zhuǎn)化 66
3.5.1 瀑布模式到敏捷模式中人和組織的轉(zhuǎn)化 66
3.5.2 瀑布模式到敏捷模式中企業(yè)文化及習(xí)慣的轉(zhuǎn)化 67
3.5.3 瀑布模式到敏捷模式的轉(zhuǎn)化過程 68
兩個團(tuán)隊的故事 69
第二部分 建立以Scrum為框架的軟件開發(fā)管理體系
第4章 布好自己的局——確定Scrum中的角色、文檔和活動 76
4.1 敏捷轉(zhuǎn)型的布局規(guī)劃 76
4.2 建立自己的敏捷過程 76
4.2.1 建立一個端到端的敏捷過程 77
4.2.2 進(jìn)入Scrum迭代的準(zhǔn)備過程 79
4.2.3 敏捷迭代過程及驗證過程 80
4.2.4 敏捷的改進(jìn)過程 82
4.2.5 選擇敏捷實踐 82
4.3 確定Scrum的角色 84
4.3.1 豬和雞合作創(chuàng)業(yè)的對話 85
4.3.2 選擇Scrum產(chǎn)品經(jīng)理 85
4.3.3 選擇Scrum過程經(jīng)理 88
4.3.4 選擇Scrum團(tuán)隊成員 90
4.3.5 架構(gòu)師在Scrum團(tuán)隊中的定位 91
4.3.6 Scrum of Scrum (大敏捷項目的管理)的安排 92
4.3.7 Scrum中的共享團(tuán)隊資源 95
4.4 敏捷過程對文檔的要求 95
4.4.1 文檔的價值及應(yīng)用 95
4.4.2 敏捷文檔制作指南 96
4.4.3 敏捷過程的需求文檔 97
4.4.4 敏捷環(huán)境下的工程文檔 99
4.4.5 必要的維護(hù)文檔 99
4.4.6 敏捷(Scrum)的管理文檔 100
4.5 建立一個成熟的Scrum過程 100
4.5.1 什么是成熟的敏捷過程 101
4.5.2 保證敏捷過程的執(zhí)行力 101
4.5.3 保證敏捷過程的改進(jìn)力 102
4.6 敏捷工具 102
兩個敏捷角色的故事 103
第5章 迭代管理亦有道——執(zhí)行Scrum項目管理 106
5.1 應(yīng)對變化的敏捷計劃:波浪式的版本規(guī)劃 106
5.1.1 掌握你的團(tuán)隊速率 107
5.1.2 允許項目需求范圍有一定的靈活性 109
5.1.3 遵循“最小有市場價值”原則制訂產(chǎn)品版本計劃 111
5.1.4 制訂第一個版本計劃 112
5.2 Scrum迭代中的管理:頻繁反饋,及時調(diào)整 114
5.2.1 細(xì)化版本需求列表中的用戶故事:準(zhǔn)備好下一輪迭代的工作 114
5.2.2 計劃下一輪迭代 116
5.2.3 開好每日站立會議 117
5.2.4 展示團(tuán)隊的迭代成果:開好迭代評審會議 119
5.2.5 不斷完善Scrum過程:開好迭代回顧會議 120
5.3 建立、維護(hù)你的敏捷島 122
5.3.1 迭代任務(wù)狀態(tài)板塊 122
5.3.2 其他信息板塊 125
5.3.3 白板是最有效的溝通方式 128
5.4 Scrum中的風(fēng)險管理 129
5.4.1 軟件項目的5大風(fēng)險來源 129
5.4.2 把握你的進(jìn)度風(fēng)險 130
5.4.3 把握好需求使之自然完善而不是遍地蔓生 131
5.4.4 建立一個T字型能力團(tuán)隊緩解團(tuán)隊不穩(wěn)定風(fēng)險 132
5.4.5 建立維護(hù)好產(chǎn)品規(guī)格 132
5.4.6 克服低效率風(fēng)險的幾個法寶 133
兩個團(tuán)隊的故事 134
第6章 把握好敏捷的度——敏捷工程及質(zhì)量控制實踐 139
6.1 再議技術(shù)債務(wù) 139
6.1.1 技術(shù)債務(wù)的來源 140
6.1.2 管理技術(shù)債務(wù) 140
6.1.3 減少技術(shù)債務(wù)的實踐 142
6.1.4 減少技術(shù)債務(wù)的具體步驟 143
6.1.5 技術(shù)債務(wù)的度量 144
6.2 敏捷中的需求開發(fā)及管理 145
6.2.1 敏捷四級產(chǎn)品計劃 146
6.2.2 用戶類型的識別過程 146
6.2.3 建立維護(hù)典型用戶檔案 148
6.2.4 從用例到用戶故事 148
6.2.5 貫穿整個開發(fā)過程中的需求澄清:串講及反串講 149
6.3 敏捷中的設(shè)計和開發(fā) 150
6.3.1 簡明設(shè)計原則 151
6.3.2 設(shè)計決策的時機(jī) 153
6.3.3 再議程序開發(fā)中的代碼重構(gòu) 154
6.3.4 敏捷中的評審 156
6.4 敏捷中的測試 157
6.4.1 測試驅(qū)動開發(fā)的價值及方法 158
6.4.2 持續(xù)集成:提高開發(fā)效率的重要保證 158
6.4.3 敏捷測試策略及方法 160
6.4.4 讓發(fā)現(xiàn)的缺陷的價值最大化 162
6.5 健康迭代比速度更重要 163
兩個團(tuán)隊的故事 165
第三部分 CMMI框架下的敏捷實施
第7章 盲人摸象——關(guān)于敏捷和CMMI的錯誤偏見 170
7.1 來自兩個陣營的偏見 170
7.2 CMMI的核心和價值 172
7.3 CMMI+敏捷:解決軟件開發(fā)問題之匙 175
7.4 來自敏捷宣言起草者及CMMI作者的最新聲音 178
敏捷和CMMI的故事 180
第8章 建立敏捷的保護(hù)網(wǎng)——CMMI架構(gòu)下的敏捷實施 187
8.1 從使用角度看CMMI 187
8.1.1 一個產(chǎn)品開發(fā)最佳實踐的集合 187
8.1.2 CMMI的4條主線 188
8.1.3 正確解讀CMMI評估 190
8.1.4 CMMI對工作產(chǎn)品(文檔)的要求 191
8.2 完善Scrum實現(xiàn)CMMI項目管理的要求 192
8.2.1 需求管理和“Scrum+極限編程” 193
8.2.2 項目計劃和“Scrum+極限編程” 194
8.2.3 項目監(jiān)督與控制和“Scrum+極限編程” 195
8.2.4 供方協(xié)議管理和“Scrum+極限編程” 196
8.2.5 集成項目管理和“Scrum+極限編程” 197
8.2.6 風(fēng)險管理和“Scrum+極限編程” 198
8.3 用敏捷實踐實現(xiàn)CMMI工程活動的要求 199
8.3.1 需求開發(fā)和“Scrum+極限編程” 199
8.3.2 技術(shù)解決方案和“Scrum+極限編程” 201
8.3.3 產(chǎn)品集成和“Scrum+極限編程” 202
8.3.4 驗證和“Scrum+極限編程” 203
8.3.5 確認(rèn)和“Scrum+極限編程” 205
8.4 用敏捷手段實現(xiàn)CMMI支持活動的要求 206
8.4.1 敏捷環(huán)境下的過程與產(chǎn)品質(zhì)量保證 206
8.4.2 敏捷環(huán)境下的配置管理 210
8.4.3 敏捷環(huán)境下的度量與分析 212
8.4.4 敏捷環(huán)境下的決策分析與解決 214
8.5 敏捷環(huán)境下實現(xiàn)CMMI過程管理的要求 215
8.5.1 敏捷環(huán)境下的組織級過程關(guān)注 215
8.5.2 敏捷環(huán)境下的組織級過程定義 217
8.5.3 Scrum環(huán)境下的組織級培訓(xùn) 218
8.6 敏捷環(huán)境下實現(xiàn)CMMI高成熟度的要求 219
8.6.1 敏捷下的量化管理:QPPO、基線及模型(OPP和QPM) 219
8.6.2 敏捷環(huán)境下過程優(yōu)化管理:CAR和OPM 221
8.7 敏捷環(huán)境下的CMMI評估應(yīng)關(guān)注的兩個問題 224
8.7.1 實施選擇還是模型要求 224
8.7.2 理解模型的目的 225
敏捷環(huán)境下的兩個CMMI實施和評估故事 226
第四部分 新一代精益軟件工程
第9章 敏捷不是解決軟件開發(fā)問題的銀彈 232
9.1 再議軟件過程的特殊性 233
9.1.1 軟件過程公理 233
9.1.2 軟件過程體系應(yīng)追求的價值 235
9.2 敏捷的局限及挑戰(zhàn) 236
9.2.1 如何盡早獲取有價值的用戶反饋 236
9.2.2 如何設(shè)計軟件架構(gòu)支持快速迭代開發(fā) 237
9.2.3 缺乏具體有效方法實現(xiàn)敏捷原則 238
9.2.4 忽略了開發(fā)中的等待隊列 238
9.2.5 忽略了開發(fā)過程中的變異管理 239
9.3 有效軟件開發(fā)借鑒之源及應(yīng)具備的特點 239
9.3.1 軟件開發(fā)借鑒之源 239
9.3.2 有效軟件開發(fā)模式應(yīng)具備的特點 240
第10章 軟件開發(fā)的新模式——新一代精益軟件工程 242
10.1 初級軟件精益開發(fā)模式:看板方法 243
10.2 精益軟件開發(fā)框架 244
10.3 用經(jīng)濟(jì)指標(biāo)指導(dǎo)軟件開發(fā) 245
10.4 用基本隊列理論、統(tǒng)計方法管理軟件開發(fā)過程 247
10.4.1 管理好軟件開發(fā)中的等待隊列問題 248
10.4.2 軟件開發(fā)過程中變異量的管理 251
10.5 兩個關(guān)鍵關(guān)注點 254
10.5.1 控制好軟件批量開發(fā)規(guī)模 255
10.5.2 控制好軟件開發(fā)隊列的WIP個數(shù) 256
10.6 精益管理控制實踐 257
10.6.1 在充滿不確定的環(huán)境下,盡可能保持流暢的軟件開發(fā)通道 257
10.6.2 充分、及時、有效地利用開發(fā)過程中的反饋信息 259
10.6.3 軟件開發(fā)中集中與分散協(xié)調(diào)控制機(jī)制 260
10.7 實踐出真知 262
參考文獻(xiàn) 264
收起全部↑