【正文】 ，或是可能需要完全地改變項目的需求，瀑布式的 model是比較不適合的。 ? 敏捷方法 ? 完整地開發(fā)，每少數(shù)幾周或是少數(shù)幾個月里可以測試功能。 ? 強調在獲得最簡短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價值。 ? 在整個項目的生命周期里，可以持續(xù)的改善、增加未來的功能。 20 敏捷項目管理 VS傳統(tǒng)項目管理 ? 傳統(tǒng)項目管理： ? 事先對整個項目進行估計、計劃、分析 ? 反對變更 。 變更需要重新估計、重新規(guī)劃 ? 嚴密的合同來減少風險 , 如果改變需求要走 CR 流程 . ? 項目作為一個“黑盒子” ，對客戶與供應商的可視性差 . ? 文檔和計劃驅動的方法 . ? 軟件交付時間晚 , 意識到風險的時間晚 . ? WBS,甘特圖 ,關鍵路徑分析 ? 敏捷項目管理 : ? 對整個項目做一個粗略的估計 ,每一次迭代都有詳細的計劃 . ? 鼓勵變化 , 客戶價值驅動開發(fā) . ? 信任和賦予權力 。合約使變更變得簡單，增加價值 . ? 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關系 ? 每次迭代都產生可交付的軟件 ? 專注于交付軟件 . ? 第一次迭代就可交付能工作的版本，風險發(fā)現(xiàn)的早 . 21 敏捷 與 CMMI雙劍合璧 ? CMMI更加關注于流程，敏捷更加關注于人 ? CMMI自頂向下，敏捷自底向上 ? 敏捷并不排斥必要的文檔 ? 敏捷的很多實踐是對 CMMI的一種實現(xiàn)，比如 sprint計劃會議就是 PP的實現(xiàn)，每日例會就是在做 PMC ? 很多 CMMI4~5級的公司也在應用敏捷，比如說寶信、華為 ? 項目級的敏捷實踐通過 CMMI可以在組織級得以重用 eXtreme Programming ? XP我們一般稱為極限編程，是最輕量級的開發(fā)流程。 ? 最主要的精神是 ? 『 在客戶有系統(tǒng)需求時，給予及時滿意的可執(zhí)行程序 』 ，所以最適合需求快速變動的項目。 ? 它強調客戶所要的是 ? workable的執(zhí)行碼，所以把與撰寫程序無關的工作降至最低，并要求客戶與開發(fā)人員最好以 sidebyside的方式一起工作。 ? XP的實踐包括： ? 完整團隊、計劃游戲、客戶測試 ? 簡單設計、結對編程、測試驅動開發(fā) ? 改進設計、持續(xù)集成、集體代碼所有權 ? 編碼標準、隱喻、可持續(xù)的速度 Scrum開發(fā)流程 23 Jiangsu Microsoft Technology Center 24 為什么采用敏捷 ? –預期的收益 ? 采用敏捷方法得當?shù)脑?，可以? ? 更加透明 。 隨時跟蹤項目的狀態(tài)和進展情況，及早發(fā)現(xiàn)問題和風險 . ? 快速交付 , 每次迭代都能交付可運行的軟件 . ? 最高風險和最高優(yōu)先級的需求，最優(yōu)先進行開發(fā) . ? 改善應對變更能力 , 減少大量的重計劃 . ? 改善項目溝通 . ? 更好的客戶參與 , 避免錯誤的假設 . ? 總之 : ? 提高了生產率 。 減少“浪費” （不需要的文檔，重復工作等） ，項目的每次迭代都有明確的目標 . ? 提高客戶滿意度 。 短期內產生成效 , 按預期交付軟件 , 每次迭代結束產生可以運行的軟件 . ? 改善員工的滿意度 。 團隊精神，減少官僚，能夠規(guī)劃和管理自己的工作，減少“恐慌” ，穩(wěn)定的工作量（可持續(xù)的步伐） . 25 目錄 ? 敏捷的背景與動機 ? 敏捷宣言及原則 ? 敏捷方法是什么？ ? 敏捷方法的實踐 ? Scrum的角色 ? Scrum流程和工作產品 ? Scrum應用 ? 總結 26 敏捷關鍵實踐 1——增量迭代 ? 每個迭代有一個大約為 1～ 4周的時間框，在 SCRUM里稱為一次沖刺（超過 1個月的詳細計劃往往偏差很大） ? 每次迭代都應該有明確的目標 ? 每次迭代都應該有明確的可演示的工作成果 ? 迭代過程中項目團隊應該盡量免受打擾 ? 迭代可以將項目的壓力分解到每個小的階段，風險也能同時分解 27 敏捷關鍵實踐 2——測試驅動開發(fā) TDD ? 什么是測試驅動？ ? 首先創(chuàng)建測試用例，然后開發(fā)軟件通過測試(在開發(fā)代碼前，首先編寫測試代碼 ) ? 一種設計軟件的方法，而不僅僅是一種測試方法 ? 所創(chuàng)建的測試用例用來指導和約束項目中的各項工作，對未來的各項工作提供一個安全的保護 ? 不需要測試的工作不需要完成 ? 所創(chuàng)建的測試用例通常替代詳細的業(yè)務和技術需求定 ? 測試也有效地驅動設計，使設計更加趨向于可行的設計 ? 通常情況下需要自動測試的支持 (EUnit, JUnit etc.). ? 對于 UI軟件應用 TDD方法有一定的困難 28 敏捷關鍵實踐 3——持續(xù)集成 ? 極限編程稱為“每日構建” ? 持續(xù)集成一般利用 ANT、 MAVEN等工具 ? 日構建的好處： ? 將集成風險降到最低 ? 降低質量風險 ? 提升士氣 ? 日構建可以看做是項目的心跳，冒煙測試就像是聽診器 ? 日構建必須至少：成功編譯、打包、發(fā)布；不含有任何明顯的缺陷；通過冒煙測試 29 敏捷關鍵實踐 4——面對面交流 ? 雖然如今通訊工具花樣繁多，但面對面交流在某些場合下仍然是不可替代的； ? 敏捷開發(fā)把交流缺失問題考慮在內，要求團隊成員彼此直接協(xié)作，盡量創(chuàng)造面對面交流的機會； ? 尤其當業(yè)務分析師和軟件開發(fā)人員一起工作的時候，面對面的交流是很重要的。 ? 匿名共享需求文檔只會打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。 30 敏捷方法的其它實踐 ? 結對編程 ? 每日立會 ? 用戶故事 ? 團隊工作室 ? 頻繁發(fā)布 ? 自組織團隊 ? 重構 31 重構 ——改善既有代碼的設計 ? Martin Fowler提出 ? 代碼的壞味道 ? Martin Fowler和 Kent Beck列舉了 22種壞味道：冗余代碼、冗長的方法、巨大的類、過多的參數(shù)等等 ? 重構可以彌補設計的不足 ? 簡單設計的思想 ? 重構與測試驅動的關系 ? TDD是重構的腳手架 ? IDE已經對主要的重構模式提供了自動化支持： Rename, extract method, move field等等 ? 簡單設計 測試用例 實現(xiàn)再說（重構 回歸測試） * 32 Scrum何時更有效？ ? 公司和客戶一致認為應當使用敏捷方法，雙方都能理解敏捷方法 . ? 敏捷方法對需求不完整以及經常變換的項目比較有效 . ? 項目可以劃分成固定時間間隔的迭代 , 并且可以凍結正在進行的迭代的范圍 ? 公司和客戶都有能力擔當角色尤其是 Product Owner 和 Scrum Master. ? 項目