知行合一：實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)課件

1、2020知行合一： 實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)演講人2025-11-112020知行合一： 實現(xiàn)價值驅(qū)動的敏捷和精益開發(fā)演講人202456231目錄78對本書的贊譽序一序二序三第一部分 神形兼?zhèn)涞拿艚蓍_發(fā)模式第二部分 建立以Scrum為框架的軟件開發(fā)管理體系第三部分 CMMI框架下的敏捷實施第四部分 新一代精益軟件工程456231目錄78對本書的贊譽序一序二序三第一部分 神形兼01對本書的贊譽01對本書的贊譽對本書的贊譽對本書的贊譽02序一02序一序一 序一 03序二03序二序二 序二 04序三04序三序三 序三 05第一部分 神形兼?zhèn)涞拿艚蓍_發(fā)模式05第一部分 神形兼?zhèn)涞拿艚蓍_發(fā)模式1 從

2、“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式011.1 重新審視項目成功的標準021.2 重新審視瀑布模式為代表的傳統(tǒng)開發(fā)方法031.3 復雜軟件項目的共性：需求的不確定及技術(shù)的不確定041.4 從“先知后行”到“知行合一”05兩個團隊的故事1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式1.1 重新審視項目成功的標準1.1.1 傳統(tǒng)的三要素不一定能客觀度量項目的成功與否1.1.2 新的項目管理鐵三角1.1.3 敏捷讓我們實現(xiàn)價值驅(qū)動管理1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)1 從“先知后行”到“知

3、行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式1.2 重新審視瀑布模式為代表的傳統(tǒng)開發(fā)方法1.2.1 來自制造業(yè)的接力式開發(fā)模式1.2.2 瀑布開發(fā)模式的不合理之處1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式1.3 復雜軟件項目的共性：需求的不確定及技術(shù)的不確定1.3.1 客戶對自己真正需要的產(chǎn)品需要一個認識的過程1.3.2 實現(xiàn)每個客戶需求都有代價，但不是每個需求都有價值1.3.3 技術(shù)平臺的不確定性1.3.4 團隊一開始不了解自己的效率1.3.5 傳統(tǒng)方法不能高效解決這些不確定性帶來的問題1 從“先知后行”到“知行合一”從傳統(tǒng)開

4、發(fā)模式到敏捷開發(fā)1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)模式1.4 從“先知后行”到“知行合一”1.4.1 知行合一是自然的結(jié)論1.4.2 敏捷就是在開發(fā)中學習、成長、調(diào)整和完善1.4.3 敏捷是實現(xiàn)價值驅(qū)動管理的好方法1 從“先知后行”到“知行合一”從傳統(tǒng)開發(fā)模式到敏捷開發(fā)2 敏捷開發(fā)方法摸著石頭過河的智慧2.1 經(jīng)常被錯誤解讀的敏捷宣言及敏捷原則2.2 敏捷開發(fā)架構(gòu)與Scrum：調(diào)整中增量開發(fā)2.3 Scrum是一個實現(xiàn)敏捷價值及原則的開發(fā)管理架構(gòu)一個團隊的兩個故事3 形神兼具實現(xiàn)敏捷的核心價值3.1 形似神不似的Scrum實施2 敏捷開發(fā)方法摸著石頭過河的智慧2.1 經(jīng)常

5、被錯誤解讀2 敏捷開發(fā)方法摸著石頭過河的智慧3.2 使用Scrum的藝術(shù)3.3 極限編程是Scrum最好的伙伴3.4 引入Scrum等敏捷方法是一場需要勇氣的變革3.5 變革之路：從瀑布模式到敏捷模式的轉(zhuǎn)化兩個團隊的故事2 敏捷開發(fā)方法摸著石頭過河的智慧3.2 使用Scrum2 敏捷開發(fā)方法摸著石頭過河的智慧2.1 經(jīng)常被錯誤解讀的敏捷宣言及敏捷原則2.1.1 敏捷宣言是價值宣言2.1.2 敏捷的12原則背后的故事2 敏捷開發(fā)方法摸著石頭過河的智慧2.1 經(jīng)常被錯誤解讀2 敏捷開發(fā)方法摸著石頭過河的智慧2.2 敏捷開發(fā)架構(gòu)與Scrum：調(diào)整中增量開發(fā)2.2.1 敏捷開發(fā)架構(gòu)2.2.2 用一分鐘

6、來解釋一下Scrum以及Scrum中的3個角色、3個文檔和5個會議2.2.3 敏捷框架下看Scrum2.2.4 Scrum和極限編程的結(jié)合使用2 敏捷開發(fā)方法摸著石頭過河的智慧2.2 敏捷開發(fā)架構(gòu)與2 敏捷開發(fā)方法摸著石頭過河的智慧2.3 Scrum是一個實現(xiàn)敏捷價值及原則的開發(fā)管理架構(gòu)2.3.1 Scrum讓敏捷價值的實現(xiàn)變得自然2.3.2 Scrum是敏捷原則的具體體現(xiàn)2 敏捷開發(fā)方法摸著石頭過河的智慧2.3 Scrum是一2 敏捷開發(fā)方法摸著石頭過河的智慧3.1 形似神不似的Scrum實施3.1.1 Scrum不能保證解決問題，但能保證暴露問題3.1.2 沒有本地化的適配，敏捷過程很難落

7、地生根3.1.3 不要因為錯誤的原因引入Scrum，要明確引入敏捷的目的2 敏捷開發(fā)方法摸著石頭過河的智慧3.1 形似神不似的S2 敏捷開發(fā)方法摸著石頭過河的智慧3.2 使用Scrum的藝術(shù)3.2.1 Scrum中的自我管理及實現(xiàn)方式3.2.2 管理者從監(jiān)控型到服務型的轉(zhuǎn)變3.2.3 追求問題的解決而不是最佳解決方案3.2.4 對工程人員能力提升及自律的要求3.2.5 Scrum實踐的互補，完整的Scrum才最有價值2 敏捷開發(fā)方法摸著石頭過河的智慧3.2 使用Scrum2 敏捷開發(fā)方法摸著石頭過河的智慧3.3 極限編程是Scrum最好的伙伴3.3.1 技術(shù)債務：Scrum的殺手3.3.2 極

8、限編程的4個核心價值3.3.3 極限編程的原則3.3.4 極限編程的4個核心工程活動3.3.5 極限編程的12條實踐3.3.6 極限編程+Scrum：1+122 敏捷開發(fā)方法摸著石頭過河的智慧3.3 極限編程是Sc2 敏捷開發(fā)方法摸著石頭過河的智慧3.4 引入Scrum等敏捷方法是一場需要勇氣的變革3.4.1 精益組織與敏捷團隊3.4.2 管理者的勇氣：做有遠見的智慧型領(lǐng)導者3.4.3 工程人員的勇氣：合奏與獨奏3.4.4 過程改進人員的勇氣：找到你的定位2 敏捷開發(fā)方法摸著石頭過河的智慧3.4 引入Scrum2 敏捷開發(fā)方法摸著石頭過河的智慧3.5 變革之路：從瀑布模式到敏捷模式的轉(zhuǎn)化3.5

9、.1 瀑布模式到敏捷模式中人和組織的轉(zhuǎn)化3.5.2 瀑布模式到敏捷模式中企業(yè)文化及習慣的轉(zhuǎn)化3.5.3 瀑布模式到敏捷模式的轉(zhuǎn)化過程2 敏捷開發(fā)方法摸著石頭過河的智慧3.5 變革之路：從瀑06第二部分 建立以Scrum為框架的軟件開發(fā)管理體系06第二部分 建立以Scrum為框架的軟件開發(fā)管理體系4 布好自己的局確定Scrum中的角色、文檔和活動4.2 建立自己的敏捷過程4.4 敏捷過程對文檔的要求4.6 敏捷工具4.1 敏捷轉(zhuǎn)型的布局規(guī)劃4.3 確定Scrum的角色4.5 建立一個成熟的Scrum過程4 布好自己的局確定Scrum中的角色、文檔和活動4.24 布好自己的局確定Scrum中的角色

10、、文檔和活動兩個敏捷角色的故事5.4 Scrum中的風險管理5.3 建立、維護你的敏捷島5 迭代管理亦有道執(zhí)行Scrum項目管理5.1 應對變化的敏捷計劃：波浪式的版本規(guī)劃5.2 Scrum迭代中的管理：頻繁反饋，及時調(diào)整4 布好自己的局確定Scrum中的角色、文檔和活動兩個敏4 布好自己的局確定Scrum中的角色、文檔和活動兩個團隊的故事4 布好自己的局確定Scrum中的角色、文檔和活動兩個團4 布好自己的局確定Scrum中的角色、文檔和活動4.2 建立自己的敏捷過程4.2.1 建立一個端到端的敏捷過程4.2.2 進入Scrum迭代的準備過程4.2.3 敏捷迭代過程及驗證過程4.2.4 敏捷

11、的改進過程4.2.5 選擇敏捷實踐4 布好自己的局確定Scrum中的角色、文檔和活動4.24 布好自己的局確定Scrum中的角色、文檔和活動4.3 確定Scrum的角色4.3.1 豬和雞合作創(chuàng)業(yè)的對話4.3.2 選擇Scrum產(chǎn)品經(jīng)理4.3.3 選擇Scrum過程經(jīng)理4.3.4 選擇Scrum團隊成員4.3.5 架構(gòu)師在Scrum團隊中的定位4.3.6 Scrum of Scrum （大敏捷項目的管理）的安排4.3.7 Scrum中的共享團隊資源4 布好自己的局確定Scrum中的角色、文檔和活動4.34 布好自己的局確定Scrum中的角色、文檔和活動4.4 敏捷過程對文檔的要求4.4.1 文檔

12、的價值及應用4.4.2 敏捷文檔制作指南4.4.3 敏捷過程的需求文檔4.4.4 敏捷環(huán)境下的工程文檔4.4.5 必要的維護文檔4.4.6 敏捷（Scrum）的管理文檔4 布好自己的局確定Scrum中的角色、文檔和活動4.44 布好自己的局確定Scrum中的角色、文檔和活動4.5 建立一個成熟的Scrum過程4.5.1 什么是成熟的敏捷過程4.5.2 保證敏捷過程的執(zhí)行力4.5.3 保證敏捷過程的改進力4 布好自己的局確定Scrum中的角色、文檔和活動4.54 布好自己的局確定Scrum中的角色、文檔和活動5.1 應對變化的敏捷計劃：波浪式的版本規(guī)劃5.1.1 掌握你的團隊速率5.1.2 允許

13、項目需求范圍有一定的靈活性5.1.3 遵循“最小有市場價值”原則制訂產(chǎn)品版本計劃5.1.4 制訂第一個版本計劃4 布好自己的局確定Scrum中的角色、文檔和活動5.14 布好自己的局確定Scrum中的角色、文檔和活動5.2 Scrum迭代中的管理：頻繁反饋，及時調(diào)整5.2.1 細化版本需求列表中的用戶故事：準備好下一輪迭代的工作5.2.2 計劃下一輪迭代5.2.3 開好每日站立會議5.2.4 展示團隊的迭代成果：開好迭代評審會議5.2.5 不斷完善Scrum過程：開好迭代回顧會議4 布好自己的局確定Scrum中的角色、文檔和活動5.24 布好自己的局確定Scrum中的角色、文檔和活動5.3 建

14、立、維護你的敏捷島5.3.1 迭代任務狀態(tài)板塊5.3.2 其他信息板塊5.3.3 白板是最有效的溝通方式4 布好自己的局確定Scrum中的角色、文檔和活動5.34 布好自己的局確定Scrum中的角色、文檔和活動5.4 Scrum中的風險管理5.4.1 軟件項目的5大風險來源5.4.2 把握你的進度風險5.4.3 把握好需求使之自然完善而不是遍地蔓生5.4.4 建立一個T字型能力團隊緩解團隊不穩(wěn)定風險5.4.5 建立維護好產(chǎn)品規(guī)格5.4.6 克服低效率風險的幾個法寶4 布好自己的局確定Scrum中的角色、文檔和活動5.46 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.1 再議技術(shù)債務6.2 敏捷中的

15、需求開發(fā)及管理6.3 敏捷中的設計和開發(fā)6.4 敏捷中的測試6.5 健康迭代比速度更重要兩個團隊的故事6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.1 再議技術(shù)6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.1 再議技術(shù)債務6.1.1 技術(shù)債務的來源6.1.2 管理技術(shù)債務6.1.3 減少技術(shù)債務的實踐6.1.4 減少技術(shù)債務的具體步驟6.1.5 技術(shù)債務的度量6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.1 再議技術(shù)6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.2 敏捷中的需求開發(fā)及管理6.2.1 敏捷四級產(chǎn)品計劃6.2.2 用戶類型的識別過程6.2.3 建立維護典型用戶檔案6.2.4 從用例到用戶故

16、事6.2.5 貫穿整個開發(fā)過程中的需求澄清：串講及反串講6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.2 敏捷中的6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.3 敏捷中的設計和開發(fā)6.3.1 簡明設計原則6.3.2 設計決策的時機6.3.3 再議程序開發(fā)中的代碼重構(gòu)6.3.4 敏捷中的評審6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.3 敏捷中的6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.4 敏捷中的測試6.4.1 測試驅(qū)動開發(fā)的價值及方法6.4.2 持續(xù)集成：提高開發(fā)效率的重要保證6.4.3 敏捷測試策略及方法6.4.4 讓發(fā)現(xiàn)的缺陷的價值最大化6 把握好敏捷的度敏捷工程及質(zhì)量控制實踐6.4 敏

17、捷中的07第三部分 CMMI框架下的敏捷實施07第三部分 CMMI框架下的敏捷實施第三部分 CMMI框架下的敏捷實施7 盲人摸象關(guān)于敏捷和CMMI的錯誤偏見DE7.1 來自兩個陣營的偏見7.2 CMMI的核心和價值7.3 CMMI+敏捷：解決軟件開發(fā)問題之匙7.4 來自敏捷宣言起草者及CMMI作者的最新聲音敏捷和CMMI的故事ABC第三部分 CMMI框架下的敏捷實施7 盲人摸象關(guān)于敏捷和8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施18.1 從使用角度看CMMI28.2 完善Scrum實現(xiàn)CMMI項目管理的要求38.3 用敏捷實踐實現(xiàn)CMMI工程活動的要求48.4 用敏捷手段實現(xiàn)CMMI支持活動

18、的要求58.5 敏捷環(huán)境下實現(xiàn)CMMI過程管理的要求68.6 敏捷環(huán)境下實現(xiàn)CMMI高成熟度的要求8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施18.1 從8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.7 敏捷環(huán)境下的CMMI評估應關(guān)注的兩個問題敏捷環(huán)境下的兩個CMMI實施和評估故事8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.7 敏捷8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.1 從使用角度看CMMI8.1.1 一個產(chǎn)品開發(fā)最佳實踐的集合8.1.2 CMMI的4條主線8.1.3 正確解讀CMMI評估8.1.4 CMMI對工作產(chǎn)品（文檔）的要求8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施

19、8.1 從使8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.2 完善Scrum實現(xiàn)CMMI項目管理的要求8.2.1 需求管理和“Scrum+極限編程”8.2.2 項目計劃和“Scrum+極限編程”8.2.3 項目監(jiān)督與控制和“Scrum+極限編程”8.2.4 供方協(xié)議管理和“Scrum+極限編程”8.2.5 集成項目管理和“Scrum+極限編程”8.2.6 風險管理和“Scrum+極限編程”8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.2 完善8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.3 用敏捷實踐實現(xiàn)CMMI工程活動的要求8.3.1 需求開發(fā)和“Scrum+極限編程”8.3.2 技術(shù)

20、解決方案和“Scrum+極限編程”8.3.3 產(chǎn)品集成和“Scrum+極限編程”8.3.4 驗證和“Scrum+極限編程”8.3.5 確認和“Scrum+極限編程”8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.3 用敏8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.4 用敏捷手段實現(xiàn)CMMI支持活動的要求8.4.1 敏捷環(huán)境下的過程與產(chǎn)品質(zhì)量保證8.4.2 敏捷環(huán)境下的配置管理8.4.3 敏捷環(huán)境下的度量與分析8.4.4 敏捷環(huán)境下的決策分析與解決8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.4 用敏8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.5 敏捷環(huán)境下實現(xiàn)CMMI過程管理的要求8

21、.5.1 敏捷環(huán)境下的組織級過程關(guān)注8.5.2 敏捷環(huán)境下的組織級過程定義8.5.3 Scrum環(huán)境下的組織級培訓8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.5 敏捷8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.6 敏捷環(huán)境下實現(xiàn)CMMI高成熟度的要求8.6.1 敏捷下的量化管理：QPPO、基線及模型（OPP和QPM）8.6.2 敏捷環(huán)境下過程優(yōu)化管理：CAR和OPM8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.6 敏捷8 建立敏捷的保護網(wǎng)CMMI架構(gòu)下的敏捷實施8.7 敏捷環(huán)境下的CMMI評估應關(guān)注的兩個問題8.7.1 實施選擇還是模型要求8.7.2 理解模型的目的8 建立敏捷的保護

22、網(wǎng)CMMI架構(gòu)下的敏捷實施8.7 敏捷08第四部分 新一代精益軟件工程08第四部分 新一代精益軟件工程9 敏捷不是解決軟件開發(fā)問題的銀彈9.1 再議軟件過程的特殊性9.2 敏捷的局限及挑戰(zhàn)9.3 有效軟件開發(fā)借鑒之源及應具備的特點9 敏捷不是解決軟件開發(fā)問題的銀彈9.1 再議軟件過程的特殊9 敏捷不是解決軟件開發(fā)問題的銀彈9.1 再議軟件過程的特殊性9.1.1 軟件過程公理9.1.2 軟件過程體系應追求的價值9 敏捷不是解決軟件開發(fā)問題的銀彈9.1 再議軟件過程的特殊9 敏捷不是解決軟件開發(fā)問題的銀彈9.2 敏捷的局限及挑戰(zhàn)9.2.1 如何盡早獲取有價值的用戶反饋9.2.2 如何設計軟件架構(gòu)支持快速迭代開發(fā)9.2.3 缺乏具體有效方法實現(xiàn)敏捷原則9.2.4 忽略了