敏捷開發方法Scrum經驗總結

通過實踐證實，Scrum 方法用於開發要求快速、靈活，且生命週期短的需求仍是很給力的。

關於啓動 Scrum 方法的套路就再也不贅述了，都是經典的東西。下面總結一下獨特的經驗（你們鼓掌）：

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

互聯網行業的開發很是適應 Scrum 的特色，由於週期短、變化多、交付快……。Scrum 自己是一種思想方法，不一樣的項目對其須要有不一樣的實現和裁剪，經過不斷的迭代（sprint），找到最合適本身的實踐。

做者：胡奇 for 51CTO.com