敏捷項(xiàng)目管理終極培訓(xùn)-Scrum

1、敏捷項(xiàng)目管理終極培訓(xùn)-Scrum2016年6月目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)2敏捷的背景與動(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)的軟件工程難以滿(mǎn)足這些要求所以軟件團(tuán)隊(duì)除了在技術(shù)上必須日益精進(jìn)，更需要運(yùn)用有效的開(kāi)發(fā)流程，以確保團(tuán)隊(duì)能夠發(fā)揮綜效。這正是Agile Process (敏捷的軟件開(kāi)發(fā)流程)于近年來(lái)興起的主要原因。軟件項(xiàng)目的復(fù)雜性橫軸代表需求的復(fù)雜度縱軸表示技術(shù)的復(fù)雜度還有人力資源的復(fù)雜度4解

2、決復(fù)雜性問(wèn)題需要采用經(jīng)驗(yàn)式方式解決問(wèn)題的兩種方式：預(yù)定義過(guò)程控制（富士康流水線生產(chǎn)）經(jīng)驗(yàn)性過(guò)程控制（摸著石頭過(guò)河）如果復(fù)雜度超過(guò)預(yù)定義方式的能力范圍，應(yīng)該采用經(jīng)驗(yàn)性方式經(jīng)驗(yàn)性方式的三大支柱：可見(jiàn)性、檢查及適應(yīng)5他山之石互聯(lián)網(wǎng)時(shí)代的出版模式作者最開(kāi)始的時(shí)候并沒(méi)有想出一本書(shū)，而只是把多年的積累梳理出來(lái)寫(xiě)成了博客，憑借博客的成功最后得到了出版商和紙版讀者的認(rèn)可。在寫(xiě)成本書(shū)的過(guò)程中，作者是漸進(jìn)式的進(jìn)行的，每寫(xiě)完一個(gè)章節(jié)，放到博客上去征求讀者的反饋，很多反饋意見(jiàn)在后面的章節(jié)或修訂中及時(shí)地體現(xiàn)出來(lái)，這樣就形成了與讀者之間的良好反饋，在出版之前就鎖定了大量的讀者。這就是敏捷開(kāi)發(fā)提倡的“增量迭代、及時(shí)交付”的

3、思想。這種模式能最大程度地不偏離客戶(hù)需求的本質(zhì)。精益制造消除浪費(fèi)、關(guān)注流程、建立無(wú)間斷流程以快速應(yīng)變 、降低庫(kù)存 、一次做對(duì)、基于顧客需求的拉動(dòng)生產(chǎn) 、標(biāo)準(zhǔn)化與工作創(chuàng)新 、尊重員工，給員工授權(quán) 等目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)7敏捷的歷史敏捷軟件開(kāi)發(fā)又稱(chēng)敏捷開(kāi)發(fā)，從1990年代開(kāi)始逐漸引起廣泛關(guān)注的一些新型軟件開(kāi)發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開(kāi)發(fā)能力。2001年初，因觀察到許多的軟件團(tuán)隊(duì)身陷不斷擴(kuò)大的流程之中的困境，一群業(yè)界專(zhuān)家聚集在一起，勾勒出一些能讓軟件團(tuán)隊(duì)迅速工作，

4、以及響應(yīng)變化的價(jià)值觀和原則。他們自稱(chēng)為Agile Alliance。之后的七個(gè)月里，他們創(chuàng)造具有價(jià)值的聲明，也就是敏捷軟件的開(kāi)發(fā)宣言。十五人中包括：大名鼎鼎的Kent Beck（XP,TDD的創(chuàng)始人,Junit的創(chuàng)始人之一）、Ward Cunningham（Wiki概念的發(fā)明者）、Martin Fowler（企業(yè)應(yīng)用架構(gòu)模式作者）、Robert C. Martin、Ken Schwaber 敏捷價(jià)值觀之敏捷宣言9敏捷開(kāi)發(fā)的核心思想是敏捷開(kāi)發(fā)的核心思想是：以人為本，適應(yīng)變化以人為本，適應(yīng)變化。敏捷價(jià)值觀之敏捷宣言-1個(gè)體和交互勝過(guò)過(guò)程和工具人是軟件項(xiàng)目獲得成功最為重要的因素合作、溝通能力以及交互

5、能力比單純的軟件編程能力和工具更為重要方法和工具是死的，人是活的，人要是太“面”或者協(xié)作不好，再?gòu)?qiáng)大的方法和工具都是白扯；10敏捷價(jià)值觀之敏捷宣言-2可以工作的軟件勝過(guò)面面俱到的文檔過(guò)多的面面俱到的文檔往往比過(guò)少的文檔更糟軟件開(kāi)發(fā)的主要和中心活動(dòng)是創(chuàng)建可以工作的軟件直到迫切需要并且意義重大時(shí)，才進(jìn)行文檔編制編制的內(nèi)部文檔應(yīng)盡量短小并且主題突出11敏捷價(jià)值觀之敏捷宣言-3客戶(hù)合作勝過(guò)合同談判客戶(hù)不可能做到一次性地將他們的需求完整清晰地表述在合同中為開(kāi)發(fā)團(tuán)隊(duì)和客戶(hù)的協(xié)同工作方式提供指導(dǎo)的合同才是最好的合同12敏捷價(jià)值觀之敏捷宣言-4響應(yīng)變化勝過(guò)循環(huán)計(jì)劃變化是軟件開(kāi)發(fā)中存在的現(xiàn)實(shí)計(jì)劃必須有足夠的靈活

6、性與可塑性短期的迭代的計(jì)劃比中長(zhǎng)期計(jì)劃更有效Jiangsu Microsoft Technology Center 13敏捷開(kāi)發(fā)的12個(gè)原則我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的軟件來(lái)使客戶(hù)滿(mǎn)意。即使到了開(kāi)發(fā)的后期，也歡迎改變需求。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個(gè)月，交付的時(shí)間間隔越短越好 。在整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一起工作。圍繞被激勵(lì)起來(lái)的個(gè)人來(lái)構(gòu)建項(xiàng)目。在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談。 敏捷開(kāi)發(fā)的12個(gè)原則工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。敏捷過(guò)程提倡平穩(wěn)的開(kāi)發(fā)節(jié)奏；發(fā)起人、開(kāi)發(fā)者和用戶(hù)應(yīng)該能夠保

7、持一個(gè)長(zhǎng)期的、恒定的開(kāi)發(fā)速度。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。 簡(jiǎn)單化是根本（不做過(guò)度設(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)整。 目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)16什么是敏捷方法？敏捷方法是一類(lèi)軟件開(kāi)發(fā)流程的泛稱(chēng)；敏捷方法是相對(duì)于傳統(tǒng)的瀑布式軟件過(guò)程提出的；敏捷方法可以用敏捷宣言（4條）、敏捷原則（12條）來(lái)概括；敏捷原則通過(guò)一系列的敏捷實(shí)踐來(lái)體現(xiàn)出來(lái)；敏捷方法有很多種

8、。問(wèn)題1，請(qǐng)舉出你知道的2個(gè)以上敏捷方法名字來(lái)敏捷的方法Extreme ProgrammingExtreme Programming (XP)極限編程ScrumScrum Adaptive Software Development (ASD)自適應(yīng)軟件開(kāi)發(fā)Crystal Clear and Other Crystal Methodologies水晶方法Dynamic Systems Development Method (DSDM)動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法等敏捷方法 VS. 瀑布模型瀑布模型固定的、沒(méi)有彈性的。很困難去達(dá)到互動(dòng)。假如說(shuō)需求沒(méi)有完全的被了解，或是可能需要完全地改變項(xiàng)目的需求，瀑布式的mo

9、del是比較不適合的。敏捷方法完整地開(kāi)發(fā)，每少數(shù)幾周或是少數(shù)幾個(gè)月里可以測(cè)試功能。強(qiáng)調(diào)在獲得最簡(jiǎn)短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價(jià)值。在整個(gè)項(xiàng)目的生命周期里，可以持續(xù)的改善、增加未來(lái)的功能。敏捷項(xiàng)目管理VS傳統(tǒng)項(xiàng)目管理傳統(tǒng)項(xiàng)目管理：事先對(duì)整個(gè)項(xiàng)目進(jìn)行估計(jì)、計(jì)劃、分析反對(duì)變更; 變更需要重新估計(jì)、重新規(guī)劃嚴(yán)密的合同來(lái)減少風(fēng)險(xiǎn), 如果改變需求要走 CR 流程.項(xiàng)目作為一個(gè)“黑盒子” ，對(duì)客戶(hù)與供應(yīng)商的可視性差.文檔和計(jì)劃驅(qū)動(dòng)的方法.軟件交付時(shí)間晚, 意識(shí)到風(fēng)險(xiǎn)的時(shí)間晚.WBS,甘特圖,關(guān)鍵路徑分析敏捷項(xiàng)目管理:對(duì)整個(gè)項(xiàng)目做一個(gè)粗略的估計(jì),每一次迭代都有詳細(xì)的計(jì)劃.鼓勵(lì)變化, 客戶(hù)價(jià)值驅(qū)動(dòng)開(kāi)發(fā)

10、.信任和賦予權(quán)力;合約使變更變得簡(jiǎn)單，增加價(jià)值.客戶(hù)和開(kāi)發(fā)人員之間是緊密的連續(xù)的合作關(guān)系每次迭代都產(chǎn)生可交付的軟件專(zhuān)注于交付軟件.第一次迭代就可交付能工作的版本，風(fēng)險(xiǎn)發(fā)現(xiàn)的早. 20敏捷 與CMMI雙劍合璧CMMI更加關(guān)注于流程，敏捷更加關(guān)注于人CMMI自頂向下，敏捷自底向上敏捷并不排斥必要的文檔敏捷的很多實(shí)踐是對(duì)CMMI的一種實(shí)現(xiàn)，比如sprint計(jì)劃會(huì)議就是PP的實(shí)現(xiàn)，每日例會(huì)就是在做PMC很多CMMI45級(jí)的公司也在應(yīng)用敏捷，比如說(shuō)寶信、華為項(xiàng)目級(jí)的敏捷實(shí)踐通過(guò)CMMI可以在組織級(jí)得以重用21eXtreme ProgrammingXP我們一般稱(chēng)為極限編程，是最輕量級(jí)的開(kāi)發(fā)流程。最主要的精

11、神是在客戶(hù)有系統(tǒng)需求時(shí)，給予及時(shí)滿(mǎn)意的可執(zhí)行程序，所以最適合需求快速變動(dòng)的項(xiàng)目。它強(qiáng)調(diào)客戶(hù)所要的是workable的執(zhí)行碼，所以把與撰寫(xiě)程序無(wú)關(guān)的工作降至最低，并要求客戶(hù)與開(kāi)發(fā)人員最好以side-by-side的方式一起工作。XP的實(shí)踐包括：完整團(tuán)隊(duì)、計(jì)劃游戲、客戶(hù)測(cè)試簡(jiǎn)單設(shè)計(jì)、結(jié)對(duì)編程、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)改進(jìn)設(shè)計(jì)、持續(xù)集成、集體代碼所有權(quán)編碼標(biāo)準(zhǔn)、隱喻、可持續(xù)的速度Scrum開(kāi)發(fā)流程Jiangsu Microsoft Technology Center 23為什么采用敏捷? 預(yù)期的收益 采用敏捷方法得當(dāng)?shù)脑?huà)，可以：更加透明; 隨時(shí)跟蹤項(xiàng)目的狀態(tài)和進(jìn)展情況，及早發(fā)現(xiàn)問(wèn)題和風(fēng)險(xiǎn) .快速交付, 每次迭代

12、都能交付可運(yùn)行的軟件.最高風(fēng)險(xiǎn)和最高優(yōu)先級(jí)的需求，最優(yōu)先進(jìn)行開(kāi)發(fā).改善應(yīng)對(duì)變更能力, 減少大量的重計(jì)劃.改善項(xiàng)目溝通.更好的客戶(hù)參與, 避免錯(cuò)誤的假設(shè).總之:提高了生產(chǎn)率; 減少“浪費(fèi)” （不需要的文檔，重復(fù)工作等） ，項(xiàng)目的每次迭代都有明確的目標(biāo).提高客戶(hù)滿(mǎn)意度; 短期內(nèi)產(chǎn)生成效, 按預(yù)期交付軟件, 每次迭代結(jié)束產(chǎn)生可以運(yùn)行的軟件.改善員工的滿(mǎn)意度; 團(tuán)隊(duì)精神，減少官僚，能夠規(guī)劃和管理自己的工作，減少“恐慌” ，穩(wěn)定的工作量（可持續(xù)的步伐）. 24目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)25

13、敏捷關(guān)鍵實(shí)踐1增量迭代每個(gè)迭代有一個(gè)大約為14周的時(shí)間框，在SCRUM里稱(chēng)為一次沖刺（超過(guò)1個(gè)月的詳細(xì)計(jì)劃往往偏差很大）每次迭代都應(yīng)該有明確的目標(biāo)每次迭代都應(yīng)該有明確的可演示的工作成果迭代過(guò)程中項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該盡量免受打擾迭代可以將項(xiàng)目的壓力分解到每個(gè)小的階段，風(fēng)險(xiǎn)也能同時(shí)分解26敏捷關(guān)鍵實(shí)踐2測(cè)試驅(qū)動(dòng)開(kāi)發(fā) TDD什么是測(cè)試驅(qū)動(dòng)？首先創(chuàng)建測(cè)試用例，然后開(kāi)發(fā)軟件通過(guò)測(cè)試(在開(kāi)發(fā)代碼前，首先編寫(xiě)測(cè)試代碼)一種設(shè)計(jì)軟件的方法，而不僅僅是一種測(cè)試方法所創(chuàng)建的測(cè)試用例用來(lái)指導(dǎo)和約束項(xiàng)目中的各項(xiàng)工作，對(duì)未來(lái)的各項(xiàng)工作提供一個(gè)安全的保護(hù)不需要測(cè)試的工作不需要完成所創(chuàng)建的測(cè)試用例通常替代詳細(xì)的業(yè)務(wù)和技術(shù)需求定測(cè)試

14、也有效地驅(qū)動(dòng)設(shè)計(jì)，使設(shè)計(jì)更加趨向于可行的設(shè)計(jì)通常情況下需要自動(dòng)測(cè)試的支持 (EUnit, JUnit etc.).對(duì)于UI軟件應(yīng)用TDD方法有一定的困難27敏捷關(guān)鍵實(shí)踐3持續(xù)集成28極限編程稱(chēng)為“每日構(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è)試敏捷關(guān)鍵實(shí)踐4面對(duì)面交流 雖然如今通訊工具花樣繁多，但面對(duì)面交流在某些場(chǎng)合下仍然是不可替代的；敏捷開(kāi)發(fā)把交流缺失問(wèn)題考慮在內(nèi)，要求團(tuán)隊(duì)成員彼此直接協(xié)作，盡量創(chuàng)造面對(duì)面交流的機(jī)會(huì)；尤其

15、當(dāng)業(yè)務(wù)分析師和軟件開(kāi)發(fā)人員一起工作的時(shí)候，面對(duì)面的交流是很重要的。匿名共享需求文檔只會(huì)打開(kāi)曲解和誤解之門(mén)，更不用說(shuō)書(shū)面信息比口頭交流還要慢很多。29敏捷方法的其它實(shí)踐結(jié)對(duì)編程 每日立會(huì) 用戶(hù)故事團(tuán)隊(duì)工作室 頻繁發(fā)布自組織團(tuán)隊(duì)重構(gòu)30重構(gòu)改善既有代碼的設(shè)計(jì)Martin Fowler提出代碼的壞味道Martin Fowler和Kent Beck列舉了22種壞味道：冗余代碼、冗長(zhǎng)的方法、巨大的類(lèi)、過(guò)多的參數(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, extract method, move field等等

16、簡(jiǎn)單設(shè)計(jì)測(cè)試用例實(shí)現(xiàn)再說(shuō)（重構(gòu)回歸測(cè)試）*31Scrum何時(shí)更有效？公司和客戶(hù)一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法.敏捷方法對(duì)需求不完整以及經(jīng)常變換的項(xiàng)目比較有效.項(xiàng)目可以劃分成固定時(shí)間間隔的迭代, 并且可以?xún)鼋Y(jié)正在進(jìn)行的迭代的范圍公司和客戶(hù)都有能力擔(dān)當(dāng)角色尤其是Product Owner 和 Scrum Master.項(xiàng)目的人員結(jié)構(gòu)能夠分成6到10人的團(tuán)隊(duì)，最好每個(gè)工作地點(diǎn)一個(gè)小組.（Scrum of Scrums，Scrum的擴(kuò)展）團(tuán)隊(duì)成員能夠以自組織的方式工作. 項(xiàng)目的合同允許變更.固定價(jià)格的項(xiàng)目可以使用敏捷，但應(yīng)當(dāng)盡量避免。最好在按時(shí)間和材料付費(fèi)或者按月付費(fèi)的項(xiàng)目中進(jìn)行使用、

17、變更項(xiàng)目的范圍不需要高級(jí)管理層的批準(zhǔn).32問(wèn)題2，為什么SCRUM團(tuán)隊(duì)人員最好在10人以?xún)?nèi)？目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐ScrumScrum的角色的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)33敏捷特別強(qiáng)調(diào)人的因素相對(duì)于過(guò)程與工具，敏捷更強(qiáng)調(diào)“人”的因素。誠(chéng)信是基礎(chǔ)沒(méi)有過(guò)程能夠?qū)φ\(chéng)信進(jìn)行有效的約束誠(chéng)信與否是有效實(shí)施敏捷過(guò)程的最大限制34Scrum框架海頤軟件Scrum角色Scrum角色之Product Owner產(chǎn)品負(fù)責(zé)人（Product Owner）的職責(zé)如下：確定產(chǎn)品的功能。決定發(fā)布的日期和發(fā)布內(nèi)容。為產(chǎn)品的profitability of th

18、e product (ROI)負(fù)責(zé)。根據(jù)市場(chǎng)價(jià)值確定功能優(yōu)先級(jí)。每個(gè)Sprint，根據(jù)需要調(diào)整功能和優(yōu)先級(jí)（每個(gè)Sprint開(kāi)始前調(diào)整）。接受或拒絕接受開(kāi)發(fā)團(tuán)隊(duì)的工作成果。37Scrum角色之ScrumMaster作為T(mén)eam Leader和Product owner緊密地工作在一起，他可以及時(shí)地為團(tuán)隊(duì)成員提供幫助。他必須:保證團(tuán)隊(duì)資源完全可被利用并且全部是高產(chǎn)出的。保證各個(gè)角色及職責(zé)的良好協(xié)作。解決團(tuán)隊(duì)開(kāi)發(fā)中的障礙。做為團(tuán)隊(duì)和外部的接口，屏蔽外界對(duì)團(tuán)隊(duì)成員的干擾。保證開(kāi)發(fā)過(guò)程按計(jì)劃進(jìn)行，組織 Daily Scrum, Sprint Review and Sprint Planning mee

19、tings。38Scrum角色之Scrum Team一般情況人數(shù)在5-9個(gè)左右團(tuán)隊(duì)要跨職能（包括開(kāi)發(fā)人員、測(cè)試人員、用戶(hù)界面設(shè)計(jì)師等）團(tuán)隊(duì)成員需要全職。（有些情況例外，比如數(shù)據(jù)庫(kù)管理員）在項(xiàng)目向?qū)Х秶鷥?nèi)有權(quán)利做任何事情已確保達(dá)到Sprint的目標(biāo)。高度的自我組織能力。向Product Owner演示產(chǎn)品功能。團(tuán)隊(duì)成員構(gòu)成在sprint內(nèi)不允許變化。39目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 ScrumScrum流程和工作流程和工作產(chǎn)品產(chǎn)品 Scrum應(yīng)用總結(jié)40Scrum 流程41Sprint Planning Meeting:Next Sprint

20、 GoalSprint BacklogUpdated Product BacklogDaily Scrum meetings : What did you do yesterdayWhat will you do today?What obstacles are in your way?Source: http:/ ScrumSprintRetrospectiveShippableProduct IncrementSprints(沖刺)Scrum的項(xiàng)目過(guò)程有一系列的Sprint組成。Sprint的長(zhǎng)度一般控制在2-4周。通過(guò)固定的周期保持良好的節(jié)奏。產(chǎn)品的設(shè)計(jì)、開(kāi)發(fā)、測(cè)試都在Sprint期間完

21、成。Sprint結(jié)束時(shí)交付可以工作的軟件。在Sprint過(guò)程中不允許發(fā)生變更。42Scrum框架43Scrum儀式之Sprint計(jì)劃會(huì)議Jiangsu Microsoft Technology Center 44Scrum儀式之Sprint計(jì)劃會(huì)議Jiangsu Microsoft Technology Center 45Scrum儀式之每日Scrum會(huì)議(Daily Scrum)每日Scrum會(huì)議，即團(tuán)隊(duì)每日例會(huì)，條件允許的話(huà)，每天都應(yīng)該在同樣的時(shí)間和地點(diǎn)，組織所有成員站立進(jìn)行。最好是每天早晨開(kāi)，一般15分鐘左右，時(shí)間比較短，也有利于團(tuán)隊(duì)成員安排好當(dāng)天的工作。只有團(tuán)隊(duì)成員可以在例會(huì)上發(fā)言，其

22、他人員有興趣可以參加，但只能旁聽(tīng)，不能發(fā)言。（小豬和小雞的故事）每日Scrum會(huì)議由Scrum Master主持， Scrum團(tuán)隊(duì)所有成員輪流回答以下3個(gè)問(wèn)題：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困難？Jiangsu Microsoft Technology Center 46Scrum 任務(wù)板(Task Board)Jiangsu Microsoft Technology Center 47任務(wù)板（墻）展現(xiàn)了在Sprint過(guò)程中所有要完成的任務(wù)。在Sprint過(guò)程中我們要不斷的更新它。如果某個(gè)開(kāi)發(fā)人員想到了一個(gè)任務(wù)他就可以把這個(gè)任務(wù)寫(xiě)下來(lái)放在任務(wù)墻上。 無(wú)論每日站會(huì)過(guò)

23、程中或者之后，如果估計(jì)發(fā)生了變化，任務(wù)會(huì)根據(jù)變化在任務(wù)墻上做相應(yīng)的調(diào)整。通常的任務(wù)板是下面這個(gè)樣子:Scrum儀式之Sprint評(píng)審會(huì)議Sprint評(píng)審會(huì)用來(lái)演示在這個(gè)Sprint中開(kāi)發(fā)的產(chǎn)品功能給Product Owner. Product Owner會(huì)組織這階段的會(huì)議并且邀請(qǐng)相關(guān)的干系人參加。團(tuán)隊(duì)展示Sprint中完成的功能一般是通過(guò)現(xiàn)場(chǎng)演示的方式展現(xiàn)功能和架構(gòu)不要太正式不需要PPT一般控制在2個(gè)小時(shí)團(tuán)隊(duì)成員都要參加可以邀請(qǐng)所有人參加Jiangsu Microsoft Technology Center 48Scrum儀式之Sprint回顧會(huì)議Jiangsu Microsoft Techn

24、ology Center 49團(tuán)隊(duì)的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。一般控制在15-30分鐘每個(gè)Sprint都要做全體參加Scrum Master產(chǎn)品負(fù)責(zé)人團(tuán)隊(duì)可能的客戶(hù)或其它干系人Sprint回顧會(huì)議上，全體成員討論有哪些好的做法可以啟動(dòng)，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚(yáng)。Scrum物件之產(chǎn)品訂單(Product Backlog)一個(gè)需求的列表。一般情況使用用戶(hù)故事來(lái)表示backlog條目理想情況每個(gè)需求項(xiàng)都對(duì)產(chǎn)品的客戶(hù)或用戶(hù)有價(jià)值Backlog條目按照商業(yè)價(jià)值排列優(yōu)先級(jí)優(yōu)先級(jí)由產(chǎn)品負(fù)責(zé)人來(lái)排列在每個(gè)Sprint結(jié)束的時(shí)候要更新優(yōu)先級(jí)的排列Jiangsu M

25、icrosoft Technology Center 50Scrum物件之產(chǎn)品訂單(Product Backlog)Jiangsu Microsoft Technology Center 51Scrum物件之沖刺訂單(Sprint Backlog)Jiangsu Microsoft Technology Center 52Sprint Backlog 示例53Personsworking onthe taskDescription of the taskEffort estimateTask blockedby an impedimentSprint goalMeets the definit

26、ion of doneScrum物件之沖刺訂單(Sprint Backlog)管理Sprint的backlog:團(tuán)隊(duì)成員自己挑選任務(wù)，而不是指派任務(wù)對(duì)每一個(gè)任務(wù)，每天要更新剩余的工作量估算每個(gè)團(tuán)隊(duì)成員都可以修改Sprint backlog，增加、刪除或者修改任務(wù)Jiangsu Microsoft Technology Center 54Scrum物件之燃盡圖(Burn Down Chart)55Ideal burndown.Actual burndown.Remaining work increasing Tasks underestimated and/or work remainingno

27、t updated. Tasks removed from the Sprint Backlog to meetSprint Goal faster decline.Sum of remaining work h for all tasks in the Sprint Backlog on a particular day.Initial estimate (752 h)In the beginning of theSprint 擴(kuò)展Scrum一般情況一個(gè)團(tuán)隊(duì)的人數(shù)控制在5-9人大型項(xiàng)目可以采用多團(tuán)隊(duì)，通過(guò)team of teams來(lái)擴(kuò)展Scrum。影響擴(kuò)展的因素團(tuán)隊(duì)規(guī)模項(xiàng)目類(lèi)型項(xiàng)目周期團(tuán)隊(duì)分

28、布Scrum曾被用于超過(guò)1000人團(tuán)隊(duì)規(guī)模的項(xiàng)目。 Jiangsu Microsoft Technology Center 56Scrum Of ScrumsJiangsu Microsoft Technology Center 57Scrum項(xiàng)目之估計(jì)Scrum團(tuán)隊(duì)對(duì)產(chǎn)品需求清單的每一項(xiàng)的規(guī)模提供初步的估計(jì)，通常采用事件點(diǎn)作為單位Story Points (模糊的).也可采用人天或者人小時(shí)作為單位，但容易混淆： a) 實(shí)際的規(guī)模 b) 時(shí)間的單位.精確的估計(jì)值可以在Sprint 規(guī)劃時(shí)給出, 當(dāng)前階段沒(méi)有足夠的信息.規(guī)模的相對(duì)值才有意義.這個(gè)估計(jì)值有助于確定優(yōu)先級(jí);可以采用估算撲克 58所需

29、時(shí)間所需時(shí)間團(tuán)隊(duì)速度團(tuán)隊(duì)速度產(chǎn)品規(guī)模產(chǎn)品規(guī)模完成的定義 當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時(shí)，變?yōu)椤耙淹瓿伞睜顟B(tài)定義“已完成”的含義是非常重要的, 例如:如何記錄軟件的變化.使用什么樣的代碼分析工具 ，發(fā)現(xiàn)的問(wèn)題應(yīng)當(dāng)如何處理.進(jìn)行了什么樣的測(cè)試, 結(jié)果是如何記錄的, 通過(guò)標(biāo)準(zhǔn)（如覆蓋率、修正的錯(cuò)誤）是什么.定義“已完成”意味著定義質(zhì)量上的需求.“已完成”是0/1變量：完成或者未完成. 所有的任務(wù)（task)都完成了迭代任務(wù)才算完成.在第一個(gè)迭代開(kāi)始之前應(yīng)該定義好，因?yàn)樗鼤?huì)影響工作量, 而且必須文檔化，這樣團(tuán)隊(duì)和產(chǎn)品所有者的理解是一致的.59完成的定義 - Example完成的定義 遵循編碼規(guī)范能在模

30、擬器上演示 使用PCLint 進(jìn)行靜態(tài)代碼分析具有EUnit 測(cè)試套件的通過(guò)率 和執(zhí)行率. 或者使用結(jié)對(duì)編程，或者進(jìn)行代碼走查60障礙基本上，任何阻止團(tuán)隊(duì)正常工作的，都可稱(chēng)之為障礙，例如:無(wú)法訪問(wèn)信息系統(tǒng).所需要的信息不能及時(shí)提供或者提供的不正確，如界面規(guī)格或者其它軟件模塊不到位或不正確開(kāi)發(fā)環(huán)境或者原型系統(tǒng)出現(xiàn)問(wèn)題其他的任務(wù)分配：培訓(xùn)，售前支持缺乏必要的信息或者相應(yīng)的知識(shí)對(duì)于團(tuán)隊(duì)提出的各項(xiàng)障礙，Scrum Master要以列表形式進(jìn)行記錄，61誰(shuí)來(lái)清除障礙？每個(gè)人自我管理、自我組織的團(tuán)隊(duì)Scrum Master產(chǎn)品所有者管理層其他相關(guān)的干系人Scrum Master 負(fù)責(zé)確定障礙已經(jīng)清除，不一

31、定親自自己清除62清除障礙某些障礙是浪費(fèi)部分地完成工作額外的過(guò)程額外的功能任務(wù)轉(zhuǎn)換等待缺陷清除障礙的過(guò)程是團(tuán)隊(duì)和組織學(xué)習(xí)的過(guò)程63浪費(fèi)產(chǎn)生的原因多問(wèn)幾個(gè)“為什么”對(duì)于每個(gè)標(biāo)識(shí)的障礙或者浪費(fèi)，問(wèn)一問(wèn)“為什么”浪費(fèi)會(huì)存在多問(wèn)幾個(gè)“為什么”，找到造成浪費(fèi)的根本原因64目錄敏捷的背景與動(dòng)機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 ScrumScrum應(yīng)用應(yīng)用總結(jié)65SCRUM實(shí)踐研發(fā)部2009年開(kāi)始在幾個(gè)項(xiàng)目當(dāng)中進(jìn)行了SCRUM項(xiàng)目管理的嘗試：營(yíng)銷(xiāo)綜合停電系統(tǒng)開(kāi)發(fā)FLEX-ADP開(kāi)發(fā)海頤OA項(xiàng)目等海頤軟件SCRUM看板海頤軟件SCRUM燃盡圖海頤軟件SCRUM帶來(lái)的改善項(xiàng)目的計(jì)劃性更強(qiáng)了，將項(xiàng)目按SPRINT進(jìn)行分解，每個(gè)SPRINT要進(jìn)行計(jì)劃和總結(jié)，每天也有立會(huì)來(lái)進(jìn)行簡(jiǎn)短的總結(jié)和計(jì)劃；引入SCRUM以后，項(xiàng)目團(tuán)隊(duì)的溝通比以往更有效，項(xiàng)目看板為項(xiàng)