Converting a Scrum team to Kanban,
Mattias Skarin
source: http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
決定什麼先解決
在這兩周, Kanban 的白板上顯示了一些有趣的資訊
1. 故事老是在停留在測試階段很久
2. 故事進入到 sprint 後, 還沒做完就結束了, 然後下次再進到 sprint 裏.
結果顯示, 有幾個故事很難在一個 sprint 中完成. 不幸地, 他們被強迫要準時完成專案. Sprint 做不完, 下個 sprint 可以再來. 但是專案的範圍不能改變. 這對團隊來說有打擊士氣的效果, 看到相同的事情一再發生, 可是卻沒有令人滿意的解決.
我也注意到, 團隊和專案經理追蹤不同的東西: 專案經理追蹤完成的工作數目; 可是團隊追蹤 sprint 完成的狀況. 在專案的進度上並沒有存在相同的看法.
找出時間去做必要的改進
雖然我們試圖要去解決好幾件事情, 但是我們發現還有更重要的事情: 要能找出空閒的時間來做改進. 開發人員的時間都已經排到晚上才能把事情做完. 所以我們必須要先找出空閒的時間.
簡單地評估
將評估簡化來當作起始點, 好讓我們有時間去處理更多更重要的問題. 我需要有時間跟團隊談談, 但是他們忙於工作的評估, 他們已經承諾要交付故事的評估給客戶, 並且要花一天的時間來完成. 我跟專案經理建議: 如果我們可以很快完成所期待的評估, 可以把剩下的時間給團隊嗎? 她很願意去嘗試新的做法, 所以她說沒問題. 我要求團隊和我共進午餐, 並且把他們要評估的故事一起帶來. 在吃飯的時候, 把故事傳遞下去, 讓團隊成員利用 T-shirt size 的方法, 完成故事的評估. 在喝咖啡之前, 所有的故事已經被評估完畢, 我和團隊就有空閒的時間.
我們用來評估的方法非常簡單
- 小的故事: 一天或小於一天
- 中的故事: 一周或小於一周
- 大的故事: 大於一周
廢止 sprint
在我們的 sprint 中, 並沒有看到可交付有價值的東西. 例如, 他們持續被外界的事件打斷. 所以我們決定停止採用 sprint. 轉向專注于提高品質, 以及讓整個工作流程能運作順暢.
有件事情我們仍然保留的, 就是每週發佈的節奏. 如果有項工作已經完成, 並且有高質量的水準, 那就會被放到這次發佈中. 如果還沒有, 那將會放到下個禮拜的發佈裡. 這樣可以讓專案經理減輕”接近完成”這種困境, 讓他們放到下週的發佈中. 而不是讓這次的發佈再延幾天.
這個改變所帶來的好處, 是讓我們覺得沒有因時間到了, 就一定要交出來. 故事是允許一直待在被處理的狀態, 直到真的做完為止.
解決開發和品質的不平衡
在看板中看到以下的狀況並不稀奇:
故事集中在測試欄位. 我們很快寫完程式, 但是測試和修改錯誤並沒有這麼快. 我們是由專案經理來進行測試. 所以事實上, 我們只有兼職的測試人員
內建品質
如何改進這樣不平衡的狀況? 我們開始導入測試驅動開發. 這個意圖是想把部分的品質工作, 轉移到開發人員, 並且也讓錯誤可以變得較少,
我們很快地執行了四個回合, 來教導團隊測試驅動開發. 因為時程緊迫, 我們沒有時間在下班時進行這個訓練. 在團隊的同意下, 大家願意有四天早上比較早來, 以參加 TDD 的工作坊.
我們如何處理測試框架和技術障礙
並非所有部分的程式都可以使用 TDD 來開發. 例如, 有些 GUI 的程式並不支援 TDD. 雖然我們知道怎樣解決這個問題, 但是開發必要的基礎架構需要花很多時間. 有些技術障礙或其他事情無法在短時間內處理掉. 因此我們有些折衷方法:
- 盡我們所能為可測性做設計
- 對於我們不能寫自動化測試的部分, 進行手動測試
我們如何達到可以發佈的狀態
新的問題很快就浮現
當原先的品質已經有所改進, 可是因後來提交的程式, 導致原先可運行的又失敗. 為了解決這件事, 我們改變分支的政策.
我們要求兩個團隊都要這樣實作, 當一切都按部就班時, 可以幫助我們維持有穩定的發佈. 趁問題還小時, 就把它處理掉.
小的改善徵兆
即使壓力很大, 但是微小的改善徵兆仍然浮現. 可以聽到像這樣的建言: “為什麼我們的程式有這樣的東西?”, 團隊成員會主動開始去進行重構, 以解決品質的問題.
當專案經理從和客戶的會議回來時, 他告訴我說: "你知道嗎, 即使他們仍然感到有壓力, 當你說我們正要交付一些東西時, 他們還是相信我們”.
這些小的指標, 都告訴我們, 我們在正確的軌道上.
我們如何讓持續改進繼續下去
目前我們已經就守備位置, 當問題浮現就擊退他們. 此外, 我們也有來之外面顧問的支援. 但是我們需要加強團隊的能力, 讓他們可以主動起作用.
這次團隊開始掌管 Kanban 白板, 增加政策(policies) 以及調整工作的狀態.
我訓練團隊如何利用看板, 早點看出有什麼問題, 然後進行根本原因分析(root cause ananlysis), 讓團隊來解決它. 團隊每週和專案經理一起, 進行持續改進的活動. 每次活動都只著重一個簡單的事情, 也就是每週修復一個問題.
根本原因分析可以幫助我們, 從個人問題的觀點, 轉移到因果關係的整體了解.
看問題如何開始浮現, 是件非常迷人的事情. 例如上面的範例顯示: “交付的編輯器易用性不好” (畫面的原件少了些重要的功能). 這個案例, 專案經理已經知道這個問題, 不過把它揭露出來也沒有用, 因為還沒有好的方法去解決它. 等到被揭露後, 會立即訓練團隊了解目前的程式架構, 去解決這個問題.
如何將 Scrum 團隊轉換成 Kanban 團隊 (3): http://kojenchieh.pixnet.net/blog/post/376582736
如何將 Scrum 團隊轉換成 Kanban 團隊 (1): http://kojenchieh.pixnet.net/blog/post/375942851
留言列表
