 |
-- 會員 / 註冊 --
|
 |
|
|
|
知行合一 實現價值驅動的敏捷和精益開發 ( 簡體 字) |
| 作者：叢斌 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：人民郵電出版社 |  3dWoo書號： 47870
詢問書籍請說出此書號！【有庫存】
NT售價： 395 元 |
| 出版日：10/1/2017 |
| 頁數：266 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787115465566 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
| 前言： |
內容簡介：《知行合一 實現價值驅動的敏捷和精益開發》是作者幾十年從事軟體工程教學、諮詢和研究的一個總結，它從軟體產品開發的“軟”“易變”“非線性增長複雜度”“創新”等特點入手，系統討論了軟體工程自身的特殊性，清楚揭示了我們遵循幾十年的借鑒傳統行業開發模式的方法不能高效匹配軟體發展，導致軟體工程成為低效工程領域的原因。本書系統探討了從瀑布模式到敏捷模式轉型的成功實踐，在特定企業環境下讓敏捷在組織、團隊、專案中落地，並使其價值*化，擺脫常見的“形似神不似”的敏捷實施。本書關於CMMI和敏捷開發模式結合的內容對國內眾多的CMMI企業有很好的現實意義，二者的互補性使其結合彌補了各自的不足，使企業能更好地提升其開發過程的能力。如何將新一代精益開發的原則、實踐移植到軟體發展中的內容是本書另一個亮點。 各類軟體組織的管理人員、技術人員、品質控制人員和過程改進人員都可以從《知行合一 實現價值驅動的敏捷和精益開發》中獲得所需的知識，《知行合一 實現價值驅動的敏捷和精益開發》也可以作為高校軟體工程相關課程的教材。 |
目錄：第一部分 神形兼備的敏捷開發模式
第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 建立自己的敏捷過程 76
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 驗證和“Scrum 極限程式設計” 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
|
| 序： |
|
