經過實踐證明，Scrum 方法用於開發要求快速、靈活，且生命週期短的需求還是很給力的。
關於啓動 Scrum 方法的套路就不再贅述了，都是經典的東西。下面總結一下獨特的經驗（大家鼓掌）：
- 在 sprint planning meeting 上定好本次迭代（迭代即 sprint，之於Scrum的意義不解釋）的計劃，計算出總“人天”和這次迭代的總“工作日”，畫出 burn down 圖，burn down 圖對於把控 sprint 的進度、及時發現進度和阻礙方面問題是有幫助的。
- 可以考慮加入“投入程度 ”這個指標調節個人的“人天”數，如果有需求之外因素，例如技術變革啥玩意干擾的話。
- 爲方便管理和估算，最小的估算時間單位爲 0.5人天 ，比這個還小的粒度或忽略或歸併。
- 一般最大的任務單位爲 5人天 ，即一個工作周的時間。我認爲一個任務工作量的估算超過這個數字就不適用 Scrum 敏捷的特徵了，這時候要麼拆解，要麼直接回歸經典軟件工程的“人月神話”得了。
- 在白板上建立 next 域 和 緊急任務 域 是非常重要的。前者可以確保你不會丟失因爲種種原因而未排入本次 sprint 的需求任務；後者用於處理不可避免的緊急任務（一般是老大從戰略角度壓下來的，非計劃的），這也能讓管理者清楚的看到計劃爲何 delay 或爲何要加班。
- 在 sprint 過程中，如果發現因爲需求不明確而無法進行的任務，請立即歸入 next 域（不要猶豫，因爲開發不明確的需求猶如盲人摸象，返工成本絕對夠任何人喝一壺的），這樣可有效的避免浪費時間，可敦促需求人員完善設計，且不會丟失需求。——如果這種情況多了，burn down 圖會很快燃盡，Scrum master 能夠及時提醒 Scrum owner 提高需求和設計的質量。
- 對於臨時插入的任務，重要且緊急 的立刻排入 緊急任務 域，立刻打斷 sprint 計劃，不惜代價開始搞，因爲你已經將此任務識別爲重要且緊急。——如果這種情況多了，白板上的反映爲 緊急任務 域密密麻麻，而此段時間內，burn down 圖將呈一條水平線。這是因爲計劃任務被大量緊急任務打斷，而無法“燃燒”，這時候，插入臨時任務的人就應該思考了？爲什麼那麼多事情都沒有計劃！
- 對於臨時插入的任務，重要且不緊急 的進入 next 域，走下次 sprint。這樣即可以給這些重要的任務一個應有的地位，也不會打亂現有的計劃。我們要儘量按計劃做事，否則再好的計劃也沒有人會執行鳥。
- 除此之外的任務，開發人員還用考慮麼？需求人員懂的。
- 每天的晨會可以方便大家的互相瞭解情況，及時的發現並解決一些問題，隱藏的很深的 Block 一般在這個時候會被識別出來。
- 週期再短的 sprint，也會有開發人員先行完成所有計劃任務，這時候可以嘗試把此人拿去和某些未完成關鍵任務的人去玩結隊編程或同級評審（peer review）。這也可應付突發情況，例如，即使某個關鍵人物得了病，sprint 也不至於完蛋。
- 對於任務完成（done）的定義就是：隨時可以上線 。因爲畢竟要上線還是需要一個“良辰吉日”——所有的相關需求都OK才行。
- 每個 sprint 結束後，最好有一天間歇的時間整理總結。一個 sprint 緊接着一個 sprint 容易使人疲勞。
- 對於需求人員（包括 Scrum owner）由於經驗不足，在 sprint planning meeting 提出的需求過小，而 sprint 開始後需求頻繁變更或擴大化導致技術人員對任務評估不足的情況。可以有下面3個解決步驟：
- 需求文檔化。即執行CMM方法的需求管理模塊，嚴格跟蹤需求變更，需求必須文檔化。需求變更可以，但是要有標記、可追溯。需求文檔納入配置管理。
- 識別：需求變更需要一部到位的。在達成需求擴大的共識後，把擴大的需求單獨拆出，放到“緊急任務”域中。前面已經說了這在燃盡圖上會體現出來，導致“燃不盡”，讓問題暴露出來！
- 識別：需求變更可以分段優化的。在當前 sprint 中留出擴展接口，需求變更作爲新需求扔到 next 域裏，歸入下一個 sprint。還是那句話，儘量按照計劃來，這是個原則。
- 當然還要遵循“緊急/不緊急”的原則，可以這樣理解：sprint 計劃是 Scrum master 和 Scrum owner 簽訂的“合同”，合同不能篡改。而對於合同的增補和裁剪是允許的，但需要記錄在案、有案可查。
- “團隊凝聚力”是 Scrum 的核心要素之一，如果一個團隊同心協力完成了多個 sprint，團隊成員就會變得非常緊密。他們會學會如何達成團隊涌流（group flow，請參見 http://en.wikipedia.org/wiki/Flow_%28psychology%29 ），生產力會提升至難以置信的地步。不過要達到這個地步需要花上一定時間。如果不斷變換團隊組成，你就永遠無法得到強悍的“團隊生產力”。所以，如果你確實想要重新組織團隊，請先考慮一下後果。這是個長期變化還是短期變化？如果是短期變化，最好考慮跳過這一步。如果是長期變化，那可以幹。
互聯網行業的開發非常適應 Scrum 的特點，因爲週期短、變化多、交付快……。Scrum 本身是一種思想方法，不同的項目對其需要有不同的實現和裁剪，通過不斷的迭代（sprint），找到最合適自己的實踐。
作者：胡奇 for 51CTO.com