Scrum敏捷軟件開發(fā)過程說明

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

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