1、Scrum敏捷項(xiàng)目管理,2011年2月,目錄,敏捷的背景與動(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)的軟件工程難以滿足這些要求 所以軟件團(tuán)隊(duì)除了在技術(shù)上必須日益精進(jìn)，更需要運(yùn)用有效的開發(fā)流程，以確保團(tuán)隊(duì)能夠發(fā)揮綜效。這正是Agile Process (敏捷的軟件開發(fā)流程)于近年來興起的主要原因。,軟件項(xiàng)目的復(fù)雜性,橫軸代表需求的復(fù)雜度 縱軸表示技術(shù)的復(fù)雜

2、度 還有人力資源的復(fù)雜度,4,解決復(fù)雜性問題需要采用經(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)出來，這樣就形成了與讀者之間的良好反饋，在出版之前就鎖定了大量的

3、讀者。 這就是敏捷開發(fā)提倡的“增量迭代、及時(shí)交付”的思想。 這種模式能最大程度地不偏離客戶需求的本質(zhì)。 精益制造 消除浪費(fèi)、關(guān)注流程、建立無間斷流程以快速應(yīng)變 、降低庫存 、一次做對(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,敏捷的歷史,敏捷軟件開發(fā)又稱敏捷開發(fā)， 從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開發(fā)能力。 2001年初，因觀察到許多的軟件團(tuán)隊(duì)身陷不斷擴(kuò)大的流程之

4、中的困境，一群業(yè)界專家聚集在一起，勾勒出一些能讓軟件團(tuán)隊(duì)迅速工作，以及響應(yīng)變化的價(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ā)的核心思想是：以人為本，適應(yīng)變化。,敏捷價(jià)值觀之敏捷宣言-1,個(gè)體和交互勝過過程和工具 人是軟件項(xiàng)目獲

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

6、宣言-4,響應(yīng)變化勝過循環(huán)計(jì)劃 變化是軟件開發(fā)中存在的現(xiàn)實(shí) 計(jì)劃必須有足夠的靈活性與可塑性 短期的迭代的計(jì)劃比中長(zhǎng)期計(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ā)人員必須天天都在一起工作。 圍繞被激勵(lì)起來的個(gè)人來構(gòu)建項(xiàng)目。 在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對(duì)面的交談。,敏捷開發(fā)的1

7、2個(gè)原則,工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。 敏捷過程提倡平穩(wěn)的開發(fā)節(jié)奏；發(fā)起人、開發(fā)者和用戶應(yīng)該能夠保持一個(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)整。,目錄,敏捷的背景與動(dòng)機(jī) 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),16,什么是敏捷方法？,敏捷方法是一類軟件開發(fā)流程的泛稱； 敏捷方法是相對(duì)于傳統(tǒng)的瀑布式軟件過程提出的； 敏捷方

8、法可以用敏捷宣言（4條）、敏捷原則（12條）來概括； 敏捷原則通過一系列的敏捷實(shí)踐來體現(xiàn)出來； 敏捷方法有很多種。,問題1，請(qǐng)舉出你知道的2個(gè)以上敏捷方法名字來,敏捷的方法,Extreme Programming (XP)極限編程 Scrum Adaptive Software Development (ASD)自適應(yīng)軟件開發(fā) Crystal Clear and Other Crystal Methodologies水晶方法 Dynamic Systems Development Method (DSDM)動(dòng)態(tài)系統(tǒng)開發(fā)方法 等,敏捷方法 VS. 瀑布模型,瀑布模型 固定的、沒有彈性的。 很困難

9、去達(dá)到互動(dòng)。 假如說需求沒有完全的被了解，或是可能需要完全地改變項(xiàng)目的需求，瀑布式的model是比較不適合的。 敏捷方法 完整地開發(fā)，每少數(shù)幾周或是少數(shù)幾個(gè)月里可以測(cè)試功能。 強(qiáng)調(diào)在獲得最簡(jiǎn)短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價(jià)值。 在整個(gè)項(xiàng)目的生命周期里，可以持續(xù)的改善、增加未來的功能。,敏捷項(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è)“黑盒子” ，對(duì)客戶與供應(yīng)商的可視性差. 文檔和計(jì)劃驅(qū)動(dòng)的方法. 軟件交付時(shí)間晚, 意識(shí)到風(fēng)險(xiǎn)的時(shí)間晚. WBS,甘

10、特圖,關(guān)鍵路徑分析,敏捷項(xiàng)目管理: 對(duì)整個(gè)項(xiàng)目做一個(gè)粗略的估計(jì),每一次迭代都有詳細(xì)的計(jì)劃. 鼓勵(lì)變化, 客戶價(jià)值驅(qū)動(dòng)開發(fā). 信任和賦予權(quán)力;合約使變更變得簡(jiǎn)單，增加價(jià)值. 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系 每次迭代都產(chǎ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)用敏捷，比如說寶信、華為 項(xiàng)目

11、級(jí)的敏捷實(shí)踐通過CMMI可以在組織級(jí)得以重用,21,eXtreme Programming,XP我們一般稱為極限編程，是最輕量級(jí)的開發(fā)流程。 最主要的精神是 在客戶有系統(tǒng)需求時(shí)，給予及時(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ù)的速度,Scrum開發(fā)流程,Jiangsu Microsoft Techn

12、ology Center,23,為什么采用敏捷? 預(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ī)劃和管理自己的工作，減少

13、“恐慌” ，穩(wěn)定的工作量（可持續(xù)的步伐）.,24,目錄,敏捷的背景與動(dòng)機(jī) 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),25,敏捷關(guān)鍵實(shí)踐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測(cè)試驅(qū)動(dòng)開發(fā) TDD,什么是測(cè)試驅(qū)動(dòng)？ 首先創(chuàng)建測(cè)試用例，然后開發(fā)軟件通過測(cè)試(在開發(fā)代碼前，首先

14、編寫測(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, JUnit etc.). 對(duì)于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)目的心跳，冒煙測(cè)試就像是聽診器 日構(gòu)

15、建必須至少：成功編譯、打包、發(fā)布；不含有任何明顯的缺陷；通過冒煙測(cè)試,敏捷關(guā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ì)打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。,29,敏捷方法的其它實(shí)踐,結(jié)對(duì)編程 每日立會(huì) 用戶故事 團(tuán)隊(duì)工作室 頻繁發(fā)布 自組織團(tuán)隊(duì) 重構(gòu),30,重構(gòu)改善既有代碼的設(shè)計(jì),Martin Fowler提出 代碼的壞味道 Martin Fowle

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

17、er 和 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)目的范圍不需要高級(jí)管理層的批準(zhǔn).,32,問題2，為什么SCRUM團(tuán)隊(duì)人員最好在10人以內(nèi)？,目錄,敏捷的背景與動(dòng)機(jī) 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),33,敏捷特別強(qiáng)調(diào)人的因素,相對(duì)于過程與工具，敏

18、捷更強(qiáng)調(diào)“人”的因素。 誠信是基礎(chǔ) 沒有過程能夠?qū)φ\信進(jìn)行有效的約束 誠信與否是有效實(shí)施敏捷過程的最大限制,34,Scrum框架,35,海頤軟件,Scrum角色,Scrum角色之Product Owner,產(chǎn)品負(fù)責(zé)人（Product Owner）的職責(zé)如下： 確定產(chǎn)品的功能。 決定發(fā)布的日期和發(fā)布內(nèi)容。 為產(chǎn)品的profitability of the product (ROI)負(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,Scrum角色之ScrumMaster,作為Team Lead

19、er和Product owner緊密地工作在一起，他可以及時(shí)地為團(tuán)隊(duì)成員提供幫助。他必須: 保證團(tuán)隊(duì)資源完全可被利用并且全部是高產(chǎn)出的。 保證各個(gè)角色及職責(zé)的良好協(xié)作。 解決團(tuán)隊(duì)開發(fā)中的障礙。 做為團(tuán)隊(duì)和外部的接口，屏蔽外界對(duì)團(tuán)隊(duì)成員的干擾。 保證開發(fā)過程按計(jì)劃進(jìn)行，組織 Daily Scrum, Sprint Review and Sprint Planning meetings。,38,Scrum角色之Scrum Team,一般情況人數(shù)在5-9個(gè)左右 團(tuán)隊(duì)要跨職能 （包括開發(fā)人員、測(cè)試人員、用戶界面設(shè)計(jì)師等） 團(tuán)隊(duì)成員需要全職。 （有些情況例外，比如數(shù)據(jù)庫管理員） 在項(xiàng)目向?qū)Х秶鷥?nèi)有權(quán)利做

20、任何事情已確保達(dá)到Sprint的目標(biāo)。 高度的自我組織能力。 向Product Owner演示產(chǎn)品功能。 團(tuán)隊(duì)成員構(gòu)成在sprint內(nèi)不允許變化。,39,目錄,敏捷的背景與動(dòng)機(jī) 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),40,Scrum 流程,41,Sprint Planning Meeting: Next Sprint Goal Sprint Backlog Updated Product Backlog,Daily Scrum meetings : What did you do yesterday What wil

21、l you do today? What obstacles are in your way?,Source: ,Daily Scrum,Sprint Retrospective,Shippable Product Increment,Sprints(沖刺),Scrum的項(xiàng)目過程有一系列的Sprint組成。 Sprint的長(zhǎng)度一般控制在2-4周。 通過固定的周期保持良好的節(jié)奏。 產(chǎn)品的設(shè)計(jì)、開發(fā)、測(cè)試都在Sprint期間完成。 Sprint結(jié)束時(shí)交付可以工作的軟件。 在Sprint過程中不允許發(fā)生變更。,42,Scrum框架,43,Scrum儀式之Sprint計(jì)劃會(huì)議,Jiangsu Micr

22、osoft Technology Center,44,Scrum儀式之Sprint計(jì)劃會(huì)議,Jiangsu Microsoft Technology Center,45,Scrum儀式之每日Scrum會(huì)議(Daily Scrum),每日Scrum會(huì)議，即團(tuán)隊(duì)每日例會(huì)，條件允許的話，每天都應(yīng)該在同樣的時(shí)間和地點(diǎn)，組織所有成員站立進(jìn)行。 最好是每天早晨開，一般15分鐘左右，時(shí)間比較短，也有利于團(tuán)隊(duì)成員安排好當(dāng)天的工作。 只有團(tuán)隊(duì)成員可以在例會(huì)上發(fā)言，其他人員有興趣可以參加，但只能旁聽，不能發(fā)言。（小豬和小雞的故事） 每日Scrum會(huì)議由Scrum Master主持， Scrum團(tuán)隊(duì)所有成員輪流回答

23、以下3個(gè)問題： 昨天我完成了什么工作？ 今天我打算做什么？ 我在工作中遇到了什么困難？,Jiangsu Microsoft Technology Center,46,Scrum 任務(wù)板(Task Board),Jiangsu Microsoft Technology Center,47,任務(wù)板（墻）展現(xiàn)了在Sprint過程中所有要完成的任務(wù)。在Sprint過程中我們要不斷的更新它。如果某個(gè)開發(fā)人員想到了一個(gè)任務(wù)他就可以把這個(gè)任務(wù)寫下來放在任務(wù)墻上。 無論每日站會(huì)過程中或者之后，如果估計(jì)發(fā)生了變化，任務(wù)會(huì)根據(jù)變化在任務(wù)墻上做相應(yīng)的調(diào)整。通常的任務(wù)板是下面這個(gè)樣子:,Scrum儀式之Sprint評(píng)

24、審會(huì)議,Sprint評(píng)審會(huì)用來演示在這個(gè)Sprint中開發(fā)的產(chǎn)品功能給Product Owner. Product Owner會(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)所有人參加,Jiangsu Microsoft Technology Center,48,Scrum儀式之Sprint回顧會(huì)議,Jiangsu Microsoft Technology Center,49,團(tuán)隊(duì)的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。 一般控制在15-30分鐘

25、 每個(gè)Sprint都要做 全體參加 Scrum Master 產(chǎn)品負(fù)責(zé)人 團(tuán)隊(duì) 可能的客戶或其它干系人,Sprint回顧會(huì)議上，全體成員討論有哪些好的做法可以啟動(dòng)，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚(yáng)。,Scrum物件之產(chǎn)品訂單(Product Backlog),一個(gè)需求的列表。 一般情況使用用戶故事來表示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í)的排列,Jiangsu Microsoft Technology Center,50,Scrum物件

26、之產(chǎn)品訂單(Product Backlog),Jiangsu Microsoft Technology Center,51,Scrum物件之沖刺訂單(Sprint Backlog),Jiangsu Microsoft Technology Center,52,Sprint Backlog 示例,53,Persons working on the task,Description of the task,Effort estimate,Task blocked by an impediment,Sprint goal,Meets the definition of done,Scrum物件之沖刺

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

28、,Tasks removed from the Sprint Backlog to meet Sprint 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 the Sprint,擴(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)

29、隊(duì)分布 Scrum曾被用于超過1000人團(tuán)隊(duì)規(guī)模的項(xiàng)目。,Jiangsu Microsoft Technology Center,56,Scrum Of Scrums,Jiangsu Microsoft Technology Center,57,Scrum項(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)前階段沒有足夠的信息. 規(guī)模的相對(duì)值才有意義. 這個(gè)估計(jì)值有助于確定優(yōu)先級(jí); 可

30、以采用估算撲克,58,所需時(shí)間,團(tuán)隊(duì)速度,產(chǎn)品規(guī)模,完成的定義,當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時(shí)，變?yōu)椤耙淹瓿伞睜顟B(tài) 定義“已完成”的含義是非常重要的, 例如: 如何記錄軟件的變化. 使用什么樣的代碼分析工具 ，發(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,完成的定義 - Example,完

31、成的定義 遵循編碼規(guī)范 能在模擬器上演示 使用PCLint 進(jìn)行靜態(tài)代碼分析 具有EUnit 測(cè)試套件的通過率 和執(zhí)行率. 或者使用結(jié)對(duì)編程，或者進(jìn)行代碼走查,60,障礙,基本上，任何阻止團(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)障礙，Scrum Master要以列表形式進(jìn)行記錄，,61,誰來清除障礙？,每個(gè)人 自我管理、自我組織的團(tuán)隊(duì) Scrum Master 產(chǎn)品所有者 管理層 其

32、他相關(guān)的干系人 Scrum Master 負(fù)責(zé)確定障礙已經(jīng)清除，不一定親自自己清除,62,清除障礙,某些障礙是浪費(fèi) 部分地完成工作 額外的過程 額外的功能 任務(wù)轉(zhuǎn)換 等待 缺陷,清除障礙的過程是團(tuán)隊(duì)和組織學(xué)習(xí)的過程,63,浪費(fèi)產(chǎn)生的原因,多問幾個(gè)“為什么” 對(duì)于每個(gè)標(biāo)識(shí)的障礙或者浪費(fèi)，問一問“為什么”浪費(fèi)會(huì)存在 多問幾個(gè)“為什么”，找到造成浪費(fèi)的根本原因,64,目錄,敏捷的背景與動(dòng)機(jī) 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實(shí)踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),65,SCRUM實(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)行分解