Stormpath 是一家 user management API 的公司, 提供一些機制讓你可以在任何系統中, 方便管理其系統的使用者. 這家公司從 2013 年開始, 從 Scrum 開發方法轉型到使用 Kanban 的做法. 為什麼他們要做這樣的轉換呢? 讓我們來看看他們的想法:
敏捷原則在 Stormpath中還是很重要的. 這些 principles 在開發過程中都是要遵守的, 它帶來了透明度, iteration讓你頻繁交付, 小的故事可以讓我們更容易掌握進度, 這些都可以讓我們更早發現問題, 更早知道客戶是否喜歡這些功能.
但是他們覺得 Scrum 對他們來說還是不可行的, 覺得太僵化, 太多開銷, 導致讓團隊成員最後排斥使用 Scrum. 以下是他們所遭遇的問題:
1. 開銷
sprint planning meeting 通常要很長的時間, 讓大家一起來規劃這個 sprint 要做的事情. 即使 Stormpath 已經是一個合作密切的公司, 工程師們還是要花個一個早上, 坐在一起去聽些跟他們沒有的關的部分
2. 評估的神話
我們知道長時間的東西會估不準, 但是不代表即使 1-2 周的工作, 我們就能很精確. 此外, agile 在評估時, 都是先評估 size, 然後再轉換成時間. 但是與其花時間討論 size, 不如好好把它拆解的更小, 或者是直接去開工了. 所以 planning 的效用並沒有很大, 因為 Scrum 還是假設我們在 sprint 中的工作會估得很準
3. 不預期的改變
在專案進行的過程中, 總是會有遇到一些嚴重的 bug; 或者是 users 建議了一些東西, 導致我們承諾要做的東西要修正; 這些東西都可能導致我們要再重新評估時間. 像這樣的事情, 會一直在發生, 讓我們一直花時間在更新計劃. 然後我們在 retro 的時候就會指責為什麼做不完, 而忘記這些 change 所帶來的 replan 以及一堆混亂. 進而使大家士氣低落.
這些項目正好跟我遇到的情況, 大約有 80% 以上吻合. 大多數的人都抱怨雷同的狀況, 因此 Stormpath 就開始尋找, 是否有別的方法, 能夠幫他們改善 Scrum 的缺點, 而且還能讓他們開發過程更順利. 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 之後, 團隊的氣氛是變得比較快樂的.
資料來源: https://stormpath.com/blog/so-long-scrum-hello-kanban/
發表迴響