上回提到 (http://kojenchieh.pixnet.net/blog/post/375219767) Stormpath 要從 Scrum 轉換到 Kanban 的原因, 這次我們來看看 Stormpath 為什麼覺得 Kanban 有幫助
為了避免多工, 也就是同時間做太多事情, 因為這樣讓你的工作效率變差. 在 Scrum 中, 我們規定 sprint 的內容確定後, 不能再變動, 請確保我們不回讓大家同時做的事情的數量一直增加. 而在 Kanban 中, 我們用的是另一種方式, 我們限制在每個欄位中, 最多只能進行多少工作.
那這兩個有什麼差別呢? 在 scrum 中你要先估計, 每個 sprint 你可以做多少事情. 估計完後就不能再增加, 可惜的是我們都估不準, 或者是因為突發事件一直件來, 我們又需要重估, 導致大家時間都花在估計上面. 可是 kanban 就不同了, 如果在設計這個欄位中, 最多只能做 2 件事情, 你就可以最多拉 2 件工作, 做完就再拉下一個進來, 你只需要估拉進來的這件事情就好, 不用再想那些還沒拉進的工作. 因此估計這件事情就不用再花太多時間.
Kanban 另一個重點就是 cycle time, 也就每個功能 end to end 完成的時間多長. 它的重心是放在讓拉進來的功能, 要能進快的完工, 而不是一直增加開始處理的功能. 也就是專心把一件事情做完, 不要多工, 不要 context switching.
此外, 雖然沒有 sprint 的概念, 不代表我們沒有計劃, 而是我們利用資訊透明化的方式, 讓大家知道我們在做什麼, 誰在忙什麼, 為什麼你要做這麼久. 藉由看到問題, 我們來改進流程不順, 或是哪些地方品質做得不好. 這些資訊大家都看得到, 都可以提出質疑, 可以一起來改. 不要再等到 sprint planning meeting 才處理.
Scrum 的 sprint 做法, 會讓某些成員急於要在 sprint 結束前, 把他們手頭上的工作做完, 但不是把事情給做好. Kanban 裡沒有 sprint, 為的就是讓你好好把事情做好. 如果你做太慢, 會由 cycle time, 或是卡在某個欄位中看出來, 這時候會跟你做確認, 所以兼顧了要把事情做好, 以及知道工作是否延遲的兩個狀況.
我們也有進行 retrospective, 但是不像 Scrum 一樣, 在檢討我們過去哪裡做得不好. 我們把重心放在, 將來要怎麼做會比較好, 如何會開發的比較順利, 品質會比較好.
總結:
Kanban 在以下方面讓我們覺得表現不錯
1. 利用可視化來看出問題在哪
2. 專注少量的事情上面
- 做完才來拉下一個,
- 不花太多時間估計
- 確認把事情做好
雖然 Kanban 並不完美, 也不見得適合每一個人. 但是轉換到 Kanban 之後, 團隊的氣氛是變得比較快樂的.
留言列表
