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 正是他們目前的選擇.
資料來源: https://stormpath.com/blog/so-long-scrum-hello-kanban/
留言列表
