敏捷開發方法Scrum最佳實踐

首先強調一些Scrum的基本概念
本文只想爲那些不斷實驗敏捷開發方法、追尋快速交付產品的IT管理者提供全套通過驗證的實踐經驗，供之參考。我首先假設你已經理解了Scrum這種敏捷開發方法的基本概念並認同之，可是仍然，我仍是要強調如下咱們對Scrum達成的「共識」:-)

Scrum開發流程一般以30 天或者更短的一段時間爲一個週期，由產品經理（Product Owner） 提供新產品的需求規格開始，開發團隊（Dev Team） 與產品經理於每個階段開始時挑選該完成的規格部分，開發團隊必須盡力於週期時間內交付成果，團隊由開發主管（Scrum Master） 召集，天天使用15分鐘開會檢查每一個成員的進度與計劃，瞭解所遭遇的困難並設法排除之。

Scrum的重要名詞
Backlog - 能夠預知的任務集，包括功能性的和非功能性的全部任務。

Sprint - 一次迭×××發的時間週期，通常最多以30天爲一個週期。在這段時間內，開發團隊須要完成一個制定的Backlog。

Product Owner - 這個角色被稱爲產品經理。他負責定義產品並向開發團隊提出需求，最終驗收開發團隊的工做成果。

Scrum Master - 負責監督整個Scrum進程、修訂計劃的一個團隊成員。

Sprint planning meeting - 在啓動每一個Sprint前召開。通常爲一天時間（8小時）。該會議須要制定的任務是：Product Owner和團隊成員將Backlog分解成小的功能模塊（即任務），決定在即將進行的Sprint裏須要完成多少小功能模塊，肯定好這個Product Backlog的任務優先級。另外，該會議還需詳細地討論如何可以按照需求完成這些小功能模塊。

Daily scrum meeting - 開發團隊成員參加，通常爲15分鐘。每一個開發成員須要向Scrum Master彙報三個項目：今天完成了什麼？ 是否遇到了障礙？ 即將要作什麼？經過該會議，團隊成員能夠相互瞭解項目進度。

Sprint review meeting - 在每一個Sprint結束後，將這個Sprint的工做成果演示給Product Owner和其餘相關的人員。通常該會議爲４小時。

Sprint retrospective meeting - 對剛結束的Sprint進行總結。會議的參與人員爲團隊開發的內部人員。通常該會議爲３小時。

Scrum過程簡單介紹

1 將整個產品的Backlog分解成若干Sprint Backlog，每一個Sprint Backlog是按照目前的人力物力條件能夠完成的。

2 召開Sprint planning meeting，劃分、肯定這個Sprint內須要完成的任務，標註任務的優先級並分配給每一個成員。

3 進入Sprint開發週期，在這個週期內，天天須要召開Daily Scrum meeting。

4 整個Sprint週期結束，召開Sprint review meeting，將成果演示給Product Owner。

5 團隊成員最後召開Sprint retrospective meeting，總結問題和經驗。

6 周而復始，按照一樣的步驟進行下一次Sprint。

下面開始進入正題——最佳實踐指導思想
Scrum和極限編程（XP）都要求團隊在每一次迭代的結尾完成一些能夠交付的工做片斷。迭代要短、有時間限制。將注意力集中於在短期內交付可工做的代碼，這就意味着Scrum和XP團隊沒有時間進行理論研究。他們不會花時間用建模工具來畫UML圖、編寫完美的需求文檔，也不會爲了應對在可預計的將來中全部可能發生的變化而去寫代碼。實際上，Scrum和XP都關注如何把事情作好。這些團隊認可在開發過程當中會犯錯，可是他們明白：

要投入實踐中，動手去構建產品，這纔是找出錯誤的最好方式；不要只是停留在理論層次上對軟件進行分析和設計。

Scrum不是方法學，它是一個框架。也就是說Scrum不會告訴你到底該作些什麼。所以，如下和你分享的Scrum經驗，只能夠說是供你參考的個案。你不須要徹底仿照如下的作法。實際上若是換個不一樣的場景，也許某些實踐方式就應該換了。

Scrum的強大和使人痛苦之處就在於你不得不根據本身的具體狀況來對它進行調整。

Backlog - Story

如何描述咱們的「故事」（如下的「故事」等同於Backlog），最佳實踐證實至少須要包括這樣一些字段：

ID—— 統一標識符，就是個自增加的數字而已。以防重命名故事之後找不到它們。

Name—— 簡短的、描述性的故事名。好比「查看你本身的交易明細」。它必需要含義明確，這樣開發人員和產品負責人才能大體明白咱們說的是什麼東西，跟其餘故事區分開。它通常由2到10個字組成。

Importance—— 重要性。產品負責人評出一個數值，指示這個故事有多重要。例如10或150。分數越高越重要。
提醒：我一直都想避免「優先級」這個說法，由於通常說來優先級 1 都表示「最高」優先級，但若是後來有其餘更重要的東西就麻煩了。它的優先級評級應該是什麼呢？優先級0？優先級-1？思考一下吧:-)

Initial estimate—— 初始估算。團隊的初步估算，表示與其餘故事相比，完成該故事所需的工做量。
我認爲估算是最具備技術含量和不肯定性的部分，固然也是Scrum過程當中須要持續不斷改進的部分 。
最小的單位是故事點（Story Point），通常大體至關於一個「理想的人天（man-day）」。

什麼是「理想的人天」？ 問一下你的團隊：「若是能夠投入最適合的人員來完成這個故事（人數要適中，一般爲2個），把這些人鎖到一個屋子裏，有不少食物:-P 在徹底沒有打擾的狀況下工做，那麼須要幾天，才能給出一個通過測試驗證的、能夠交付的完整實現呢？」若是答案是「把3我的關在一塊兒，大約須要4天時間」，那麼初始估算的結果就是12個故事點。
一些小經驗： 不須要保證這個估值絕對無誤（好比兩個故事點的故事就應該花兩天時間），而是要保證相對的正確性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半）；區別於「人月神話」中的「人月」，Scrum方法最小的估算粒度通常爲「人天」，有時候能夠小到「0.5人天」，再小就值得商榷了，我是這樣認爲的。這足夠「敏捷」了。

How to demo—— 如何作演示成果。它大略描述了這個故事應該如何在Sprint 演示上進行示範，本質就是一個簡單的測試規範。「先這樣作，而後那樣作，就應該獲得……的結果」。若是你在使用TDD（測試驅動開發），那麼這段描述就能夠做爲驗收測試的僞碼錶示。

Notes—— 註解。相關信息、解釋說明和對其它資料的引用等等。通常都很是簡短。

利用以上的經驗，咱們能夠設計出一個最爲簡單有效的Backlog描述模板，以下：

 

不少團隊曾試過用不少字段描述「故事」，但最後發現，只有上面提到的六個字段會一直使用下去。

內部質量和外部質量
我建議盡力把內部質量和外部質量分開。

外部質量是系統用戶能夠感知的。運行緩慢、讓人迷糊的用戶界面就屬於外部質量低劣。
內部質量通常指用戶看不到的要素，它們對系統的可維護性有深遠影響。可維護性包括系統設計的一致性、測試覆蓋率、代碼可讀性和重構等等。
通常來講，系統內部質量優秀，外部質量仍有可能不好。而內部質量差的系統，外部質量確定也不怎麼樣。

鬆散的沙灘上怎麼可能建起精美的樓閣？

Scrum Master 把外部質量也看做Scrum範圍的一部分。有時出於業務考慮，可能會先發佈一個系統版本，其中用戶界面給人的感受可能比較簡陋，並且反應也很慢；不過隨後會發佈一個乾淨的版本。Scrum Master 都是讓 Product Owner 作權衡，由於他是負責定義項目範圍的人。

不過內部質量就沒什麼好說的了。無論何時，團隊都要保證系統質量，這一點毋庸置疑，也沒有折扣可講。如今如此、未來如此、一直如此，直到永遠。

一個典型的Sprint計劃會議時間表
Sprint 計劃會議：13:00 – 17:00 （建議每小時休息10分鐘）

13:00 – 13:30 產品負責人對Sprint目標進行整體介紹，歸納產品Backlog。定下演示的時間地點。
13:30 – 15:00 團隊估算時間，在必要的狀況下拆分Backlog條目——把「故事」進一步拆分紅「任務」。 產品負責人在必要時修改重要性評分。理清每一個條目的含義。全部重要性高的Backlog條目都要填寫「如何演示」。
15:00 – 16:00 團隊選擇要放入Sprint中的故事。計算生產率，用做覈查工做安排的基礎。
16:00 – 17:00 爲每日Scrum會議（簡稱每日例會）安排固定的時間地點——若是和上次不一樣的話。
Sprint應該多長才好？
時間短就好。公司會所以而變得「敏捷」，有利於隨機應變。

短的Sprint = 短反饋週期 = 更頻繁的交付 = 更頻繁的客戶反饋 = 在錯誤方向上花的時間更少 = 學習和改進的速度更快

衆多好處接踵而至！

可是，時間長的Sprint也不錯:-) 團隊能夠有更多時間充分準備、解決發生的問題、繼續達成Sprint目標，團隊成員也不會被連續不斷的Sprint計劃會議、演示等等壓得不堪重負。

產品負責人通常會喜歡短一點的Sprint，而開發人員喜歡時間長的Sprint。因此Sprint的長度是妥協後的產物。作過屢次實驗後，咱們最終總結出了最受歡迎的長度：三個星期 （固然，這仍然須要根據大家正在開發的產品的實際狀況調整！）。絕大部分團隊的Sprint長度都是三週。它不長不短，既讓咱們擁有足夠的敏捷性，又可讓團隊進入「流暢」的狀態。

此外還有一個有效的經驗：剛開始要根據實際狀況試驗Sprint的長度。不要浪費太多時間作分析。選一個能夠接受的長度先開始再說，等作完一兩個Sprint再進行調整。

爲啥要肯定Sprint的目標?
這個目標能夠是「掙更多的錢」，或者「完成優先級排在最前面的三個故事」，或「讓老闆滿意」，或「把系統作的足夠好，能夠做爲beta版發佈給真正的用戶使用」，或「添加基本的後臺系統支持」等等。它必須用業務術語表達，而不是技術詞彙，由於須要讓團隊之外的人也可以理解。

剛開始制定Sprint計劃的時候，這個目標也許看上去即愚蠢又不合適，但它在Sprint中經常會被提到，這樣，至少你們不會對本身成天忙忙碌碌到底是爲啥而感到困惑。

如何估算Sprint中該包含哪些Story
有兩個通過實踐驗證的技術：

1 本能反應
2 生產率計算

有一個很簡單的辦法：看看團隊的歷史。看看他們在過去幾個Sprint裏面的生產率是多少，而後假定在下一個Sprint裏面生產率也差很少不變。這項技術也被叫作「昨日天氣（yesterday’s weather）」。要想使用該技術，必須知足兩個條件：團隊已經完成了幾個Sprint（這樣就能夠獲得統計數據），會以幾乎徹底相同的方式（團隊長度不變，工做狀態等條件不變）來進行下一個Sprint。

「昨日天氣」用起來很方便，但須要考慮一些常識：

若是上一個Sprint乾得很糟，是由於大部分紅員都病了一星期，或其它很難碰上的變故。那你差很少能夠放心假設此次運氣不會那麼壞，給這個Sprint設個高點的投入程度；

若是團隊最近剛裝了一個執行速度快如閃電的持續集成系統，那你也能夠所以提升一下Sprint的投入程度；

若是有新人加入這個Sprint，就得把他的培訓佔用的精力也算進來，下降Sprint的投入程度；

如何定義「完成（done）」
有一點很重要：產品負責人和團隊須要對「完成」有一致的定義。全部代碼被 check in 之後，故事就算完成了嗎？仍是被部署到測試環境中，通過集成測試組的驗證之後纔算完成？

咱們儘量使用這樣的定義：「隨時能夠上線 」，不過有時候咱們也能夠這樣說：「已經部署到測試服務器上，準備進行驗收測試」。

若是你經常對怎樣定義完成感到困惑，或者你故事的「完成」定義是不能肯定的，那麼，你或許應該在每一個故事上都添加一個字段，起名爲「何謂完成」。

如何精確的估算
若是讓整個團隊進行估算，一般那個對故事理解最透徹的人會第一個發言。不幸的是，這會嚴重影響其餘人的估算。

有一項很優秀的技術能夠避免這一點——它的名字是「計劃紙牌 」。

每一個人都會獲得如上圖所示的13張卡片。在估算故事的時候，每一個人都選出一張卡片來表示他的時間估算（以故事點的方式表示），並把它正面朝下扣在桌上。全部人都完成之後，桌上的紙牌會被同時揭開。這樣每一個人都會被迫進行自我思考，而不是依賴於其餘人估算的結果。
若是在兩個估算之間有着巨大差別，團隊就會就此進行討論，並試圖讓你們對故事內容達成共識。他們也許會進行任務分解，以後再從新估算。這樣的循環會往復進行，直到時間估算趨於一致爲止，也就是每一個人對這個故事的估算都差很少相同。

估算須要注意如下幾點
1 試着避免技術故事。 努力找到一種方式，把技術故事變成能夠衡量業務價值的普通故事。這樣有助於產品負責人作出正確的權衡，由於產品負責人可能對技術知之甚少。

2 若是沒法把技術故事轉變成普通故事，那就看看這項工做能不能看成另外一個故事中的某個任務。 例如，「重構DAO層」能夠做爲「編輯用戶」中的一個任務，由於這個故事會涉及到DAO層。

3 若是以上兩者都無論用，那就把它定義爲一個技術故事，用另一個單獨的列表來存放。 產品負責人能看到它，可是不能編輯它。用「投入程度」和「預估生產率」這兩個參數來跟產品負責人協商，從Sprint裏撥出一些時間來完成這些技術故事。

咱們該如何管理Backlog
這個問題看起來有點難搞。

用Excel來管理產品 Backlog 很不錯，不過你仍然須要一個Bug跟蹤系統，這時Excel就無奈了。能夠用Jira。

那咱們怎麼把 Jira 上的 issue 帶到 Sprint 計劃會議上和咱們每日的工做中來呢？個人提議是：
把 Sprint Backlog 計劃，貼到「白板」上！

如下很少說廢話，直接上圖——看圖說話：

很明顯，這是一張「健康」的燃盡（Burn Down）圖，隨着時間的推動，以 人/天 爲單位的故事點基本上沿着標準線減小，直至「燃盡」……

一面典型的、簡潔的、實用的「白板」。很不幸，它描述了「計劃趕不上變化」的場景——臨時插入的大量任務阻塞了計劃，致使了燃盡圖「燃而不盡」。

通常來講，咱們把高優先級的任務放在上面，是爲了先作之。這面「白板」很成功的描述了次序顛倒、「撿了芝麻、丟了西瓜」的錯誤工做順序。

 

 

 

燃盡圖是個很好的玩意，它可讓咱們以最簡單的方法發現項目進行中的一些問題。下面的任務彷佛太多或太難了，正在逐漸偏離計劃。也許須要尋找問題了，也許須要調整一下現行的計劃了……

下面計劃定的彷佛太寬鬆了，做爲開發人員也許很Happy:-)，但若是你是老闆或管理者該怎麼辦？加活吧！讓弟兄們的工做來的更加「充實」些吧……

最後，呼應一下前面： 咱們用 人/天 做爲全部時間估算的基礎（咱們也把它叫作故事點）。它的最小值是0.5，也就是說小於0.5的任務要麼被移除，要麼跟其餘任務合併，要麼就乾脆給它0.5的估算值 。乾淨利落。