在實施 Scrum 時, 最常遇到的一個狀況, 就是忽然說有急件, 希望團隊可以趕快處理.
根據 Scrum 的定義, 在 iteration 中途, 是不能再加功能, 也不能變更iteration 的長短.
可是如果真的需要處理這些緊急的要求(這些急件可能是新的需求, 或者是之前出貨的產品有嚴重的瑕疵), 那該怎麼做才是比較合理呢?
1. 仔細把關
Sales 或是產品經理老是說, 如果沒有這個功能就賣不出去; 或者是說有了這個項目, 客戶就會簽約. 但是事實會是這樣嗎? 大多狀況都是做了以後, 也不會賺進半毛錢. 產品負責人需要好好把關, 和 Sales 和產品經理好好討論, 很慎重告訴他們, 黃牛太多次後, engineers只會越做越慢, 反而造成之後兩敗俱傷.
2. 下個 iteration 再做
有很多東西可能是要做沒錯, 但是不一定要馬上立即做. 有時候可能讓產品負責人先去討論需求, 來來回回確認之後, 其實已經是下個 iteration 的開始. 因為很名正言順的下個 iteration 開始做. 完全不會打亂正常 scrum 的作息.
3. 拿還沒開工的 story 來換
有時候真的強迫開始開工, 這時候可以看看 iteration 中是否有還沒開工的 story, 如果有的話, 便可以和這個緊急事件交換, 或許大小不一定相等; 並且你可能還要花時間評估, 以及拆解細部的 task, 但是這樣已經降低不少傷害. 比被強迫再多做一個新的項目好很多.
4. 10% 的 buffer.
這個方法是在每次挑選功能時, 只拿出 90% 的火力來做事, 保留 10% 的能量, 以備不時之需. 如果你所在的環境中, 常常有急件的狀況發生, 說不定這是一個不錯的方式. 但是如果常常有急件進來, 或者急件的複雜度很多, 10% 的 buffer 可能也是吃不下.
5. 採用 Kanban 的做法.
如果急件在你的組織是常態, 那這時候可能要思考, scrum 是否是合適的選擇. 說不定可能沒有 iteration 限制的 Kanban, 比較合適在你的團隊中. 只要目前手頭的做完, 下一個便處理你所謂的急件.
6. 兩個團隊
一個團隊處理原先 sprint 要做的事情, 另一個團隊專門處理外面來的急件, 某種程度和 10% 的 buffer 很類似. 但是這完全是分開的兩組人馬處理, 這樣另一組人員就可以完全專心工作.
但是不管你採取哪種方法, 最後有件事, 值得你去思考一下: 做一下魚骨圖分析, 為什麼 PM/sales 定好的功能, 老是跟急件的不一樣? 或者你的程式為什麼老是不穩定, 導致有重大的 bug 要立即修復? 救急不是辦法, 或許要解決源頭才是根本!!
留言列表
