SCRUM是一個用于開發(fā)和維持復(fù)雜產(chǎn)品的框架

1、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團隊總是先開發(fā)對客戶具有較高價值的需求。在 Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得

2、到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog 。在每個迭代結(jié)束時，Scrum團隊將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開發(fā)項目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項目。Scrum流程如下圖：WWW.se HUMCMXOM ECRU 岫中更“SCRUM匡架包括3個角色、3個工件、5個 活動、5個價值3個角色1. 產(chǎn)品負(fù)責(zé)人(Product Owner )2. Scrum Master3. Scrum 團隊3個工件1 .產(chǎn)品 Backlog (Product Backlog )2 . SprintBacklog3 .燃盡圖(Burn-down Chart)5個活動1. Spri

3、nt 計劃會議(Sprint Planning Meeting )2. 每日站會(Daily Scrum Meeting )3. Sprint 評審會議(Sprint Review Meeting )4. Sprint 回顧會議(Sprint Retrospective Meeting )5. 產(chǎn)品 Backlog 梳理會議(Product Backlog Refinement )5個價值1 .承諾-愿意對目標(biāo)做出承諾2 .專注- 把你的心思和能力都用到你承諾的工作上去3 .開放-Scrum把項目中的一切開放給每個人看4 .尊重-每個人都有他獨特的背景和經(jīng)驗5 .勇氣-有勇氣做出承諾，履行承諾

4、，接受別人的尊重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ù)

5、已經(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)品是不合 格的，那么便需要對過程或是材料進行調(diào)整。調(diào)整工作必須盡快實施，以減少進一步的偏差。Scrum中通過三個活動

6、進行檢驗和適應(yīng)：每日例會檢驗Sprint目標(biāo)的進展，做出調(diào)整，從而優(yōu)化次日的工作價值； Sprint評審和計劃會議檢驗發(fā)布目標(biāo)的進展，做出調(diào)整，從而優(yōu)化下一個 Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Sprint ,并且確定做出什么樣的改善可以使接下來的 Sprint更加高效、更加令人滿意，并且工作更快樂。SCRUMSScrum： Scrum無對應(yīng)中文翻譯Agile : 敏捷Lean: 精益Iterative :迭代式的Iteration :迭代Agile Manifesto : 敏捷宣言Empirical : 經(jīng)驗性的Empirical Process :經(jīng)驗性過程T

7、ransparency :透明性Inspect and Adapt :檢視與調(diào)整Sprint :原意為沖刺，Scrum中的Sprint無對應(yīng)中文翻譯，指一個迭代Sprint Goal : Sprint 目標(biāo)Product Owner :產(chǎn)品負(fù)責(zé)人 簡稱POScrum Master :簡稱SM, 一般不翻譯Development Team : Scrum 開發(fā)團隊Scrum Team：指PO,SM和開發(fā)團隊Scrum Roles : Scrum角色，指 PO,SM和開發(fā)團隊Emergent :涌現(xiàn)的Product Backlog :產(chǎn)品待辦列表，指需求清單Sprint Backlog : Spr

8、int待辦列表，指 Sprint 任務(wù)清單Sprint Burn-down Chart : Sprint燃盡圖，團隊用于做Sprint內(nèi)的進展跟蹤Release Burn-down Chart:發(fā)布燃盡圖，產(chǎn)品負(fù)責(zé)人做發(fā)布進展跟蹤Sprint Planning Meeting: Sprint計劃會議Daily Scrum Meeting :每日站會Sprint Review Meeting : Sprint 評審會議Sprint Retrospective Meeting: Sprint回顧會議Product Backlog Refinement:產(chǎn)品待辦列表梳理Product Backlog

9、 Item:產(chǎn)品待辦清單條目，簡稱 PBIUser Story: 用戶故事，指一條需求Story Point :衡量用戶故事的工作量大小的計量單位Velocity:團隊速度Sprint Task:實現(xiàn)一條需求需要做的一個技術(shù)任務(wù)Definition of Done: DoD ,完成的定義Stakeholders :干系人Backlog :待辦列表Artifact :工件Estimation :估算Collaboration :協(xié)作Scaling Scrum :大規(guī)模 ScrumSCRUMSScrum的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時在犯規(guī)地點對陣爭球。爭球雙方各有8個隊員參與

10、，各方出3名前鋒隊員，并肩各站成一橫排，面對面躬身互相頂肩，中間形成一條通道，其 他前鋒隊員分別站在后面，后排隊員用肩頂住前鋒隊員的臀部，組成3、2、3或3、4、1陣形。然后，由犯規(guī)隊的對方隊員在對陣一側(cè)1碼外，用雙手低手將球拋入通道，不得有利于本隊。當(dāng)球拋入通道時，前排的3對前鋒隊員互相抗擠，爭相踢球給本方前衛(wèi)或后衛(wèi)隊員，前衛(wèi)和后衛(wèi)隊員必須等候前鋒將球踢回后，方可移動。1986 Scrum這個詞匯首次應(yīng)用于產(chǎn)品開發(fā)1986年，竹內(nèi)弘高和野中郁次郎在 New New Product DevelopmentGame文章首次提到將Scrum應(yīng)用與產(chǎn)品開發(fā)，他們指出：傳統(tǒng)的“接力式”的開發(fā)模式已經(jīng)不

11、能滿足快速靈活的市場需求，而整體或“橄欖球式”的方 法一一團隊作為一個整體前進，在團隊的內(nèi)部傳球并保持前進，這也許可以更好的滿足當(dāng)前激 烈的市場競爭。1993年Jeff Sutherland 首次將Scrum用于軟件開發(fā)敏捷思想深受日本工業(yè)界最佳實踐的影響，尤其是豐田和本田公司推行的精益原則，以及竹內(nèi) 弘高和 野中郁次郎開發(fā)的知識管理策略。受到以上思想的影響，以及對世界范圍內(nèi)軟件項目的 研究，Jeff Sutherland 在1993年首次在 Easel公司定義了用于了軟件開發(fā)行業(yè)的Scrum流程，并開始實施。1995 年 Jeff Sutherland 和 Ken Schwaber 規(guī)范化了

12、 Scrum 框架，并在 OOPSLA 95上公開發(fā) 布。2001年敏捷宣言及原則發(fā)布、敏捷聯(lián)盟成立，Scrum是其中一種敏捷方法。2001年，Ken Schwaber和Mike Beedle 推出第一本 Scrum書籍Scrum敏捷軟件開發(fā)。2002 年 Ken Schwaber 和 Mike Cohn 共同創(chuàng)辦了 Scrum 聯(lián)盟。經(jīng)驗性過程軟件開發(fā)是一個復(fù)雜的活動，在軟件產(chǎn)品開發(fā)的過程中不僅存在著需求的不確定性，也存在著技術(shù)的不確定性，再加上參與軟件開發(fā)的主體通常是由多人組成的軟件開發(fā)團隊，加上人的因素，就讓整個軟件開發(fā)的活動變得非常復(fù)雜。如下圖所示，軟件開發(fā)活動通常處在下圖的很復(fù) 雜的

13、區(qū)域。需求的不確定性技術(shù)的不確定性圖-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)驗性過

14、程的特點是過程是不能夠完全預(yù)先定義好，結(jié)果是不可預(yù)知的，生產(chǎn)過程是不 可重復(fù)的。比如研究一項新技術(shù)，下一盤棋，踢一場球賽，在過程運行當(dāng)中，我們需要通過不 斷的獲得真實的反饋，然后進行適應(yīng)和調(diào)整，使得過程能夠產(chǎn)出我們需要的結(jié)果?！霸谶^程運行機制相當(dāng)簡單易懂的情況下，典型的做法是采用預(yù)定義的建模方式。如果過程復(fù)雜程度超出預(yù)定義方式的能力范圍，便應(yīng)用經(jīng)驗性方式。”B.A.Ogunnaike and W.H.Ray過程動態(tài)學(xué)、建模與控制軟件產(chǎn)品的研發(fā)通常存在多很多的不確定性，并且生產(chǎn)的過程非常的復(fù)雜，所以更適合使用經(jīng) 驗性過程來管理。Scrum以經(jīng)驗性過程控制理論做為理論基礎(chǔ)的過程。Scrum采用迭代

15、、增量的方法來優(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ī)定的

16、檢驗頻率超出了過程檢驗所 能容許的程度，那么就會出現(xiàn)問題。幸運的是，軟件開發(fā)并不會出現(xiàn)這種情況。另一個因素就 是檢驗工作成果人員的技能水平和積極性。第三：適應(yīng)(Adaptation )如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標(biāo)準(zhǔn)，并且最終產(chǎn)品是不合 格的，那么便需要對過程或是材料進行調(diào)整。調(diào)整工作必須盡快實施，以減少進一步的偏差。Scrum中通過三個活動進行檢驗和適應(yīng)：每日例會檢驗Sprint目標(biāo)的進展，做出調(diào)整，從而優(yōu)化次日的工作價值；Sprint評審和計劃會議檢驗發(fā)布目標(biāo)的進展，做出調(diào)整，從而優(yōu)化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Spr

17、int ,并且確定做出什么樣的改善可以使接下來的 Sprint更加高效、更加令人滿意，并且工作更快樂。SCRUhffl隊的三個角色Scrum團隊中包括三個角色，他們分別是產(chǎn)品負(fù)責(zé)人、開發(fā)團隊和Scrum Master。Scrum團隊是自組織、跨職能的完整團隊。自組織團隊決定如何最好地完成他們的工作，而不是由團隊外的其他人來指揮他們。跨職能的團隊擁有完成工彳所需要的全部技能，不需要依賴團隊外部的人。Scrum團隊模式的目的是最大限度地優(yōu)化適應(yīng)性、創(chuàng)造性和生產(chǎn)力。Scrum團隊通過迭代和增量交付產(chǎn)品功能的方法最大化反饋的機會。增量交付潛在可交付的產(chǎn) 品增量保證了 每個迭代都有潛在可發(fā)布的版本。Sc

18、rum角色之：產(chǎn)品負(fù)責(zé)人產(chǎn)品負(fù)責(zé)人負(fù)責(zé)最大化產(chǎn)品以及開發(fā)團隊工作的價值。實現(xiàn)這一點的方式會隨著組織、Scrum團隊以及單個團隊成員的不同而不同。產(chǎn)品負(fù)責(zé)人是管理產(chǎn)品待辦事項列表的唯一責(zé)任人。產(chǎn)品待辦事項列表的管理包括：? 清晰地表達產(chǎn)品代辦事項列表條目? 對產(chǎn)品代辦事項列表中的條目進行排序，最好地實現(xiàn)目標(biāo)和使命? 確保開發(fā)團隊所執(zhí)行工作的價值? 確保產(chǎn)品代辦事項列表對所有人可見、透明、清晰 ，并且顯示Scrum團隊的下一步工 作? 確保開發(fā)團隊對產(chǎn)品代辦事項列表中的條目達到一定程度的理解產(chǎn)品負(fù)責(zé)人可以親自完成上述工作，也可以讓開發(fā)團隊來完成。然而，產(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ā)團隊按照另一套需求開展工作，開發(fā)團隊也不允許聽從任何其他人的指令。Scrum角色之：開發(fā)團隊開發(fā)團隊包含了專業(yè)人員，負(fù)責(zé)在每個Sprint 的結(jié)尾交付潛在可發(fā)布的“完成”產(chǎn)品增量。只有開發(fā)團隊的成員才能創(chuàng)造增量。開發(fā)團隊由組織構(gòu)建并授權(quán) ，來組織和管理他們的工作。所產(chǎn)生的協(xié)同工作能最大化開發(fā)團隊的整體效率和效力。開發(fā)團隊有以下幾

20、個特點：?他們是自組織的，沒有人（即使是Scrum Master 都不可以）告訴開發(fā)團隊如何把產(chǎn)品代辦事項列表變成潛在可發(fā)布的功能。?開發(fā)團隊是跨職能的，團隊作為一個整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。? Scrum不認(rèn)可開發(fā)團隊成員的頭銜，無論承擔(dān)哪種工作他們都是開發(fā)者。此規(guī)則無一例夕卜。?開發(fā)團隊中的每個成員可以有特長和專注領(lǐng)域，但是責(zé)任歸屬于整個開發(fā)團隊?開發(fā)團隊不包含如測試或業(yè)務(wù)分析等負(fù)責(zé)特定領(lǐng)域的子團隊。開發(fā)團隊的規(guī)模開發(fā)團隊最佳規(guī)模是小到足以保持敏捷性，大到足以完成重要工作。少于 3人的開發(fā)團隊沒有足夠的交互，因而所獲得的生產(chǎn)力增長也不會很大。小團隊在 Sprint中可能會受到技

21、能限制從而導(dǎo)致無法交付可發(fā)布的產(chǎn)品增量。大于9人的團隊需要過多的協(xié)調(diào)溝通工作。大型團隊會產(chǎn)生太多復(fù)雜性，不便于經(jīng)驗過程管理。產(chǎn)品負(fù)責(zé)人和 Scrum Master 的角色不包含在此數(shù)字 中，除非他們也參與執(zhí)行 Sprint 代表事項列表中的工作。Scrum 角色之：Scrum MasterScrum Master負(fù)責(zé)確保 Scrum 被理解并實施。為了達到這個目的，Scrum Master 要確保Scrum團隊遵循Scrum 的理論、實踐和規(guī)則。Scrum Master是Scrum團隊中的服務(wù)式領(lǐng)導(dǎo)。Scrum Master幫助Scrum團隊外的人員了解他們?nèi)绾闻cScrum團隊交互是有益的。S

22、crumMaster通過改變這些交互來最大化Scrum團隊所創(chuàng)造的價值。Scrum Master服務(wù)于產(chǎn)品負(fù)責(zé)人Scrum Master以各種方式服務(wù)于產(chǎn)品負(fù)責(zé)人，包括：?找到有效管理產(chǎn)品代辦事項列表的技巧? 清晰地和開發(fā)團隊溝通愿景、目標(biāo)和產(chǎn)品代表事項列表條目? 教導(dǎo)開發(fā)團隊創(chuàng)建清晰簡明的產(chǎn)品代表事項列表條目? 在經(jīng)驗主義環(huán)境中理解長期的產(chǎn)品規(guī)劃? 理解并實踐敏捷? 按需推動Scrum活動Scrum Master服務(wù)于開發(fā)團隊Scrum Master以各種方式服務(wù)于開發(fā)團隊 ，包括：? 指導(dǎo)開發(fā)團隊自組織和跨職能? 教導(dǎo)并領(lǐng)導(dǎo)開發(fā)團隊創(chuàng)造高價值的產(chǎn)品? 移除開發(fā)團隊進展過程中的障礙? 按需推

23、動Scrum活動? 在Scrum還未完全被采納和理解的組織環(huán)境下指導(dǎo)開發(fā)團隊Scrum Master以各種方式服務(wù)于組織 ，包括：? 領(lǐng)導(dǎo)并指導(dǎo)組織采用 Scrum? 在組織范圍內(nèi)計劃 Scrum的實施? 幫助員工及干系人理解并實施Scrum和經(jīng)驗性產(chǎn)品開發(fā)? 發(fā)起能提升Scrum團隊生產(chǎn)力的變革? 與其他Scrum Master 一起工作，幫助組織更有效的應(yīng)用ScrumSCRUM勺三個工件Scrum的工件以不同的方式展現(xiàn)工作和價值，可以用來提供透明性以及檢驗和適應(yīng)的機會。Scrum中所定義的工件能最大化關(guān)鍵信息的透明性，來保證Scrum團隊成功地交付完成的增量。Product Backlog

24、 -產(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)境的變化而演進。待辦事項列表是動態(tài)的，它經(jīng)常發(fā)生變化以識別使產(chǎn)品合理、有競爭力和有用所必需的東西。只要產(chǎn)品存在，產(chǎn)品待辦事項列表就存在。產(chǎn)品待辦事項列表列出了所有的特性、功能、需求、改進方法和缺陷修復(fù)等對未來發(fā)布產(chǎn)品進行的改變。產(chǎn)品待辦事項列表條目包含描述、次序和估算的特征。產(chǎn)品待辦事項列表通常以價值、風(fēng)險、優(yōu)先級和必須性排序

25、。它是一個按照優(yōu)先級由高到低排 列的一個序列，每個條目有唯一的順序。排在頂部的產(chǎn)品待辦事項列表條目需要立即進行開 發(fā)。排序越高，產(chǎn)品待辦事項列表條目越緊急，就越需要仔細(xì)斟酌，并且對其價值的意見越一致。更詳盡的排序越高的產(chǎn)品待辦事項列表條目比排序低的更清晰、更具體。根據(jù)更清晰的內(nèi)容和信息就能做出更準(zhǔn)確的彳算。優(yōu)先級越低，細(xì)節(jié)信息越少。開發(fā)團隊在接下來的Sprint 中將要進行開發(fā)的產(chǎn)品待辦事項列表條目是細(xì)粒度的，已經(jīng)被分解過，因此，任何一個條目在Sprint的時間盒內(nèi)都可以被“完成”。開發(fā)團隊在一個Sprint 中可以“完 成”的產(chǎn)品待辦事項列表條目被認(rèn)為是“準(zhǔn)備好的”或者“可執(zhí)行的”，能在Sp

26、rint 計劃會議中被選擇。隨著產(chǎn)品的使用、價值的獲取以及市場的反饋，產(chǎn)品待辦事項列表變成了更大、更詳 盡的列表。因為需求永遠(yuǎn)不會停止改變，所以產(chǎn)品待辦事項列表是個不斷更新的工件。業(yè) 務(wù)需求、市場形勢和技術(shù)的變化都會引起產(chǎn)品待辦事項列表的變化。若干個Scrum團隊常常會一起開發(fā)某個產(chǎn)品。但描述下一步產(chǎn)品開發(fā)工作的產(chǎn)品待辦事項列表 只能有一個。那么這就需要使用對產(chǎn)品待辦事項列表條目進行分組的屬性。通過產(chǎn)品Backlog地梳理來增添細(xì)節(jié)、估算和排序。這是一個持續(xù)不斷 的過程，產(chǎn)品負(fù)責(zé)人和 開發(fā)團隊協(xié)作討論產(chǎn)品代表事項列表條目的細(xì)節(jié)。在產(chǎn)品待辦事項列表梳理的時候，條目會被評審和修改。然而，產(chǎn)品負(fù)責(zé)人

27、可以隨時更新產(chǎn)品代辦事項列表條目或酌情決定。梳理在Sprint中是一項兼職活動，在產(chǎn)品負(fù)責(zé)人和開發(fā)團隊之間展開。通常，開發(fā)團隊有自行優(yōu)化的領(lǐng)域知識。然而，何時如何完成優(yōu)化是 Scrum團隊的決定。優(yōu)化通常占用不超過開發(fā)團 隊10%的時間。開發(fā)團隊負(fù)責(zé)所有的估算工作。產(chǎn)品負(fù)責(zé)人可以通過協(xié)助團隊權(quán)衡取舍來影響他們的決定。但是，最后的估算是由執(zhí)行工作的人來決定的。監(jiān)控向目標(biāo)前進的進度在任何時間，達成目標(biāo)的剩余工作量是可以被累計的。產(chǎn)品負(fù)責(zé)人至少在每個Sprint 評審的時候追蹤剩余工作總量。產(chǎn)品負(fù)責(zé)人把這個數(shù)量與之前Sprint 評審時的剩余工作量做比較，來評估在希望的時間點完成預(yù)計工作達成目標(biāo)的進

28、度。這份信息對所有的干系人都透明。Scrum不考慮已經(jīng)花在產(chǎn)品代辦事項列表條目上的工作時間。我們只關(guān)心剩余工作和日期這兩 個變量。各種趨勢燃盡圖、燃燒圖和其他計劃實踐都能用來預(yù)測進度。它們已經(jīng)被證實有用。然而，這并不能代替經(jīng)驗主義的重要性。在復(fù)雜的環(huán)境下，將要發(fā)生的東西是未知的 ，只有已經(jīng)發(fā)生的事情才能用來做前瞻式的決策。SPRINT BACKLOGSprint代辦事項列表是一組為當(dāng)前 Sprint 選出的產(chǎn)品代辦事項列表條目，外加交付產(chǎn)品增量 和實現(xiàn)Sprint 目標(biāo)的計劃。Sprint代辦事項列表是開發(fā)團隊對于哪些功能要包含在下個增量中，以及交付那些功能所需工作的預(yù)計。Sprint代辦事項

29、列表定義了開發(fā)團隊把產(chǎn)品代辦事項列表條目轉(zhuǎn)換成“完成”的增量所需要執(zhí)行的工作。Sprint代辦事項列表使開發(fā)團隊確定的、達到 Sprint 目標(biāo)所需的工作清晰可 見。Sprint代辦事項列表是一份足夠具體的計劃，使得進度上的改變能在每日例會中得到理解。開發(fā)團隊在整個 Sprint中都會修改 Sprint 代辦事項列表，Sprint 代辦事項列表也 會在Sprint的進程中慢慢顯現(xiàn)，比如開發(fā)團隊按照計劃工作并對完成Sprint目標(biāo)所需的工作有更多的了解。當(dāng)出現(xiàn)新工作時，開發(fā)團隊需要將其追加到 Sprint 待辦事項列表中去。隨著任務(wù)進行或者被完成，需要更新每項任務(wù)的估算剩余工作量。如果計劃中某個

30、部分失去開發(fā)的意義，就可以將其除去。在Sprint內(nèi)只有開發(fā)團隊可以對Sprint 待辦事項列表進行修改。 Sprint 待辦事項列表是高度可見的，是對團隊計劃在當(dāng)前 Sprint 內(nèi)完成工作的實時反映，并且，該列表只屬于開發(fā)團隊。Product Backlog功能點被放到 Sprint的固定周期中， Sprint Backlog會因為如下原因發(fā)生變化：1 .隨著時間的變化，開發(fā)團隊對于需求有了更好的理解，有可能發(fā)現(xiàn)需要增加一些新的任務(wù)到 Sprint Backlog 中。2 .程序缺陷做為新的任務(wù)加進來，這個都做為承諾提交任務(wù)中未完成的工作。Product Owner也許會和 Scrum t

31、eam 一起工作，以幫助 team更好的理解 Sprint的目標(biāo)， ScrumMaster和team也許會覺得小的調(diào)整不會影響 sprint的進度，但會給客戶帶來更多商業(yè) 價值。監(jiān)控Sprint 進度在Sprint 中的任意時間點,Sprint 待辦事項列表的所有剩余工作總和都可以被計算。開發(fā)團隊至少在每日例會時追蹤所有的剩余工作。開發(fā)團隊每天追蹤剩余總和并預(yù)測達成Sprint 目標(biāo)的可能性。通過在 Sprint 中不斷追蹤剩余工作，開發(fā)團隊可以管理自己 的進度。Scrum不考慮已經(jīng)花在 Sprint 待辦事項列表上的工作時間。我們只關(guān)心剩余工作和日期這兩 個變量。燃盡圖(BURN-DOWN

32、CHART)Sprint 燃盡圖(Sprint Burn-down Chart)Sprint Burndown Chart 顯示了 Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的 趨勢圖。圖中Y軸代表的是剩余工作量，X軸代表的是Sprint的工作日。hex在Sprint開始的時候，Scrum Team會標(biāo)示和估計在這個 Sprint需要完成的詳細(xì)的任務(wù)。所有這個Sprint中需要完成，但沒有完成的任務(wù)的工作量是累積工作量，團隊會根據(jù)進展情況每天更新累積工作量，如果在Sprint結(jié)束時，累積工作量降低到0, Sprint就成功結(jié)束。由于在Sprint的剛開始的時候，增加的任務(wù)工作量

33、可能大于完成的任務(wù)工作量，所以燃盡圖有 可能略微呈上升趨勢。發(fā)布燃盡圖(Release Burn-down Chart )在Scrum項目中，團隊通過每個 Sprint結(jié)束時更新的發(fā)布燃盡圖來跟蹤整個發(fā)布計劃的進展。發(fā)布燃盡圖記錄了在一段時間內(nèi)產(chǎn)品Backlog的總剩余估算工作量的變化趨勢。X軸代表的項目周期，以Sprint為單位，Y軸代表的是剩余工作量，通常以用戶故事點、理想人天或者 team-days 為單位。SCRUM勺五個活動Scrum活動：產(chǎn)品待辦事項列表梳理產(chǎn)品待辦事項通常會很大 ，也很寬泛，而且想法會變來變?nèi)ァ?yōu)先級也會變化，所以產(chǎn)品待 辦事項列表梳理是一個貫穿整個Scrum項目

34、始終的活動。該活動包含但不限于以下的內(nèi)容：? 保持產(chǎn)品待辦事項列表有序? 把看起來不再重要的事項移除或者降級? 增加或提升涌現(xiàn)出來的或變得更重要的事項? 將事項分解成更小的事項? 將事項歸并為更大的事項? 對事項進行估算產(chǎn)品待辦事項列表梳理的一個最大好處是為即將到來的幾個Sprint做準(zhǔn)備。為此，梳理時會特別關(guān)注那些即將被實現(xiàn)的事項。需要考慮不少因素，這包括但不限于以下的內(nèi)容 ：理想情況下，下一個Sprint的備選事項都應(yīng)該提升“商業(yè)價值”。開發(fā)團隊需要能夠在一個Sprint內(nèi)完成每一個事項。每個人都需要清楚預(yù)期產(chǎn)出是什么。產(chǎn)品開發(fā)決定了 ，有可能需要其它的技能和輸入。因此 ，產(chǎn)品待辦事項列表

35、梳理最好是所有團隊 成員都參與的活動，而不單單是產(chǎn)品負(fù)責(zé)人。Scrum活動：Sprint計劃會議每個Sprint都以Sprint計劃會議作為開始，這是一個固定時長的會議，在這個會議中 ，Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。整個團隊都要參加Sprint計劃會議。針對排好序的產(chǎn)品待辦事項列表(Product Backlog), 產(chǎn)品負(fù)責(zé)人和開發(fā)團隊成員討論每個事項，并對該事項達成共識，包括根據(jù)當(dāng)前的“完成的定義”，為了完成該事項所需要完成的所有事情。所有的 Scrum會議都是限定時？的。Sprint計劃會議推薦時？是Sprint中的每周對應(yīng)兩？時或者更少(譯者注：比

36、如，一個Sprint包含2個星期，則Sprint計劃會議時長應(yīng)為4個小時或者更少)。因為會議是限制時？長的,Sprint計劃會議的成功？分依賴于產(chǎn)品待辦事項列表的質(zhì)量。這就是產(chǎn)品待辦事項列表梳理十分重要的原 因。在Scrum中,Sprint計劃會議有兩部分：1 .決定在Sprint中需要完成哪些工作2 .決定這些工作如何完成第一部分：需要完成哪些工作？在會議的第一部分，產(chǎn)品負(fù)責(zé)人向開發(fā)團隊介紹排好序的產(chǎn)品待辦事項，整個Scrum團隊共同理解這些工作。Sprint中需要完成的產(chǎn)品待辦事項數(shù)目完全由開發(fā)團隊決定。為了決定做多少，開發(fā)團隊需要考慮當(dāng)前產(chǎn)品增量的狀態(tài)，團隊過去的工作情況，團隊當(dāng)前的生產(chǎn)

37、能力，以及排好序的產(chǎn)品待辦事 項列表。做多少工作只能由開發(fā)團隊決定。產(chǎn)品負(fù)責(zé)人或任何其它人，都不能給開發(fā)團隊強加更多的工作量。通常Sprint都有個目標(biāo)，稱彳Sprint目標(biāo)。這將十分有效地幫助大家更加專注于需要完成的工 作的本質(zhì)，而不必花太多精力去關(guān)注那些對于我們需要完成的工作并不重要的？小細(xì)節(jié)。第二部分：如何完成工作？在會議的第二部分？里，開發(fā)團隊需要根據(jù)當(dāng)前的“完成的定義” 一起決定如何實現(xiàn)下一個產(chǎn)品 增量。他們進？行?足夠的設(shè)計和計劃，從而有信心可以在 Sprint中完成所有工作。頭幾天的工作會 被分解成？小的單元，每個工作單元不超過一天。之后要完成的工作可以稍 ？大些，以后再對它們進

38、？行分解。決定如何完成工作是開發(fā)團隊的職責(zé)，決定做什么則是產(chǎn)品負(fù)責(zé)人的職責(zé)。在計劃會議的第二部分，產(chǎn)品負(fù)責(zé)人可以繼續(xù)留下來回答問題，以及澄清一些誤解。不管怎樣 ，團隊?wèi)?yīng)該很容易找到產(chǎn)品負(fù)責(zé)人。Sprint計劃會議的產(chǎn)出 Sprint 計劃會議最終需要 Scrum團隊對Sprint需要完成工作的數(shù)量和 復(fù)雜度達成共識，并預(yù)期在一個合理的條件范圍內(nèi)完成它們。開發(fā)團隊預(yù)測并共同承諾他們要完 成的工作量?？偠垦灾涸赟print計劃會議中，開發(fā)團隊和產(chǎn)品負(fù)責(zé)人一起考慮并討論產(chǎn)品待辦事項，確保他們對這些事項的理解，選擇一些他們預(yù)測能完成的事項，創(chuàng)建足夠詳細(xì)的計劃來確保他們能夠完成這些事項。最終產(chǎn)生的待

39、辦事項列表就是“Sprint待辦事項列表(Sprint Backlog) ”。Scrum活動：每日Scrum會議開發(fā)團隊是自組織的。開發(fā)團隊通過每日Scrum會議來確認(rèn)他們?nèi)匀豢梢詫崿F(xiàn) Sprint的目標(biāo)。這個會議每天在同樣的時間和同樣的地點召開。每一個開發(fā)團隊成員需要提供以下三點信息：從上一個每日Scrum到現(xiàn)在，我完成了什么；從現(xiàn)在到下一個每日Scrum,我計劃完成什么；有什么阻礙了我的進展。每日Scrum中可能有簡要的問題澄清和回答，但是不應(yīng)該有任何話題的討論。通常，許多團隊 會在每日Scrum之后？馬上開會處理他們遇到的任何問題。每日Scrum既不是向管理層匯報，也不是向產(chǎn)品負(fù)責(zé)？人或

40、者ScrumMaster匯報。它是一個開發(fā)團隊內(nèi)部的溝通會議，來保證他們對現(xiàn)狀有一致的了解。只有 Scrum團隊的成員，包括 ScrumMaster和產(chǎn)品負(fù)責(zé)？人，可以在會議中發(fā)？言。其他感興趣的？人可以來旁聽。在必要 時，開發(fā)團隊會基于會議中的發(fā)現(xiàn)重新組織他們的工作來完成Sprint的？目標(biāo)。每日Scrum是Scrum的一個關(guān)鍵組成部分，它可以帶來透明性，信任和更好的績效。它能幫助快速發(fā)現(xiàn)問題，并促進團隊的自組織和自？立。所有 Scrum會議都是限定時？長的。每日 Scrum通 常不超過15分鐘。Scrum活動:Sprint 評審會議Sprint結(jié)束時，Scrum團隊和相關(guān)？人員一起評審Sp

41、rint的產(chǎn)出。所有Scrum會議都是限定時?長 的,Sprint 評審會議的推薦時？長是Sprint中的每一周對應(yīng)一個小時 (譯者注：？比如，一個Sprint 包含2個星期，則Sprint評審會議時？長為2個小時)。討論圍繞著Sprint中完成的產(chǎn)品增量。由于 Sprint的產(chǎn)出會涉及到一些？人的“利益”，因此一個明智的做法是邀請他們參加這個會議，這會很有幫助。這個會議是個？非正式的會議，幫助?大家了解我們？目前進展到哪？里 ，并一起討論我們下一步如何推進。每個？人都可以在Sprint評審會議 上發(fā)表意？見。當(dāng)然，產(chǎn)品負(fù)責(zé)？人會對未來做出最終的決定，并適當(dāng)?shù)卣{(diào)整產(chǎn)品待辦事項列表 (Produ

42、ct Backlog) 。團隊會找到他們自己的方式來開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團隊會聚在一起開 Sprint回顧會議，目的是回顧一下團隊在流程 人際關(guān)系以及工具方面做得如何。團隊識別出哪些做得好，哪些做得不好，并找出潛在 的

43、改進事項，為將來的改進制定計劃。所有的Scrum會議都是限定時？長的,Sprint回顧會議的 推薦時?長是 Sprint中的每一周對應(yīng)一個小時 （譯者注：？比如，一個Sprint包含2個星期，則Sprint 回顧會議時？長為 2個小時）。Scrum團隊總是在 Scrum的框架內(nèi)，改進他們自己的流程。SCRUM勺五個價值觀1 .承諾-愿意對目標(biāo)做出承諾2 .專注- 把你的心思和能力都用到你承諾的工作上去3 .開放-Scrum把項目中的一切開放給每個人看4 .尊重-每個人都有他獨特的背景和經(jīng)驗5 .勇氣-有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM勺四大支柱迭代開發(fā)增量交付高優(yōu)先級的需求驅(qū)動

44、自組織團隊迭代開發(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é)尾，新的增量必須“完成”,這意味著它必須可用并且達到了Scrum團隊 “完成”的定義的標(biāo)準(zhǔn)。無論產(chǎn)品負(fù)責(zé)人是否決定真正發(fā)布它，增量必須

45、可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。自組織團隊Scrum團隊是一個自組織的團隊，傳統(tǒng)的命令與控制式的團隊只有執(zhí)行任務(wù)的權(quán)利，而自組織 團隊有權(quán)進行設(shè)計、計劃和執(zhí)行任務(wù)，自組織團隊還需要自己監(jiān)督和管理他們的工程過程和進 度，自組織團隊自己決定團隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。高優(yōu)先級的需求驅(qū)動在Scrum中，我們使用 Product Backlog來管理需求， Product Backlog 是一個需求的清單，Product Backlog中的需求是漸進明細(xì)的，Backlog當(dāng)中的條目必須按照商業(yè)價值的高低排序。Scrum團隊在開發(fā)需求的時候，從 B

46、acklog最上層的高優(yōu)先級的需求開始開發(fā)。在 Scrum中， 只要有足夠1-2個Sprint開發(fā)的細(xì)化了的高優(yōu)先級的需求，我們就可以啟動Sprint 了，而不必等到所有的需求都細(xì)化之后。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細(xì)化需求。SCRU咽隊在傳統(tǒng)的工作方式下，開發(fā)團隊會有很多不同的角色，比如項目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、設(shè) 計師、用戶體驗設(shè)計師，程序員，測試人員，DBA等等。但是，在 Scrum的工作方式下，總共只有三個角色，這三個角色分別是產(chǎn)品負(fù)責(zé)人（P。,Scrum Master和開發(fā)團隊。我們通常可以以劃龍舟的團隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳

47、團隊三個角色。Scrum中的PO就是舵手的角色，他對產(chǎn)品的方向負(fù)責(zé)，對產(chǎn)品的Why和What負(fù)責(zé)，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負(fù)責(zé)。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協(xié)作，他是一個Scrum的專家，團隊的教練，團隊的服務(wù)式領(lǐng)導(dǎo)。Scrum中的團隊，對應(yīng)到龍舟賽的劃槳團隊，團隊必須協(xié)調(diào)一致，作為一個整體 前進，在這樣的環(huán)境下單打獨斗，各自為政沒有任何勝算。Scrum的開發(fā)團隊對實現(xiàn) Sprint目標(biāo)需要做的所有事情負(fù)責(zé)，包括技術(shù)方案和決策，團隊分工 （誰做什么），執(zhí)行 Sprint開發(fā)任務(wù)等，而且作為自組織的團隊，他們也對他們的工作進

48、度的跟蹤和管理負(fù)責(zé)。Scrum開發(fā)團隊的主要職責(zé)包括如下五個方面：?執(zhí)行 Sprint? 梳理產(chǎn)品Backlog? 做Sprint 計劃? 每天跟進工作進展，并對他們的工作做檢查和調(diào)整? 每個迭代對產(chǎn)品和團隊的工作過程做檢查和調(diào)整開發(fā)團隊有如下10方面的特征：? 自組織? 多元化、跨職能的完整團隊? 團隊成員符合T型技能，即一專多長? 持續(xù)改進? 最大限制的溝通? 透明溝通?2個披薩的團隊大?。?-9人）? 專注、投入? 按照可持續(xù)的節(jié)奏工作?團隊長期存在，人員穩(wěn)定自組織團隊什么是自組織團隊？自組織團隊是敏捷軟件開發(fā)的基本觀念。敏捷宣言的原則中提到：“最好的架構(gòu)、需求和設(shè)計出于自組織團隊 ”。

49、自組織團隊也叫做自管理團隊、或者被授權(quán)的團隊。團隊被授權(quán)自己管理 他們的工作過程和進度、并且團隊決定如何完成工作。自組織團隊和經(jīng)理領(lǐng)導(dǎo)的團隊的區(qū)別對于經(jīng)理領(lǐng)導(dǎo)的團隊來說，團隊成員被分配任務(wù)，團隊成員只有執(zhí)行任務(wù)的權(quán)利。對于經(jīng)理領(lǐng)導(dǎo)的團隊來說，管理者除了要確定目標(biāo)、方向，團隊的上下文（組織結(jié)構(gòu)、團隊結(jié) 構(gòu)、團隊組成），還需要監(jiān)督和管理團隊的過程和進度，分配任務(wù)即確定誰做什么。這種團隊 的管理方式，更多的是命令與控制，以及微觀管理。對于自組織團隊來說，他們擁有如下權(quán)利：?團隊決定誰做什么，即任務(wù)的分配?團隊決定如何做，如何實現(xiàn)目標(biāo)，即團隊做技術(shù)決策?團隊需要在確保目標(biāo)的前提下制定團隊內(nèi)的行為準(zhǔn)則?

50、團隊有義務(wù)保持過程的透明性?團隊監(jiān)督和管理他們的過程和進度在自組織團隊的環(huán)境下，管理層關(guān)注在如下幾個方面:? 確定團隊目標(biāo)和愿景? 確定團隊上下文，組織結(jié)構(gòu)、團隊結(jié)構(gòu)、團隊組成? 提供環(huán)境和支持（安全感、良好的團隊空間、氛圍，技能輔導(dǎo)等）? 授權(quán)團隊? 訓(xùn)練協(xié)作對于自組織團隊的普遍誤解：? 誤解1:團隊自己決定目標(biāo)是什么；糾正：管理層決定團隊目標(biāo)? 誤解2:團隊自己決定誰進入團隊；糾正：管理層決定團隊上下文? 誤解3:團隊自己設(shè)計團隊結(jié)構(gòu)；糾正：管理層決定團隊上下文? 誤解4:自組織團隊不需要管理者；糾正：管理者從微觀管理轉(zhuǎn)向目標(biāo)驅(qū)動、授權(quán)團隊的管理方式? 誤解5:自組織團隊需要員工更加主動；

51、糾正：自組織讓團隊更加主動，每個人都不喜歡被命令和控制，每個人期望有成就感、期望被認(rèn)可? 誤解6:自組織團隊想干什么就干什么；糾正：管理層決定團隊目標(biāo)，團隊決定如何實現(xiàn)目標(biāo)一個自組織的團隊通常由不同職能專業(yè)、思考方式和行為模式的成員組成，也就是說它是跨職 能的團隊。自組織的團隊不是與生俱來的，打造一個團隊需要一個過程，打造一個組織團隊也是一樣。打造自組織團隊，首先要讓團隊需要完全自主；其次，有了自主，管理者需要引導(dǎo)團隊持續(xù)改進，幫助團隊持續(xù)地挑戰(zhàn)更高的目標(biāo)；第三，給團隊提供環(huán)境和支持，引導(dǎo)團隊往正確地方向 邁進。特性團隊如果我們的產(chǎn)品開發(fā)團隊只有在10人以內(nèi)，我們使用一個跨職能的Scrum團隊

52、，可以很容易地按照scrum和敏捷的方式開發(fā)產(chǎn)品。但是，如果產(chǎn)品團隊規(guī)模較大，比如是幾十人，甚至幾百人的開發(fā)團隊的時候，我們就需要考慮團隊的結(jié)構(gòu)和組織方式。在一個大的開發(fā)組織中，Scrum會把大的開發(fā)團隊劃分成多個5-9人的小團隊，那么我們應(yīng)該按照什么方式來劃分呢？在傳統(tǒng)的開發(fā)模式下，我們習(xí)慣于按照系統(tǒng)的架構(gòu)模塊，或者系統(tǒng)分層組織團隊，也有的團隊 按照系統(tǒng)需求、開發(fā)、測試結(jié)合系統(tǒng)架構(gòu)混合組織的方式。這種團隊組織的方式，我們稱之為 組件團隊，是指每個團隊只是完成系統(tǒng)功能的某一個部件，而不是一個端到端用戶可見的功組件團隊看起來像這個樣子:按照系統(tǒng)分層組織的組件團隊Copyright w-Kcurn

53、icn.E按照Scrum和敏捷的交付模式，組件團隊有如下一些限制：第一：按照組件來組織團隊，很難避免團隊之間的依賴，跨團隊的協(xié)調(diào)和依賴管理更加復(fù)雜， 不利于跨組件或者各個層之間的溝通。第二：每個團隊專注在自己的模塊，由于各模塊、或分層需求工作量的不同，很容易產(chǎn)生等待，并且容易產(chǎn)生低價值的交付。第三：由于職責(zé)單一，限制了學(xué)習(xí)，使得專業(yè)更加單一化第四：Sprint結(jié)束的時候無法提交可交付的增量產(chǎn)品功能，延遲價值交付按照Scrum和敏捷的交付模式，以用戶為中心，按照用戶場景作為邊界來組織團隊是比較推薦的做法。這種以用戶為中心的團隊叫做特性團隊。特性團隊的特點：? 長期穩(wěn)定的團隊，逐個端到端完成客戶特

54、性? 以客戶為中心的特性驅(qū)動? 跨職能、完整團隊? 共享代碼庫，統(tǒng)一的持續(xù)集成? 擁有通用型專家特性團隊看起來像這個樣子：團隊1用戶界面層業(yè)務(wù)邏輯層持久層數(shù)據(jù)庫以用戶為中心的特性團隊用戶故事什么是用戶故事?誰要使用這個功能。1要完成什么樣的功能。用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素Copyright wwwtecn se2.活動團隊內(nèi)可以做到端到端，所以減少了等待，周期加快 比較容易在一個Sprint中交付可用的產(chǎn)品增量 減少了團隊之間依賴，計劃會更容易3.商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。用戶故事通常按照如下的格式來表達：英文：A

55、s a , I want to , so that .中文：作為一個角色 ,我想要,以便于商業(yè)價值舉例：作為一個“網(wǎng)站管理員”，我想要“統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他們帶來什么收益?！毙枰⒁獾氖怯脩艄适虏荒軌蚴褂眉夹g(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。Ron Jeffries 的 3 個 C關(guān)于用戶故事，Ron Jeffries 用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é)商的，