Scrum敏捷項目管理知識

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