【正文】 負責人（Product Owner）2. Scrum Master3. Scrum團隊3個工件1. 產品Backlog（Product Backlog）2. SprintBacklog3. 燃盡圖（Burndown Chart)5個活動1. Sprint計劃會議（Sprint Planning Meeting）2. 每日站會（Daily Scrum Meeting）3. Sprint評審會議（Sprint Review Meeting）4. Sprint回顧會議（Sprint Retrospective Meeting）5. 產品Backlog梳理會議（ Product Backlog Refinement）5個價值1. 承諾 – 愿意對目標做出承諾2. 專注– 把你的心思和能力都用到你承諾的工作上去3. 開放– Scrum 把項目中的一切開放給每個人看4. 尊重– 每個人都有他獨特的背景和經驗5. 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM理論基礎Scrum以經驗性過程控制理論（經驗主義）做為理論基礎的過程。 Scrum起源于軟件開發(fā)項目，但它適用于任何復雜的或是創(chuàng)新性的項目。SCRUM術語Scrum： Scrum無對應中文翻譯Agile： 敏捷Lean： 精益Iterative：迭代式的Iteration：迭代Agile Manifesto： 敏捷宣言Empirical： 經驗性的Empirical Process：經驗性過程Transparency： 透明性Inspect and Adapt： 檢視與調整Sprint：原意為沖刺，Scrum中的Sprint無對應中文翻譯，指一個迭代Sprint Goal：Sprint目標Product Owner ：產品負責人 簡稱POScrum Master ：簡稱SM, 一般不翻譯Development Team ： Scrum開發(fā)團隊Scrum Team：指PO,SM和開發(fā)團隊Scrum Roles：Scrum角色，指PO,SM和開發(fā)團隊Emergent ：涌現(xiàn)的Product Backlog：產品待辦列表，指需求清單Sprint Backlog：Sprint待辦列表，指Sprint任務清單Sprint Burndown Chart：Sprint燃盡圖，團隊用于做Sprint內的進展跟蹤Release Burndown Chart: 圖01為了管理軟件開發(fā)的活動，我們會引入過程控制來管理它。 也就是說，當某個人在檢驗一個過程，并確信某一個任務已經完成時，這個完成必須等同于他們對完成的定義。Scrum角色之：產品負責人產品負責人負責最大化產品以及開發(fā)團隊工作的價值。只有開發(fā)團隊的成員才能創(chuàng)造增量。大于 9 人的團隊需要過多的協(xié)調溝 通工作。 教導并領導開發(fā)團隊創(chuàng)造高價值的產品產品待辦事項列表列出了所有的特性、功能、需求、改進方法和缺陷修復等對未來發(fā)布產品進行的改變。那么這就需要使用對產品待辦事項列表條目進行分組的屬性。Scrum 不考慮已經花在產品代辦事項列表條目上的工作時間。 Sprint 待辦事項列表是高度可見的,是對團隊計劃在當前 Sprint 內完成工作的實時反 映,并且,該列表只屬于開發(fā)團隊。發(fā)布燃盡圖記錄了在一段時間內產品Backlog的總剩余估算工作量的變化趨勢。Scrum活動：Sprint計劃會議每個Sprint都以Sprint計劃會議作為開始， 這是一個固定時長的會議，在這個會議中,Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。頭幾天的工作會 被分解成?小的單元,每個工作單元不超過一天。通常,許多團隊 會在每日Scrum之后?馬上開會處理他們遇到的任何問題。當然,產品負責?人會對未來做出最終的決定,并適當?shù)卣{整產品待辦事項列表 (Product Backlog)。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。 做Sprint計劃團隊被授權自己管理他們的工作過程和進度、并且團隊決定如何完成工作。 誤解2：團隊自己決定誰進入團隊； 糾正：管理層決定團隊上下文 長期穩(wěn)定的團隊，逐個端到端完成客戶特性 卡片（Card） – 用戶故事一般寫在小的記事卡片上。集體估算，通常采用估算撲克作為工具，團隊通過玩估算游戲進行集體估算。 回到第二步，開始估算下一個條目。 ?Sprint 包含并由 Sprint 計劃會議、每日站會、開發(fā)工作、Sprint 評審會議和 Sprint 回顧會議構成。假如有些條目已經潛在可交付,那產品負責人就會采納它。這樣的好處是在開會的時候，每個人都可以看到當前的進展情況。SCRUM MASTER檢查單一位合格的ScrumMaster通常能夠同時處理2到3個團隊的事務。 團隊成員之間相處得怎么樣？氣氛融洽嗎？有為彼此的成功感到高興嗎？ 你們正在開發(fā)的系統(tǒng)有“開始測試”按鈕能讓每個都很容易地察覺到自己是否破壞了某些功能呢？通常這個是靠xUnit框架來實現(xiàn)的（JUnit，NUnit等等）。但是有時候結對編程實在挑戰(zhàn)大家的極限，有時候甚至會使完成任務的時間變長（如果我們更重視數(shù)量而不是質量的話）。 你的公司已經被外界認定為最好的工作場所或者業(yè)界的領頭羊了嗎？恐懼是你的朋友, 一旦你開始意識到你能夠做些事情來改變現(xiàn)狀，你可能會感到恐懼而退縮。 團隊能夠被保護得足夠好而避免微管理嗎？你可以在每個Sprint評審會議的時候給大家展示Mike Cohn的產品和版本燃盡圖，這樣就可以更早地發(fā)現(xiàn)當前的進度是不是能夠符合預期。 產品待辦事列表里面的項目已經根據(jù)Product Owner的最新想法排好優(yōu)先級了嗎？是不是所有來自股東的需求都已經被待辦事列表中的項目涵蓋了？要記得待辦事列表是涌現(xiàn)的。這個增量是可用的,所以產品負責人可以選擇立即發(fā)布它。2. 不會有ScrumMaster或者其他任何人來指派任務。 團隊回顧昨天的工作，做調整，持續(xù)改進什么時候、在什么地點開每日站會？Scrum定義了開展每日站會的一些基本的規(guī)則。比如公司的發(fā)展方向, 或是市場、技術等情況發(fā)生了變化,這些變化都可能導致取消 Sprint。Sprint的長度一旦確定，保持不變。 所有人都出牌之后，閱讀者向大家確認是否都已經確定估算結果，確認后，數(shù)”1,2,3″,大家同時展示估算結果。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。 可協(xié)商性（Negotiable）— 一個用戶故事的內容要是可以協(xié)商的，用戶故事不是合同。3. 商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。第二：每個團隊專注在自己的模塊，由于各模塊、或分層需求工作量的不同，很容易產生等待，并且容易產生低價值的交付。 提供環(huán)境和支持（安全感、良好的團隊空間、氛圍，技能輔導等） 團隊長期存在，人員穩(wěn)定自組織團隊Scrum的開發(fā)團隊對實現(xiàn)Sprint目標需要做的所有事情負責，包括技術方案和決策，團隊分工（誰做什么），執(zhí)行Sprint開發(fā)任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。這里需要強調的是在每個迭代必須產出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。討論圍繞著Sprint中完成的產品增量。每一個開發(fā)團隊成員需要提供以下三點信息:從上一個每日Scrum到現(xiàn)在,我完成了什么。通常Sprint都有個目標,稱作Sprint目標。 開發(fā)團隊需要能夠在一個Sprint內完成每一個事項。在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。當出現(xiàn)新工作時,開發(fā)團隊需要將其追加到 Sprint 待辦事項列表中去。監(jiān)控向目標前進的進度在任何時間,達成目標的剩余工作量是可以被累計的。因為需求永遠不會停止改變,所以產品待辦事項列表是個不斷更新的工件。產品待辦事項列表是一個持續(xù)完善的清單, 最初的版本只列出最初始的和眾所周知的需求。 在經驗主義環(huán)境中理解長期的產品規(guī)劃 開發(fā)團隊不包含如測試或業(yè)務分析等負責特定領域的子團隊。為保證產品負責人的工作取得成功,組織中的所有人員都必須尊重他的決定?？缏毮艿膱F隊擁有完成工作所需要的全部技能,不需要依賴團隊外部的人。Scrum以經驗性過程控制理論做為理論基礎的過程。 ”2001年，Ken Schwaber和Mike Beedle推出第一本Scrum書籍《Scrum敏捷軟件開發(fā)》。另一個因素就是檢驗工作成果人員的技能水平和積極性。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。Scrum的三大支柱如下：第一：透明性（Transparency）透明度是指，在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產結果的人保持透明。1986 Scrum這個詞匯首次應用于產品開發(fā)1986年，竹內弘高和 野中郁次郎在New New Product Development它的優(yōu)勢在于可以大規(guī)模批量生產。 另一個因素就是檢驗工作成果人員的技能水平和積極性。 對產品代辦事項列表中的條目進行排序,最好地實現(xiàn)目標和使命Scrum Master是Scrum團隊中的服務式領導。 在組織范圍內計劃 Scrum 的實施排序越高,產品待辦事項列表條目越緊急,就越需要仔細斟酌,并且對其價值的意見越一致。梳理在 Sprint 中是一項兼職活動,在產品負責人和開發(fā)團隊之間展開。在復雜的環(huán)境下,將要發(fā)生的東西是未知的,只有已經發(fā)生的事情才能用來做前瞻式的決策。開發(fā)團隊至少在每日例會時追蹤所有的剩余工作。 把看起來不再重要的事項移除或者降級因為會議是限制時?長的,Sprint計劃會議的成功?分依賴于產品待辦事項列表的質量。Sprint計劃會議的產出 Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數(shù)量和復雜度達成共識,并預期在一個合理的條件范圍內完成它們。在必要時, 開發(fā)團隊會基于會議中的發(fā)現(xiàn)重新組織他們的工作來完成Sprint的??目標。因此,通常都會在Sprint評審會議中調 整產品待辦事項列表。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細化需求。 團隊成員符合T型技能，即一專多長 團隊決定誰做什么，即任務的分配自組織的團隊不是與生俱來的，打造一個團隊需要一個過程，打造一個組織團隊也是一樣。 團隊內可以做到端到端，所以減少了等待，周期加快 確認（Confirmation） 通過驗收測試確認用戶故事被正確完成。 可以估算性（Estimable）—開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。敏捷估算時，我們使用故事點作為計量單位，它是一個倍數(shù)，我們會先找一個我們認為最小的一個功能的大小作為參考基準，定義為1個故事點，把其它的故事和它做比較，如果是2倍大小，就是2個故事點，如果是5倍大小，就是5個故事點。 Sprint的質量目標和驗收標準團隊需要建立他們的工作協(xié)議來確保團隊成員按時出席，并且遵守站會紀律，比如團隊可以商量對于遲到的人員要有一些讓他們改進的措施，比如適當?shù)慕o一些罰金，多少由團隊共同決定，這些錢如何支配也由團隊共同決定， 或者做俯臥撐、掛一個遲到的牌子等等。如果這還不夠，參考一下其他人的實踐經驗，比如：Martin Fowler’s 《Patterns of Daily Standup Meetings》你如何知道每日站會起到了很好的效果？一個好的每日站會有如下幾個特點：1.如果你能夠感受到這個節(jié)奏，則說明團隊是很健康的，每日站會起到了很好的效果。我們推薦每個7人左右的團隊都有一位專職的ScrumMaster，尤其是剛開始實施Scrum的時候。 如果你正在使用自動工具來管理你的待辦事列表，想一下它真的能夠幫助你嗎？自動化的管理工具有可能成為ScrumMaster了解信息的障礙。 團隊在開發(fā)過程中有沒有集中在驗收標準上？也許你應該在Sprint當中舉行一次會議來評審當前Sprint所承諾的