Scrum敏捷軟件開發過程1精選ppt目錄什么是敏捷軟件開發？敏捷方法的工程方案敏捷工程管理和傳統工程管理為什么使用敏捷？Scrum概述Scrum的角色Scrum實踐和工作產品敏捷開發中的估計方法測試驅動開發Scrum應用支持工具和模版一些常見的誤解2精選ppt敏捷開發方法什么是敏捷軟件開發?敏捷軟件開發是軟件工程的一個概念框架.有許多建立在敏捷概念上的方法，如Scrum和ExtremeProgramming(XP).與僵化的、重量級的、官僚式的方法形成對照，比方瀑布模型〔指純粹形式的〕最大限度地降低短期固定時間的迭代式軟件的開發風險.4精選ppt敏捷宣言〔2001年〕人和交互勝過過程和工具.Individualsandinteractionsoverprocessesandtools可以工作的軟件勝過完備的文檔.Workingsoftwareovercomprehensivedocuments客戶協作勝過合同談判.Customercollaborationovercontractnegotiation隨時應對變化勝過遵循方案.Respondingtochangeoverfollowingaplan5精選ppt敏捷過程的限制敏捷軟件開發過程包含過程、原那么、工具，和最重要的-人因此誠信是根底沒有過程能夠對誠信進行有效地約束誠信與否是有效實施敏捷過程的最大限制6精選ppt使用敏捷方法的工程方案ProductBacklog(Features)5213858∑32InitialSizeEstimatesAsStoryPointsLongtermplanning(bestguessatthemoment):32SPoffunctionality,TeamVelocity8SP/Sprint4SprintsTargetSprintforeachPBLitemset,feasibleimplementationOrder.SprintBacklog(Tasks)85831“Sprintful〞oftop-priorityPBLtothenextSprintMoreaccurateestimatesasmanhoursShorttermplanning(commitmentbyTeam):MaybeconstantlyupdatedScopefrozennewPBLitemstonextSprint7精選ppt敏捷工程管理和傳統工程管理傳統工程管理：事先對整個工程進行估計、方案、分析反對變更;變更需要重新估計、重新規劃嚴密的合同來減少風險,如果改變需求要走CR流程.工程作為一個“黑盒子〞，對客戶與供給商的可視性差.產品化和測試階段是別離的.文檔和方案驅動的方法.軟件交付時間晚,意識到風險的時間晚.敏捷工程管理:對整個工程做一個粗略的估計,每一次迭代都有詳細的方案.鼓勵變化,客戶價值驅動開發.信任和賦予權力;合約使變更變得簡單，增加價值.客戶和開發人員之間是緊密的連續的合作關系每次迭代都產生可交付的軟件專注于交付軟件.第一次迭代就可交付能工作的版本，風險發現的早.8精選ppt為什么采用敏捷?–預期的收益采用敏捷方法得當的話，可以：更加透明;隨時跟蹤工程的狀態和進展情況，及早發現問題和風險.快速交付,每次迭代都能交付可運行的軟件.最高風險和最高優先級的需求，最優先進行開發.改善應對變更能力,減少大量的重方案.改善工程溝通.更好的客戶參與,防止錯誤的假設.總之:提高了生產率;減少“浪費〞〔不需要的文檔，重復工作等〕，工程的每次迭代都有明確的目標.提高客戶滿意度;短期內產生成效,按預期交付軟件,每次迭代結束產生可以運行的軟件.改善員工的滿意度;團隊精神，減少官僚，能夠規劃和管理自己的工作，減少“恐慌〞，穩定的工作量〔可持續的步伐〕.9精選ppt敏捷方法何時有效？公司和客戶一致認為應當使用敏捷方法，雙方都能理解敏捷方法.敏捷方法對需求不完整以及經常變換的工程比較有效.工程可以劃分成固定時間間隔的迭代,并且可以凍結正在進行的迭代的范圍公司和客戶都有能力擔當角色尤其是ProductOwner和ScrumMaster.工程的人員結構能夠分成6到10人的團隊，最好每個工作地點一個小組.團隊成員能夠以自組織的方式工作.工程的合同允許變更.固定價格的工程可以使用敏捷，但應當盡量防止。最好在按時間和材料付費或者按月付費的工程中進行使用、變更工程的范圍不需要高級管理層的批準.10精選ppt警告！??！敏捷開發過程是一個艱苦的過程AgileWorkisHardWork這種狀態也許會存在很長時間！！不舒服疑惑有挫折感11精選pptScrum概述Scrum概述(1/3)Scrum是管理軟件工程的一個輕量級的敏捷方法,名字來源于橄欖球運動中的scrum過程簡單，但高度的紀律性依賴迭代和增量的敏捷方法.Scrum是一種工作管理的方法，不僅僅限于軟件開發，可以用來管理其它活動.Scrum不包含技術方法或實踐.13精選pptScrum概述(2/3)–工程的階段工程分成增量的迭代過程，在Scrum中稱為迭代任務清單,通常持續2-4周的時間.Sprint的時間是限定好的;不能從外部改變正在進行中的sprint持續時間和范圍.每個sprint都可以產生可交付的迭代,即測試過并具備文檔的的功能點原那么上,當產品開發到一定程度時，如實現了足夠的客戶價值，工程可以在任何一個sprint后結束,.如同任何工程，敏捷的工程有三個主要階段:產品定義(規劃);運行Sprints所需要的準備、規劃、技術分析.執行Sprints(執行):在增量時間段內實現需求(產品需求清單).結束:準備最終發布，結束工程14精選pptScrum概述(3/3)SprintPlanningMeeting:NextSprintGoalSprintBacklogUpdatedProductBacklogDailyScrummeetings:WhatdidyoudoyesterdayWhatwillyoudotoday?Whatobstaclesareinyourway?Source:://amdika/scrum_primer_1_0.pdfDailyScrumSprintRetrospectiveShippableProductIncrement15精選pptScrum角色、實踐和工作產品Scrum中的三種角色ProductOwner-產品所有者個人：代表所有的干系人ScrumMaster:個人：負責指導過程的執行ScrumTeam–Scrum團隊:承諾完成工作，向干系人交付產品價值17精選pptScrum角色–Scrum團隊Scrum團隊是Scrum的中心角色，產品交付要依靠團隊.Scrum團隊自我組織、自我管理Scrum團隊是職能交叉的，包含產品交付的所有角色:開發人員、測試人員、buildmanagers,文檔編寫,界面設計人員.Scrum團隊中的角色是不分等級的;不應當出現“我是開發人員我不作測試〞.團隊按照最有利于工程的原那么來分擔責任(如組件的所有權等).敏捷是建立在信任和授權的根底上，因此團隊是自發組織的，組員選擇自己的任務，而不是別人強制加以分配的.另一方面，Scrum團隊有交付的責任，他們需要能夠自我鼓勵和對工作目標進行承諾.團隊最正確規模：6-10人18精選pptScrum角色–Scrum團隊主要職責參與迭代任務清單的創立執行為干系人創造價值的工作根據團隊的承諾完成所需的各項任務將工作中的各項障礙迅速與ScrumMaster進行溝通全面參與所有的各項會議更新任務狀態自發選擇任務標識任務的完成標識發現的新的任務與其它團隊共同進行工作19精選pptScrum角色–ScrumMasterScrumMaster不是一個管理者，而是一個教練和推動者-Scrum團隊是一種自發的組織，是自我管理的.ScrumMaster的角色通常由工程組的成員擔當，組長或者工程經理。ScrumMaster應當是工程中的成員.主要職責:評價過程的健康狀況加強過程消除障礙促進過程改進支持團隊開發ScrumMaster的主要工作是做決策、消除障礙，保證團隊能順利交付產品20精選pptScrum角色–ScrumMasterScrumMaster還有如下責任與其它角色配合.訓練團隊，提高生產率.培訓產品所有者和干系人，確保Scrum流程的執行確保一切工作按照既定的標準來運行.規劃并進行必要的改進.推動會議的召開.維護障礙列表維護Scrum過程改進列表優秀的ScrumMaster應當是專注的,、有決心的、有領導才能.21精選pptScrum角色–ProductOwner產品所有者代表投資方的利益，確保交付的產品與期望的一致〔提供更好的投資回報).ProductOwner決定產品具有哪些功能.ProductOwner’s的主要責任是創立和維護產品需求清單,即管理工程的范圍.ProductOwner不斷的把產品需求清單按優先級進行排序，使得最重要的功能能優先實現.對于團隊來說，只有一個需求集。所有的需求申請都歸口到ProductOwner管理商業價值〔投資回報〕ProductOwner還有如下責任:方案工程的發布，什么時間、向什么人等.對每次Sprint的結果進行評審和批準22精選pptScrum角色–ProductOwner參與Scrum會議迭代方案會議團隊進展跟蹤會議迭代評審和回憶會議能夠隨時答復團隊工作中產生的各項和產品/業務相關的問題ProductOwner的角色一般由客戶擔當，作為效勞提供商的公司無法設定優先級.23精選pptScrum角色–客戶與管理層客戶和管理的角色是可選的，需要時才設立客戶:是產品的最終用戶通過ProductOwner來設定對產品的期望把當前的業務傳達給工程.管理層:公司高級管理層,代表公司在工程中的利益.通過ProductOwner來傳達公司的利益和優先級〔priorities〕24精選ppt產品需求清單ProductBacklog(1/4)–概論根本上，產品需求清單是為了實現產品的功能所需要的工作的列表，包括:功能方面的需求;功能點.非功能方面的需求,如性能改進.要修改的Bug;上一版本的錯誤.新技術,如支持新的操作系統或者平臺.問題;日后的不確定項,如新的功能.產品需求清單是不斷完善的.ProductOwner在工程進行過程中可以隨時更新：增加、刪除、修改功能，變更優先級等.下一次迭代中要包含較高優先級的需求.產品需求清單也可稱為UserStories(用例)，因為它們能夠給產品的用戶帶來價值.在一次迭代中要能夠實現產品需求清單，如果不能全部實現要進行分解.25精選ppt產品需求清單(2/4)–構成ProductOwner負責創立最初的產品需求清單，一開始是不完整的.最初的清單應當包含足夠的需求.清單應當包含多少需求,取決于定價模型(black-box,更多的方案時間).產品需求清單來源于:客戶;標書,需求規格說明等.Scrum團隊的想法;增強型新功能等.現有產品的迭代增量;錯誤,技術問題等.比較好的做法是ProductOwner、Scrum團隊、客戶/管理以及其它相關方〔如相關的Scrum團隊〕舉行一次或者屢次研討會ScrumMaster或者ProductOwner來促成會議的召開，必須要有人來做.要有效率、要圍繞主題、溝通良好、防止不同的假設，承諾并且共通合作，確定優先級.26精選ppt產品需求清單(3/4)–估計Scrum團隊對產品需求清單的每一項的規模提供初步的估計，通常采用事件點作為單位StoryPoints(模糊的).也可采用人天或者人小時作為單位，但容易混淆：a)實際的規模b)時間的單位.精確的估計值可以在Sprint規劃時給出,當前階段沒有足夠的信息.規模的相對值才有意義.這個估計值有助于確定優先級;所需時間團隊速度產品規模27精選ppt產品需求清單(4/4)–優先級優先級是產品需求清單中的主要問題.優先級不但反映了客戶的價值也反映了風險.產品所有者-PO設定優先級.清單中的每一項的優先級是唯一的,但可以對它們進行分類優先級可以在工程的任何時候進行更改;如新的重要的功能可以直接給較高的優先級.確定優先級考慮：價值風險依賴關系28精選ppt產品需求清單–例如PriorityID,likeinanyrequirementsdocumentDescriptionoftheitem=UserStoryThesewilllikelyendupinthefirstSprint29精選ppt版本發布方案在Scrum中,不是每個Sprints都要發布一個版本.迭代的結果主要是要實現功能的演示,不一定就是發布的版本.版本發布方案決定了每次迭代應當包含產品需求清單的哪些功能.根據現有的信息制定的工程總體的長期的方案.根據產品需求清單和團隊的進度來決定(實施的范圍/迭代,e.g.inStoryPoints).Scrum團隊參與版本發布方案的制定;架構、風險、依賴性決定了可行的實現順序.版本發布方案很大程度上依賴于客戶的時間表和發布周期，即什么時候客戶的產品需要包含我們的模塊〔交付物〕.版本發布方案不是一成不變的;每個迭代結束后都可以更改.30精選ppt完成的定義當迭代任務清單上的任務都完成時，變為“已完成〞狀態定義“已完成〞的含義是非常重要的,例如:如何記錄軟件的變化.使用什么樣的代碼分析工具，發現的問題應當如何處理.進行了什么樣的測試,結果是如何記錄的,通過標準〔如覆蓋率、修正的錯誤〕是什么.定義“已完成〞意味著定義質量上的需求.“已完成〞是0/1變量：完成或者未完成.所有的任務〔task)都完成了迭代任務才算完成.在第一個迭代開始之前應該定義好，因為它會影響工作量,而且必須文檔化，這樣團隊和產品所有者的理解是一致的.31精選ppt完成的定義 完成的范圍隨著團隊的成熟程度會逐漸發生變化計劃分析架構設計開發測試性能指標驗收試運行代碼評審支持文檔集成用戶文檔潛在的可交付的軟件32精選ppt完成的定義-Example完成的定義遵循編碼標準能在模擬器上演示使用PCLint進行靜態代碼分析具有EUnit測試套件的通過率和執行率.或者使用結對編程，或者進行代碼走查33精選ppt迭代任務清單規劃(1/5)–總論迭代任務清單規劃的主要目的是從產品任務清單中挑選高優先級的任務包含在下一次迭代中，即確定迭代的范圍.至于能夠包含多少產品任務清單中的任務取決于Scum團隊能夠承諾完成多少.承諾總是來自于內部，不能從外部強加.迭代不應當有空閑時間,因此規劃迭代范圍時要保證工作量是穩定的(進度是持續的速度).依賴多個因素;團隊的能力,技術的成熟度,當前迭代增量的情況等.迭代的范圍在迭代任務清單中描述;團隊設定優先級.產品所有者PO定義每個迭代的任務說明〔missionstatement〕，目標(sprintgoal)，使迭代更具有針對性，如.“實現一個可擴展的列表控件，其工程是可以選擇的〞34精選pptSprint迭代方案(2/5)–輸入和輸出SprintPlanningMeetingProductBacklogTeamCapabilitiesBusinessConditionsTechnologyCurrentProductSprintBacklogProductOwnerScrumTeamManagementCustomersSprintGoal35精選ppt迭代任務清單規劃(3/5)–邏輯迭代任務清單規劃是“鐵三角〞法那么的另一個例子在Scrum,邊界是一個變量，因為:資源(Scrum團隊)是確定的.進度表〔迭代的時間〕是不能變的.質量是無法協商的團隊在一個迭代內能完成的任務，可以用團隊進度來衡量(StoryPoints/Sprint).如果可能的話利用同一個團隊上個迭代的進度,“yesterday’sweather〞.30-daysprint20workdays1dayforplanning,1forreview/retrospective=18workdays5personsinteam90theoreticalmandays7.5-hourworkingday,average85%toprojectwork90*7.5*0.85=574manhours5%reservedforre-estimationandre-planning545manhours36精選ppt迭代任務清單規劃(4/5)–規劃會議召開迭代任務清單規劃會議的目的是確定迭代的邊界.時間是限定的,最長時間是一個工作日(對持續4個星期的迭代,迭代持續的時間越短，用在規劃上的時間也應該越少.由ScrumMaster推動會議.由于會議時間有限，ProductOwner和Scrum團隊都應該事前進行準備.前提:產品需求清單是有效的〔valid〕;最新的,標注了優先級并且表述清楚.規劃會議要解決兩個問題:下次迭代要做什么.確定迭代的目標，包含產品需求清單上高優先級的功能.給Bug修改留一定的余地怎么樣實現下次增量所需要的功能.改進設計以實現產品需求清單上的功能.37精選ppt迭代任務清單規劃(5/5)–工作流程產品所有者向團隊介紹起草的產品需求清單和迭代目標.產品所有者傳達迭代的起止日期.Scrum團隊從產品需求清單中選取高優先級的功能作為迭代的任務，如果有必要，更新其規模估計.Scrum團隊改進架構和設計以便能夠實現提出的產品需求.Scrum團隊把產品需求清單的每一項劃分成小的任務，并估算每個任務要花費的小時數.“撲克規劃〞方法是估算工作量的有效方法.Scrum團隊決定一個迭代中能夠實現產品需求清單的多少功能產品所有者和Scrum團隊明確了各自要承擔的義務.38精選pptSprintBacklog例如PersonsworkingonthetaskDescriptionofthetaskEffortestimateTaskblockedbyanimpedimentSprintgoalMeetsthedefinitionofdone39精選ppt執行迭代任務清單執行迭代任務清單意味著團隊在迭代期間自行開發.團隊清楚要到達什么的目標以及怎樣到達目標.每人每一時間只有一個任務團隊是自發組織的；成員自己挑選任務,ScrumMaster提供指導并去除障礙.不能從外部改變迭代的范圍或者迭代的周期.為了到達迭代的目標，團隊可以增加、刪除任務或者改變其優先次序.如果要重新設定迭代的范圍時需要產品所有者的配合.迭代周期短，意味著工期緊;應該把重點放在剩余的工作和風險的消除，要區分任務的優先級，重要的事情應領先做.迭代應當到達工程的質量要求(definitionof“done〞);沒有獨立的測試階段.40精選ppt迭代進度圖-BurndownChartScrum注重成果，它關心的是要花多少時間到達目標，而不是已經花費的時間;.團隊能否在既定的時間到達迭代的目標,可以查看要完成產品需求清單的功能所剩余的工作Remainingwork=EstimatetoComplete(ETC).描述剩余工作量和時間關系的圖表稱為SprintBurndown圖,是Scrum中非常重要的控制方法(controlmeasure).給Scrum團隊和產品所有者提供直觀的信息.術語burndown說明Scrum團隊在迭代過程中消耗剩余工作的能力;迭代結束時其值為0.每個任務〔task〕的工作量由Scrum團隊來估計.每天都要進行估計，以便進行跟蹤.可以使用電子表格或者專門的工具〔如ScrumWorks〕41精選ppt迭代進度圖-BurndownChartIdealburndown.Actualburndown.Remainingworkincreasing

Tasksunderestimatedand/orworkremainingnotupdated.TasksremovedfromtheSprintBacklogtomeetSprintGoalfasterdecline.Sumofremainingwork[h]foralltasksintheSprintBacklogonaparticularday.Initialestimate(752h)InthebeginningoftheSprint42精選ppt迭代進度圖-BurndownChart43精選pptScrum每日例會(1/4)–小雞和豬的故事Achickenandapigaretogetherwhenthechickensays,"Let'sstartarestaurant!“Thepigthinksitoverandsays,"Whatwouldwecallthisrestaurant?“Thechickensays,"Hamn'Eggs!“Thepigsays,"Nothanks.I'dbecommitted,butyou'donlybeinvolved!“InaDailySprint,onlyScrumMasterandScrumTeamarecommitted,andthusallowedtospeak.Othersareonlyinvolved.44精選pptScrum每日例會(2/4)–概述例會最長15分鐘，在整個迭代過程中每天的同一時間召開.團隊成員之間交流信息.了解工程的真實的進展情況交流風險和存在的問題.面對面的會議加強了承諾.ScrumMaster負責整個會議(會議地點,邀請等).其他人可以參與,但只允許ScrumMaster和Scrum團隊成員講話(小雞和豬).例會之前團隊要更新工作量估計，使進度表保持最新.45精選pptScrum每日例會(3/4)–形式為使會議簡短而富有成效，要遵循嚴格的規程每個成員向其他人匯報以下內容:上次會議以后所做的工作?下次會議之前要做的工作?工作中是否有什么障礙?如果出現其它的問題〔如設計的問題〕，應當在會議后處理.紀錄會議紀要，例如wiki.要養成良好的會議習慣46精選pptScrum每日例會(4/4)47精選ppt障礙根本上，任何阻止團隊正常工作的，都可稱之為障礙，例如:無法訪問信息系統.所需要的信息不能及時提供或者提供的不正確，如界面規格或者其它軟件模塊不到位或不正確開發環境或者原型系統出現問題其他的任務分配：培訓，售前支持缺乏必要的信息或者相應的知識對于團隊提出的各項障礙，ScrumMaster要以列表形式進行記錄，48精選ppt誰來去除障礙？每個人自我管理、自我組織的團隊ScrumMaster產品所有者管理層其他相關的干系人ScrumMaster負責確定障礙已經去除，不一定親自自己去除49精選ppt去除障礙某些障礙是浪費局部地完成工作額外的過程額外的功能任務轉換等待缺陷去除障礙的過程是團隊和組織學習的過程50精選ppt浪費產生的原因多問幾個“為什么〞對于每個標識的障礙或者浪費，問一問“為什么〞浪費會存在多問幾個“為什么〞，找到造成浪費的根本原因51精選ppt迭代中的同步工作每次迭代不是小的瀑布工程而是，每件事情同時都做一點52精選ppt迭代的非正常終止在Scrum中，結束正在進行的迭代是一種極端的行為，只有在萬不得以的情況下才能這么做.有時候確實需要停下來重新規劃，而不是一味的蠻干(bangingyourheadagainstthewall).迭代終止可能由下面的人發起:Scrum團隊,如果他們認為達不到目標或者目標不清楚.ScrumMaster,如果迭代沒有進展,或者無法克服某個困難.客戶/管理層,如果目標已經陳舊/過時(目標產品被取消，平臺過時)，或者其它的原因(資源問題等).迭代終止以后,啟動新迭代的方案.導致迭代終止的原因不應該在新的迭代中再次出現.要考慮到合同方面的問題，如時間表的變更等.53精選ppt迭代評審–概述迭代評審，在迭代結束后進行，展示迭代的成果(功能運行).確保成果與預期的一致，收集反響為工程提供一個參考點，根據目前的位置方案下一期的旅程為下次迭代提供輸入〔改正、修改、新的想法可以由產品所有者添加到產品需求清單.與其它Scrum會議一樣,ScrumMaster主持迭代評審會議,Scrum團隊負責演示.參加會議的其他人包括:產品所有者ProductOwner(必須參加)、客戶、管理人員,以及其它感興趣的人,例如其他Scrum團隊(注意保密協議的要求).評審會議的時間是固定的:最長4個小時.評審會議應當是非正式的、創造性的，不用幻燈片等正式的東西.54精選ppt迭代評審–流程在評審會議召開之前，團隊要做好準備:有組織、有效地進行演示，不要超過4個小時.誰來演示，演示什么，怎樣演示?方案準備的時間不要超過一個小時.迭代評審流程的一個例子:ScrumMaster介紹本次迭代的總體情況.目標和清單vs.實際的結果,如果存在差距，原因是什么.Scrum團隊簡要介紹所涉及的技術問題，如架構及其變更.Scrum團隊演示已經實現的功能:演示并進行功能說明在場的人能夠親自嘗試使用不同的功能.ScrumMaster推動自由討論，集思廣益.迭代評審應當是互動的;有問題提出,問題解答，并歡送提出想法和建議.55精選ppt迭代評審–可能的措施產品所有者根據評審的結果可能采取如下行動:更新產品需求清單，重新設定優先級:包含沒有按方案實現的功能(進度比預期的要慢,任務未完成).不在方案中當卻已經實現的功能(進度比預期的快).迭代評審中出現的新的想法.與ScrumMaster一起解決團隊的變動問題.要求把演示的功能，或者把上次迭代的功能，作為一個版本發布給客戶.決定工程不再持續下去，不再進行迭代;認為產品已完備.要求把產品需求清單授權給另外的團隊來一起工作.……56精選ppt迭代回憶會議SprintRetrospective回憶的目的是評價本次迭代并醞釀改進，使得下一個迭代進行的更好.類似于工程的最終評審，但經常舉行.障礙列表具有很好的參考價值!ScrumMaster主持召開,持續半天,Scrum團隊參加(產品所有者也可參加).簡單流程:ScrumMaster總結本次迭代;迭代任務清單,重要的事情和決策,預期的/實際進度.每個組員陳述迭代中那些方法進行的較好、哪些需要改進,ScrumMaster進行記錄.對重要的問題方案相應的措施：團隊自己解決,或者提交給公司的管理層.57精選pptScrum方法應用敏捷開發中使用撲克Poker方法進行估計(1/3)盡管名字有好笑,但卻非常可靠和有效.可以來估算產品需求清單中每項的規?！惨幠９浪?用例點storypoint〕以及迭代任務清單中任務的估計(工作量估算：人時).ScrumMaster推動活動的進行,一個以上的專家參與估算,而且最好是工程團隊中的人.估算時使用卡片：寫有一系列的離散數據，如0,1,2,3,5,8,13,?(無法估計).59精選ppt敏捷開發中使用撲克Poker方法進行估計(2/3)前提條件:提前準備好要估算的任務、UserStories等;迭代任務清單和產品需求清單都已經起草好.對某個任務最有經驗的開發者做一個簡短的概述.可以通過簡短的討論澄清任務的具體含義，找出存在的風險以及不確定性.各自對任務進行估計，所有的人將寫有各自估計數據的撲克/卡片扣上。(單位事先進行約定：工時、事件點).大家同時把撲克/卡片翻過來.如果撲克/卡片上的數差距比較明顯(如一個13，2個5，一個1),就要討論一下為什么會出現這么大的差距，估計值所基于的假定要進行澄清.如果差距較小(如三個8兩個5)，主持人幫助確定最終的估值.對于不確定性，估算數據中可以多包含一些余量.不斷的重復該過程直到達成一致.將這些估值記錄到相應的文檔中(產品需求清單,迭代任務清單).60精選ppt敏捷開發中使用撲克Poker方法進行估計(3/3)為什么使用離散的數字?比使用任意數字更加容易進行估算.在整個工程中或者迭代中,每個人估計值的錯誤會相互抵消掉.對每個任務,16小時是上限,不確定性會隨著規模的增加而增加.為什么要有“?〞.將較大的任務進行分解，幫助更加精確的估計同時減少不確定性.為什么要“討論并重復〞?弄清不同的假設(利用重用代碼或者重新編碼)和可能的誤解更為可靠的估計.對于那些偏離平均值的估計，即使由有經驗的人給出的，也必須要有充分的理由.61精選ppt練習在一個小時之內編寫一個三只小豬的連環畫冊使用Scrum實踐自組織團隊迭代每日Scrum會議產品需求清單迭代任務清單62精選ppt練習-進度安排5分鐘:迭代目標團隊與產品所有者共同協作，從產品需求列表中選擇本次迭代要完成的工程5分鐘:迭代任務清單團隊從所選擇的產品需求列表中產生任務10分鐘:第一天團隊完成任務和產品需求列表中的工程產品所有者負責答復以下問題5分鐘:“每日〞“Scrum會議每個人答復三個問題10分鐘:第二天團隊繼續完成任務和產品需求列表中的工程產品所有者負責答復以下問題5分鐘:“每日〞“Scrum會議每個人答復三個問題10分鐘:第三天團隊完成產品的一個版本產品所有者負責答復以下問題每組5分鐘:演示團隊向產品所有者展示完成的連環畫冊63精選ppt練習–給出優先級的產品需求清單展示根本的故事用鉛筆畫展示的故事每頁圖畫配有說明給出寫有標題的封面故事用9頁進行說明展示版權信息添加色彩廣告教小孩數數1，2，3寓教于樂：鞏固的重要性封皮吸引人硬的封皮3D效果的卡通形象展示所有的故事內容產品所有者-ProductOwner充分考慮市場情況，對產品進行規劃并進行簡要地說明規劃當前該產品如何占有更多的市場份額規劃今后該產品的開展前景Scrum團隊根據產品所有者的產品規劃進行開發64精選ppt測試驅動開發TestDrivenDevelopment什么是測試驅動？一種能夠支持Scrum的敏捷實踐方法，開發滿足DoD的軟件首先創立測試用例，然后開發軟件通過測試(在開發代碼前，首先編寫測試代碼)一種設計軟件的方法，而不僅僅是一種測試方法所創立的測試用例用來指導和約束工程中的各項工作，對未來的各項工作提供一個平安的保護不需要測試的工作不需要完成所創立的測試用例通常替代詳細的業務和技術需求定測試也有效地驅動設計，使設計更加趨向于可行的設計通常情況下需要自動測試的支持(EUnit,JUnitetc.).對于UI軟件應用TDD方法有一定的困難65精選ppt測試驅動開發–TDD測試用例的作用：確定所要完成的工作溝通工具產生一致的結果對軟件開發提供一個平安的保障66精選pptScrum的核心反響檢查接受結對編程單體測試階段發布每日Scrum會議迭代演示67精選ppt應用(1/4)–概述根本原那么:不能只挑自己喜歡的，不管其它的Scrum非常簡單，為了有效地發揮作用，應當具備:所有的角色.所有的實踐.所有的產品.Scrum可以進行裁剪,但應當明白裁剪對工程的影響需要經驗和仔細考慮.68精選ppt應用(2/4)–大型/跨地域工程6到10人在同一房間進行工作時，Scrum能夠發揮最大效用.Scrum也可應用在大型的跨地域的工程.一些指導原那么:將大的工程分成多個團隊，每個團隊6到10人，有各自的ScrumMaster.對跨地域的工程，盡量不要把一個Scrum團隊分到多個地方，一個Scrum團隊就在一個地方，有自己的ScrumMaster.但是，如果團隊的跨地域是不可防止的，可以使用網絡工具遠程召開Scrum例會.劃分團隊時，團隊之間應該有一個“自然界面〞，如為防止混亂，不同的團隊負責產品的不同局部.對于整個工程/產品：一個產品/工程只能有一個產品所有者和產品需求清單.團隊之間的協調利用ScrumofScrums方法69精選ppt應用(3/4)-ScrumofScrumsScrumTeam6-10personsScrumTeam6-10personsScrumTeam6-10personsScrumofScrums“ScrumonTeamLevel〞1-3times/week,orondemandEachteamrepresentedbydedicatedpersons(onlyoneifnoissuestoescalate)ProjectdividedtoScrumteamsbasedonprojectsizeorgeographicallocationScrumTeamshaveDailyScrummeetings,ScrumofScrumscanbeheldlessfrequently.Teleandvideoconferencingutilizedasneeded.70精選ppt應用(4/4)–固定價格的工程Scrum不鼓勵固定價格的工程每次迭代時進行工程預算,產品需求清單可以根據當前的優先級進行調整.某些工程中,客戶需要我們對整個工程給一個報價或者預算.價格固定限制了靈活性(對變化的響應):如果價格和進度是固定的，那么整個工程的范圍也是固定的(PB).必須對工程所有的迭代都進行詳細的方案和規模估計.變更工程的范圍，以及隨之而來的預算/進度的變更需要提交CR.當然可以改變產品需求清單的優先級，或者不改變工作量前提下把其中的某一項換成另一項.仍然可以使用Scrum，并從中獲益71精選ppt支持工具和模版TasksnotstartedTasksinprogressTaskscompleted(done)PrioritySprintGoalSprintBurndownChartTasks:DescriptionResponsiblepersonWorkremaining72精選ppt一些常見的誤解敏捷是拯救任何工程的銀彈.敏捷方法只有運用得當才有效果.敏捷意味著ad-hochacking，不需要任何文檔.敏捷是有嚴格要求的，也是面向質量的根據溝通的需要產生相應的文檔.敏捷只是開發者的問題根本的開發方法與傳統相比有顯著不同,影響工程的各個方面:合同,角色,定價模型,工程管理等.采用敏捷方法的開發組/工程不需要制定方案敏捷工程需要經常制定方案，但是不需要試圖超前制定工程方案，通常這也是不可能的.敏捷工程的范圍可以隨時改變.變更可以等到下一次迭代開始，當前正在進行中的迭代不能變更只對小工程適用在中型和大型的工程中一樣取得了成功73精選ppt74精選ppt敏捷開發各階段的主要活動JinghuaLiQualityManagerTietoEnatorCorporationT&MMDRMIDjinghua.li@tietoenator工程生命周期主要包含三個階段：產品定義(方案)：進行迭代所需要的工程準備、工程方案和技術分析迭代開發(執行)：在固定時間的迭代中實現需求〔產品需求清單中的工程〕結束：準備最終的發布，結束工程(rampdown)76精選ppt產品定義階段通常稱為“SprintZero〞也使用Scrum的實踐，例如每日會議目標：進行工程準備〔justenough〕。在方案階段進行的方案和技術分析是為了使迭代以一種受控的方式進行所需的活動和詳細程度取決于軟件的復雜程度、質量要求、工程規模、工程設置和重用的要求等如果沒有適當的方案就進入首次迭代會有很大的風險通常情況下由核心團隊完成，由專家進行工程的方案