轉載自：http://www.cnblogs.com/stay/archive/2011/08/23/2151329.html

 抽空學習了下敏捷開發，覺得跟自己的一些想法不謀而合，如果一個團隊能實施ｓｃｒｕｍ，那效率一定非常高，非常適合移動開發，Ａｎｄｒｏｉｄ，ＩＯＳ，ＷＭ等小ｔｅａｍ開發一個ａｐｐ。希望對大家也有幫助，

　　前期可能會覺得有點彆扭，但是堅持下來，效果會非常不一樣。你會發現，效果高很多，而且規範。

　　產品backlog是Scrum的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序，它裡面包含的是客戶想要的東西，並用客戶的術語加以描述。

包括以下欄位：

 ID – 統一識別符號，自增長

 NAME – 簡短的、描述性的名稱

 Importance – 產品負責人評出一個數值，指示這個條目有多重要，比如10 – 150，分數越高越重要。

 Initial estimate(初始估算) – 團隊的初步估算該條目的工作日。

 How to demo – 簡單的測試規範，這段描述可以作為驗收測試的偽碼錶示。

 Notes – 相關資訊、解釋說明和對其它資料的引用等，一般都非常簡短。

 

為了便於產品負責人判斷優先級別，我們也會在產品backlog中使用一些其它欄位

 Track(類別) – 當前故事的大致分類，例如”後臺系統”或”優化”

。這樣產品負責人就可以很容易選出所有的”優化”條目，把他們的級別都設得比較低。類似的操作執行起來都很方便。

Components – 如“資料庫，伺服器，客戶端”。團隊或者產品負責人可以在這裡進行標識，以明確哪些技術元件在這個條目的實現中會被包含進來。這種做法在多個Scrum團隊協作的時候很有用—比如一個後臺系統團隊和一個客戶端團隊—他們很容易知道自己應當對哪些需求負責。

  Requestor(請求者) – 產品負責人可能需求記錄是哪個客戶或相關干係人最先提出了這項需求，在後續開發過程中向他提供反饋。

產品負責人應當理解每個故事的含義（通常需求都是由他來編寫的，但是有的時候其他人也會新增一些請求，產品負責人對它們劃分先後次序）。他不需要知道每個需求具體是如何實現的，但是他要知道為什麼這個需求會在這裡。

         Sprint計劃會議非常關鍵，應該算是Scrum中最重要的活動。要是它執行的不好，整個sprint甚至都會被毀掉。舉辦Sprint計劃會議，是為了讓團隊獲得足夠的資訊，能夠在幾個星期內不受干擾的工作，也是為了讓產品負責人能對此有充分的信心。

         Sprint計劃會議成果：

1．  Sprint目標。

2．  團隊成員名單(以及他們的投入程度，如果不是100%的話)

3．  Sprint backlog(即Sprint中包括的需求列表)

4．  確定好sprint演示日期

5．  確定好時間地點，供舉行每日scrum會議

整個團隊和產品負責人都必須參加sprint計劃會議。原因在於，每個需求都含有三個變數，它們兩兩之間都對彼此有著強烈依賴。

         

範圍(Scope)和重要性(Importance)由產品負責人設定。估算(estimate)由團隊設定。在sprint計劃會議上，經過團隊和產品負責人面對面的對話，這三個變數會逐步得到調整優化。會議啟動後，產品負責人一般會先概況一下希望在這個sprint中達成的目標，還有他認為最重要的故事，接下來，團隊從最重要的故事開始逐一討論每個故事，一一估算時間。

質量分為內部質量和外部質量

外部質量是系統使用者可以感知的。執行緩慢、讓人迷糊的使用者介面就屬於外部質量低劣。

內部質量指使用者開不到的要素，它們對系統的可維護性有深遠影響。可維護性有深遠影響。可維護性包括系統設計的一致性、測試覆蓋率、程式碼可讀性和重構等等。

一般來說，系統內部質量優秀，外部質量仍有可能很差。而內部質量差的系統，外部質量肯定也不怎麼樣。犧牲內部質量是一個糟糕透頂的想法。現在節省下來一點時間，接下來的日子裡你就要一直為它付出代價。一旦我們放鬆要求，允許程式碼庫中暗藏問題，後面就很難恢復質量了。

用生產率計算來估算：

         1．得出估算生產率。

         2．計算在不超出估算生產率的情況下可以加入多少故事。

生產率是“已完成工作總量”的一個衡量方式，其中每一個需求都是用它的原始估算進行衡量的。

下圖中，左邊是sprint啟動時的估算生產率，右邊是sprint結束時的實際生產率。每個矩形都是一個需求，裡面的數字表示這個需求的原始估算。

注意，這裡的實際生產率建立在每個故事的原始估算基礎之上，在sprint過程中對需求時間進行的修改都被忽略了。敏捷軟體開發和精益製造的要求：把事情完全做完！達到可以交付的狀態！事情只做了一半，它的價值就是0(也許還會是負數)。

This Sprint’s Estimated velocity:

         (Available Man-Days) * (Focus Factor) = (Estimated Velocity)

投入程度(Focus Factor)用來估算團隊會在sprint中投入多少精力。投入程度低，就表示團隊估計會受到很大幹擾，或者他們覺得自己的時間估算太過理想化。要想得出一個合理的投入程度，最好的辦法就是看看上一個sprint的值（對前幾個sprint取平均值自然更好）

Last Sprint’s Focus Factor:

         (Focus Factor) = (Actual Velocity) / (Available Man-Days)

生產率計算：

1，  直覺反應、

2，  基於昨日天氣的生產率計算、

3，  基於可用人-天和估算投入程度的生產率計算

在大多數sprint計劃會議上，大家都會討論產品backlog中的需求細節。對故事進行估算、重定優先順序、進一步確認細節、拆分，等等都會在會議上完成。

要想收到好的效果，不妨建立一些索引卡，把他們放到牆上(或一張大桌子上)

這種使用者體驗比計算機和投影儀好得多：

大家站起來四處走動—他們可以更長時間的保持清醒，並留心會議進展。

他們有更多的個人參與感(而不是隻有那個拿著鍵盤的傢伙才有)

多個故事可以同時編輯。

重新劃分優先順序變得易如反掌 – 挪動索引卡就行。

會議結束後，索引卡可以拿出會議室，貼在牆上的任務板上。

把需求拆分成任務後，時間估算就變得更容易(也更精確)了

不要讓任務拆分出現在產品backlog中，原因有二：

任務拆分的隨機性比較強，在sprint進行中，它們常常會發生變化，不斷調整，所以保持產品backlog的同步很讓人頭大。

產品負責人不需要關心這種程度的細節。

使用計劃紙牌做時間估算

估算是一項團隊活動 --- 通常每個成員都會參與所有需求的估算。為啥要每個人都參加？

1，  在計劃的時候，我們一般都還不知道到底誰會來實現哪個需求的哪個部分。

2，  每個需求一般有好幾個人蔘與，也包括不同型別的專長(使用者介面設計、程式設計、測試、等)

3，  團隊成員必須要對需求內容有一定的理解才能進行估算。要求每個人都做估算，我們就可以確保他們都理解了每個條目的內容。這樣就為大家在sprint中相互幫助夯實了基礎，也有助於需求中的重要問題被儘早發現。

4，  如果要求每個人都對需求做估算，我們就會常常發現兩個人對同一需求的估算結果差異很大。我們應該儘早發現這種問題並就此進行討論。

每個人都會得到如上圖的13張卡片。在估算需求的時候，每個人都選出一張卡片來表示他的時間估算(以man-day的方式表示)，並把它正面朝下扣在桌上。所有人都完成以後，桌上的紙牌會被同時揭開。這樣每個人都會被迫進行自我思考，而不是依賴於其他人估算的結果。如果在兩個估算之間有著巨大差異，團隊就會就辭進行討論，並試圖讓大家對需求內容達成共識。他們也許會進行任務分解，之後再重新估算。這樣的迴圈會往復進行，知道時間估算趨於一致為止，也就是每個人對這個需求的估算都差不多相同。

重要的是，我們必須提醒團隊成員，他們要對這個故事中所包含的全部工作進行估算。而不是”他們自己負責”的部分工作。測試人員不能只估算測試工作。

有些卡片比較特殊：

1，  0 = “這個故事已經完成了” 或者”這個故事根本沒啥東西，幾分鐘就能搞定”

2，  ？ = “我一點概念都沒有，沒想法。”

3，  咖啡杯 = “我太累了，先歇會吧”

把需求拆分成任務

故事是可以交付的東西，是產品負責人所關心的。任務是不可交付的東西，產品負責人對它也不關心。

需求拆分成更小的需求

 

需求拆分成任務

1，  新組建的Scrum團隊不願意花時間來預先把故事拆分成任務。有些人覺得這像是瀑布式的做法。

2，  有些故事，大家都理解的很清楚，那麼預先拆分還是隨後拆分都一樣簡單。

3，  這種型別的拆分常常可以發現一些會導致時間估算增加的工作，最後得出的sprint計劃會更貼近現實。

4，  這種預先拆分可以給每日例會的效率帶來顯著提高

5，  及時拆分不夠精確，而且一旦開始具體工作，事先的拆分結果也許會發生變化，但我們依然可以得到以上種種好處。

最後界限在哪裡

優先順序列表：

1，  Sprint目標和演示日期。

2，  經過團隊認可、要新增到這個sprint中的需求列表。

3，  Sprint中每個需求的估算值。

4，  Sprint中每個需求的”如何演示”

5，  生產率和資源計算，用作sprint計劃的現實核查。包括團隊成員的名單及每個人的承諾(不然就沒法計算生產率)

6，  明確每日例會固定舉行的時間地點。

7，  把需求拆分成任務。這個拆分也可以在每日例會上做，不過這回稍稍打亂sprint的流程。

技術需求：需要完成但又不屬於可交付物的東西，跟任何故事都沒有直接關聯，不會給產品負責人帶來直接的價值。如：安裝持續構建故武器、編寫系統設計概覽、重構DAO層、

Sprint資訊頁

Sprint backlog

 

燃盡圖

讓團隊坐在一起：

“一起”意味著：

1．  互相聽到：所有人都可以彼此交談，不必大聲喊，不必離開座位。

2．  互相看到：所有人都可以看到彼此，都能看到任務版

3．  隔離：如果你們整個團隊突然站起來，自發形成一個激烈的設計討論，團隊外的任何人都不會打擾到。

產品負責人應該離團隊很近，既方便團隊成員走過來討論問題，他也能隨時踱到任務版前面去。但是他不應該跟團隊坐在一起。為什麼？因為這樣他就無法控制自己不去關注具體細節，團隊也無法”凝結”成整體(即達到關係緊密、自組織、具有超高生產力的狀態)

怎樣更新任務版

無論sprint backlog是什麼形式，都要盡力讓整個團隊參與到保持sprint backlog及時更新的工作中來，我們曾經試過讓Scrum master自己維護sprint backlog，他就不得不每天都去詢問大家各自剩餘的工作估算時間。這種做法的缺點是：

1．  Scrum master把太多時間用在了管理之類的工作上，而不是為團隊提供支援，消除他們的障礙

2．  因為團隊成員不再關心sprint backlog ，所以他們就意識不不到sprint的狀態，缺少了反饋，團隊整體的敏捷度和精力的集中程度都會下降。

如果sprint backlog設計得很好，那每個人都應該很容易修改它。

怎樣進行sprint演示

Sprint演示是Scrum中很重要的一環。一次做的不錯的演示，即使看上去很一般，也會帶來深遠影響。

1．  團隊的成果得到認可，他們會感覺很好。

2．  其他人可以瞭解你的團隊在做些什麼。

3．  演示可以吸引相關干係人的注意，並得到重要反饋。

4．  演示是一種社會活動，不同的團隊可以在這裡相互交流，討論各自的工作。這很有意義。

5．  做演示會迫使團隊真正完成一些工作，進行釋出(即使是隻在測試環境中)。如果沒有演示，我們就會總是得到99%完成的工作。有了演示以後，也許我們完成的事情會變少，但它們是真正完成的。這比得到一堆貌似完成的工作要好得多，而且後者還會汙染下一個sprint。

Sprint演示檢查列表

1．  確保清晰闡述了Sprint目標。如果在演示上有些人對產品一無所知，那就花上幾分鐘來進行描述。

2．  不要花太多時間準備演示，尤其是不要做花裡胡哨的演講，把那些玩意扔一邊去，集中精力演示可以實際工作的程式碼。

3．  節奏要快，也就是說要把準備的經歷放在保持演示的快節奏上，而不是讓它看上去好看

4．  讓演示關注於業務層次，不要管技術細節。注意力放在”我們做了什麼”，而不是”我們怎麼做的”

5．  可能的話，讓觀眾自己試一下產品。

6．  不要演示一大堆細碎的bug修復和微不足道的特性，你可以提到一些，但是不要演示，因為他們通常會花很長時間。而且會分散大家的注意力，讓他們不能關注更加重要的需求。

Scrum回顧

回顧是Scrum中第二重要的事件(最重要的是sprint計劃會議)，因為這是你做改進的最佳時機。如果沒有回顧，團隊就會不斷重犯同樣的錯誤。

回顧組織：

1．  根據要討論的內容範圍，設定為1到3小時

2．  參與者：產品負責人，整個團隊。

3．  在不受干擾的情況下討論。

4．  一般不要在團隊房間中進行回顧，因為這往往會分散大家的注意力。

5．  制定某人當祕書。

6．  Scrum master 向大家展示sprint backlog ，在團隊的幫助下對sprint做總結。包括重要事件和決策等。

7．  輪流發言，每個人都有機會在不被人打斷的情況下講出自己的想法，他認為什麼是好的，哪些可以做的更好，哪些需要在下個sprint中改變。

8．  我們隊預估生產率和時機生產率進行比較。如果差異比較大的話，我們會分析原因。

9．  快結束的時候，Scrum master對具體建議進行總結，得出下個sprint需要改進的地方。

我們的回顧會議一般沒有太規整的結構，不過潛在的主題都是一樣的：”我們怎樣才能在下個sprint中做的更好

Scrum回顧白板：

圖中的三列分別是：

1．  Good : 如果我們可以重做同一個sprint，哪些做法可以保持。

2．  Could have done better: 如果我們可以重做同一個sprint，哪些做法需要改變。

3．  Improvements:有關將來如何改進的具體想法。

第一列和第二列是回顧過去，第三列是展望將來。

團隊通過頭腦風暴得出所有的想法，寫在即時貼上，如何用”圓點投票”來決定下一個sprint會著重進行哪些改進。每個人都有三塊小磁鐵，投票決定下個sprint所要採取措施的優先順序。他們可以隨意投票，也可以把全部三票投在一件事情上。根據投票情況，選出幾項重點進行過程改進，在下一個回顧中，跟蹤這些改進的執行情況。不要想一口吃成個胖子，這一點很重要，每個sprint只關注幾個改進就夠了。

定義你的驗收標準

除了普通的產品backlog之外，產品負責人還會定義一系列的驗收標準，它從合同的角度將產品backlog中重要性級別的含義進行了簡單分類。

驗收標準規則的例子：

1．  所有重要性>= 100的條目都必須在1.0版中釋出，不然我們就會被罰款。

2．  所有重要性在50-99之間的條目應該在1.0中釋出，不過也許我們可以在緊接著的一個快速釋出版中完成這些。

3．  重要性在25-49之間的條目也都是需要的，不過可以在1.1版中釋出

4．  重要性<25的條目都是不確定的，也許永遠不會用到。

對最重要的條目進行時間估算

為了制定釋出計劃，產品負責人需要進行時間估算，至少是要估算在合同中包含的故事。跟sprint計劃會議一樣，這是產品負責人和團隊協作共同完成的—團隊進行估算，產品負責人描述條目內容，回答問題。

統計一切因素，生成釋出計劃

有了時間估算和生產率，可以很容易的把產品backlog拆到sprints中：

3sprints=9個星期=2個月。這是我們要向客戶許諾的最後期限麼？要視合同情況，範圍限制有多嚴格，等等而定。我們通常都會增加相當多的時間緩衝，以避免糟糕的時間估算、未預期的問題和未預期的特性等造成影響。在這種情況下，我們可能會同意把釋出日期定在三個月後，讓我們”保留”一個月。我們可以每隔三個星期就給客戶演示一些有用的東西，並在過程中邀請他們更改需求。

調整發布計劃

每個sprint之後，我們都要看一下這個sprint的實際生產率。如果實際生產率跟估算生產率差距很大，我們就會給下面的sprint調整生產率，更新發布計劃。如果這會給我們帶來麻煩，產品負責人就會跟客戶進行談判；或者檢查一下是否能夠在不違反合同的情況下調整範圍；或者他跟團隊一起找出一些方法，通過消除某些在sprint中發現的嚴重障礙，提高生產率或是投入程度。

組合使用Scrum和XP

Scrum注重的是管理和組織實踐，而XP關注的是實際的程式設計實踐。這就是為什麼它們可以很好的協同工作—-- 它們解決的是不同領域的問題，可以互為補充，相得益彰。

結對程式設計

1．  結對程式設計可以提高程式碼質量。

2．  結對程式設計可以讓團隊的精力更加集中

3．  結對程式設計令人精疲力竭，不能全天都這樣做。

4．  常常更換結對是有好處的。

5．  結對程式設計可以增進團隊間的知識傳播。速度快到令人難以想象。

6．  有些人就是不習慣結對程式設計。不要因為一個優秀的開發人員不習慣結對程式設計就把他置之不理。

7．  可以把程式碼審查座位結對程式設計的替代方案。

8．  “領航員”(不用鍵盤的傢伙)應該自己也有一臺機器。不是用來開發，而是在需要的時候稍稍做一些探索嘗試、當”司機”(使用鍵盤的傢伙)、遇到難題的時候檢視文件，等等。

9．  不要強制大家使用結對程式設計。鼓勵他們，提供合適的工具，讓他們按照自己的節奏去嘗試。

測試驅動開發(TDD)

測試驅動開發意味著你要先寫一個自動測試，然後編寫恰好夠用的程式碼，讓它通過這個測試，接著對程式碼進行重構，主要是提高它的可讀性和消除重複。整理一下，然後繼續。

它會把開發-構建-測試這三者構成的迴圈變得奇快無比，同時還可以充當一張安全網，讓開發人員有足夠的信心頻繁重構，伴隨著系統的增長，設計依然可以保持整潔和簡單。

增量設計

一開始應該保持設計簡單化，然後不斷進行改進;而不是一開始努力保證它的正確性，然後就凍結它，不再改變。

程式碼標準

絕大多數程式設計師都有他們自己特定的程式設計風格。例如他們如何處理異常，如何註釋程式碼，何時返回null等等。有時候這種差異沒什麼關係，但在某些情況下，系統設計就會因此出現不一致的現象，情況嚴重，程式碼也不容易看懂。這時程式碼標準的用處就會凸顯，從造成影響的因素中就可以知道了。

在每個sprint中少做工作來提高質量

回到sprint計劃會議上，簡單來說，就是別把太多故事都放到sprint裡面去！如果碰到了質量問題，或者驗收測試周期太長，乾脆就每個sprint少乾點！這會自動帶來質量提升、驗收測試周期縮短、影響終端使用者的bug減少，並在短期內得到更高的生產率，因為團隊可以始終關注與新的東西，而不是不斷修復出現問題的舊功能。相對於構建大量功能，然後不得不在驚慌失措的狀態下做熱修復來說，少構建一些功能，但是把它弄的穩定點兒，這樣做要合算得多。

Sprint週期 vs. 驗收測試周期

解決下一個sprint和bug的衝突

“可以開始構建新東西，但是要給‘將舊功能產品化’分配高優先順序”

一般我們完成一個sprint以後就會開始進行下一個。但是我們會在接下來的sprint中花一些時間解決過往sprint中留下的bug。如果修復bug佔用了太多時間，從而導致接下來的sprint遭到嚴重破壞，我們就會分析問題產生的原因以及如何提高質量。我們會確保sprint的長度，使之足以完成對上個sprint中一定數量bug的修復。隨著時間推移，經過幾個月以後，修復上個sprint遺留bug所有的時間久會減少。而且當bug發生以後，所牽扯的人也更少了，所以不會總是干擾整個團隊。現在這種做法已經的到了更多人的認可。在sprint計劃會議上，考慮到會花時間修復上個sprint的bug，所以我們會把投入程度設得足夠低。

 

產品層次的Scrum-of-Scrums

這個會議非常重要。我們一週開一次，有時候頻率會更高。在會議上我們會討論整合問題，團隊平衡問題，為下個sprint計劃會議做準備，等等。

議程安排如下：

1．  每個人圍著桌子坐好，描述一下上週各自的團隊都完成了什麼事情，這周計劃完成什麼事情，遇到了什麼障礙。

2．  其他需要討論的跨團隊的問題，例如整合。

團體層次的Scrum-of-Scrums

會議的形式為：

1．  開發主管介紹最新情況。例如即將發生的事件資訊。

2．  大迴圈。每個產品組都有一個人彙報他們上週完成的工作，這周計劃完成的工作，及碰到的問題。其他人也會作報告。

3．  其他人都可以自由補充任何資訊，或者提問問題。

Scrum master檢查列表

         Sprint開始階段

                   Sprint計劃會議之後，建立Sprint資訊頁面

1．  在wiki上建立從dashboard指向所建立頁面的連結。

2．  把頁面打印出來，貼在通過團隊工作區域之外的牆上，讓經過的人都可以看到

給每個發郵件，宣告新的sprint已經啟動。郵件中要包括sprint目標和指向sprint資訊頁面的連結。

更新sprint資料文件。加入估算生產率、團隊大小和sprint長度等等。

確保每日Scrum會議可以按時開始和結束。

為了保證sprint可以如期完成，需要適當地增刪故事。確保產品負責人瞭解這些變化

確保團隊可以及時得知Sprint backlog和燃盡圖的最新狀況。

確保存在的問題和障礙都能被解決，並報告給產品負責人以及開發主管。

在sprint結束時

進行開放式的Sprint演示

在演示開始前一兩天，就要通知到每個人。

與整個團隊以及產品負責人一起開Sprint回顧會議。開發主管也應該受邀參加，他可以把你們的經驗教訓大範圍傳播開來。

更新sprint資料文件。加入實際生產率和回顧會議中總結出的關鍵點。

過程與工具、面面俱到的文件、合同談判、遵循計劃

個體與互動勝過過程與工具

可以工作的軟體勝過面面俱到的文件

客戶協作勝過合同談判

響應變化勝過遵循計劃