Source: When to dump Scrum for Kanban
當你的團隊開始使用 agile時, 很多人會開始研究 Scrum Guide (http://www.scrumguides.org/), 然後進行了許多次的 sprints, 團隊進行都相當順暢和快速. 團隊成員也感到非常高興, 因為他們被充分授權去完成產品. 這樣的好日子直到有一天 ….
CEO 或是高階主管跑來, 要求在這個 sprint 中要增加 X, Y, Z 三個功能進去.
是的, 沒錯, 你們遇到了 Stormpath 遭遇到問題: 需求一直在修改. 有沒有覺得很熟悉, 大家都遇到同樣的問題. 請看這一篇的說明: 為什麼 Stormpath 要從 Scrum 轉換到 Kanban 的原因?
這些”小” 的修改, 將會產生下面的狀況:
- 團隊的速度會不正確
- 無意義的 sprint 規劃會議
- context switching 的狀況變多
為什麼會發生這些事情呢? 我想大家可以從這篇文章得到一些解答: Why SCRUM Sprints slow you down
因此, 你可能接下來會一個問題: 如果我無法把承諾的工作, 在 sprint 內把事情做完, 那我為什麼還要進行規劃會議? (因為有太多變動, 導致我們的估計嚴重不準.)
所以, 哪我們為什麼要導入 Scrum? 或者說什麼狀況下才能實施 Scrum?
對於 Scrum 來說, 在 sprint 中承諾的範圍是不變的. 但是對於 Kanban 來說, 只要沒超過 WIP 的話, 承諾的範圍就不會改變.
因此, 如果你要使用 Scrum, 並且能反應快速的話, 你可能...
- sprint 的長度不應該太長
- 教育你的產品負責人和相關利害關係人, 讓他們可能提供較明確的需求.
- 終於了解 Scrum 可能根本不適合你們的 project
專注而非快速
Kanban 對於需求或是優先順序常常改變的狀況是非常有用的, 它可以讓你即時反應, 但是它並不是要求做比較快, 而是希望藉由專事把事情做好, 來讓整個進度變得比較快.
要如何可以專心做好呢? agile 藉由 swarm 的方式, 也就是大家一起齊心合作, 共同處理一個相同的問題, 來讓事情可以專心做好.
而 Kanban 呢? 則是利用限制 WIP limit 的方式, 減少同時處理的工作, 來讓大家專心.
所以, 剛你需要反應快速, 並且能夠做出更多東西, Kanban 可能比 Scrum 更合適你.
全站熱搜
留言列表
