首先強調一些Scrum的基本概念
本文只想爲那些不斷實驗敏捷開發方法、追尋快速交付產品的IT管理者提供全套經過驗證的實踐經驗，供之參考。我首先假設你已經理解了Scrum這種敏捷開發方法的基本概念並認同之，但是仍然，我還是要強調以下我們對Scrum達成的“共識”:-)
本文只想爲那些不斷實驗敏捷開發方法、追尋快速交付產品的IT管理者提供全套經過驗證的實踐經驗，供之參考。我首先假設你已經理解了Scrum這種敏捷開發方法的基本概念並認同之，但是仍然，我還是要強調以下我們對Scrum達成的“共識”:-)
Scrum開發流程通常以30 天或者更短的一段時間爲一個週期，由產品經理（Product Owner） 提供新產品的需求規格開始，開發團隊（Dev Team） 與產品經理於每一個階段開始時挑選該完成的規格部分，開發團隊必須盡力於週期時間內交付成果，團隊由開發主管（Scrum Master） 召集，每天使用15分鐘開會檢查每個成員的進度與計劃，瞭解所遭遇的困難並設法排除之。
Scrum的重要名詞
Backlog - 可以預知的任務集，包括功能性的和非功能性的所有任務。
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和極限編程（XP）都要求團隊在每一次迭代的結尾完成一些可以交付的工作片段。迭代要短、有時間限制。將注意力集中於在短時間內交付可工作的代碼，這就意味着Scrum和XP團隊沒有時間進行理論研究。他們不會花時間用建模工具來畫UML圖、編寫完美的需求文檔，也不會爲了應對在可預計的未來中所有可能發生的變化而去寫代碼。實際上，Scrum和XP都關注如何把事情做好。這些團隊承認在開發過程中會犯錯，但是他們明白：
要投入實踐中，動手去構建產品，這纔是找出錯誤的最好方式；不要只是停留在理論層次上對軟件進行分析和設計。
Scrum不是方法學，它是一個框架。也就是說Scrum不會告訴你到底該做些什麼。因此，以下和你分享的Scrum經驗，只可以說是供你參考的個案。你不需要完全仿照以下的做法。實際上如果換個不同的場景，也許某些實踐方式就應該換了。
Scrum的強大和令人痛苦之處就在於你不得不根據自己的具體情況來對它進行調整。
Backlog - Story
如何描述我們的“故事”（以下的“故事”等同於Backlog），最佳實踐證明至少需要包括這樣一些字段：
ID—— 統一標識符，就是個自增長的數字而已。以防重命名故事以後找不到它們。
Name—— 簡短的、描述性的故事名。比如“查看你自己的交易明細”。它必須要含義明確，這樣開發人員和產品負責人才能大致明白我們說的是什麼東西，跟其他故事區分開。它一般由2到10個字組成。
Importance—— 重要性。產品負責人評出一個數值，指示這個故事有多重要。例如10或150。分數越高越重要。
提醒：我一直都想避免“優先級”這個說法，因爲一般說來優先級 1 都表示“最高”優先級，但如果後來有其他更重要的東西就麻煩了。它的優先級評級應該是什麼呢？優先級0？優先級-1？思考一下吧:-)
提醒：我一直都想避免“優先級”這個說法，因爲一般說來優先級 1 都表示“最高”優先級，但如果後來有其他更重要的東西就麻煩了。它的優先級評級應該是什麼呢？優先級0？優先級-1？思考一下吧:-)
Initial estimate—— 初始估算。團隊的初步估算，表示與其他故事相比，完成該故事所需的工作量。
我認爲估算是最具有技術含量和不確定性的部分，當然也是Scrum過程中需要持續不斷改進的部分 。
最小的單位是故事點（Story Point），一般大致相當於一個“理想的人天（man-day）”。
我認爲估算是最具有技術含量和不確定性的部分，當然也是Scrum過程中需要持續不斷改進的部分 。
最小的單位是故事點（Story Point），一般大致相當於一個“理想的人天（man-day）”。
什麼是“理想的人天”？ 問一下你的團隊：“如果可以投入最適合的人員來完成這個故事（人數要適中，通常爲2個），把這些人鎖到一個屋子裏，有很多食物:-P 在完全沒有打擾的情況下工作，那麼需要幾天，才能給出一個經過測試驗證的、可以交付的完整實現呢？”如果答案是“把3個人關在一起，大約需要4天時間”，那麼初始估算的結果就是12個故事點。
一些小經驗： 不需要保證這個估值絕對無誤（比如兩個故事點的故事就應該花兩天時間），而是要保證相對的正確性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半）；區別於“人月神話”中的“人月”，Scrum方法最小的估算粒度一般爲“人天”，有時候可以小到“0.5人天”，再小就值得商榷了，我是這樣認爲的。這足夠“敏捷”了。
一些小經驗： 不需要保證這個估值絕對無誤（比如兩個故事點的故事就應該花兩天時間），而是要保證相對的正確性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半）；區別於“人月神話”中的“人月”，Scrum方法最小的估算粒度一般爲“人天”，有時候可以小到“0.5人天”，再小就值得商榷了，我是這樣認爲的。這足夠“敏捷”了。
How to demo—— 如何做演示成果。它大略描述了這個故事應該如何在Sprint 演示上進行示範，本質就是一個簡單的測試規範。“先這樣做，然後那樣做，就應該得到……的結果”。如果你在使用TDD（測試驅動開發），那麼這段描述就可以作爲驗收測試的僞碼錶示。
Notes—— 註解。相關信息、解釋說明和對其它資料的引用等等。一般都非常簡短。
利用以上的經驗，我們可以設計出一個最爲簡單有效的Backlog描述模板，如下：
很多團隊曾試過用很多字段描述“故事”，但最後發現，只有上面提到的六個字段會一直使用下去。
內部質量和外部質量
我建議盡力把內部質量和外部質量分開。
我建議盡力把內部質量和外部質量分開。
外部質量是系統用戶可以感知的。運行緩慢、讓人迷糊的用戶界面就屬於外部質量低劣。
內部質量一般指用戶看不到的要素，它們對系統的可維護性有深遠影響。可維護性包括系統設計的一致性、測試覆蓋率、代碼可讀性和重構等等。
一般來說，系統內部質量優秀，外部質量仍有可能很差。而內部質量差的系統，外部質量肯定也不怎麼樣。
內部質量一般指用戶看不到的要素，它們對系統的可維護性有深遠影響。可維護性包括系統設計的一致性、測試覆蓋率、代碼可讀性和重構等等。
一般來說，系統內部質量優秀，外部質量仍有可能很差。而內部質量差的系統，外部質量肯定也不怎麼樣。
鬆散的沙灘上怎麼可能建起精美的樓閣？
Scrum Master 把外部質量也看作Scrum範圍的一部分。有時出於業務考慮，可能會先發佈一個系統版本，其中用戶界面給人的感覺可能比較簡陋，而且反應也很慢；不過隨後會發佈一個乾淨的版本。Scrum Master 都是讓 Product Owner 做權衡，因爲他是負責定義項目範圍的人。
不過內部質量就沒什麼好說的了。不管什麼時候，團隊都要保證系統質量，這一點毋庸置疑，也沒有折扣可講。現在如此、將來如此、一直如此，直到永遠。
一個典型的Sprint計劃會議時間表
Sprint 計劃會議：13:00 – 17:00 （建議每小時休息10分鐘）
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應該多長才好？
時間短就好。公司會因此而變得“敏捷”，有利於隨機應變。
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版發佈給真正的用戶使用”，或“添加基本的後臺系統支持”等等。它必須用業務術語表達，而不是技術詞彙，因爲需要讓團隊以外的人也能夠理解。
這個目標可以是“掙更多的錢”，或者“完成優先級排在最前面的三個故事”，或“讓老闆滿意”，或“把系統做的足夠好，可以作爲beta版發佈給真正的用戶使用”，或“添加基本的後臺系統支持”等等。它必須用業務術語表達，而不是技術詞彙，因爲需要讓團隊以外的人也能夠理解。
剛開始制定Sprint計劃的時候，這個目標也許看上去即愚蠢又不合適，但它在Sprint中常常會被提到，這樣，至少大家不會對自己整天忙忙碌碌究竟是爲啥而感到困惑。
如何估算Sprint中該包含哪些Story
有兩個經過實踐驗證的技術：
有兩個經過實踐驗證的技術：
1 本能反應
2 生產率計算
2 生產率計算
有一個很簡單的辦法：看看團隊的歷史。看看他們在過去幾個Sprint裏面的生產率是多少，然後假定在下一個Sprint裏面生產率也差不多不變。這項技術也被叫做“昨日天氣（yesterday’s weather）”。要想使用該技術，必須滿足兩個條件：團隊已經完成了幾個Sprint（這樣就可以得到統計數據），會以幾乎完全相同的方式（團隊長度不變，工作狀態等條件不變）來進行下一個Sprint。
“昨日天氣”用起來很方便，但需要考慮一些常識：
如果上一個Sprint乾得很糟，是因爲大部分成員都病了一星期，或其它很難碰上的變故。那你差不多可以放心假設這次運氣不會那麼壞，給這個Sprint設個高點的投入程度；
如果團隊最近剛裝了一個執行速度快如閃電的持續集成系統，那你也可以因此提高一下Sprint的投入程度；
如果有新人加入這個Sprint，就得把他的培訓佔用的精力也算進來，降低Sprint的投入程度；
如何定義“完成（done）”
有一點很重要：產品負責人和團隊需要對“完成”有一致的定義。所有代碼被 check in 以後，故事就算完成了嗎？還是被部署到測試環境中，經過集成測試組的驗證以後纔算完成？
有一點很重要：產品負責人和團隊需要對“完成”有一致的定義。所有代碼被 check in 以後，故事就算完成了嗎？還是被部署到測試環境中，經過集成測試組的驗證以後纔算完成？
我們儘可能使用這樣的定義：“隨時可以上線 ”，不過有時候我們也可以這樣說：“已經部署到測試服務器上，準備進行驗收測試”。
如果你常常對怎樣定義完成感到困惑，或者你故事的“完成”定義是不能確定的，那麼，你或許應該在每個故事上都添加一個字段，起名爲“何謂完成”。
如何精確的估算
如果讓整個團隊進行估算，通常那個對故事理解最透徹的人會第一個發言。不幸的是，這會嚴重影響其他人的估算。
如果讓整個團隊進行估算，通常那個對故事理解最透徹的人會第一個發言。不幸的是，這會嚴重影響其他人的估算。
有一項很優秀的技術可以避免這一點——它的名字是“計劃紙牌 ”。
每個人都會得到如上圖所示的13張卡片。在估算故事的時候，每個人都選出一張卡片來表示他的時間估算（以故事點的方式表示），並把它正面朝下扣在桌上。所有人都完成以後，桌上的紙牌會被同時揭開。這樣每個人都會被迫進行自我思考，而不是依賴於其他人估算的結果。
如果在兩個估算之間有着巨大差異，團隊就會就此進行討論，並試圖讓大家對故事內容達成共識。他們也許會進行任務分解，之後再重新估算。這樣的循環會往復進行，直到時間估算趨於一致爲止，也就是每個人對這個故事的估算都差不多相同。
如果在兩個估算之間有着巨大差異，團隊就會就此進行討論，並試圖讓大家對故事內容達成共識。他們也許會進行任務分解，之後再重新估算。這樣的循環會往復進行，直到時間估算趨於一致爲止，也就是每個人對這個故事的估算都差不多相同。
估算需要注意以下幾點
1 試着避免技術故事。 努力找到一種方式，把技術故事變成可以衡量業務價值的普通故事。這樣有助於產品負責人做出正確的權衡，因爲產品負責人可能對技術知之甚少。
1 試着避免技術故事。 努力找到一種方式，把技術故事變成可以衡量業務價值的普通故事。這樣有助於產品負責人做出正確的權衡，因爲產品負責人可能對技術知之甚少。
2 如果無法把技術故事轉變成普通故事，那就看看這項工作能不能當作另一個故事中的某個任務。 例如，“重構DAO層”可以作爲“編輯用戶”中的一個任務，因爲這個故事會涉及到DAO層。
3 如果以上二者都不管用，那就把它定義爲一個技術故事，用另外一個單獨的列表來存放。 產品負責人能看到它，但是不能編輯它。用“投入程度”和“預估生產率”這兩個參數來跟產品負責人協商，從Sprint裏撥出一些時間來完成這些技術故事。
我們該如何管理Backlog
這個問題看起來有點難搞。
這個問題看起來有點難搞。
用Excel來管理產品 Backlog 很不錯，不過你仍然需要一個Bug跟蹤系統，這時Excel就無奈了。可以用Jira。
那我們怎麼把 Jira 上的 issue 帶到 Sprint 計劃會議上和我們每日的工作中來呢？我的提議是：
把 Sprint Backlog 計劃，貼到“白板”上！
把 Sprint Backlog 計劃，貼到“白板”上！
以下不多說廢話，直接上圖——看圖說話：
很明顯，這是一張“健康”的燃盡（Burn Down）圖，隨着時間的推進，以 人/天 爲單位的故事點基本上沿着標準線減少，直至“燃盡”……
一面典型的、簡潔的、實用的“白板”。很不幸，它描述了“計劃趕不上變化”的場景——臨時插入的大量任務阻塞了計劃，導致了燃盡圖“燃而不盡”。
一般來說，我們把高優先級的任務放在上面，是爲了先做之。這面“白板”很成功的描述了次序顛倒、“撿了芝麻、丟了西瓜”的錯誤工作順序。
下面計劃定的似乎太寬鬆了，作爲開發人員也許很Happy:-)，但如果你是老闆或管理者該怎麼辦？加活吧！讓弟兄們的工作來的更加“充實”些吧……
