敏捷項(xiàng)目終極培訓(xùn)-scrum教學(xué)文稿

敏捷項(xiàng)目管理終極(zhōngjí)培訓(xùn)-Scrum2016年6月第一頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品(chǎnpǐn)Scrum應(yīng)用總結(jié)2第二頁，共74頁。敏捷的背景(bèijǐng)與動(dòng)機(jī)軟件危機(jī)及軟件工程的出現(xiàn)速度是企業(yè)競(jìng)爭(zhēng)致勝的關(guān)鍵因素，軟件項(xiàng)目的最大挑戰(zhàn)在于一方面要應(yīng)付變動(dòng)中的需求一方面要在緊縮的時(shí)程內(nèi)完成項(xiàng)目傳統(tǒng)的軟件工程難以滿足這些要求所以軟件團(tuán)隊(duì)除了在技術(shù)上必須日益精進(jìn)，更需要運(yùn)用有效的開發(fā)流程，以確保團(tuán)隊(duì)能夠發(fā)揮綜效。這正是AgileProcess(敏捷的軟件開發(fā)流程)于近年來興起的主要(zhǔyào)原因。第三頁，共74頁。軟件(ruǎnjiàn)項(xiàng)目的復(fù)雜性橫軸代表需求的復(fù)雜度縱軸表示(biǎoshì)技術(shù)的復(fù)雜度還有人力資源的復(fù)雜度4第四頁，共74頁。解決復(fù)雜性問題需要采用(cǎiyòng)經(jīng)驗(yàn)式方式解決問題的兩種方式：預(yù)定義過程控制(kòngzhì)（富士康流水線生產(chǎn)）經(jīng)驗(yàn)性過程控制(kòngzhì)（摸著石頭過河）如果復(fù)雜度超過預(yù)定義方式的能力范圍，應(yīng)該采用經(jīng)驗(yàn)性方式經(jīng)驗(yàn)性方式的三大支柱：可見性、檢查及適應(yīng)5第五頁，共74頁。他山之石(tāshānzhīshí)互聯(lián)網(wǎng)時(shí)代的出版模式作者最開始的時(shí)候并沒有想出一本書，而只是把多年的積累梳理(shūlǐ)出來寫成了博客，憑借博客的成功最后得到了出版商和紙版讀者的認(rèn)可。在寫成本書的過程中，作者是漸進(jìn)式的進(jìn)行的，每寫完一個(gè)章節(jié)，放到博客上去征求讀者的反饋，很多反饋意見在后面的章節(jié)或修訂中及時(shí)地體現(xiàn)出來，這樣就形成了與讀者之間的良好反饋，在出版之前就鎖定了大量的讀者。這就是敏捷開發(fā)提倡的“增量迭代、及時(shí)交付”的思想。這種模式能最大程度地不偏離客戶需求的本質(zhì)。精益制造消除浪費(fèi)、關(guān)注流程、建立無間斷流程以快速應(yīng)變、降低庫存、一次做對(duì)、基于顧客需求的拉動(dòng)生產(chǎn)、標(biāo)準(zhǔn)化與工作創(chuàng)新、尊重員工，給員工授權(quán)等第六頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作(gōngzuò)產(chǎn)品Scrum應(yīng)用總結(jié)7第七頁，共74頁。敏捷(mǐnjié)的歷史敏捷軟件開發(fā)又稱敏捷開發(fā)，從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種(yīzhǒnɡ)應(yīng)對(duì)快速變化的需求的一種(yīzhǒnɡ)軟件開發(fā)能力。2001年初，因觀察到許多的軟件團(tuán)隊(duì)身陷不斷擴(kuò)大的流程之中的困境，一群業(yè)界專家聚集在一起，勾勒出一些能讓軟件團(tuán)隊(duì)迅速工作，以及響應(yīng)變化的價(jià)值觀和原則。他們自稱為AgileAlliance。之后的七個(gè)月里，他們創(chuàng)造具有價(jià)值的聲明，也就是敏捷軟件的開發(fā)宣言。十五人中包括：大名鼎鼎的KentBeck（XP,TDD的創(chuàng)始人,Junit的創(chuàng)始人之一）、WardCunningham（Wiki概念的發(fā)明者）、MartinFowler（《企業(yè)應(yīng)用架構(gòu)模式》作者）、RobertC.Martin、KenSchwaber第八頁，共74頁。敏捷(mǐnjié)價(jià)值觀之敏捷(mǐnjié)宣言9敏捷(mǐnjié)開發(fā)的核心思想是：以人為本，適應(yīng)變化。第九頁，共74頁。敏捷(mǐnjié)價(jià)值觀之敏捷(mǐnjié)宣言-1個(gè)體和交互勝過過程和工具人是軟件項(xiàng)目獲得成功最為重要的因素合作、溝通能力以及交互能力比單純的軟件編程能力和工具更為重要方法和工具是死的，人是活的，人要是太“面”或者協(xié)作不好，再強(qiáng)大(qiángdà)的方法和工具都是白扯；10第十頁，共74頁。敏捷(mǐnjié)價(jià)值觀之敏捷(mǐnjié)宣言-2可以工作的軟件勝過面面俱到的文檔過多的面面俱到的文檔往往比過少的文檔更糟軟件開發(fā)的主要和中心活動(dòng)(huódòng)是創(chuàng)建可以工作的軟件直到迫切需要并且意義重大時(shí)，才進(jìn)行文檔編制編制的內(nèi)部文檔應(yīng)盡量短小并且主題突出11第十一頁，共74頁。敏捷(mǐnjié)價(jià)值觀之敏捷(mǐnjié)宣言-3客戶合作勝過合同談判客戶不可能做到一次性地將他們的需求完整(wánzhěng)清晰地表述在合同中為開發(fā)團(tuán)隊(duì)和客戶的協(xié)同工作方式提供指導(dǎo)的合同才是最好的合同12第十二頁，共74頁。敏捷(mǐnjié)價(jià)值觀之敏捷(mǐnjié)宣言-4響應(yīng)變化勝過循環(huán)計(jì)劃變化是軟件開發(fā)中存在(cúnzài)的現(xiàn)實(shí)計(jì)劃必須有足夠的靈活性與可塑性短期的迭代的計(jì)劃比中長(zhǎng)期計(jì)劃更有效JiangsuMicrosoftTechnologyCenter13第十三頁，共74頁。敏捷(mǐnjié)開發(fā)的12個(gè)原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價(jià)值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個(gè)月，交付的時(shí)間間隔越短越好。在整個(gè)項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵(lì)(jīlì)起來的個(gè)人來構(gòu)建項(xiàng)目。在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談。

第十四頁，共74頁。敏捷(mǐnjié)開發(fā)的12個(gè)原則工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。敏捷過程提倡平穩(wěn)的開發(fā)節(jié)奏；發(fā)起人、開發(fā)者和用戶應(yīng)該(yīnggāi)能夠保持一個(gè)長(zhǎng)期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。簡(jiǎn)單化是根本（不做過度設(shè)計(jì)和預(yù)測(cè)）。最好的構(gòu)架、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反思并對(duì)自己的行為進(jìn)行相應(yīng)調(diào)整。第十五頁，共74頁。目錄(mùlù)敏捷的背景(bèijǐng)與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品Scrum應(yīng)用總結(jié)16第十六頁，共74頁。什么(shénme)是敏捷方法？敏捷方法是一類軟件開發(fā)流程的泛稱(fànchēnɡ)；敏捷方法是相對(duì)于傳統(tǒng)的瀑布式軟件過程提出的；敏捷方法可以用敏捷宣言（4條）、敏捷原則（12條）來概括；敏捷原則通過一系列的敏捷實(shí)踐來體現(xiàn)出來；敏捷方法有很多種。問題(wèntí)1，請(qǐng)舉出你知道的2個(gè)以上敏捷方法名字來第十七頁，共74頁。敏捷(mǐnjié)的方法ExtremeProgramming(XP)極限編程ScrumAdaptiveSoftwareDevelopment(ASD)自適應(yīng)軟件開發(fā)CrystalClearandOtherCrystalMethodologies水晶方法DynamicSystemsDevelopmentMethod(DSDM)動(dòng)態(tài)(dòngtài)系統(tǒng)開發(fā)方法等第十八頁，共74頁。敏捷方法VS.瀑布(pùbù)模型瀑布模型固定的、沒有彈性的。很困難去達(dá)到互動(dòng)。假如說需求沒有完全的被了解，或是可能需要完全地改變項(xiàng)目的需求，瀑布式的model是比較不適合的。敏捷方法完整地開發(fā)(kāifā)，每少數(shù)幾周或是少數(shù)幾個(gè)月里可以測(cè)試功能。強(qiáng)調(diào)在獲得最簡(jiǎn)短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價(jià)值。在整個(gè)項(xiàng)目的生命周期里，可以持續(xù)的改善、增加未來的功能。第十九頁，共74頁。敏捷(mǐnjié)項(xiàng)目管理VS傳統(tǒng)項(xiàng)目管理傳統(tǒng)項(xiàng)目管理：事先對(duì)整個(gè)項(xiàng)目進(jìn)行估計(jì)、計(jì)劃、分析反對(duì)變更;變更需要重新估計(jì)、重新規(guī)劃嚴(yán)密的合同來減少風(fēng)險(xiǎn),如果改變需求要走CR流程.項(xiàng)目作為一個(gè)(yīɡè)“黑盒子”，對(duì)客戶與供應(yīng)商的可視性差.文檔和計(jì)劃驅(qū)動(dòng)的方法.軟件交付時(shí)間晚,意識(shí)到風(fēng)險(xiǎn)的時(shí)間晚.WBS,甘特圖,關(guān)鍵路徑分析敏捷項(xiàng)目管理:對(duì)整個(gè)項(xiàng)目做一個(gè)粗略的估計(jì),每一次迭代(diédài)都有詳細(xì)的計(jì)劃.鼓勵(lì)變化,客戶價(jià)值驅(qū)動(dòng)開發(fā).信任和賦予權(quán)力;合約使變更變得簡(jiǎn)單，增加價(jià)值.客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系每次迭代(diédài)都產(chǎn)生可交付的軟件專注于交付軟件.第一次迭代(diédài)就可交付能工作的版本，風(fēng)險(xiǎn)發(fā)現(xiàn)的早.20第二十頁，共74頁。敏捷(mǐnjié)與CMMI雙劍合璧CMMI更加關(guān)注于流程，敏捷更加關(guān)注于人CMMI自頂向下，敏捷自底向上敏捷并不排斥必要的文檔敏捷的很多實(shí)踐是對(duì)CMMI的一種實(shí)現(xiàn)，比如sprint計(jì)劃會(huì)議就是PP的實(shí)現(xiàn)，每日例會(huì)就是在做PMC很多CMMI4~5級(jí)的公司也在應(yīng)用敏捷，比如說寶信、華為項(xiàng)目級(jí)的敏捷實(shí)踐通過(tōngguò)CMMI可以在組織級(jí)得以重用21第二十一頁，共74頁。eXtremeProgrammingXP我們一般稱為極限編程，是最輕量級(jí)的開發(fā)流程。最主要的精神是『在客戶有系統(tǒng)需求時(shí)，給予及時(shí)(jíshí)滿意的可執(zhí)行程序』，所以最適合需求快速變動(dòng)的項(xiàng)目。它強(qiáng)調(diào)客戶所要的是workable的執(zhí)行碼，所以把與撰寫程序無關(guān)的工作降至最低，并要求客戶與開發(fā)人員最好以side-by-side的方式一起工作。XP的實(shí)踐包括：完整團(tuán)隊(duì)、計(jì)劃游戲、客戶測(cè)試簡(jiǎn)單設(shè)計(jì)、結(jié)對(duì)編程、測(cè)試驅(qū)動(dòng)開發(fā)改進(jìn)設(shè)計(jì)、持續(xù)集成、集體代碼所有權(quán)編碼標(biāo)準(zhǔn)、隱喻、可持續(xù)的速度第二十二頁，共74頁。Scrum開發(fā)(kāifā)流程JiangsuMicrosoftTechnologyCenter23第二十三頁，共74頁。為什么采用敏捷(mǐnjié)?–預(yù)期的收益采用敏捷方法得當(dāng)?shù)脑?，可以：更加透?隨時(shí)跟蹤項(xiàng)目的狀態(tài)和進(jìn)展情況，及早發(fā)現(xiàn)問題和風(fēng)險(xiǎn).快速交付,每次迭代都能交付可運(yùn)行的軟件.最高風(fēng)險(xiǎn)和最高優(yōu)先級(jí)的需求，最優(yōu)先進(jìn)行開發(fā).改善應(yīng)對(duì)變更能力,減少大量的重計(jì)劃.改善項(xiàng)目溝通.更好的客戶參與,避免錯(cuò)誤的假設(shè).總之:提高了生產(chǎn)率;減少“浪費(fèi)”（不需要的文檔，重復(fù)工作等），項(xiàng)目的每次迭代都有明確的目標(biāo).提高客戶滿意度;短期內(nèi)產(chǎn)生成效,按預(yù)期交付軟件,每次迭代結(jié)束產(chǎn)生可以運(yùn)行的軟件.改善員工的滿意度;團(tuán)隊(duì)精神，減少官僚，能夠規(guī)劃和管理自己的工作，減少“恐慌(kǒnghuāng)”，穩(wěn)定的工作量（可持續(xù)的步伐）.24第二十四頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程(liúchéng)和工作產(chǎn)品Scrum應(yīng)用總結(jié)25第二十五頁，共74頁。敏捷(mǐnjié)關(guān)鍵實(shí)踐1——增量迭代每個(gè)迭代有一個(gè)大約為1～4周的時(shí)間框，在SCRUM里稱為一次沖刺（超過1個(gè)月的詳細(xì)計(jì)劃往往偏差很大）每次迭代都應(yīng)該有明確的目標(biāo)每次迭代都應(yīng)該有明確的可演示的工作成果迭代過程中項(xiàng)目(xiàngmù)團(tuán)隊(duì)?wèi)?yīng)該盡量免受打擾迭代可以將項(xiàng)目(xiàngmù)的壓力分解到每個(gè)小的階段，風(fēng)險(xiǎn)也能同時(shí)分解26第二十六頁，共74頁。敏捷(mǐnjié)關(guān)鍵實(shí)踐2——測(cè)試驅(qū)動(dòng)開發(fā)TDD什么是測(cè)試驅(qū)動(dòng)？首先創(chuàng)建測(cè)試用例，然后開發(fā)軟件通過(tōngguò)測(cè)試(在開發(fā)代碼前，首先編寫測(cè)試代碼)一種設(shè)計(jì)軟件的方法，而不僅僅是一種測(cè)試方法所創(chuàng)建的測(cè)試用例用來指導(dǎo)和約束項(xiàng)目中的各項(xiàng)工作，對(duì)未來的各項(xiàng)工作提供一個(gè)安全的保護(hù)不需要測(cè)試的工作不需要完成所創(chuàng)建的測(cè)試用例通常替代詳細(xì)的業(yè)務(wù)和技術(shù)需求定測(cè)試也有效地驅(qū)動(dòng)設(shè)計(jì)，使設(shè)計(jì)更加趨向于可行的設(shè)計(jì)通常情況下需要自動(dòng)測(cè)試的支持(EUnit,JUnitetc.).對(duì)于UI軟件應(yīng)用TDD方法有一定的困難27第二十七頁，共74頁。敏捷(mǐnjié)關(guān)鍵實(shí)踐3——持續(xù)集成28極限編程稱為“每日構(gòu)建”持續(xù)集成(jíchénɡ)一般利用ANT、MAVEN等工具日構(gòu)建的好處：將集成(jíchénɡ)風(fēng)險(xiǎn)降到最低降低質(zhì)量風(fēng)險(xiǎn)提升士氣日構(gòu)建可以看做是項(xiàng)目的心跳，冒煙測(cè)試就像是聽診器日構(gòu)建必須至少：成功編譯、打包、發(fā)布；不含有任何明顯的缺陷；通過冒煙測(cè)試第二十八頁，共74頁。敏捷關(guān)鍵(guānjiàn)實(shí)踐4——面對(duì)面交流雖然如今通訊工具花樣繁多，但面對(duì)面交流在某些場(chǎng)合下仍然是不可替代的；敏捷開發(fā)把交流缺失問題考慮在內(nèi)，要求團(tuán)隊(duì)成員彼此直接協(xié)作，盡量創(chuàng)造面對(duì)面交流的機(jī)會(huì)；尤其當(dāng)業(yè)務(wù)分析師和軟件開發(fā)人員一起工作的時(shí)候，面對(duì)面的交流是很重要的。匿名共享需求文檔只會(huì)打開曲解和誤解之門，更不用說書面(shūmiàn)信息比口頭交流還要慢很多。29第二十九頁，共74頁。敏捷(mǐnjié)方法的其它實(shí)踐結(jié)對(duì)編程每日立會(huì)用戶故事(gùshì)團(tuán)隊(duì)工作室頻繁發(fā)布自組織團(tuán)隊(duì)重構(gòu)30第三十頁，共74頁。重構(gòu)——改善既有代碼(dàimǎ)的設(shè)計(jì)MartinFowler提出(tíchū)代碼的壞味道MartinFowler和KentBeck列舉了22種壞味道：冗余代碼、冗長(zhǎng)的方法、巨大的類、過多的參數(shù)等等重構(gòu)可以彌補(bǔ)設(shè)計(jì)的不足簡(jiǎn)單設(shè)計(jì)的思想重構(gòu)與測(cè)試驅(qū)動(dòng)的關(guān)系TDD是重構(gòu)的腳手架IDE已經(jīng)對(duì)主要的重構(gòu)模式提供了自動(dòng)化支持：Rename,extractmethod,movefield等等簡(jiǎn)單設(shè)計(jì)>>測(cè)試用例>>實(shí)現(xiàn)再說>>（重構(gòu)>>回歸測(cè)試）*31第三十一頁，共74頁。Scrum何時(shí)(héshí)更有效？公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法.敏捷方法對(duì)需求不完整以及經(jīng)常變換的項(xiàng)目比較有效.項(xiàng)目可以劃分成固定時(shí)間間隔(jiàngé)的迭代,并且可以凍結(jié)正在進(jìn)行的迭代的范圍公司和客戶都有能力擔(dān)當(dāng)角色尤其是ProductOwner和ScrumMaster.項(xiàng)目的人員結(jié)構(gòu)能夠分成6到10人的團(tuán)隊(duì)，最好每個(gè)工作地點(diǎn)一個(gè)小組.（ScrumofScrums，Scrum的擴(kuò)展）團(tuán)隊(duì)成員能夠以自組織的方式工作.項(xiàng)目的合同允許變更.固定價(jià)格的項(xiàng)目可以使用敏捷，但應(yīng)當(dāng)盡量避免。最好在按時(shí)間和材料付費(fèi)或者按月付費(fèi)的項(xiàng)目中進(jìn)行使用、變更項(xiàng)目的范圍不需要高級(jí)管理層的批準(zhǔn).32問題2，為什么SCRUM團(tuán)隊(duì)人員最好(zuìhǎo)在10人以內(nèi)？第三十二頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品(chǎnpǐn)Scrum應(yīng)用總結(jié)33第三十三頁，共74頁。敏捷(mǐnjié)特別強(qiáng)調(diào)人的因素相對(duì)于過程與工具，敏捷更強(qiáng)調(diào)“人”的因素。誠信是基礎(chǔ)沒有(méiyǒu)過程能夠?qū)φ\信進(jìn)行有效的約束誠信與否是有效實(shí)施敏捷過程的最大限制34第三十四頁，共74頁。Scrum框架(kuànɡjià)35第三十五頁，共74頁。www.海頤軟件(ruǎnjiàn)Scrum角色(juésè)第三十六頁，共74頁。Scrum角色(juésè)之ProductOwner產(chǎn)品負(fù)責(zé)(fùzé)人（ProductOwner）的職責(zé)如下：確定產(chǎn)品的功能。決定發(fā)布的日期和發(fā)布內(nèi)容。為產(chǎn)品的profitabilityoftheproduct(ROI)負(fù)責(zé)(fùzé)。根據(jù)市場(chǎng)價(jià)值確定功能優(yōu)先級(jí)。每個(gè)Sprint，根據(jù)需要調(diào)整功能和優(yōu)先級(jí)（每個(gè)Sprint開始前調(diào)整）。接受或拒絕接受開發(fā)團(tuán)隊(duì)的工作成果。37第三十七頁，共74頁。Scrum角色(juésè)之ScrumMaster作為TeamLeader和Productowner緊密地工作在一起，他可以及時(shí)地為團(tuán)隊(duì)成員提供幫助。他必須:保證團(tuán)隊(duì)資源完全可被利用并且全部是高產(chǎn)出的。保證各個(gè)角色及職責(zé)的良好協(xié)作。解決團(tuán)隊(duì)開發(fā)中的障礙。做為團(tuán)隊(duì)和外部的接口，屏蔽外界對(duì)團(tuán)隊(duì)成員的干擾(gānrǎo)。保證開發(fā)過程按計(jì)劃進(jìn)行，組織DailyScrum,SprintReviewandSprintPlanningmeetings。38第三十八頁，共74頁。Scrum角色(juésè)之ScrumTeam一般情況人數(shù)在5-9個(gè)左右團(tuán)隊(duì)要跨職能（包括開發(fā)人員、測(cè)試人員、用戶界面設(shè)計(jì)師等）團(tuán)隊(duì)成員需要全職。（有些情況例外，比如數(shù)據(jù)庫管理員）在項(xiàng)目向?qū)Х秶?fànwéi)內(nèi)有權(quán)利做任何事情已確保達(dá)到Sprint的目標(biāo)。高度的自我組織能力。向ProductOwner演示產(chǎn)品功能。團(tuán)隊(duì)成員構(gòu)成在sprint內(nèi)不允許變化。39第三十九頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言(xuānyán)及原則敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品Scrum應(yīng)用總結(jié)40第四十頁，共74頁。Scrum流程(liúchéng)41SprintPlanningMeeting:NextSprintGoalSprintBacklogUpdatedProductBacklogDailyScrummeetings:WhatdidyoudoyesterdayWhatwillyoudotoday?Whatobstaclesareinyourway?Source:/scrum_primer_1_0.pdfDailyScrumSprintRetrospectiveShippableProductIncrement第四十一頁，共74頁。Sprints(沖刺(chōngcì))Scrum的項(xiàng)目過程有一系列的Sprint組成。Sprint的長(zhǎng)度一般控制在2-4周。通過固定的周期保持良好的節(jié)奏(jiézòu)。產(chǎn)品的設(shè)計(jì)、開發(fā)、測(cè)試都在Sprint期間完成。Sprint結(jié)束時(shí)交付可以工作的軟件。在Sprint過程中不允許發(fā)生變更。42第四十二頁，共74頁。Scrum框架(kuànɡjià)43第四十三頁，共74頁。Scrum儀式(yíshì)之Sprint計(jì)劃會(huì)議JiangsuMicrosoftTechnologyCenter44第四十四頁，共74頁。Scrum儀式之Sprint計(jì)劃(jìhuà)會(huì)議JiangsuMicrosoftTechnologyCenter45第四十五頁，共74頁。Scrum儀式(yíshì)之每日Scrum會(huì)議(DailyScrum)每日Scrum會(huì)議，即團(tuán)隊(duì)每日例會(huì)，條件允許的話(dehuà)，每天都應(yīng)該在同樣的時(shí)間和地點(diǎn)，組織所有成員站立進(jìn)行。最好是每天早晨開，一般15分鐘左右，時(shí)間比較短，也有利于團(tuán)隊(duì)成員安排好當(dāng)天的工作。只有團(tuán)隊(duì)成員可以在例會(huì)上發(fā)言，其他人員有興趣可以參加，但只能旁聽，不能發(fā)言。（小豬和小雞的故事）每日Scrum會(huì)議由ScrumMaster主持，Scrum團(tuán)隊(duì)所有成員輪流回答以下3個(gè)問題：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困難？JiangsuMicrosoftTechnologyCenter46第四十六頁，共74頁。Scrum任務(wù)(rènwu)板(TaskBoard)JiangsuMicrosoftTechnologyCenter47任務(wù)(rènwu)板（墻）展現(xiàn)了在Sprint過程中所有要完成的任務(wù)(rènwu)。在Sprint過程中我們要不斷的更新它。如果某個(gè)開發(fā)人員想到了一個(gè)任務(wù)(rènwu)他就可以把這個(gè)任務(wù)(rènwu)寫下來放在任務(wù)(rènwu)墻上。無論每日站會(huì)過程中或者之后，如果估計(jì)發(fā)生了變化，任務(wù)(rènwu)會(huì)根據(jù)變化在任務(wù)(rènwu)墻上做相應(yīng)的調(diào)整。通常的任務(wù)(rènwu)板是下面這個(gè)樣子:第四十七頁，共74頁。Scrum儀式(yíshì)之Sprint評(píng)審會(huì)議Sprint評(píng)審會(huì)用來(yònɡlái)演示在這個(gè)Sprint中開發(fā)的產(chǎn)品功能給ProductOwner.ProductOwner會(huì)組織這階段的會(huì)議并且邀請(qǐng)相關(guān)的干系人參加。團(tuán)隊(duì)展示Sprint中完成的功能一般是通過現(xiàn)場(chǎng)演示的方式展現(xiàn)功能和架構(gòu)不要太正式不需要PPT一般控制在2個(gè)小時(shí)團(tuán)隊(duì)成員都要參加可以邀請(qǐng)所有人參加JiangsuMicrosoftTechnologyCenter48第四十八頁，共74頁。Scrum儀式(yíshì)之Sprint回顧會(huì)議JiangsuMicrosoftTechnologyCenter49團(tuán)隊(duì)的定期自我檢視，發(fā)現(xiàn)(fāxiàn)什么是好的，什么是不好的。一般控制在15-30分鐘每個(gè)Sprint都要做全體參加ScrumMaster產(chǎn)品負(fù)責(zé)人團(tuán)隊(duì)可能的客戶或其它干系人Sprint回顧會(huì)議上，全體成員討論有哪些(nǎxiē)好的做法可以啟動(dòng)，哪些(nǎxiē)不好的做法不能再繼續(xù)下去了，哪些(nǎxiē)好的做法要繼續(xù)發(fā)揚(yáng)。第四十九頁，共74頁。Scrum物件之產(chǎn)品(chǎnpǐn)訂單(ProductBacklog)一個(gè)需求的列表。一般情況使用用戶故事(gùshì)來表示backlog條目理想情況每個(gè)需求項(xiàng)都對(duì)產(chǎn)品的客戶或用戶有價(jià)值Backlog條目按照商業(yè)價(jià)值排列優(yōu)先級(jí)優(yōu)先級(jí)由產(chǎn)品負(fù)責(zé)人來排列在每個(gè)Sprint結(jié)束的時(shí)候要更新優(yōu)先級(jí)的排列JiangsuMicrosoftTechnologyCenter50第五十頁，共74頁。Scrum物件之產(chǎn)品(chǎnpǐn)訂單(ProductBacklog)JiangsuMicrosoftTechnologyCenter51第五十一頁，共74頁。Scrum物件(wùjiàn)之沖刺訂單(SprintBacklog)JiangsuMicrosoftTechnologyCenter52第五十二頁，共74頁。SprintBacklog示例(shìlì)53PersonsworkingonthetaskDescriptionofthetaskEffortestimateTaskblockedbyanimpedimentSprintgoalMeetsthedefinitionofdone第五十三頁，共74頁。Scrum物件(wùjiàn)之沖刺訂單(SprintBacklog)管理Sprint的backlog:團(tuán)隊(duì)成員自己挑選(tiāoxuǎn)任務(wù)，而不是指派任務(wù)對(duì)每一個(gè)任務(wù)，每天要更新剩余的工作量估算每個(gè)團(tuán)隊(duì)成員都可以修改Sprintbacklog，增加、刪除或者修改任務(wù)JiangsuMicrosoftTechnologyCenter54第五十四頁，共74頁。Scrum物件(wùjiàn)之燃盡圖(BurnDownChart)55Idealburndown.Actualburndown.RemainingworkincreasingTasksunderestimatedand/orworkremainingnotupdated.TasksremovedfromtheSprintBacklogtomeetSprintGoalfasterdecline.Sumofremainingwork[h]foralltasksintheSprintBacklogonaparticularday.Initialestimate(752h)InthebeginningoftheSprint第五十五頁，共74頁。擴(kuò)展(kuòzhǎn)Scrum一般情況一個(gè)團(tuán)隊(duì)的人數(shù)控制在5-9人大型項(xiàng)目可以采用多團(tuán)隊(duì)，通過(tōngguò)teamofteams來擴(kuò)展Scrum。影響擴(kuò)展的因素團(tuán)隊(duì)規(guī)模項(xiàng)目類型項(xiàng)目周期團(tuán)隊(duì)分布Scrum曾被用于超過1000人團(tuán)隊(duì)規(guī)模的項(xiàng)目。JiangsuMicrosoftTechnologyCenter56第五十六頁，共74頁。ScrumOfScrumsJiangsuMicrosoftTechnologyCenter57第五十七頁，共74頁。Scrum項(xiàng)目(xiàngmù)之估計(jì)Scrum團(tuán)隊(duì)對(duì)產(chǎn)品需求清單的每一項(xiàng)的規(guī)模(guīmó)提供初步的估計(jì)，通常采用事件點(diǎn)作為單位StoryPoints(模糊的).也可采用人天或者人小時(shí)作為單位，但容易混淆：a)實(shí)際的規(guī)模(guīmó)b)時(shí)間的單位.精確的估計(jì)值可以在Sprint規(guī)劃時(shí)給出,當(dāng)前階段沒有足夠的信息.規(guī)模(guīmó)的相對(duì)值才有意義.這個(gè)估計(jì)值有助于確定優(yōu)先級(jí);可以采用估算撲克58所需時(shí)間(shíjiān)團(tuán)隊(duì)速度產(chǎn)品規(guī)模第五十八頁，共74頁。完成(wánchéng)的定義當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時(shí)，變?yōu)椤耙淹瓿伞睜顟B(tài)定義“已完成”的含義是非常重要的,例如:如何記錄軟件的變化(biànhuà).使用什么樣的代碼分析工具，發(fā)現(xiàn)的問題應(yīng)當(dāng)如何處理.進(jìn)行了什么樣的測(cè)試,結(jié)果是如何記錄的,通過標(biāo)準(zhǔn)（如覆蓋率、修正的錯(cuò)誤）是什么.定義“已完成”意味著定義質(zhì)量上的需求.“已完成”是0/1變量：完成或者未完成.所有的任務(wù)（task)都完成了迭代任務(wù)才算完成.在第一個(gè)迭代開始之前應(yīng)該定義好，因?yàn)樗鼤?huì)影響工作量,而且必須文檔化，這樣團(tuán)隊(duì)和產(chǎn)品所有者的理解是一致的.59第五十九頁，共74頁。完成(wánchéng)的定義-Example完成的定義遵循(zūnxún)編碼規(guī)范能在模擬器上演示使用PCLint進(jìn)行靜態(tài)代碼分析具有EUnit測(cè)試套件的通過率和執(zhí)行率.或者使用結(jié)對(duì)編程，或者進(jìn)行代碼走查60第六十頁，共74頁。障礙(zhàngài)基本上，任何(rènhé)阻止團(tuán)隊(duì)正常工作的，都可稱之為障礙，例如:無法訪問信息系統(tǒng).所需要的信息不能及時(shí)提供或者提供的不正確，如界面規(guī)格或者其它軟件模塊不到位或不正確開發(fā)環(huán)境或者原型系統(tǒng)出現(xiàn)問題其他的任務(wù)分配：培訓(xùn)，售前支持缺乏必要的信息或者相應(yīng)的知識(shí)對(duì)于團(tuán)隊(duì)提出的各項(xiàng)障礙，ScrumMaster要以列表形式進(jìn)行記錄，61第六十一頁，共74頁。誰來清除(qīngchú)障礙？每個(gè)人自我管理、自我組織的團(tuán)隊(duì)ScrumMaster產(chǎn)品所有者管理層其他相關(guān)的干系人ScrumMaster負(fù)責(zé)確定障礙已經(jīng)清除(qīngchú)，不一定親自自己清除(qīngchú)62第六十二頁，共74頁。清除(qīngchú)障礙某些障礙是浪費(fèi)部分地完成(wánchéng)工作額外的過程額外的功能任務(wù)轉(zhuǎn)換等待缺陷清除(qīngchú)障礙的過程是團(tuán)隊(duì)和組織學(xué)習(xí)的過程63第六十三頁，共74頁。浪費(fèi)(làngfèi)產(chǎn)生的原因多問幾個(gè)“為什么”對(duì)于每個(gè)標(biāo)識(shí)的障礙(zhàngài)或者浪費(fèi)，問一問“為什么”浪費(fèi)會(huì)存在多問幾個(gè)“為什么”，找到造成浪費(fèi)的根本原因64第六十四頁，共74頁。目錄(mùlù)敏捷的背景與動(dòng)機(jī)敏捷宣言及原則(yuánzé)敏捷方法是什么？敏捷方法的實(shí)踐Scrum的角色Scrum流程和工作產(chǎn)品Scrum應(yīng)用總結(jié)65第六十五頁，共74頁。SCRUM實(shí)踐(shíjiàn)研發(fā)部2009年開始在幾個(gè)項(xiàng)目當(dāng)中進(jìn)行了SCRUM項(xiàng)目管理的嘗試：營銷綜合(zōnghé)停電系統(tǒng)開發(fā)FLEX-ADP開發(fā)海頤OA項(xiàng)目等www.海頤軟件(ruǎnjiàn)第六十六頁，共74頁。SCRUM看板(kànbǎn)www.海頤軟件(ruǎnjiàn)第六十七頁，共74頁。SCRUM燃盡圖www.海頤軟件(ruǎnjiàn)第六十八頁，共74頁。SCRUM帶來的改善(gǎishàn)項(xiàng)目的計(jì)劃性更強(qiáng)了，將項(xiàng)目按SPRINT進(jìn)行分解，每個(gè)SPRINT要進(jìn)行計(jì)劃和總