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