Scrum敏捷項(xiàng)目管理

1、Scrum敏捷項(xiàng)目管理2011年2月目錄敏捷的背景與動機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)2敏捷的背景與動機(jī)軟件危機(jī)及軟件工程的出現(xiàn)速度是企業(yè)競爭致勝的關(guān)鍵因素，軟件項(xiàng)目的最大挑戰(zhàn)在于一方面要應(yīng)付變動中的需求一方面要在緊縮的時(shí)程內(nèi)完成項(xiàng)目傳統(tǒng)的軟件工程難以滿足這些要求所以軟件團(tuán)隊(duì)除了在技術(shù)上必須日益精進(jìn)，更需要運(yùn)用有效的開發(fā)流程，以確保團(tuán)隊(duì)能夠發(fā)揮綜效。這正是Agile Process (敏捷的軟件開發(fā)流程)于近年來興起的主要原因。軟件項(xiàng)目的復(fù)雜性橫軸代表需求的復(fù)雜度縱軸表示技術(shù)的復(fù)雜度還有人力資源的復(fù)雜度4解決復(fù)雜性問

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

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

4、化的價(jià)值觀和原則。他們自稱為Agile Alliance。之后的七個(gè)月里，他們創(chuàng)造具有價(jià)值的聲明，也就是敏捷軟件的開發(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敏捷開發(fā)的核心思想是敏捷開發(fā)的核心思想是：以人為本，適應(yīng)變化以人為本，適應(yīng)變化。敏捷價(jià)值觀之敏捷宣言-1個(gè)體和交互勝過過程和工具人是軟件項(xiàng)目獲得成功最為重要的因素合作、溝通能力以及交互能力比單純

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

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

7、的、恒定的開發(fā)速度。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會增強(qiáng)敏捷能力。 簡單化是根本（不做過度設(shè)計(jì)和預(yù)測）。 最好的構(gòu)架、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。每隔一定時(shí)間，團(tuán)隊(duì)會在如何才能更有效地工作方面進(jìn)行反思并對自己的行為進(jìn)行相應(yīng)調(diào)整。 目錄敏捷的背景與動機(jī)敏捷宣言及原則敏捷方法是什么？敏捷方法是什么？敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用總結(jié)16什么是敏捷方法？敏捷方法是一類軟件開發(fā)流程的泛稱；敏捷方法是相對于傳統(tǒng)的瀑布式軟件過程提出的；敏捷方法可以用敏捷宣言（4條）、敏捷原則（12條）來概括；敏捷原則通過一系列的敏捷實(shí)踐來體現(xiàn)出來；敏捷方法有很多種。問題1，

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

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

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

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

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

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

14、動設(shè)計(jì)，使設(shè)計(jì)更加趨向于可行的設(shè)計(jì)通常情況下需要自動測試的支持 (EUnit, JUnit etc.).對于UI軟件應(yīng)用TDD方法有一定的困難27敏捷關(guān)鍵實(shí)踐3持續(xù)集成28極限編程稱為“每日構(gòu)建”持續(xù)集成一般利用ANT、MAVEN等工具日構(gòu)建的好處：將集成風(fēng)險(xiǎn)降到最低降低質(zhì)量風(fēng)險(xiǎn)提升士氣日構(gòu)建可以看做是項(xiàng)目的心跳，冒煙測試就像是聽診器日構(gòu)建必須至少：成功編譯、打包、發(fā)布；不含有任何明顯的缺陷；通過冒煙測試敏捷關(guān)鍵實(shí)踐4面對面交流 雖然如今通訊工具花樣繁多，但面對面交流在某些場合下仍然是不可替代的；敏捷開發(fā)把交流缺失問題考慮在內(nèi)，要求團(tuán)隊(duì)成員彼此直接協(xié)作，盡量創(chuàng)造面對面交流的機(jī)會；尤其當(dāng)業(yè)務(wù)分析

15、師和軟件開發(fā)人員一起工作的時(shí)候，面對面的交流是很重要的。匿名共享需求文檔只會打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。29敏捷方法的其它實(shí)踐結(jié)對編程 每日立會 用戶故事團(tuán)隊(duì)工作室 頻繁發(fā)布自組織團(tuán)隊(duì)重構(gòu)30重構(gòu)改善既有代碼的設(shè)計(jì)Martin Fowler提出代碼的壞味道Martin Fowler和Kent Beck列舉了22種壞味道：冗余代碼、冗長的方法、巨大的類、過多的參數(shù)等等重構(gòu)可以彌補(bǔ)設(shè)計(jì)的不足簡單設(shè)計(jì)的思想重構(gòu)與測試驅(qū)動的關(guān)系TDD是重構(gòu)的腳手架IDE已經(jīng)對主要的重構(gòu)模式提供了自動化支持：Rename, extract method, move field等等簡單設(shè)計(jì)測

16、試用例實(shí)現(xiàn)再說（重構(gòu)回歸測試）*31Scrum何時(shí)更有效？公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法.敏捷方法對需求不完整以及經(jīng)常變換的項(xiàng)目比較有效.項(xiàng)目可以劃分成固定時(shí)間間隔的迭代, 并且可以凍結(jié)正在進(jìn)行的迭代的范圍公司和客戶都有能力擔(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)行使用、變更項(xiàng)目的

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

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

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

20、Sprint 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)目過程有一系列的Sprint組成。Sprint的長度一般控制在2-4周。通過固定的周期保持良好的節(jié)奏。產(chǎn)品的設(shè)計(jì)、開發(fā)、測試都在Sprint期間完成。Spr

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

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

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

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

25、oft 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 definition o

26、f doneScrum物件之沖刺訂單(Sprint Backlog)管理Sprint的backlog:團(tuán)隊(duì)成員自己挑選任務(wù)，而不是指派任務(wù)對每一個(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 remainingnot upd

27、ated. 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ì)，通過team of teams來擴(kuò)展Scrum。影響擴(kuò)展的因素團(tuán)隊(duì)規(guī)模項(xiàng)目類型項(xiàng)目周期團(tuán)隊(duì)分布Scru

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

29、間團(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)的問題應(yīng)當(dāng)如何處理.進(jìn)行了什么樣的測試, 結(jié)果是如何記錄的, 通過標(biāo)準(zhǔn)（如覆蓋率、修正的錯誤）是什么.定義“已完成”意味著定義質(zhì)量上的需求.“已完成”是0/1變量：完成或者未完成. 所有的任務(wù)（task)都完成了迭代任務(wù)才算完成.在第一個(gè)迭代開始之前應(yīng)該定義好，因?yàn)樗鼤绊懝ぷ髁? 而且必須文檔化，這樣團(tuán)隊(duì)和產(chǎn)品所有者的理解是一致的.59完成的定義 - Example完成的定義 遵循編碼規(guī)范能在模擬器上演示

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

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