天天看點

靈活開發方法Scrum經驗總結

經過實踐證明,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 的特點,因為周期短、變化多、傳遞快……。Scrum 本身是一種思想方法,不同的項目對其需要有不同的實作和裁剪,通過不斷的疊代(sprint),找到最合适自己的實踐。

     本文轉自胡奇 51CTO部落格,原文連結:http://blog.51cto.com/huqicto/367467,如需轉載請自行聯系原作者

繼續閱讀