Scrum to Kanban - 10 Lessons learnt from migrating
這是一個針對 metro.co.uk 重新設計的專案, 這個專案經歷了 14 次的 sprint, 每個 sprint 為期 2 週. 在這個過程中, 我們從 scrum 轉換到 kanban, 最主要的原因是因為我們的需求的優先順序常常變動. 在做完這個 project 後, 作者認為自己可能很難再回到 sprint 節奏的專案中. 並且很熱情地分享了他所學習的經驗給我們.
1. 為了要盡可能經常發佈, smoke test 和自動化部署是必要的投資. 這些是需要花時間去建置.
2. 利用 feature branch 方式來開發. 可以讓變動和測試在各自的環境中處理. 也許這需要一段時間來適應, 但是這也是值得的投資.
3. 不要低估 DevOp 文化所帶來的好處. 如果大家能開發和測試都會做一點, 可以讓你節省很多時間.
4. 將功能盡量的切小, 可以讓你盡快得到回饋. 並不說你不能做大的專案, 而是要把大型的專案切成許多小的發佈來處理.
5. 限制 backlog 內工作項目的數目(使用 WIP). 通常龐大的 backlog 是沒有效率的來源.
6. 利用產品效能會議來去取代 sprint 規劃會議. 每次開會時要有度量數據和客戶回饋, 並且邀請業務和開發兩邊都來參加. 讓資料來解決拍腦袋的爭吵.
7. 有更多對話需要週期性舉行. 像現在我們每週有 2 次的 product owner 的站立會議. 最主要是因為當我們加快腳步時, 原先每兩週一次的談話週期已經不足夠了.
8. 對於要處理的問題, 一開始從簡單或是小的解法開始嘗試, 然後藉由疊代來從中學習.
9. 白板是你的好朋友. 可以讓你隨時可以腦力激盪. 並且讓燙手的問題放在大家可見的地方, 使用大家可以隨時回來討論它, 直到這個問題被解決為止
10. 不要忘記召開 retrospective
作者說自從它改成這樣的方式工作, 整體的速度加快很多. 事情之所以能變得有效率, 最大的關鍵就是要把事情切小. 這也增加了我們的靈活度, 因為我們不用等到下個 sprint planning meeting 時, 我們就可以決定是否要處理它. 整體說起來好處多多!!
全站熱搜
留言列表
