Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
摘要
在 2009 年, 我遇到一個陷入困境的團隊: 他們大量地加班, 並且只埋頭寫程式, 卻不問問題. 他們的任務, 是要把一個重要客戶的核心商業系統給換掉. 在距離截止時間還有 2 個半月前(雖然客戶已經掏錢出來, 但是未來的合約還八字沒有一撇), 我們的挑戰是如何顯示真正要處理的問題, 並且採用快速有效的對策.
這份報告是想告訴大家, 我們如何利用 Kanban, 來讓問題浮現, 並且解決它們. Kanban 可以幫助我們:
- 讓流程不順的問題給浮現
- 讓一線經理, 專案經理, 開發人員一起來解決它們.
- 一步一步讓重心從把程式寫完, 轉移到交付高品質的系統
- 即使在時間的高壓下, 仍然維持品質至上的紀律
- 讓相關的夥伴 (像是客戶的開發人員) 一起加入我們想要的改變
最後交付的項目準時完成, 客戶願意讓我們做他們的下個專案. 在系統上線後, 團隊不再加班. 並且在那段期間, 團隊的速度增加了 1.9 倍.
將 Scrum 團隊轉換成 Kanban 團隊
- 利用 kanban 來當作持續改進的主要機制
簡介
團隊遭遇到了困難, 客戶威脅我們說要終止合約, 我們只能花 6 個月的時間, 去完成一個 8 個月的專案. 這意味著我們會失去這個重要的客戶. 當初剛開始的時候, 我們執行的很好, 準時交付試驗的系統, 客戶也很高興, 可是現在卻變成嚴重的加班, 很多東西重做, 並且還欠了一堆技術債.
一路上, 範圍一直在調整. 但是到現在, 只要求做出可以讓客戶業務運轉的功能就好, 也就是沒有再砍功能的空間. 這個系統是被開發來執行客戶的核心業務, 他們非常擔心, 是否無法達成這個目標.
從正面的角度來看 (拜託, 總有光明的一面): 團隊成員都非常重承諾; 每週對會跟客戶對話(雖然不是很愉快, 但是都有做); 專案經理和產品負責人都很正面思考; 管理階層也都很支持這個團隊.
當我第一次和這個團隊見面時, 我問他們這裡最大的問題是什麼.
專案經理說
- 交付有品質的東西
- 團隊壓力過大
- 評估完全不準, 尤其是新的項目可能誤差高達 5 倍
團隊成員說
- 在太多工作之間轉換
- 同時間做太多事情
客戶說
- 這個團隊無法勝任這份工作
每個被問的角色都回答不同的答案. 所以我覺得搞清楚要先解決什麼問題是沒有幫助的.
團隊的組成
事實上這裡有兩個團隊. 一個在大不列顛島(客戶端), 一個在法國(我們所在的位置).
主要的開發工作是由在法國的團隊來處理的. 有些擴充的部分是由客戶端來完成. 我們的產品負責人和他們的專案經理, 每週會見面一次, 來調整工作的優先順序, 以及檢視 demo 的內容.
在法國的團隊已經使用 Scrum 幾個月了. 專案經理是為認證過的 Scrum master. 目前不難找出問題在哪. 團隊密集的超時工作, 有時候寫程式寫到凌晨 1 點. 循環的燃燒圖呈現出令人擔心的模式:
當詢問到 Scrum 對他們有效嗎? 開發人員說: 我們不確定 Scrum 能幫得上忙.
Kanban 如何被引進
團隊之所以會引進 Kanban 是因為 CEO 的關係. 他注意到了另一個由我指導的團隊發生了什麼事情. 那個團隊已經實施了 Kanban 好幾個禮拜. 他詢問我是否也能導入雷同的方式到他們的團隊, 我回答說”當然可以”. 下週他們的第一個 Kanban 便出現了, 並開始運作.
現在的工作流程並沒有任何東西真的被改變, 唯一新的東西, 是引入同時正在處理的工作的個數(Work In Progress limit), 以及增加價值流的可視性.
使用 Kanban 過了兩周後
團隊持續使用 Kanban 來進行他們的 sprint 已經兩個禮拜了. 以下是他們這兩周循環的燃燒圖
它讓我知道了, 如果狀況不錯的話, 這個團隊是可以交付可運行的軟體. 並且在這段時間, 我剛好有機會整天和這個團隊在一起
如何將 Scrum 團隊轉換成 Kanban 團隊 (2): http://kojenchieh.pixnet.net/blog/post/376108454
留言列表