Scrum敏捷項目管理知識

1、SCRUMS捷管理知識一、 什 么是 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ā)。挑選的需求

2、 在 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 梳理會議(

3、 ProductBacklogRefinement )Sprint 計劃會議( SprintPlanningMeeting )每日站會( DailyScrumMeeting )Sprint 評審會議( SprintReviewMeeting )Sprint 回顧會議( SprintRetrospectiveMeeting)5 個價值承諾-愿意對目標(biāo)做出承諾專注-把你的心思和能力都用到你承諾的工作上去開放-Scrum把項目中的一切開放給每個人看尊重-每個人都有他獨(dú)特的背景和經(jīng)驗勇氣-有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM理論基礎(chǔ)Scrum 以經(jīng)驗性過程控制理論(經(jīng)驗主義)做為理論基礎(chǔ)

4、的過程。經(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)完成時，這個完成必須等同于他們對完成的定義。第二：檢驗( Inspectio

5、n )開發(fā)過程中的各方面必須做到足夠頻繁地檢驗， 確保能夠及時發(fā)現(xiàn)過程中的重大偏差。 在確 定檢驗頻率時， 需要考慮到檢驗會引起所有過程發(fā)生變化。 當(dāng)規(guī)定的檢驗頻率超出了過程檢 驗所能容許的程度， 那么就會出現(xiàn)問題。 幸運(yù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)展，做

6、出調(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 ：敏捷Lea n :精益Iterative ：迭代式的Iteration :迭代AgileManifesto :敏捷宣言Empirical :經(jīng)驗性的EmpiricalProcess :經(jīng)驗性過程Transparency :透明性Insp

7、ectandAdapt :檢視與調(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ù)清單SprintBur

8、n-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: 用戶故事，指一條需求S

9、toryPoint ：衡量用戶故事的工作量大小的計量單位Velocity: 團(tuán)隊速度SprintTask: 實現(xiàn)一條需求需要做的一個技術(shù)任務(wù)DefinitionofDone:DoD ，完成的定義Stakeholders ：干系人Backlog ：待辦列表Artifact ：工件Estimation ：估算Collaboration ：協(xié)作ScalingScrum ：大規(guī)模 Scrum三、SCRUM起源Scrum 的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時在犯規(guī)地點(diǎn)對陣爭球。爭球雙方各有8個隊員參與，各方出 3 名前鋒隊員，并肩各站成一橫排，面對面躬身互相頂肩，中間形成一條通道， 其他

10、前鋒隊員分別站在后面，后排隊員用肩頂住前鋒隊員的臀部，組成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)隊作

11、為一個整體前進(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 框架，并在 OOPSLA9上

12、公開發(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

13、為了管理軟件開發(fā)的活動， 我們會引入過程控制來管理它。 過程控制通常有兩種方式， 第一 種方式是預(yù)定義的過程，第二種方式是經(jīng)驗性過程。我們所熟知的是預(yù)定義的過程， 它通常是使用已知的方法解決已知的問題。 制造業(yè)的生產(chǎn)線 就是典型的預(yù)定義過程， 例如生產(chǎn)餅干、 啤酒、汽車的生產(chǎn)線等。 預(yù)定義的過程的特點(diǎn)是給 予固定的輸入， 得到固定的輸出，過程可重復(fù)。它的優(yōu)勢在于可以大規(guī)模批量生產(chǎn)。預(yù)定義 過程的缺點(diǎn)在于一旦過程定義出現(xiàn)錯誤，或產(chǎn)品設(shè)計上存在瑕疵，會造成比較大的損失。圖 02如果我們期望解決的問題比較復(fù)雜， 并且存在著較大的不確定性的時候， 我們需要使用經(jīng)驗 性過程。 經(jīng)驗性過程的特點(diǎn)是過程是不

14、能夠完全預(yù)先定義好， 結(jié)果是不可預(yù)知的， 生產(chǎn)過程 是不可重復(fù)的。比如研究一項新技術(shù)，下一盤棋，踢一場球賽，在過程運(yùn)行當(dāng)中，我們需要 通過不斷的獲得真實的反饋，然后進(jìn)行適應(yīng)和調(diào)整，使得過程能夠產(chǎn)出我們需要的結(jié)果?！霸谶^程運(yùn)行機(jī)制相當(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 過

15、程框架的基石包括如下三個方面：第一：透明性( 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ī)定的檢驗頻率超出了過程檢 驗

16、所能容許的程度， 那么就會出現(xiàn)問題。 幸運(yù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 回顧會議是用來回顧

17、已經(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)品功能的方法最大化反饋的機(jī)會。增量交付潛在可交付的產(chǎn)品增量保證了每個迭代都有潛在

18、可發(fā)布的版本。Scrum 角色之：產(chǎn)品負(fù)責(zé)人產(chǎn)品負(fù)責(zé)人負(fù)責(zé)最大化產(chǎn)品以及開發(fā)團(tuán)隊工作的價值。 實現(xiàn)這一點(diǎ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é)人是一個人，

19、而不是一個委員會。產(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)隊有以下幾

20、個特點(diǎ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中可能會受到技能限 制，從

21、而導(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通過改變這些交互

22、來最大化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)隊ScrumM

23、aster服務(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)用Scrum六、SCRU M的三個工件Scrum的工件以不同的方式展現(xiàn)工作和價值,可以用來提供透明性以及檢驗和適應(yīng)的機(jī)會。Scrum中所定義的工件能最大化關(guān)鍵信息的透明性，來保證Scrum團(tuán)隊成功地交付完成的增量。ProductBacklog -產(chǎn)品待辦事項列表產(chǎn)品待辦事項列表是一個排序的列表 ， 包含所有產(chǎn)品需要的東西

24、 ， 也是產(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)先級由高到低 排列的一個序列，

25、每個條目有唯一的順序。 排在頂部的產(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í)行的” ， 能在

26、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)品待辦事項列表梳理的時候， 條目會被評審和修

27、改。然而 ， 產(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 評

28、審時的剩余工作量做比較 , 來評估在希望的時間點(diǎn)完成預(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 代辦事

29、項列表是開發(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)

30、新工作時 , 開發(fā)團(tuán)隊需要將其追加到Sprint 待辦事項列表中去。 隨著任務(wù)進(jìn)行或者被完成 , 需要更新每項任務(wù)的估算剩余工作量。如果計劃中某個部分失去開發(fā)的意義 , 就可以將其除去。在 Sprint 內(nèi)只有開發(fā)團(tuán)隊可以對項列表是高度可見的 , 是對團(tuán)隊計劃在當(dāng)前Sprint 待辦事項列表進(jìn)行修改。 Sprint 待辦事Sprint 內(nèi)完成工作的實時反映 , 并且, 該列表只屬于開發(fā)團(tuán)隊。ProductBacklog 功能點(diǎn)被放到 Sprint 的固定周期中， SprintBacklog 會因為如下原因發(fā)生 變化:1. 隨著時間的變化， 開發(fā)團(tuán)隊對于需求有了更好的理解， 有可能發(fā)現(xiàn)需要增加一

31、些新的任務(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 中的任意時間點(diǎn) ,Sprint 待辦事項列表的所有剩余工作總和都可以被計算。開發(fā) 團(tuán)隊至少在每日例會時追蹤所有的剩余工作。開發(fā)團(tuán)隊每天追蹤剩余總和并預(yù)測達(dá)成Sprint 目標(biāo)的可能性。 通過在 Sp

32、rint 中不斷追蹤剩余工作 , 開發(fā)團(tuán)隊可以管理自己的進(jìn)度。Scrum 不考慮已經(jīng)花在 Sprint 待辦事項列表上的工作時間。我們只關(guān)心剩余工作和日期這 兩個變量。燃盡圖( BURN-DOWNCHART)Sprint 燃盡圖( SprintBurn-downChart)SprintBurndownChart 顯示了 Sprint 中累積剩余的工作量，它是一個反映工作量完成狀況 的趨勢圖。圖中 Y 軸代表的是剩余工作量， X 軸代表的是 Sprint 的工作日。在Sprint開始的時候，ScrumTeam會標(biāo)示和估計在這個 Sprint需要完成的詳細(xì)的任務(wù)。所 有這個 Sprint 中需要完

33、成，但沒有完成的任務(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的總剩余估算工作量的變化趨勢。X軸代表的項目周期，以 Sprint為單位，Y軸代表的是剩余工作量，通常以用戶故事點(diǎn)

34、、理想人 天或者 team-days 為單位。七、SCRU M的五個活動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)容：理想情況下

35、，下一個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活動：Spri nt計劃會議每個Sprint都以Sprint計劃會議作為開始，這是一個固定時長的會議，在這個會議中，Scrum團(tuán)隊共同選擇和理解在即將到來的Sprint中要完成的工作。整個團(tuán)隊都要參加Spri nt計劃會議。針對排好序的產(chǎn)品待辦事項列表(Product Backlog)，產(chǎn) 品負(fù)責(zé)人和開發(fā)團(tuán)隊成員討論每個事項，

36、并對該事項達(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)隊介紹排好序的

37、產(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)隊強(qiáng)加更多的工作量。通常 Sprint 都有個目標(biāo) ， 稱作 Sprint 目標(biāo)。這將十分有效地幫助大家更加專注于需要完成 的工 作的本質(zhì) ， 而不必花太多精力去關(guān)注那些對于我們需要完成的工作并不重要的 ?小細(xì) 節(jié)。第二部分 : 如何完成工作 ?在會議的第二部分 ?里 ， 開發(fā)團(tuán)

38、隊需要根據(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á)成共識 ，

39、并預(yù)期在一個合理的條件范圍內(nèi)完成它們。開發(fā)團(tuán)隊預(yù)測并共同承諾 他們要完成的工作量?？偠?？言之：在Sprint計劃會議中，開發(fā)團(tuán)隊和產(chǎn)品負(fù)責(zé)人一起考慮并討論產(chǎn)品待辦事項 ， 確保他們對這些事項的理解 ， 選擇一些他們預(yù)測能完成的事項 ， 創(chuàng)建足 夠詳細(xì)的計劃來確保他們能夠完成這些事項。最終產(chǎn)生的待辦事項列表就是“ Sprint 待辦事項列表 (Sprint Backlog) ”。Scrum 活動 ： 每日 Scrum 會議開發(fā)團(tuán)隊是自組織的。開發(fā)團(tuán)隊通過每日Scrum會議來確認(rèn)他們?nèi)匀豢梢詫崿F(xiàn)Sprint的目標(biāo)。 這個會議每天在同樣的時間和同樣的地點(diǎn)召開。每一個開發(fā)團(tuán)隊成員需要提供以下三 點(diǎn)信息

40、 ：從上一個每日 Scrum 到現(xiàn)在 ， 我完成了什么 ; 從現(xiàn)在到下一個每日 Scrum， 我計劃完成什么 ;有什么阻礙了我的進(jì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是Scru

41、m的一個關(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)出

42、會涉及到一些 ?人的“利益”, 因此一個明 智的做法是邀請他們參加這個會議 ， 這會很有幫助。 這個會議是個 ?非正式的會 議， 幫助?大家了解我們?目前進(jìn)展到哪 ?里，并一起討論我們下一步如何推進(jìn)。每個?人都可以在 Sprint 評審會議 上發(fā)表意?見。 當(dāng)然， 產(chǎn)品負(fù)責(zé) ?人會對未來做出最終的決定 ， 并適當(dāng)?shù)卣{(diào)整產(chǎn)品待辦事項列表（Product Backlog） 。團(tuán)隊會找到他們自己的方式來開Sprint 評審會議。 通常會演?示產(chǎn)品增量 ，整個小組也會經(jīng)常討論他們在 Sprint 中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。他們還會討論產(chǎn)品待辦 事項列表 的狀態(tài)、可能的完成日期以及在這些日

43、期前能完成什么。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 回

44、顧會議時長為 2個小時）。Scrum團(tuán)隊總是在 Scrum的框架內(nèi)，改進(jìn)他們自己的流程。八、SCRU M的五個價值觀承諾-愿意對目標(biāo)做出承諾專注-把你的心思和能力都用到你承諾的工作上去開放-Scrum把項目中的一切開放給每個人看尊重-每個人都有他獨(dú)特的背景和經(jīng)驗勇氣-有勇氣做出承諾，履行承諾，接受別人的尊重九、SCRUM的四大支柱迭代開發(fā)在 Scrum 的開發(fā)模式下， 我們將開發(fā)周期分成多個 1-4 周的迭代， 每個迭代都交付一些增量 的可工作的功能。 迭代的長度是固定的， 如果我們選擇了 1 周的迭代， 那么保持它的長度不 要發(fā)生變化， 在整個產(chǎn)品開發(fā)周期內(nèi)每個迭代都是1 周的長度。 這里需

45、要強(qiáng)調(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)隊還

46、需要自己監(jiān)督和管理他們的工程過程 和進(jìn)度，自組織團(tuán)隊自己決定團(tuán)隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。 高優(yōu)先級的需求驅(qū)動在 Scrum 中，我們使用 Product Backlog 來管理需求， Product Backlog 是一個需求的清單， Product Backlog 中的需求是漸進(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ì)化之后

47、。我們可以在開發(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 ,Scrum Master和開發(fā)團(tuán)隊。我們通常可以以劃龍舟的團(tuán)隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團(tuán)隊三個角色。Scrum中的P0就是舵手的角色，他對產(chǎn)品的方向負(fù)責(zé)，對產(chǎn)品的Why和What負(fù)責(zé)，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負(fù)責(zé)。Scrum中的Scrum Master

48、鼓手的角色，他幫助團(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)境下單打獨(dú)斗，各自為政沒有任何勝算。Scrum的開發(fā)團(tuán)隊對實現(xiàn) Sprint目標(biāo)需要做的所有事情負(fù)責(zé)，包括技術(shù)方案和決策，團(tuán)隊 分工（誰做什么），執(zhí)行 Spri nt開發(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)整每個迭

49、代對產(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)利。

50、對于經(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)

51、隊訓(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)隊不

52、是與生俱來的， 打造一個團(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)該按照什么方式來劃分呢？在

53、傳統(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è)更

54、加單一化第四：Sprint結(jié)束的時候無法提交可交付的增量產(chǎn)品功能，延遲價值交付按照Scrum和敏捷的交付模式， 以用戶為中心，按照用戶場景作為邊界來組織團(tuán)隊是比較推 薦的做法。這種以用戶為中心的團(tuán)隊叫做特性團(tuán)隊。特性團(tuán)隊的特點(diǎn)：長期穩(wěn)定的團(tuán)隊，逐個端到端完成客戶特性以客戶為中心的特性驅(qū)動跨職能、完整團(tuán)隊共享代碼庫，統(tǒng)一的持續(xù)集成擁有通用型專家特性團(tuán)隊看起來像這個樣子：特性團(tuán)隊的好處：團(tuán)隊內(nèi)可以做到端到端，所以減少了等待，周期加快比較容易在一個Spri nt中交付可用的產(chǎn)品增量減少了團(tuán)隊之間依賴，計劃會更容易責(zé)任范圍的擴(kuò)大，各種不同領(lǐng)域的專家在一個團(tuán)隊，增加了個人學(xué)習(xí)和團(tuán)隊學(xué)習(xí)的 機(jī)會十三、 用

55、戶故事什么是用戶故事？用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：角色：誰要使用這個功能?；顒樱盒枰瓿墒裁礃拥墓δ?。商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。用戶故事通常按照如下的格式來表達(dá)：英文：As a , I want to , so that .中文：作為一個 角色 ,我想要 活動 ,以便于 商業(yè)價值舉例：作為一個“網(wǎng)站管理員”，我想要“統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊 助商了解我的網(wǎng)站會給他們帶來什么收益。 需要注意的是用戶故事不能夠使用技術(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描 述。Ron Jeffries 的

56、 3 個 C關(guān)于用戶故事，Ron Jeffries 用3個C來描述它：卡片(Card)-用戶故事一般寫在小的記事卡片上?？ㄆ峡赡軙懮瞎适碌暮?短描述，工作量估算等。交談(Conversation )-用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流 溝通。確認(rèn)(Confirmation )-通過驗收測試確認(rèn)用戶故事被正確完成。用戶故事的六個特性-INVESTINVEST = In depe nden t, Negotiable, Valuable, Estimable, Small, Testable一個好的用戶故事應(yīng)該遵循INVEST原則，分別如下：獨(dú)立性(Independent )

57、要盡可能的讓一個用戶故事獨(dú)立于其他的用戶故事。用 戶故事之間的依賴使得制定計劃，確定優(yōu)先級，工作量估算都變得很困難。通常我們可 以通過組合用戶故事和分解用戶故事來減少依賴性。可協(xié)商性(Negotiable ) 一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細(xì)節(jié)。具體 的細(xì)節(jié)在溝通階段產(chǎn)出。一個用戶故事卡帶有了太多的細(xì)節(jié)，實際上限制了和用戶的溝 通。有價值(Valuable )每個故事必須對客戶具有價值(無論是用戶還是購買方)。 一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用 戶故事并不是一個契約而

58、且可以進(jìn)行協(xié)商的時候，他們將非常樂意寫下故事。可估算性(Estimable )開發(fā)團(tuán)隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏(這種情 況下需要更多的溝通)，或者故事太大了(這時需要把故事切分成小些的)。短小(Small) 一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量，至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風(fēng)險就會越大?？蓽y試性(Testable )一個用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知

59、道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。十四、敏捷估算無論是團(tuán)隊研發(fā)一款產(chǎn)品或者開發(fā)某一個項目，我們都需要回答“我們大概什么時間能夠完成？ ”，或者到某一個時間點(diǎn)，我們能夠做到什么程度，因此和傳統(tǒng)的開發(fā)模式一樣，我們在工作開始之前需要對我們需要做的事情進(jìn)行工作量的估算。相對與傳統(tǒng)的工作量估算方式，敏捷估算有如下幾個特點(diǎn)：團(tuán)隊集體估算在Scrum的開發(fā)過程中，團(tuán)隊共擔(dān)責(zé)任，集體承諾每個Sprint的工作，因此對于工作量的估算敏捷團(tuán)隊采用集體估算的方式。集體估算，通常采用估算撲克作為工具，團(tuán)隊通過玩估算游戲進(jìn)行集體估算。使用估算撲克來做工作量估算是最有效，也是非常有

60、趣的一種估算方式。估算撲克由一組類似斐波納契數(shù)列的數(shù)字組成，這些數(shù)字包括：0, ,1,2,3,5,8,20,40,?,每幅撲克有四組這樣的數(shù)字，可供4個人使用。估算撲克的使用方法：每個團(tuán)隊成員拿到一組卡片，包括0,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)后