某公司項目管理課程(PPT 74頁).ppt

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

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

3、讀者。 這就是敏捷開發(fā)提倡的“增量迭代、及時交付”的思想。 這種模式能最大程度地不偏離客戶需求的本質(zhì)。 精益制造 消除浪費、關(guān)注流程、建立無間斷流程以快速應(yīng)變 、降低庫存 、一次做對、基于顧客需求的拉動生產(chǎn) 、標(biāo)準(zhǔn)化與工作創(chuàng)新 、尊重員工，給員工授權(quán) 等,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),7,敏捷的歷史,敏捷軟件開發(fā)又稱敏捷開發(fā)， 從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。 2001年初，因觀察到許多的軟件團隊身陷不斷擴大的流程之

4、中的困境，一群業(yè)界專家聚集在一起，勾勒出一些能讓軟件團隊迅速工作，以及響應(yīng)變化的價值觀和原則。他們自稱為Agile Alliance。 之后的七個月里，他們創(chuàng)造具有價值的聲明，也就是敏捷軟件的開發(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,敏捷價值觀之敏捷宣言,9,敏捷開發(fā)的核心思想是：以人為本，適應(yīng)變化。,敏捷價值觀之敏捷宣言-1,個體和交互勝過過程和工具 人是軟件項目獲

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

6、宣言-4,響應(yīng)變化勝過循環(huán)計劃 變化是軟件開發(fā)中存在的現(xiàn)實 計劃必須有足夠的靈活性與可塑性 短期的迭代的計劃比中長期計劃更有效,Jiangsu Microsoft Technology Center,13,敏捷開發(fā)的12個原則,我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。 即使到了開發(fā)的后期，也歡迎改變需求。 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好 。 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。 圍繞被激勵起來的個人來構(gòu)建項目。 在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。,敏捷開發(fā)的1

7、2個原則,工作的軟件是首要的進度度量標(biāo)準(zhǔn)。 敏捷過程提倡平穩(wěn)的開發(fā)節(jié)奏；發(fā)起人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。 簡單化是根本（不做過度設(shè)計和預(yù)測）。 最好的構(gòu)架、需求和設(shè)計出自于自組織的團隊。 每隔一定時間，團隊會在如何才能更有效地工作方面進行反思并對自己的行為進行相應(yīng)調(diào)整。,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),16,什么是敏捷方法？,敏捷方法是一類軟件開發(fā)流程的泛稱； 敏捷方法是相對于傳統(tǒng)的瀑布式軟件過程提出的； 敏捷方

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

9、去達到互動。 假如說需求沒有完全的被了解，或是可能需要完全地改變項目的需求，瀑布式的model是比較不適合的。 敏捷方法 完整地開發(fā)，每少數(shù)幾周或是少數(shù)幾個月里可以測試功能。 強調(diào)在獲得最簡短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價值。 在整個項目的生命周期里，可以持續(xù)的改善、增加未來的功能。,敏捷項目管理VS傳統(tǒng)項目管理,傳統(tǒng)項目管理： 事先對整個項目進行估計、計劃、分析 反對變更; 變更需要重新估計、重新規(guī)劃 嚴(yán)密的合同來減少風(fēng)險, 如果改變需求要走 CR 流程. 項目作為一個“黑盒子” ，對客戶與供應(yīng)商的可視性差. 文檔和計劃驅(qū)動的方法. 軟件交付時間晚, 意識到風(fēng)險的時間晚. WBS,甘

10、特圖,關(guān)鍵路徑分析,敏捷項目管理: 對整個項目做一個粗略的估計,每一次迭代都有詳細的計劃. 鼓勵變化, 客戶價值驅(qū)動開發(fā). 信任和賦予權(quán)力;合約使變更變得簡單，增加價值. 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系 每次迭代都產(chǎn)生可交付的軟件 專注于交付軟件. 第一次迭代就可交付能工作的版本，風(fēng)險發(fā)現(xiàn)的早.,20,敏捷 與CMMI雙劍合璧,CMMI更加關(guān)注于流程，敏捷更加關(guān)注于人 CMMI自頂向下，敏捷自底向上 敏捷并不排斥必要的文檔 敏捷的很多實踐是對CMMI的一種實現(xiàn)，比如sprint計劃會議就是PP的實現(xiàn)，每日例會就是在做PMC 很多CMMI45級的公司也在應(yīng)用敏捷，比如說寶信、華為 項目

11、級的敏捷實踐通過CMMI可以在組織級得以重用,21,eXtreme Programming,XP我們一般稱為極限編程，是最輕量級的開發(fā)流程。 最主要的精神是 在客戶有系統(tǒng)需求時，給予及時滿意的可執(zhí)行程序，所以最適合需求快速變動的項目。 它強調(diào)客戶所要的是 workable的執(zhí)行碼，所以把與撰寫程序無關(guān)的工作降至最低，并要求客戶與開發(fā)人員最好以side-by-side的方式一起工作。 XP的實踐包括： 完整團隊、計劃游戲、客戶測試 簡單設(shè)計、結(jié)對編程、測試驅(qū)動開發(fā) 改進設(shè)計、持續(xù)集成、集體代碼所有權(quán) 編碼標(biāo)準(zhǔn)、隱喻、可持續(xù)的速度,Scrum開發(fā)流程,Jiangsu Microsoft Techn

12、ology Center,23,為什么采用敏捷? 預(yù)期的收益,采用敏捷方法得當(dāng)?shù)脑挘梢裕?更加透明; 隨時跟蹤項目的狀態(tài)和進展情況，及早發(fā)現(xiàn)問題和風(fēng)險 . 快速交付, 每次迭代都能交付可運行的軟件. 最高風(fēng)險和最高優(yōu)先級的需求，最優(yōu)先進行開發(fā). 改善應(yīng)對變更能力, 減少大量的重計劃. 改善項目溝通. 更好的客戶參與, 避免錯誤的假設(shè). 總之: 提高了生產(chǎn)率; 減少“浪費” （不需要的文檔，重復(fù)工作等） ，項目的每次迭代都有明確的目標(biāo). 提高客戶滿意度; 短期內(nèi)產(chǎn)生成效, 按預(yù)期交付軟件, 每次迭代結(jié)束產(chǎn)生可以運行的軟件. 改善員工的滿意度; 團隊精神，減少官僚，能夠規(guī)劃和管理自己的工作，減少

13、“恐慌” ，穩(wěn)定的工作量（可持續(xù)的步伐）.,24,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),25,敏捷關(guān)鍵實踐1增量迭代,每個迭代有一個大約為14周的時間框，在SCRUM里稱為一次沖刺（超過1個月的詳細計劃往往偏差很大） 每次迭代都應(yīng)該有明確的目標(biāo) 每次迭代都應(yīng)該有明確的可演示的工作成果 迭代過程中項目團隊?wèi)?yīng)該盡量免受打擾 迭代可以將項目的壓力分解到每個小的階段，風(fēng)險也能同時分解,26,敏捷關(guān)鍵實踐2測試驅(qū)動開發(fā) TDD,什么是測試驅(qū)動？ 首先創(chuàng)建測試用例，然后開發(fā)軟件通過測試(在開發(fā)代碼前，首先

14、編寫測試代碼) 一種設(shè)計軟件的方法，而不僅僅是一種測試方法 所創(chuàng)建的測試用例用來指導(dǎo)和約束項目中的各項工作，對未來的各項工作提供一個安全的保護 不需要測試的工作不需要完成 所創(chuàng)建的測試用例通常替代詳細的業(yè)務(wù)和技術(shù)需求定 測試也有效地驅(qū)動設(shè)計，使設(shè)計更加趨向于可行的設(shè)計 通常情況下需要自動測試的支持 (EUnit, JUnit etc.). 對于UI軟件應(yīng)用TDD方法有一定的困難,27,敏捷關(guān)鍵實踐3持續(xù)集成,28,極限編程稱為“每日構(gòu)建” 持續(xù)集成一般利用ANT、MAVEN等工具 日構(gòu)建的好處： 將集成風(fēng)險降到最低 降低質(zhì)量風(fēng)險 提升士氣 日構(gòu)建可以看做是項目的心跳，冒煙測試就像是聽診器 日構(gòu)

15、建必須至少：成功編譯、打包、發(fā)布；不含有任何明顯的缺陷；通過冒煙測試,敏捷關(guān)鍵實踐4面對面交流,雖然如今通訊工具花樣繁多，但面對面交流在某些場合下仍然是不可替代的； 敏捷開發(fā)把交流缺失問題考慮在內(nèi)，要求團隊成員彼此直接協(xié)作，盡量創(chuàng)造面對面交流的機會； 尤其當(dāng)業(yè)務(wù)分析師和軟件開發(fā)人員一起工作的時候，面對面的交流是很重要的。 匿名共享需求文檔只會打開曲解和誤解之門，更不用說書面信息比口頭交流還要慢很多。,29,敏捷方法的其它實踐,結(jié)對編程 每日立會 用戶故事 團隊工作室 頻繁發(fā)布 自組織團隊 重構(gòu),30,重構(gòu)改善既有代碼的設(shè)計,Martin Fowler提出 代碼的壞味道 Martin Fowle

16、r和Kent Beck列舉了22種壞味道：冗余代碼、冗長的方法、巨大的類、過多的參數(shù)等等 重構(gòu)可以彌補設(shè)計的不足 簡單設(shè)計的思想 重構(gòu)與測試驅(qū)動的關(guān)系 TDD是重構(gòu)的腳手架 IDE已經(jīng)對主要的重構(gòu)模式提供了自動化支持：Rename, extract method, move field等等 簡單設(shè)計測試用例實現(xiàn)再說（重構(gòu)回歸測試）*,31,Scrum何時更有效？,公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法. 敏捷方法對需求不完整以及經(jīng)常變換的項目比較有效. 項目可以劃分成固定時間間隔的迭代, 并且可以凍結(jié)正在進行的迭代的范圍 公司和客戶都有能力擔(dān)當(dāng)角色尤其是Product Own

17、er 和 Scrum Master. 項目的人員結(jié)構(gòu)能夠分成6到10人的團隊，最好每個工作地點一個小組.（Scrum of Scrums，Scrum的擴展） 團隊成員能夠以自組織的方式工作. 項目的合同允許變更. 固定價格的項目可以使用敏捷，但應(yīng)當(dāng)盡量避免。 最好在按時間和材料付費或者按月付費的項目中進行使用、 變更項目的范圍不需要高級管理層的批準(zhǔn).,32,問題2，為什么SCRUM團隊人員最好在10人以內(nèi)？,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),33,敏捷特別強調(diào)人的因素,相對于過程與工具，敏

18、捷更強調(diào)“人”的因素。 誠信是基礎(chǔ) 沒有過程能夠?qū)φ\信進行有效的約束 誠信與否是有效實施敏捷過程的最大限制,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ù)市場價值確定功能優(yōu)先級。 每個Sprint，根據(jù)需要調(diào)整功能和優(yōu)先級（每個Sprint開始前調(diào)整）。 接受或拒絕接受開發(fā)團隊的工作成果。,37,Scrum角色之ScrumMaster,作為Team Lead

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

20、任何事情已確保達到Sprint的目標(biāo)。 高度的自我組織能力。 向Product Owner演示產(chǎn)品功能。 團隊成員構(gòu)成在sprint內(nèi)不允許變化。,39,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 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的項目過程有一系列的Sprint組成。 Sprint的長度一般控制在2-4周。 通過固定的周期保持良好的節(jié)奏。 產(chǎn)品的設(shè)計、開發(fā)、測試都在Sprint期間完成。 Sprint結(jié)束時交付可以工作的軟件。 在Sprint過程中不允許發(fā)生變更。,42,Scrum框架,43,Scrum儀式之Sprint計劃會議,Jiangsu Micr

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

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

24、審會議,Sprint評審會用來演示在這個Sprint中開發(fā)的產(chǎn)品功能給Product Owner. Product Owner會組織這階段的會議并且邀請相關(guān)的干系人參加。 團隊展示Sprint中完成的功能 一般是通過現(xiàn)場演示的方式展現(xiàn)功能和架構(gòu) 不要太正式 不需要PPT 一般控制在2個小時 團隊成員都要參加 可以邀請所有人參加,Jiangsu Microsoft Technology Center,48,Scrum儀式之Sprint回顧會議,Jiangsu Microsoft Technology Center,49,團隊的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。 一般控制在15-30分鐘

25、 每個Sprint都要做 全體參加 Scrum Master 產(chǎn)品負(fù)責(zé)人 團隊 可能的客戶或其它干系人,Sprint回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚。,Scrum物件之產(chǎn)品訂單(Product Backlog),一個需求的列表。 一般情況使用用戶故事來表示backlog條目 理想情況每個需求項都對產(chǎn)品的客戶或用戶有價值 Backlog條目按照商業(yè)價值排列優(yōu)先級 優(yōu)先級由產(chǎn)品負(fù)責(zé)人來排列 在每個Sprint結(jié)束的時候要更新優(yōu)先級的排列,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: 團隊成員自己挑選任務(wù)，而不是指派任務(wù) 對每一個任務(wù)，每天要更新剩余的工作量估算 每個團隊成員都可以修改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,擴展Scrum,一般情況一個團隊的人數(shù)控制在5-9人 大型項目可以采用多團隊，通過team of teams來擴展Scrum。 影響擴展的因素 團隊規(guī)模 項目類型 項目周期 團

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

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

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

32、他相關(guān)的干系人 Scrum Master 負(fù)責(zé)確定障礙已經(jīng)清除，不一定親自自己清除,62,清除障礙,某些障礙是浪費 部分地完成工作 額外的過程 額外的功能 任務(wù)轉(zhuǎn)換 等待 缺陷,清除障礙的過程是團隊和組織學(xué)習(xí)的過程,63,浪費產(chǎn)生的原因,多問幾個“為什么” 對于每個標(biāo)識的障礙或者浪費，問一問“為什么”浪費會存在 多問幾個“為什么”，找到造成浪費的根本原因,64,目錄,敏捷的背景與動機 敏捷宣言及原則 敏捷方法是什么？ 敏捷方法的實踐 Scrum的角色 Scrum流程和工作產(chǎn)品 Scrum應(yīng)用 總結(jié),65,SCRUM實踐,研發(fā)部2009年開始在幾個項目當(dāng)中進行了SCRUM項目管理的嘗試： 營銷綜合停電系統(tǒng)開發(fā) FLEX-ADP開發(fā) 海頤OA項目 等,海頤軟件,SCRUM看板,海頤軟件,SCRUM燃盡圖,海頤軟件,SCRUM帶來的改善,項目的計劃性更強了，將項目按SPRINT進行分解