【文章內容簡介】 tBacklog會因為如下原因發(fā)生變化:，開發(fā)團隊對于需求有了更好的理解，有可能發(fā)現需要增加一些新的任務到SprintBacklog中。，這個都做為承諾提交任務中未完成的工作。ProductOwner也許會和Scrumteam一起工作，以幫助team更好的理解Sprint的目標，ScrumMaster和team也許會覺得小的調整不會影響sprint的進度，但會給客戶帶來更多商業(yè)價值。監(jiān)控Sprint進度在Sprint中的任意時間點,Sprint待辦事項列表的所有剩余工作總和都可以被計算。開發(fā)團隊至少在每日例會時追蹤所有的剩余工作。開發(fā)團隊每天追蹤剩余總和并預測達成Sprint目標的可能性。通過在Sprint中不斷追蹤剩余工作,開發(fā)團隊可以管理自己的進度。Scrum不考慮已經花在Sprint待辦事項列表上的工作時間。我們只關心剩余工作和日期這兩個變量。燃盡圖（BURNDOWNCHART)Sprint燃盡圖（SprintBurndownChart)SprintBurndownChart顯示了Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的趨勢圖。圖中Y軸代表的是剩余工作量，X軸代表的是Sprint的工作日。在Sprint開始的時候，ScrumTeam會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，團隊會根據進展情況每天更新累積工作量，如果在Sprint結束時，累積工作量降低到0，Sprint就成功結束。由于在Sprint的剛開始的時候，增加的任務工作量可能大于完成的任務工作量，所以燃盡圖有可能略微呈上升趨勢。發(fā)布燃盡圖（ReleaseBurndownChart）在Scrum項目中，團隊通過每個Sprint結束時更新的發(fā)布燃盡圖來跟蹤整個發(fā)布計劃的進展。發(fā)布燃盡圖記錄了在一段時間內產品Backlog的總剩余估算工作量的變化趨勢。X軸代表的項目周期，以Sprint為單位，Y軸代表的是剩余工作量，通常以用戶故事點、理想人天或者teamdays為單位。七、 SCRUM的五個活動Scrum活動:產品待辦事項列表梳理產品待辦事項通常會很大,也很寬泛,而且想法會變來變去、優(yōu)先級也會變化,所以產品待 辦事項列表梳理是一個貫穿整個Scrum項目始終的活動。該活動包含但不限于以下的內容: 保持產品待辦事項列表有序 把看起來不再重要的事項移除或者降級 增加或提升涌現出來的或變得更重要的事項 將事項分解成更小的事項 將事項歸并為更大的事項 對事項進行估算產品待辦事項列表梳理的一個最大好處是為即將到來的幾個Sprint做準備。為此,梳理時會特別關注那些即將被實現的事項。需要考慮不少因素,這包括但不限于以下的內容:理想情況下,下一個Sprint的備選事項都應該提升“商業(yè)價值”。 開發(fā)團隊需要能夠在一個Sprint內完成每一個事項。每個人都需要清楚預期產出是什么。產品開發(fā)決定了,有可能需要其它的技能和輸入。因此,產品待辦事項列表梳理最好是所有團隊成員都參與的活動,而不單單是產品負責人。Scrum活動：Sprint計劃會議每個Sprint都以Sprint計劃會議作為開始， 這是一個固定時長的會議，在這個會議中,Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。整個團隊都要參加Sprint計劃會議。針對排好序的產品待辦事項列表(Product Backlog),產 品負責人和開發(fā)團隊成員討論每個事項,并對該事項達成共識,包括根據當前的“完成的定 義”,為了完成該事項所需要完成的所有事情。所有的Scrum會議都是限定時的。Sprint計劃會議推薦時是Sprint中的每周對應兩?時或者更少(譯者注:比如,一個Sprint包含2個星 期,則Sprint計劃會議時長應為4個小時或者更少)。因為會議是限制時長的,Sprint計劃會議的成功?分依賴于產品待辦事項列表的質量。這就是產品待辦事項列表梳理十分重要的原因。在Scrum中,Sprint計劃會議有兩部分:1. 決定在Sprint中需要完成哪些工作2. 決定這些工作如何完成第一部分:需要完成哪些工作?在會議的第一部分,產品負責人向開發(fā)團隊介紹排好序的產品待辦事項,整個Scrum團隊共同理解這些工作。Sprint中需要完成的產品待辦事項數目完全由開發(fā)團隊決定。為了決定做多少,開發(fā)團隊需要考慮當前產品增量的狀態(tài),團隊過去的工作情況,團隊當前的生產能力,以及排好序的產品待辦事項列表。做多少工作只能由開發(fā)團隊決定。產品負責人或任何其它人,都不能給開發(fā) 團隊強加更多的工作量。通常Sprint都有個目標,稱作Sprint目標。這將十分有效地幫助大家更加專注于需要完成的工 作的本質,而不必花太多精力去關注那些對于我們需要完成的工作并不重要的?小細節(jié)。第二部分:如何完成工作?在會議的第二部分?里,開發(fā)團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增 量。他們進?行?足夠的設計和計劃,從而有信心可以在Sprint中完成所有工作。頭幾天的工作會 被分解成?小的單元,每個工作單元不超過一天。之后要完成的工作可以稍?大些,以后再對它 們進?行分解。決定如何完成工作是開發(fā)團隊的職責,決定做什么則是產品負責人的職責。在計劃會議的第二部分,產品負責人可以繼續(xù)留下來回答問題,以及澄清一些誤解。不管怎樣,團隊應該很容易找到產品負責人。Sprint計劃會議的產出 Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數量和復雜度達成共識,并預期在一個合理的條件范圍內完成它們。開發(fā)團隊預測并共同承諾他們要完成的工作量。 總而?言之:在Sprint計劃會議中,開發(fā)團隊和產品負責人一起考慮并討論產品待辦事項,確保他們對這些事項的理解,選擇一些他們預測能完成的事項,創(chuàng)建足夠詳細的計劃來確保他們能夠完成這些事項。最終產生的待辦事項列表就是“Sprint待辦事項列表(Sprint Backlog)”。Scrum活動:每日Scrum會議開發(fā)團隊是自組織的。開發(fā)團隊通過每日Scrum會議來確認他們仍然可以實現Sprint的目標。 這個會議每天在同樣的時間和同樣的地點召開。每一個開發(fā)團隊成員需要提供以下三點信息:從上一個每日Scrum到現在,我完成了什么。 從現在到下一個每日Scrum,我計劃完成什么。 有什么阻礙了我的進展。每日Scrum中可能有簡要的問題澄清和回答,但是不應該有任何話題的討論。通常,許多團隊 會在每日Scrum之后?馬上開會處理他們遇到的任何問題。每日Scrum既不是向管理層匯報,也不是向產品負責?人或者ScrumMaster匯報。它是一個開發(fā) 團隊內部的溝通會議,來保證他們對現狀有一致的了解。只有Scrum團隊的成員,包括 ScrumMaster和產品負責?人,可以在會議中發(fā)?言。其他感興趣的?人可以來旁聽。在必要時, 開發(fā)團隊會基于會議中的發(fā)現重新組織他們的工作來完成Sprint的??目標。每日Scrum是Scrum的一個關鍵組成部分,它可以帶來透明性,信任和更好的績效。它能幫助 快速發(fā)現問題,并促進團隊的自組織和自?立。所有Scrum會議都是限定時長的。每日Scrum通 常不超過15分鐘。Scrum活動:Sprint評審會議Sprint結束時,Scrum團隊和相關?人員一起評審Sprint的產出。所有Scrum會議都是限定時長 的,Sprint評審會議的推薦時長是Sprint中的每一周對應一個小時(譯者注:?比如,一個Sprint 包含2個星期,則Sprint評審會議時長為2個小時)。討論圍繞著Sprint中完成的產品增量。由于Sprint的產出會涉及到一些?人的“利益”,因此一個明 智的做法是邀請他們參加這個會議,這會很有幫助。這個會議是個?非正式的會議,幫助?大家 了解我們??目前進展到哪?里,并一起討論我們下一步如何推進。每個?人都可以在Sprint評審會議 上發(fā)表意?見。當然,產品負責?人會對未來做出最終的決定,并適當地調整產品待辦事項列表 (Product Backlog)。團隊會找到他們自己的方式來開Sprint評審會議。通常會演?示產品增量,整個小組也會經常討論他們在Sprint中觀察到了什么、有哪些新的產品想法出現。他們還會討論產品待辦事項列表 的狀態(tài)、可能的完成日期以及在這些日期前能完成什么。Sprint評審會議向每個?人展?示了當前產品增量的概況。因此,通常都會在Sprint評審會議中調 整產品待辦事項列表。Scrum活動:Sprint回顧會議在每個Sprint結束后,Scrum團隊會聚在一起開Sprint回顧會議,目的是回顧一下團隊在流程人際關系以及工具方面做得如何。團隊識別出哪些做得好,哪些做得不好,并找出潛在 的改進事項,為將來的改進制定計劃。所有的Scrum會議都是限定時長的,Sprint回顧會議的 推薦時長是Sprint中的每一周對應一個小時(譯者注:?比如,一個Sprint包含2個星期,則 Sprint回顧會議時長為2個小時)。Scrum團隊總是在Scrum的框架內,改進他們自己的流程。八、 SCRUM的五個價值觀承諾 – 愿意對目標做出承諾專注– 把你的心思和能力都用到你承諾的工作上去開放– Scrum 把項目中的一切開放給每個人看尊重– 每個人都有他獨特的背景和經驗勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重九、 SCRUM的四大支柱迭代開發(fā)在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個14周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發(fā)生變化，在整個產品開發(fā)周期內每個迭代都是1周的長度。這里需要強調的是在每個迭代必須產出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。增量交付增量是一個 Sprint 及以前所有 Sprint 中完成的所有產品代辦事項列表條目的總和。 在 Sprint 的結尾,新的增量必須“完成”,這意味著它必須可用并且達到了 Scrum 團隊 “完成”的定義的標準。無論產品負責人是否決定真正發(fā)布它,增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。自組織團隊Scrum團隊是一個自組織的團隊，傳統(tǒng)的命令與控制式的團隊只有執(zhí)行任務的權利，而自組織團隊有權進行設計、計劃和執(zhí)行任務，自組織團隊還需要自己監(jiān)督和管理他們的工程過程和進度，自組織團隊自己決定團隊內如何開展工作，決定誰來做什么，即分工協(xié)作的方式。高