Scrum敏捷項目管理知識

-.z.SCRUM敏捷管理知識什么是scrumScrum是一個用于開發(fā)和維持復雜產(chǎn)品的框架，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應的任務列表，我們稱它為Sprintbacklog。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開發(fā)項目，但它適用于任何復雜的或是創(chuàng)新性的項目。Scrum流程如下圖：SCRUM框架包括3個角色、3個工件、5個活動、5個價值，具體說明如下：3個角色產(chǎn)品負責人（ProductOwner）ScrumMasterScrum團隊3個工件產(chǎn)品Backlog（ProductBacklog）SprintBacklog產(chǎn)品增量（Increment）5個活動產(chǎn)品Backlog梳理會議（ProductBacklogRefinement）Sprint計劃會議（SprintPlanningMeeting）每日站會（DailyScrumMeeting）Sprint評審會議（SprintReviewMeeting）Sprint回顧會議（SprintRetrospectiveMeeting）5個價值承諾–愿意對目標做出承諾專注–把你的心思和能力都用到你承諾的工作上去開放–Scrum把項目中的一切開放給每個人看尊重–每個人都有他獨特的背景和經(jīng)驗勇氣–有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM理論基礎Scrum以經(jīng)驗性過程控制理論（經(jīng)驗主義）做為理論基礎的過程。經(jīng)驗主義主張知識源于經(jīng)驗,以及基于已知的東西做決定。Scrum采用迭代、增量的方法來優(yōu)化可預見性并控制風險。Scrum的三大支柱支撐起每個經(jīng)驗性過程控制的實現(xiàn):透明性、檢驗和適應。Scrum的三大支柱如下：第一：透明性（Transparency）透明度是指，在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產(chǎn)結果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內(nèi)容。也就是說，當*個人在檢驗一個過程，并確信*一個任務已經(jīng)完成時，這個完成必須等同于他們對完成的定義。第二：檢驗（Inspection）開發(fā)過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發(fā)現(xiàn)過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發(fā)生變化。當規(guī)定的檢驗頻率超出了過程檢驗所能容許的程度，則就會出現(xiàn)問題。幸運的是，軟件開發(fā)并不會出現(xiàn)這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。第三：適應（Adaptation）如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標準，并且最終產(chǎn)品是不合格的，則便需要對過程或是材料進行調(diào)整。調(diào)整工作必須盡快實施，以減少進一步的偏差。Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調(diào)整，從而優(yōu)化次日的工作價值；Sprint評審和計劃會議檢驗發(fā)布目標的進展，做出調(diào)整，從而優(yōu)化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Sprint，并且確定做出什么樣的改善可以使接下來的Sprint更加高效、更加令人滿意，并且工作更快樂。SCRUM術語Scrum：Scrum無對應中文翻譯Agile：敏捷Lean：精益Iterative：迭代式的Iteration：迭代AgileManifesto：敏捷宣言Empirical：經(jīng)驗性的EmpiricalProcess：經(jīng)驗性過程Transparency：透明性InspectandAdapt：檢視與調(diào)整Sprint：原意為沖刺，Scrum中的Sprint無對應中文翻譯，指一個迭代SprintGoal：Sprint目標ProductOwner：產(chǎn)品負責人簡稱POScrumMaster：簡稱SM,一般不翻譯DevelopmentTeam：Scrum開發(fā)團隊ScrumTeam：指PO,SM和開發(fā)團隊ScrumRoles：Scrum角色，指PO,SM和開發(fā)團隊Emergent：涌現(xiàn)的ProductBacklog：產(chǎn)品待辦列表，指需求清單SprintBacklog：Sprint待辦列表，指Sprint任務清單SprintBurn-downChart：Sprint燃盡圖，團隊用于做Sprint內(nèi)的進展跟蹤ReleaseBurn-downChart:發(fā)布燃盡圖，產(chǎn)品負責人做發(fā)布進展跟蹤SprintPlanningMeeting:Sprint計劃會議DailyScrumMeeting：每日站會SprintReviewMeeting：Sprint評審會議SprintRetrospectiveMeeting:Sprint回顧會議ProductBacklogRefinement:產(chǎn)品待辦列表梳理ProductBacklogItem:產(chǎn)品待辦清單條目，簡稱PBIUserStory:用戶故事，指一條需求StoryPoint：衡量用戶故事的工作量大小的計量單位Velocity:團隊速度SprintTask:實現(xiàn)一條需求需要做的一個技術任務DefinitionofDone:DoD，完成的定義Stakeholders：干系人Backlog：待辦列表Artifact：工件Estimation：估算Collaboration：協(xié)作ScalingScrum：大規(guī)模ScrumSCRUM起源Scrum的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時在犯規(guī)地點對陣爭球。爭球雙方各有8個隊員參與，各方出3名前鋒隊員，并肩各站成一橫排，面對面躬身互相頂肩，中間形成一條通道，其他前鋒隊員分別站在后面，后排隊員用肩頂住前鋒隊員的臀部，組成3、2、3或3、4、1陣形。然后，由犯規(guī)隊的對方隊員在對陣一側1碼外，用雙手低手將球拋入通道，不得有利于本隊。當球拋入通道時，前排的3對前鋒隊員互相抗擠，爭相踢球給本方前衛(wèi)或后衛(wèi)隊員，前衛(wèi)和后衛(wèi)隊員必須等候前鋒將球踢回后，方可移動。1986Scrum這個詞匯首次應用于產(chǎn)品開發(fā)1986年，竹內(nèi)弘高和野中郁次郎在NewNewProductDevelopmentGame文章首次提到將Scrum應用與產(chǎn)品開發(fā)，他們指出：傳統(tǒng)的"接力式”的開發(fā)模式已經(jīng)不能滿足快速靈活的市場需求，而整體或"橄欖球式”的方法——團隊作為一個整體前進，在團隊的內(nèi)部傳球并保持前進，這也許可以更好的滿足當前激烈的市場競爭。1993年JeffSutherland首次將Scrum用于軟件開發(fā)敏捷思想深受日本工業(yè)界最佳實踐的影響，尤其是豐田和本田公司推行的精益原則，以及竹內(nèi)弘高和野中郁次郎開發(fā)的知識管理策略。受到以上思想的影響，以及對世界范圍內(nèi)軟件項目的研究，JeffSutherland在1993年首次在Easel公司定義了用于了軟件開發(fā)行業(yè)的Scrum流程，并開始實施。1995年JeffSutherland和KenSchwaber規(guī)范化了Scrum框架，并在OOPSLA95上公開發(fā)布。2001年敏捷宣言及原則發(fā)布、敏捷聯(lián)盟成立，Scrum是其中一種敏捷方法。2001年，KenSchwaber和MikeBeedle推出第一本Scrum書籍《Scrum敏捷軟件開發(fā)》。2002年KenSchwaber和MikeCohn共同創(chuàng)辦了Scrum聯(lián)盟。經(jīng)驗性過程軟件開發(fā)是一個復雜的活動，在軟件產(chǎn)品開發(fā)的過程中不僅存在著需求的不確定性，也存在著技術的不確定性，再加上參與軟件開發(fā)的主體通常是由多人組成的軟件開發(fā)團隊，加上人的因素，就讓整個軟件開發(fā)的活動變得非常復雜。如下圖所示，軟件開發(fā)活動通常處在下圖的很復雜的區(qū)域。圖-01為了管理軟件開發(fā)的活動，我們會引入過程控制來管理它。過程控制通常有兩種方式，第一種方式是預定義的過程，第二種方式是經(jīng)驗性過程。我們所熟知的是預定義的過程，它通常是使用已知的方法解決已知的問題。制造業(yè)的生產(chǎn)線就是典型的預定義過程，例如生產(chǎn)餅干、啤酒、汽車的生產(chǎn)線等。預定義的過程的特點是給予固定的輸入，得到固定的輸出，過程可重復。它的優(yōu)勢在于可以大規(guī)模批量生產(chǎn)。預定義過程的缺點在于一旦過程定義出現(xiàn)錯誤，或產(chǎn)品設計上存在瑕疵，會造成比較大的損失。圖－02如果我們期望解決的問題比較復雜，并且存在著較大的不確定性的時候，我們需要使用經(jīng)驗性過程。經(jīng)驗性過程的特點是過程是不能夠完全預先定義好，結果是不可預知的，生產(chǎn)過程是不可重復的。比如研究一項新技術，下一盤棋，踢一場球賽，在過程運行當中，我們需要通過不斷的獲得真實的反饋，然后進行適應和調(diào)整，使得過程能夠產(chǎn)出我們需要的結果。"在過程運行機制相當簡單易懂的情況下，典型的做法是采用預定義的建模方式。如果過程復雜程度超出預定義方式的能力范圍，便應用經(jīng)驗性方式。”《過程動態(tài)學、建模與控制》軟件產(chǎn)品的研發(fā)通常存在多很多的不確定性，并且生產(chǎn)的過程非常的復雜，所以更適合使用經(jīng)驗性過程來管理。Scrum以經(jīng)驗性過程控制理論做為理論基礎的過程。Scrum采用迭代、增量的方法來優(yōu)化可預見性并控制風險。Scrum過程框架的基石包括如下三個方面：第一：透明性（Transparency）透明度是指，在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產(chǎn)結果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內(nèi)容。也就是說，當*個人在檢驗一個過程，并確信*一個任務已經(jīng)完成時，這個完成必須等同于他們對完成的定義。第二：檢驗（Inspection）開發(fā)過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發(fā)現(xiàn)過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發(fā)生變化。當規(guī)定的檢驗頻率超出了過程檢驗所能容許的程度，則就會出現(xiàn)問題。幸運的是，軟件開發(fā)并不會出現(xiàn)這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。第三：適應（Adaptation）如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標準，并且最終產(chǎn)品是不合格的，則便需要對過程或是材料進行調(diào)整。調(diào)整工作必須盡快實施，以減少進一步的偏差。Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調(diào)整，從而優(yōu)化次日的工作價值；Sprint評審和計劃會議檢驗發(fā)布目標的進展，做出調(diào)整，從而優(yōu)化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Sprint，并且確定做出什么樣的改善可以使接下來的Sprint更加高效、更加令人滿意，并且工作更快樂。SCRUM團隊的三個角色Scrum團隊中包括三個角色，他們分別是產(chǎn)品負責人、開發(fā)團隊和ScrumMaster。Scrum團隊是自組織、跨職能的完整團隊。自組織團隊決定如何最好地完成他們的工作,而不是由團隊外的其他人來指揮他們?？缏毮艿膱F隊擁有完成工作所需要的全部技能,不需要依賴團隊外部的人。Scrum團隊模式的目的是最大限度地優(yōu)化適應性、創(chuàng)造性和生產(chǎn)力。Scrum團隊通過迭代和增量交付產(chǎn)品功能的方法最大化反饋的機會。增量交付潛在可交付的產(chǎn)品增量保證了每個迭代都有潛在可發(fā)布的版本。Scrum角色之：產(chǎn)品負責人產(chǎn)品負責人負責最大化產(chǎn)品以及開發(fā)團隊工作的價值。實現(xiàn)這一點的方式會隨著組織、Scrum團隊以及單個團隊成員的不同而不同。產(chǎn)品負責人是管理產(chǎn)品待辦事項列表的唯一責任人。產(chǎn)品待辦事項列表的管理包括:清晰地表達產(chǎn)品代辦事項列表條目對產(chǎn)品代辦事項列表中的條目進行排序,最好地實現(xiàn)目標和使命確保開發(fā)團隊所執(zhí)行工作的價值確保產(chǎn)品代辦事項列表對所有人可見、透明、清晰,并且顯示Scrum團隊的下一步工作確保開發(fā)團隊對產(chǎn)品代辦事項列表中的條目達到一定程度的理解產(chǎn)品負責人可以親自完成上述工作,也可以讓開發(fā)團隊來完成。然而,產(chǎn)品負責人是負責任者。產(chǎn)品負責人是一個人,而不是一個委員會。產(chǎn)品負責人可能會在產(chǎn)品代辦事項列表中體現(xiàn)一個委員會的需求,但要想改變*條目的優(yōu)先級必須先說服產(chǎn)品負責人。為保證產(chǎn)品負責人的工作取得成功,組織中的所有人員都必須尊重他的決定。產(chǎn)品負責人所作的決定在產(chǎn)品待辦事項列表的內(nèi)容和排序中要清晰可見。任何人都不得要求開發(fā)團隊按照另一套需求開展工作,開發(fā)團隊也不允許聽從任何其他人的指令。Scrum角色之：開發(fā)團隊開發(fā)團隊包含了專業(yè)人員,負責在每個Sprint的結尾交付潛在可發(fā)布的"完成”產(chǎn)品增量。只有開發(fā)團隊的成員才能創(chuàng)造增量。開發(fā)團隊由組織構建并授權,來組織和管理他們的工作。所產(chǎn)生的協(xié)同工作能最大化開發(fā)團隊的整體效率和效力。開發(fā)團隊有以下幾個特點:他們是自組織的,沒有人(即使是ScrumMaster都不可以)告訴開發(fā)團隊如何把產(chǎn)品代辦事項列表變成潛在可發(fā)布的功能。開發(fā)團隊是跨職能的,團隊作為一個整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。Scrum不認可開發(fā)團隊成員的頭銜,無論承擔哪種工作他們都是開發(fā)者。此規(guī)則無一例外。開發(fā)團隊中的每個成員可以有特長和專注領域,但是責任歸屬于整個開發(fā)團隊開發(fā)團隊不包含如測試或業(yè)務分析等負責特定領域的子團隊。開發(fā)團隊的規(guī)模開發(fā)團隊最佳規(guī)模是小到足以保持敏捷性,大到足以完成重要工作。少于3人的開發(fā)團隊沒有足夠的交互,因而所獲得的生產(chǎn)力增長也不會很大。小團隊在Sprint中可能會受到技能限制,從而導致無法交付可發(fā)布的產(chǎn)品增量。大于9人的團隊需要過多的協(xié)調(diào)溝通工作。大型團隊會產(chǎn)生太多復雜性,不便于經(jīng)驗過程管理。產(chǎn)品負責人和ScrumMaster的角色不包含在此數(shù)字中,除非他們也參與執(zhí)行Sprint代表事項列表中的工作。Scrum角色之：ScrumMasterScrumMaster負責確保Scrum被理解并實施。為了達到這個目的,ScrumMaster要確保Scrum團隊遵循Scrum的理論、實踐和規(guī)則。ScrumMaster是Scrum團隊中的服務式領導。ScrumMaster幫助Scrum團隊外的人員了解他們?nèi)绾闻cScrum團隊交互是有益的。ScrumMaster通過改變這些交互來最大化Scrum團隊所創(chuàng)造的價值。ScrumMaster服務于產(chǎn)品負責人ScrumMaster以各種方式服務于產(chǎn)品負責人,包括:找到有效管理產(chǎn)品代辦事項列表的技巧清晰地和開發(fā)團隊溝通愿景、目標和產(chǎn)品代表事項列表條目教導開發(fā)團隊創(chuàng)建清晰簡明的產(chǎn)品代表事項列表條目在經(jīng)驗主義環(huán)境中理解長期的產(chǎn)品規(guī)劃理解并實踐敏捷按需推動Scrum活動ScrumMaster服務于開發(fā)團隊ScrumMaster以各種方式服務于開發(fā)團隊,包括:指導開發(fā)團隊自組織和跨職能教導并領導開發(fā)團隊創(chuàng)造高價值的產(chǎn)品移除開發(fā)團隊進展過程中的障礙按需推動Scrum活動在Scrum還未完全被采納和理解的組織環(huán)境下指導開發(fā)團隊ScrumMaster服務于組織ScrumMaster以各種方式服務于組織,包括:領導并指導組織采用Scrum在組織范圍內(nèi)計劃Scrum的實施幫助員工及干系人理解并實施Scrum和經(jīng)驗性產(chǎn)品開發(fā)發(fā)起能提升Scrum團隊生產(chǎn)力的變革與其他ScrumMaster一起工作,幫助組織更有效的應用ScrumSCRUM的三個工件Scrum的工件以不同的方式展現(xiàn)工作和價值,可以用來提供透明性以及檢驗和適應的機會。Scrum中所定義的工件能最大化關鍵信息的透明性,來保證Scrum團隊成功地交付完成的增量。ProductBacklog–產(chǎn)品待辦事項列表產(chǎn)品待辦事項列表是一個排序的列表,包含所有產(chǎn)品需要的東西,也是產(chǎn)品需求變動的唯一來源。產(chǎn)品負責人負責產(chǎn)品待辦事項列表的內(nèi)容、可用性和優(yōu)先級。產(chǎn)品待辦事項列表是一個持續(xù)完善的清單,最初的版本只列出最初始的和眾所周知的需求。產(chǎn)品待辦事項列表根據(jù)產(chǎn)品和開發(fā)環(huán)境的變化而演進。待辦事項列表是動態(tài)的,它經(jīng)常發(fā)生變化以識別使產(chǎn)品合理、有競爭力和有用所必需的東西。只要產(chǎn)品存在,產(chǎn)品待辦事項列表就存在。產(chǎn)品待辦事項列表列出了所有的特性、功能、需求、改進方法和缺陷修復等對未來發(fā)布產(chǎn)品進行的改變。產(chǎn)品待辦事項列表條目包含描述、次序和估算的特征。產(chǎn)品待辦事項列表通常以價值、風險、優(yōu)先級和必須性排序。它是一個按照優(yōu)先級由高到低排列的一個序列，每個條目有唯一的順序。排在頂部的產(chǎn)品待辦事項列表條目需要立即進行開發(fā)。排序越高,產(chǎn)品待辦事項列表條目越緊急,就越需要仔細斟酌,并且對其價值的意見越一致。排序越高的產(chǎn)品待辦事項列表條目比排序低的更清晰、更具體。根據(jù)更清晰的內(nèi)容和更詳盡的信息就能做出更準確的估算。優(yōu)先級越低,細節(jié)信息越少。開發(fā)團隊在接下來的Sprint中將要進行開發(fā)的產(chǎn)品待辦事項列表條目是細粒度的,已經(jīng)被分解過,因此,任何一個條目在Sprint的時間盒內(nèi)都可以被"完成”。開發(fā)團隊在一個Sprint中可以"完成”的產(chǎn)品待辦事項列表條目被認為是"準備好的”或者"可執(zhí)行的”,能在Sprint計劃會議中被選擇。隨著產(chǎn)品的使用、價值的獲取以及市場的反饋,產(chǎn)品待辦事項列表變成了更大、更詳盡的列表。因為需求永遠不會停止改變,所以產(chǎn)品待辦事項列表是個不斷更新的工件。業(yè)務需求、市場形勢和技術的變化都會引起產(chǎn)品待辦事項列表的變化。若干個Scrum團隊常常會一起開發(fā)*個產(chǎn)品。但描述下一步產(chǎn)品開發(fā)工作的產(chǎn)品待辦事項列表只能有一個。則這就需要使用對產(chǎn)品待辦事項列表條目進行分組的屬性。通過產(chǎn)品Backlog地梳理來增添細節(jié)、估算和排序。這是一個持續(xù)不斷的過程,產(chǎn)品負責人和開發(fā)團隊協(xié)作討論產(chǎn)品代表事項列表條目的細節(jié)。在產(chǎn)品待辦事項列表梳理的時候,條目會被評審和修改。然而,產(chǎn)品負責人可以隨時更新產(chǎn)品代辦事項列表條目或酌情決定。梳理在Sprint中是一項兼職活動,在產(chǎn)品負責人和開發(fā)團隊之間展開。通常,開發(fā)團隊有自行優(yōu)化的領域知識。然而,何時如何完成優(yōu)化是Scrum團隊的決定。優(yōu)化通常占用不超過開發(fā)團隊10%的時間。開發(fā)團隊負責所有的估算工作。產(chǎn)品負責人可以通過協(xié)助團隊權衡取舍來影響他們的決定。但是,最后的估算是由執(zhí)行工作的人來決定的。監(jiān)控向目標前進的進度在任何時間,達成目標的剩余工作量是可以被累計的。產(chǎn)品負責人至少在每個Sprint評審的時候追蹤剩余工作總量。產(chǎn)品負責人把這個數(shù)量與之前Sprint評審時的剩余工作量做比較,來評估在希望的時間點完成預計工作達成目標的進度。這份信息對所有的干系人都透明。Scrum不考慮已經(jīng)花在產(chǎn)品代辦事項列表條目上的工作時間。我們只關心剩余工作和日期這兩個變量。各種趨勢燃盡圖、燃燒圖和其他計劃實踐都能用來預測進度。它們已經(jīng)被證實有用。然而,這并不能代替經(jīng)驗主義的重要性。在復雜的環(huán)境下,將要發(fā)生的東西是未知的,只有已經(jīng)發(fā)生的事情才能用來做前瞻式的決策。SPRINTBACKLOGSprint代辦事項列表是一組為當前Sprint選出的產(chǎn)品代辦事項列表條目,外加交付產(chǎn)品增量和實現(xiàn)Sprint目標的計劃。Sprint代辦事項列表是開發(fā)團隊對于哪些功能要包含在下個增量中,以及交付那些功能所需工作的預計。Sprint代辦事項列表定義了開發(fā)團隊把產(chǎn)品代辦事項列表條目轉換成"完成”的增量所需要執(zhí)行的工作。Sprint代辦事項列表使開發(fā)團隊確定的、達到Sprint目標所需的工作清晰可見。Sprint代辦事項列表是一份足夠具體的計劃,使得進度上的改變能在每日例會中得到理解。開發(fā)團隊在整個Sprint中都會修改Sprint代辦事項列表,Sprint代辦事項列表也會在Sprint的進程中慢慢顯現(xiàn),比如開發(fā)團隊按照計劃工作并對完成Sprint目標所需的工作有更多的了解。當出現(xiàn)新工作時,開發(fā)團隊需要將其追加到Sprint待辦事項列表中去。隨著任務進行或者被完成,需要更新每項任務的估算剩余工作量。如果計劃中*個部分失去開發(fā)的意義,就可以將其除去。在Sprint內(nèi)只有開發(fā)團隊可以對Sprint待辦事項列表進行修改。Sprint待辦事項列表是高度可見的,是對團隊計劃在當前Sprint內(nèi)完成工作的實時反映,并且,該列表只屬于開發(fā)團隊。ProductBacklog功能點被放到Sprint的固定周期中，SprintBacklog會因為如下原因發(fā)生變化:1.隨著時間的變化，開發(fā)團隊對于需求有了更好的理解，有可能發(fā)現(xiàn)需要增加一些新的任務到SprintBacklog中。2.程序缺陷做為新的任務加進來，這個都做為承諾提交任務中未完成的工作。ProductOwner也許會和Scrumteam一起工作，以幫助team更好的理解Sprint的目標，ScrumMaster和team也許會覺得小的調(diào)整不會影響sprint的進度，但會給客戶帶來更多商業(yè)價值。監(jiān)控Sprint進度在Sprint中的任意時間點,Sprint待辦事項列表的所有剩余工作總和都可以被計算。開發(fā)團隊至少在每日例會時追蹤所有的剩余工作。開發(fā)團隊每天追蹤剩余總和并預測達成Sprint目標的可能性。通過在Sprint中不斷追蹤剩余工作,開發(fā)團隊可以管理自己的進度。Scrum不考慮已經(jīng)花在Sprint待辦事項列表上的工作時間。我們只關心剩余工作和日期這兩個變量。燃盡圖（BURN-DOWNCHART)Sprint燃盡圖（SprintBurn-downChart)SprintBurndownChart顯示了Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的趨勢圖。圖中Y軸代表的是剩余工作量，*軸代表的是Sprint的工作日。在Sprint開始的時候，ScrumTeam會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，團隊會根據(jù)進展情況每天更新累積工作量，如果在Sprint結束時，累積工作量降低到0，Sprint就成功結束。由于在Sprint的剛開始的時候，增加的任務工作量可能大于完成的任務工作量，所以燃盡圖有可能略微呈上升趨勢。發(fā)布燃盡圖（ReleaseBurn-downChart）在Scrum項目中，團隊通過每個Sprint結束時更新的發(fā)布燃盡圖來跟蹤整個發(fā)布計劃的進展。發(fā)布燃盡圖記錄了在一段時間內(nèi)產(chǎn)品Backlog的總剩余估算工作量的變化趨勢。*軸代表的項目周期，以Sprint為單位，Y軸代表的是剩余工作量，通常以用戶故事點、理想人天或者team-days為單位。SCRUM的五個活動Scrum活動:產(chǎn)品待辦事項列表梳理產(chǎn)品待辦事項通常會很大,也很寬泛,而且想法會變來變?nèi)?、?yōu)先級也會變化,所以產(chǎn)品待辦事項列表梳理是一個貫穿整個Scrum項目始終的活動。該活動包含但不限于以下的內(nèi)容:保持產(chǎn)品待辦事項列表有序把看起來不再重要的事項移除或者降級增加或提升涌現(xiàn)出來的或變得更重要的事項將事項分解成更小的事項將事項歸并為更大的事項對事項進行估算產(chǎn)品待辦事項列表梳理的一個最大好處是為即將到來的幾個Sprint做準備。為此,梳理時會特別關注那些即將被實現(xiàn)的事項。需要考慮不少因素,這包括但不限于以下的內(nèi)容:理想情況下,下一個Sprint的備選事項都應該提升"商業(yè)價值”。開發(fā)團隊需要能夠在一個Sprint內(nèi)完成每一個事項。每個人都需要清楚預期產(chǎn)出是什么。產(chǎn)品開發(fā)決定了,有可能需要其它的技能和輸入。因此,產(chǎn)品待辦事項列表梳理最好是所有團隊成員都參與的活動,而不單單是產(chǎn)品負責人。Scrum活動：Sprint計劃會議每個Sprint都以Sprint計劃會議作為開始，這是一個固定時長的會議，在這個會議中,Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。整個團隊都要參加Sprint計劃會議。針對排好序的產(chǎn)品待辦事項列表(ProductBacklog),產(chǎn)品負責人和開發(fā)團隊成員討論每個事項,并對該事項達成共識,包括根據(jù)當前的"完成的定義”,為了完成該事項所需要完成的所有事情。所有的Scrum會議都是限定時的。Sprint計劃會議推薦時是Sprint中的每周對應兩?時或者更少(譯者注:比如,一個Sprint包含2個星期,則Sprint計劃會議時長應為4個小時或者更少)。因為會議是限制時長的,Sprint計劃會議的成功?分依賴于產(chǎn)品待辦事項列表的質(zhì)量。這就是產(chǎn)品待辦事項列表梳理十分重要的原因。在Scrum中,Sprint計劃會議有兩部分:決定在Sprint中需要完成哪些工作決定這些工作如何完成第一部分:需要完成哪些工作"在會議的第一部分,產(chǎn)品負責人向開發(fā)團隊介紹排好序的產(chǎn)品待辦事項,整個Scrum團隊共同理解這些工作。Sprint中需要完成的產(chǎn)品待辦事項數(shù)目完全由開發(fā)團隊決定。為了決定做多少,開發(fā)團隊需要考慮當前產(chǎn)品增量的狀態(tài),團隊過去的工作情況,團隊當前的生產(chǎn)能力,以及排好序的產(chǎn)品待辦事項列表。做多少工作只能由開發(fā)團隊決定。產(chǎn)品負責人或任何其它人,都不能給開發(fā)團隊強加更多的工作量。通常Sprint都有個目標,稱作Sprint目標。這將十分有效地幫助大家更加專注于需要完成的工作的本質(zhì),而不必花太多精力去關注那些對于我們需要完成的工作并不重要的?小細節(jié)。第二部分:如何完成工作"在會議的第二部分?里,開發(fā)團隊需要根據(jù)當前的"完成的定義”一起決定如何實現(xiàn)下一個產(chǎn)品增量。他們進?行?足夠的設計和計劃,從而有信心可以在Sprint中完成所有工作。頭幾天的工作會被分解成?小的單元,每個工作單元不超過一天。之后要完成的工作可以稍?大些,以后再對它們進?行分解。決定如何完成工作是開發(fā)團隊的職責,決定做什么則是產(chǎn)品負責人的職責。在計劃會議的第二部分,產(chǎn)品負責人可以繼續(xù)留下來回答問題,以及澄清一些誤解。不管怎樣,團隊應該很容易找到產(chǎn)品負責人。Sprint計劃會議的產(chǎn)出Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數(shù)量和復雜度達成共識,并預期在一個合理的條件范圍內(nèi)完成它們。開發(fā)團隊預測并共同承諾他們要完成的工作量?？偠?言之:在Sprint計劃會議中,開發(fā)團隊和產(chǎn)品負責人一起考慮并討論產(chǎn)品待辦事項,確保他們對這些事項的理解,選擇一些他們預測能完成的事項,創(chuàng)建足夠詳細的計劃來確保他們能夠完成這些事項。最終產(chǎn)生的待辦事項列表就是"Sprint待辦事項列表(SprintBacklog)”。Scrum活動:每日Scrum會議開發(fā)團隊是自組織的。開發(fā)團隊通過每日Scrum會議來確認他們?nèi)匀豢梢詫崿F(xiàn)Sprint的目標。這個會議每天在同樣的時間和同樣的地點召開。每一個開發(fā)團隊成員需要提供以下三點信息:從上一個每日Scrum到現(xiàn)在,我完成了什么;從現(xiàn)在到下一個每日Scrum,我計劃完成什么;有什么阻礙了我的進展。每日Scrum中可能有簡要的問題澄清和回答,但是不應該有任何話題的討論。通常,許多團隊會在每日Scrum之后?馬上開會處理他們遇到的任何問題。每日Scrum既不是向管理層匯報,也不是向產(chǎn)品負責?人或者ScrumMaster匯報。它是一個開發(fā)團隊內(nèi)部的溝通會議,來保證他們對現(xiàn)狀有一致的了解。只有Scrum團隊的成員,包括ScrumMaster和產(chǎn)品負責?人,可以在會議中發(fā)?言。其他感興趣的?人可以來旁聽。在必要時,開發(fā)團隊會基于會議中的發(fā)現(xiàn)重新組織他們的工作來完成Sprint的??目標。每日Scrum是Scrum的一個關鍵組成部分,它可以帶來透明性,信任和更好的績效。它能幫助快速發(fā)現(xiàn)問題,并促進團隊的自組織和自?立。所有Scrum會議都是限定時長的。每日Scrum通常不超過15分鐘。Scrum活動:Sprint評審會議Sprint結束時,Scrum團隊和相關?人員一起評審Sprint的產(chǎn)出。所有Scrum會議都是限定時長的,Sprint評審會議的推薦時長是Sprint中的每一周對應一個小時(譯者注:?比如,一個Sprint包含2個星期,則Sprint評審會議時長為2個小時)。討論圍繞著Sprint中完成的產(chǎn)品增量。由于Sprint的產(chǎn)出會涉及到一些?人的"利益”,因此一個明智的做法是邀請他們參加這個會議,這會很有幫助。這個會議是個?非正式的會議,幫助?大家了解我們??目前進展到哪?里,并一起討論我們下一步如何推進。每個?人都可以在Sprint評審會議上發(fā)表意?見。當然,產(chǎn)品負責?人會對未來做出最終的決定,并適當?shù)卣{(diào)整產(chǎn)品待辦事項列表(ProductBacklog)。團隊會找到他們自己的方式來開Sprint評審會議。通常會演?示產(chǎn)品增量,整個小組也會經(jīng)常討論他們在Sprint中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。他們還會討論產(chǎn)品待辦事項列表的狀態(tài)、可能的完成日期以及在這些日期前能完成什么。Sprint評審會議向每個?人展?示了當前產(chǎn)品增量的概況。因此,通常都會在Sprint評審會議中調(diào)整產(chǎn)品待辦事項列表。Scrum活動:Sprint回顧會議在每個Sprint結束后,Scrum團隊會聚在一起開Sprint回顧會議,目的是回顧一下團隊在流程人際關系以及工具方面做得如何。團隊識別出哪些做得好,哪些做得不好,并找出潛在的改進事項,為將來的改進制定計劃。所有的Scrum會議都是限定時長的,Sprint回顧會議的推薦時長是Sprint中的每一周對應一個小時(譯者注:?比如,一個Sprint包含2個星期,則Sprint回顧會議時長為2個小時)。Scrum團隊總是在Scrum的框架內(nèi),改進他們自己的流程。SCRUM的五個價值觀承諾–愿意對目標做出承諾專注–把你的心思和能力都用到你承諾的工作上去開放–Scrum把項目中的一切開放給每個人看尊重–每個人都有他獨特的背景和經(jīng)驗勇氣–有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM的四大支柱迭代開發(fā)在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個1-4周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，則保持它的長度不要發(fā)生變化，在整個產(chǎn)品開發(fā)周期內(nèi)每個迭代都是1周的長度。這里需要強調(diào)的是在每個迭代必須產(chǎn)出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。增量交付增量是一個Sprint及以前所有Sprint中完成的所有產(chǎn)品代辦事項列表條目的總和。在Sprint的結尾,新的增量必須"完成”,這意味著它必須可用并且達到了Scrum團隊"完成”的定義的標準。無論產(chǎn)品負責人是否決定真正發(fā)布它,增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。自組織團隊Scrum團隊是一個自組織的團隊，傳統(tǒng)的命令與控制式的團隊只有執(zhí)行任務的權利，而自組織團隊有權進行設計、計劃和執(zhí)行任務，自組織團隊還需要自己監(jiān)督和管理他們的工程過程和進度，自組織團隊自己決定團隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。高優(yōu)先級的需求驅(qū)動在Scrum中，我們使用ProductBacklog來管理需求，ProductBacklog是一個需求的清單，ProductBacklog中的需求是漸進明細的，Backlog當中的條目必須按照商業(yè)價值的高低排序。Scrum團隊在開發(fā)需求的時候，從Backlog最上層的高優(yōu)先級的需求開始開發(fā)。在Scrum中，只要有足夠1-2個Sprint開發(fā)的細化了的高優(yōu)先級的需求，我們就可以啟動Sprint了，而不必等到所有的需求都細化之后。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細化需求。SCRUM團隊在傳統(tǒng)的工作方式下，開發(fā)團隊會有很多不同的角色，比如項目經(jīng)理、產(chǎn)品經(jīng)理、架構師、設計師、用戶體驗設計師，程序員，測試人員，DBA等等。但是，在Scrum的工作方式下，總共只有三個角色，這三個角色分別是產(chǎn)品負責人（PO）,ScrumMaster和開發(fā)團隊。我們通?？梢砸詣濤堉鄣膱F隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團隊三個角色。Scrum中的PO就是舵手的角色，他對產(chǎn)品的方向負責，對產(chǎn)品的Why和What負責，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負責。Scrum中的ScrumMaster鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協(xié)作，他是一個Scrum的專家，團隊的教練，團隊的服務式領導。Scrum中的團隊，對應到龍舟賽的劃槳團隊，團隊必須協(xié)調(diào)一致，作為一個整體前進，在這樣的環(huán)境下單打獨斗，各自為政沒有任何勝算。Scrum的開發(fā)團隊對實現(xiàn)Sprint目標需要做的所有事情負責，包括技術方案和決策，團隊分工（誰做什么），執(zhí)行Sprint開發(fā)任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。Scrum開發(fā)團隊的主要職責包括如下五個方面：執(zhí)行Sprint梳理產(chǎn)品Backlog做Sprint計劃每天跟進工作進展，并對他們的工作做檢查和調(diào)整每個迭代對產(chǎn)品和團隊的工作過程做檢查和調(diào)整開發(fā)團隊有如下10方面的特征：自組織多元化、跨職能的完整團隊團隊成員符合T型技能，即一專多長持續(xù)改進最大限制的溝通透明溝通2個披薩的團隊大?。?-9人）專注、投入按照可持續(xù)的節(jié)奏工作團隊長期存在，人員穩(wěn)定自組織團隊什么是自組織團隊？自組織團隊是敏捷軟件開發(fā)的基本觀念。敏捷宣言的原則中提到:"最好的架構、需求和設計出于自組織團隊”。自組織團隊也叫做自管理團隊、或者被授權的團隊。團隊被授權自己管理他們的工作過程和進度、并且團隊決定如何完成工作。自組織團隊和經(jīng)理領導的團隊的區(qū)別對于經(jīng)理領導的團隊來說，團隊成員被分配任務，團隊成員只有執(zhí)行任務的權利。對于經(jīng)理領導的團隊來說，管理者除了要確定目標、方向，團隊的上下文（組織結構、團隊結構、團隊組成），還需要監(jiān)督和管理團隊的過程和進度，分配任務即確定誰做什么。這種團隊的管理方式，更多的是命令與控制，以及微觀管理。對于自組織團隊來說，他們擁有如下權利：團隊決定誰做什么，即任務的分配團隊決定如何做，如何實現(xiàn)目標，即團隊做技術決策團隊需要在確保目標的前提下制定團隊內(nèi)的行為準則團隊有義務保持過程的透明性團隊監(jiān)督和管理他們的過程和進度在自組織團隊的環(huán)境下，管理層關注在如下幾個方面：確定團隊目標和愿景確定團隊上下文，組織結構、團隊結構、團隊組成提供環(huán)境和支持（安全感、良好的團隊空間、氛圍，技能輔導等）授權團隊訓練協(xié)作對于自組織團隊的普遍誤解：誤解1：團隊自己決定目標是什么；糾正：管理層決定團隊目標誤解2：團隊自己決定誰進入團隊；糾正：管理層決定團隊上下文誤解3：團隊自己設計團隊結構；糾正：管理層決定團隊上下文誤解4：自組織團隊不需要管理者；糾正：管理者從微觀管理轉向目標驅(qū)動、授權團隊的管理方式誤解5：自組織團隊需要員工更加主動；糾正：自組織讓團隊更加主動，每個人都不喜歡被命令和控制，每個人期望有成就感、期望被認可誤解6：自組織團隊想干什么就干什么；糾正：管理層決定團隊目標，團隊決定如何實現(xiàn)目標一個自組織的團隊通常由不同職能專業(yè)、思考方式和行為模式的成員組成，也就是說它是跨職能的團隊。自組織的團隊不是與生俱來的，打造一個團隊需要一個過程，打造一個自組織團隊也是一樣。打造自組織團隊，首先要讓團隊需要完全自主；其次，有了自主，管理者需要引導團隊持續(xù)改進，幫助團隊持續(xù)地挑戰(zhàn)更高的目標；第三，給團隊提供環(huán)境和支持，引導團隊往正確地方向邁進。特性團隊如果我們的產(chǎn)品開發(fā)團隊只有在10人以內(nèi)，我們使用一個跨職能的Scrum團隊，可以很容易地按照scrum和敏捷的方式開發(fā)產(chǎn)品。但是，如果產(chǎn)品團隊規(guī)模較大，比如是幾十人，甚至幾百人的開發(fā)團隊的時候，我們就需要考慮團隊的結構和組織方式。在一個大的開發(fā)組織中，Scrum會把大的開發(fā)團隊劃分成多個5-9人的小團隊，則我們應該按照什么方式來劃分呢？在傳統(tǒng)的開發(fā)模式下，我們習慣于按照系統(tǒng)的架構模塊，或者系統(tǒng)分層組織團隊，也有的團隊按照系統(tǒng)需求、開發(fā)、測試結合系統(tǒng)架構混合組織的方式。這種團隊組織的方式，我們稱之為組件團隊，是指每個團隊只是完成系統(tǒng)功能的*一個部件，而不是一個端到端用戶可見的功能。組件團隊看起來像這個樣子：按照Scrum和敏捷的交付模式，組件團隊有如下一些限制：第一：按照組件來組織團隊，很難避免團隊之間的依賴，跨團隊的協(xié)調(diào)和依賴管理更加復雜，不利于跨組件或者各個層之間的溝通。第二：每個團隊專注在自己的模塊，由于各模塊、或分層需求工作量的不同，很容易產(chǎn)生等待，并且容易產(chǎn)生低價值的交付。第三：由于職責單一，限制了學習，使得專業(yè)更加單一化第四：Sprint結束的時候無法提交可交付的增量產(chǎn)品功能，延遲價值交付按照Scrum和敏捷的交付模式，以用戶為中心，按照用戶場景作為邊界來組織團隊是比較推薦的做法。這種以用戶為中心的團隊叫做特性團隊。特性團隊的特點：長期穩(wěn)定的團隊，逐個端到端完成客戶特性以客戶為中心的特性驅(qū)動跨職能、完整團隊共享代碼庫，統(tǒng)一的持續(xù)集成擁有通用型專家特性團隊看起來像這個樣子：特性團隊的好處：團隊內(nèi)可以做到端到端，所以減少了等待，周期加快比較容易在一個Sprint中交付可用的產(chǎn)品增量減少了團隊之間依賴，計劃會更容易責任范圍的擴大，各種不同領域的專家在一個團隊，增加了個人學習和團隊學習的機會用戶故事什么是用戶故事？用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：1.角色：誰要使用這個功能。2.活動：需要完成什么樣的功能。3.商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。用戶故事通常按照如下的格式來表達：英文：Asa,Iwantto,sothat.中文：作為一個<角色>,我想要<活動>,以便于<商業(yè)價值>舉例：作為一個"網(wǎng)站管理員”，我想要"統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于"我的贊助商了解我的網(wǎng)站會給他們帶來什么收益?！毙枰⒁獾氖怯脩艄适虏荒軌蚴褂眉夹g語言來描述，要使用用戶可以理解的業(yè)務語言來描述。RonJeffries的3個C關于用戶故事，RonJeffries用3個C來描述它：卡片（Card）–用戶故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。交談（Conversation）-用戶故事背后的細節(jié)來源于和客戶或者產(chǎn)品負責人的交流溝通。確認（Confirmation）-通過驗收測試確認用戶故事被正確完成。用戶故事的六個特性-INVESTINVEST=Independent,Negotiable,Valuable,Estimable,Small,Testable一個好的用戶故事應該遵循INVEST原則，分別如下：獨立性（Independent）—要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優(yōu)先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性?？蓞f(xié)商性（Negotiable）—一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節(jié)。具體的細節(jié)在溝通階段產(chǎn)出。一個用戶故事卡帶有了太多的細節(jié)，實際上限制了和用戶的溝通。有價值（Valuable）—每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協(xié)商的時候，他們將非常樂意寫下故事?？晒浪阈裕‥stimable）—開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。但是讓開發(fā)者難以估計故事的問題來自：對于領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。短小（Small）—一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大?？蓽y試性（Testable）—一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，則你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易于使用的。敏捷估算無論是團隊研發(fā)一款產(chǎn)品或者開發(fā)*一個項目，我們都需要回答"我們大概什么時間能夠完成？”，或者到*一個時間點，我們能夠做到什么程度，因此和傳統(tǒng)的開發(fā)模式一樣，我們在工作開始之前需要對我們需要做的事情進行工作量的估算。相對與傳統(tǒng)的工作量估算方式，敏捷估算有如下幾個特點：團隊集體估算在Scrum的開發(fā)過程中，團隊共擔責任，集體承諾每個Sprint的工作，因此對于工作量的估算敏捷團隊采用集體估算的方式。集體估算，通常采用估算撲克作為工具，團隊通過玩估算游戲進行集體估算。使用估算撲克來做工作量估算是最有效，也是非常有趣的一種估算方式。估算撲克由一組類似斐波納契數(shù)列的數(shù)字組成，這些數(shù)字包括：0，0.5,1,2,3,5,8,20,40,",∞,每幅撲克有四組這樣的數(shù)字，可供4個人使用。估算撲克的使用方法：每個團隊成員拿到一組卡片，包括0,0.5,1,2,3,5,8,13,20,40,",∞,共計12張。產(chǎn)品負責人或者一名團隊成員扮演閱讀者的角色，他負責閱讀需要估算產(chǎn)品Backlog的條目，并且詢問大家是否有疑問。團隊討論這個條目。當團隊理解了這個條目之后，每個團隊成員按照自己的想法給出估算結果，并且選擇對應的撲克出牌，估算結果不能告訴其他人，出牌時數(shù)字朝下扣在桌面上。所有人都出牌之后，閱讀者向大家確認是否都已經(jīng)確定估算結果，確認后，數(shù)”1,2,3″,大家同時展示估算結果。團隊評估不同的估算結果.我們是否想法一致？我們是否存在分歧？有沒有什么是我沒有考慮到的？討論之后可以再估算一輪，最終團隊需要達成一致?；氐降诙?，開始估算下一個條目。關注Scrum中文網(wǎng)微信公眾號可以獲得微信版估算撲克。2.估算大小，而不是估算時間周期，使用相對估算，而不是絕對估算一瓶礦泉水，讓一個3歲的小妹妹把它喝完所花的時間和一個成年人把它喝完所花的時間肯定不一樣，因此同一項工作，不同能力的人完成它花費的時間顯然是不一樣的。如果我們要估算從家到公司的絕對距離時多少公里，您可能不一定知道，但是如果您時做地鐵上班，從家里到公司有多少站，你一定很容易知道，當我們知道有多少站之后，我們就可以大概清楚路上需要花多長時間了。敏捷估算時，我們不會估算絕對時間和周期，我們估算大小，和相對值，也就是倍數(shù)。敏捷估算時，我們使用故事點作為計量單位，它是一個倍數(shù)，我們會先找一個我們認為最小的一個功能的大小作為參考基準，定義為1個故事點，把其它的故事和它做比較，如果是2倍大小，就是2個故事點，如果是5倍大小，就是5個故事點。3.記錄每個Sprint的團隊速度團隊速率是一個Scrum團隊在一個Sprint中實際完成的故事點數(shù)，通過團隊速率可以知道團隊做的有多快。新開始的項目或產(chǎn)品開發(fā)，或者是新團隊，沒有初始速度，我們可以做1-2個Sprint測算一個速度，作為初始速度。在Sprint執(zhí)行過程中，我們要記錄每個Sprint的速度，為以后的計劃做參考。我們估算了產(chǎn)品Backlog的故事點總數(shù)，然后又知道了每個Sprint團隊的平均速度，則我們就可以推算我們大概需要多少個Sprint可以做完，這樣我們就得到了周期。SpringScrum是一種迭代和增量式的產(chǎn)品開發(fā)方法，Scrum通過Sprint來實現(xiàn)迭代。一個Sprint是指一個1周－4周的迭代，它是一個時間盒。Sprint的長度一旦確定，保持不變。Sprint的產(chǎn)出是"完成”的、可用的、潛在可發(fā)布的產(chǎn)品增量。Sprint在整個開發(fā)過程中的周期一致。新的Sprint在上一個Sprint完成之后立即開始。Sprint包含并由Sprint計劃會議、每日站會、開發(fā)工作、Sprint評審會議和Sprint回顧會議構成。Scrum采用迭代增量的方式，是因為需求是涌現(xiàn)的，我們對產(chǎn)品和需求的理解是漸進式的，Sprint長度越長，我們需要預測的越多，復雜度會提升、風險也會增加，所以Sprint的長度最多不超過4周。越來越多的團隊使用2周的Sprint，很多市場變化快、競爭激烈的領域，比如互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)產(chǎn)品開發(fā)團隊也會使用1周的迭代。在Sprint進行過程中，如下內(nèi)容不能發(fā)生變化：Sprint的目標Sprint的質(zhì)量目標和驗收標準開發(fā)團隊的組成集中優(yōu)勢兵力各個擊破在Sprint執(zhí)行的過程中，團隊要避免一個蘿卜一個坑的工作方式，團隊要協(xié)作，并且要集中優(yōu)勢兵力各個擊破。團隊按照蜂擁式（Swarming）的工作方式，團隊先集中工作在少數(shù)幾個需求上面，協(xié)作完成它們，然后在開始下一批需求。按照這樣的方式一方面可以加強團隊協(xié)作，另外也有利于及早完成一些需求，讓這些需求及早驗收。取消一個SprintSprint可以在Sprint時間盒結束之前取消。只有產(chǎn)品負責人才有取消Sprint的權力,但他做這樣的決定也可能是受到利益干系人、團隊或是ScrumMaster的影響。如果*個Sprint的目標過時了,則就需要取消該Sprint。比如公司的發(fā)展方向,或是市場、技術等情況發(fā)生了變化,這些變化都可能導致取消Sprint。總的來說,如果*個Sprint對于其所在環(huán)境來說失去了價值和意義,則它就應該被取消。然而,因為Sprint周期都較短,所以很少發(fā)生取消Sprint的情況。當*個Sprint被取消時,任何做完和"完成”的產(chǎn)品待辦事項列表條目都需要評審。假如有些條目已經(jīng)潛在可交付,那產(chǎn)品負責人就會采納它。所有未完成的條目就都要放回到產(chǎn)品待辦事項列表中,并重新估算?；ㄔ谒鼈兩砩系墓ぷ鲿杆儋H值,所以需要頻繁地重估。取消