這裡有篇記錄他們團隊從 Scrum 轉換到 Kanban 的心路歷程. 讓我們來看看他們的故事吧:
- 4月 07 週二 201516:25
從 Scrum 到 Kanban 的過程
這裡有篇記錄他們團隊從 Scrum 轉換到 Kanban 的心路歷程. 讓我們來看看他們的故事吧:
- 2月 03 週二 201519:00
雖然 Scrum 很棒, 但是 Kanban 對我們比較合適
作者在加入 BIzo 之前, 在一家軟體公司使用 Scrum 來開發軟體已經有 5 年了. 那家公司內的所有 projects, 都是利用 scrum 方式來進行. 所以當他加入 Bizo 時, 他以為可以將 Scrum 在 Bizo 使用的很好. 事實上, 他發現他錯了, 為什麼, 讓我們繼續看下去
- 2月 01 週日 201522:04
什麼時候我們放棄 Scrum 而使用 Kanban
- 11月 05 週三 201422:33
Adobe Brackets 從 Scrum 轉換到 Kanban 的理由
- 11月 02 週日 201421:56
從 Scrum 到 Kanban 所學習到的 10 個經驗
Scrum to Kanban - 10 Lessons learnt from migrating
http://blog.david-jensen.com/scrum-to-kanban-10-lessons-migrate/
- 7月 09 週三 201418:24
如何將 Scrum 團隊轉換成 Kanban 團隊 (3)
Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
- 7月 08 週二 201416:37
如何將 Scrum 團隊轉換成 Kanban 團隊 (2)
Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
- 7月 07 週一 201415:15
如何將 Scrum 團隊轉換成 Kanban 團隊 (1)
Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
- 7月 07 週一 201407:20
為什麼 Stormpath 要從 Scrum 轉換到 Kanban 的原因? (2)
上回提到 (http://kojenchieh.pixnet.net/blog/post/375219767) Stormpath 要從 Scrum 轉換到 Kanban 的原因, 這次我們來看看 Stormpath 為什麼覺得 Kanban 有幫助
為了避免多工, 也就是同時間做太多事情, 因為這樣讓你的工作效率變差. 在 Scrum 中, 我們規定 sprint 的內容確定後, 不能再變動, 請確保我們不回讓大家同時做的事情的數量一直增加. 而在 Kanban 中, 我們用的是另一種方式, 我們限制在每個欄位中, 最多只能進行多少工作.
- 7月 03 週四 201406:45
為什麼 Stormpath 要從 Scrum 轉換到 Kanban 的原因?
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/
