Why we moved from Scrum to Kanban
http://nealchampion.blogspot.tw/2014/01/why-we-moved-from-scrum-to-kanban.html
這篇文章裡作者提出他對 scrum 的一些經驗和看法, 我想很多人也遭遇到相同的狀況. Scrum 雖然是一個不錯的開發方法, 但是由於本身能力不夠, 或是被誤解誤用, 導致最後對它有所埋怨情況還時有所聞. 讓我們來看看他遇到了什麼事情:
以下是作者的團隊一再碰到的三個問題:
1. sprint 規劃會議是個夢魘
大部份的人不清楚功能是什麼時, 是無法做估計的. 因此他們就在規劃會議前先做需求的釐清, 可是等到需求清楚後, 又要釐清架構設計的問題, 所以在開規劃會議前, 就要花很多時間去討論, 大家才能有機會做規劃會議.
2. 測試被壓縮
一個功能要寫完後, 才能開始進行測試; 並且有時候因為開發延遲, 測試的時間會被縮短. 所以結果會有兩種狀況: (1) 測試可能會做得比較隨便, 或是 (2) 可能跟 scrum master 說, 這個 story 可能要下個 sprint才能做完.
3. 功能無法在單一 sprint 內完成
因為需求分析和架構設計要在 sprint 規劃會議前做完, 否則無法評估和事可以做完. 此外也因為測試做不完會移到下個 sprint, 所以會有單一個 sprint 只是在做 coding.
所以作者根據他所遭遇的事情, 認為傳統 Scrum 有以下問題:
1. 假設每個人可以做所有事情
他認為每個人有每個專長的項目, 會開發不一定做好測試, 會分析的不一定會開發, 所以很少有團隊可以做到, 大部份的人會做大部份的事情.
2. 假設開發一個故事只是簡單的工作
開發一個故事, 需要經過一連串的步驟, 像是需求分析, 架構設計, UI 設計, 編程, 測試等等. 而這些工作, 大多需要循序進行, 也就是說無法同時發生. 像是 UI 沒確定就無法寫程式, 程式沒寫好有些測試是無法進行的.
當你也面對同樣的狀況時, 你是怎麼處理的?
作者是選擇使用 kanban, 選擇了看版之後, 雖然不要求每個人要多技能, 也不要求要有詳細的規劃會議來評估所要的時間. 但是在使用 kanban 很重要的一件事情, 就是會一直持續改進. 他會藉由
1. 視覺化處理狀況
觀察你哪裡塞車, 哪裡隨便做做的結束了, 找出問題所在.
2. WIP 限制
限制了你同時能處理多少事情, 因此減緩了多工現象. 並且讓塞車問題及早浮現.
使用了這兩招, 你可以發現到你面前做事方法有問題, 例如: 測試的工作卡很多, 品質不好, 在寫 code 的時間停留很久等等, 這時候接下來你要做的, 就是檢討 root cause 是什麼, 接下來要如何改進.
可惜很多人使用看板只是想避開使用 scrum 遇到的困境, 可是卻不改進使用 kanban 所發現的問題. 所以我常勸人家不要因為用不順, 就從 Scrum 轉換成 Kanban, 因為你有什麼問題, 不管在 scurm or kanban 都會發生, 重點是要面對它, 改進它, 這才是正道. 而不是換一個方法來使用.
留言列表
