1. 1
Converting
a
Scrum
team
to
Kanban
Mattias
Skarin
Crisp

2. 2
摘要
在
2009
年,
我遇到一個陷入困境的團隊:
他們大量地加班,
並且只埋頭寫程式,
卻不問問題.
他們的任務,
是要把一個重要客戶的核心商業系統給換掉.
在距離截
止時間還有
2
個半月前(雖然客戶已經掏錢出來,
但是未來的合約還八字沒有一撇),
我們的挑戰是如何顯示真正要處理的問題,
並且採用快速有效的對策.
這份報告是想告訴大家,
我們如何利用
Kanban,
來讓問題浮現,
並且解決它們.
Kanban
可以幫助我們:
n 讓流程不順的問題給浮現
n 讓一線經理,
專案經理,
開發人員一起來解決它們.
n 一步一步讓重心從把程式寫完,
轉移到交付高品質的系統
n 即使在時間的高壓下,
仍然維持品質至上的紀律
n 讓相關的夥伴
(像是客戶的開發人員)
一起加入我們想要的改變
最後交付的項目準時完成,
客戶願意讓我們做他們的下個專案.
在系統上線後,
團
隊不再加班.
並且在那段期間,
團隊的速度增加了
1.9
倍.

3. 3
將
Scrum
團隊轉換成
Kanban
團隊
利用
Kanban
來當作持續改進的主要機制
簡介
團隊遭遇到了困難,
客戶威脅我們說要終止合約,
我們只能花
6
個月的時間,
去完
成一個
8
個月的專案.
這意味著我們會失去這個重要的客戶.
當初剛開始的時候,
我們執行的很好,
準時交付試驗的系統,
客戶也很高興,
可是現在卻變成嚴重的加
班,
很多東西重做,
並且還欠了一堆技
術債.
一路上,
範圍一直在調整.
但是到現在,
只要求做出可以讓客戶業務運轉的功能
就好,
也就是沒有再砍功能的空間.
這
個系統是被開發來執行客戶的核心業務,
他們非常擔心,
是否無法達成這個目標.
從正面的角度來看
(拜託,
總有光明的
一面):
團隊成員都非常重承諾;
每週對
會跟客戶對話(雖然不是很愉快,
但是都
有做);
專案經理和產品負責人都很正面
思考;
管理階層也都很支持這個團隊.
當我第一次和這個團隊見面時,
我問他們這裡最大的問題是什麼.
專案經理說
n 交付有品質的東西
n 團隊壓力過大
n 評估完全不準,
尤其是新的項目可能誤差高達
5
倍
團隊成員說
n 在太多工作之間轉換
n 同時間做太多事情

4. 4
客戶說
n 這個團隊無法勝任這份工作
每個被問的角色都回答不同的答案.
所以我覺得搞清楚要先解決什麼問題是沒有幫
助的.
團隊的組成
事實上這裡有兩個團隊.
一個在大不列顛島(客戶端),
一個在法國(我們所在的位置).
主要的開發工作是由在法國的團隊來處理的.
有些擴充的部分是由客戶端來完成.
我們的產品負責人和他們的專案經理,
每週會見面一次,
來調整工作的優先順序,
以及檢視
demo
的內容.
在法國的團隊已經使用
Scrum
幾個月了.
專案經理是為認證過的
Scrum
master.
目前不難找出問題在哪.
團隊密集的超時工作,
有時候寫程式寫到凌晨
1
點.
循環
的燃燒圖呈現出令人擔心的模式:

5. 5
當詢問到
Scrum
對他們有效嗎?
開發人員說:
我們不確定
Scrum
能幫得上忙.
Kanban
如何被引進
團隊之所以會引進
Kanban
是因為
CEO
的關係.
他注意到了另一個由我指導的團
隊發生了什麼事情.
那個團隊已經實施了
Kanban
好幾個禮拜.
他詢問我是否也能
導入雷同的方式到他們的團隊,
我回答說”當然可以”.
下週他們的第一個
Kanban
便出現了,
並開始運作.

6. 6
現在的工作流程並沒有任何東西真的被改變,
唯一新的東西,
是引入同時正在處理
的工作的個數(Work
In
Progress
limit),
以及增加價值流的可視性.
使用
Kanban
過了兩周後
團隊持續使用
Kanban
來進行他們的
sprint
已經兩個禮拜了.
以下是他們這兩周
循環的燃燒圖
它讓我知道了,
如果狀況不錯的話,
這個團隊是可以交付可運行的軟體.
並且在這
段時間,
我剛好有機會整天和這個團隊在一起.
決定什麼先解決
在這兩周, Kanban 的白板上顯示了一些有趣的資訊
1. 故事老是在停留在測試階段很久

7. 7
2. 故事進入到 sprint 後, 還沒做完就結束了, 然後下次再進到 sprint 裏.
結果顯示, 有幾個故事很難在一個 sprint 中完成. 不幸地, 他們被強迫要準時完成
專案. Sprint 做不完, 下個 sprint 可以再來. 但是專案的範圍不能改變. 這對團隊
來說有打擊士氣的效果, 看到相同的事情一再發生, 可是卻沒有令人滿意的解決.
我也注意到, 團隊和專案經理追蹤不同的東西: 專案經理追蹤完成的工作數目; 可
是團隊追蹤 sprint 完成的狀況. 在專案的進度上並沒有存在相同的看法.
找出時間去做必要的改進
雖然我們試圖要去解決好幾件事情, 但是我們發現還有更重要的事情: 要能找出空
閒的時間來做改進. 開發人員的時間都已經排到晚上才能把事情做完. 所以我們必
須要先找出空閒的時間.
簡單地評估
將評估簡化來當作起始點, 好讓我們有時間去處理更多更重要的問題. 我需要有時
間跟團隊談談, 但是他們忙於工作的評估, 他們已經承諾要交付故事的評估給客戶,
並且要花一天的時間來完成. 我跟專案經理建議: 如果我們可以很快完成所期待的
評估, 可以把剩下的時間給團隊嗎? 她很願意去嘗試新的做法, 所以她說沒問題.
我要求團隊和我共進午餐, 並且把他們要評估的故事一起帶來. 在吃飯的時候, 把
故事傳遞下去, 讓團隊成員利用 T-shirt size 的方法, 完成故事的評估. 在喝咖啡
之前, 所有的故事已經被評估完畢, 我和團隊就有空閒的時間.
我們用來評估的方法非常簡單

8. 8
- 小的故事: 一天或小於一天
- 中的故事: 一周或小於一周
- 大的故事: 大於一周
廢止 sprint
在我們的 sprint 中, 並沒有看到可交付有價值的東西. 例如, 他們持續被外界的事
件打斷. 所以我們決定停止採用 sprint. 轉向專注于提高品質, 以及讓整個工作流
程能運作順暢.
有件事情我們仍然保留的, 就是每週發佈的節奏. 如果有項工作已經完成, 並且有
高質量的水準, 那就會被放到這次發佈中. 如果還沒有, 那將會放到下個禮拜的發
佈裡. 這樣可以讓專案經理減輕”接近完成”這種困境, 讓他們放到下週的發佈中.
而不是讓這次的發佈再延幾天.
這個改變所帶來的好處, 是讓我們覺得沒有因時間到了, 就一定要交出來. 故事是
允許一直待在被處理的狀態, 直到真的做完為止.
解決開發和品質的不平衡
在看板中看到以下的狀況並不稀奇:

9. 9
故事集中在測試欄位. 我們很快寫完程式, 但是測試和修改錯誤並沒有這麼快. 我
們是由專案經理來進行測試. 所以事實上, 我們只有兼職的測試人員
內建品質
如何改進這樣不平衡的狀況? 我們開始導入測試驅動開發. 這個意圖是想把部分的
品質工作, 轉移到開發人員, 並且也讓錯誤可以變得較少,
我們很快地執行了四個回合, 來教導團隊測試驅動開發. 因為時程緊迫, 我們沒有
時間在下班時進行這個訓練. 在團隊的同意下, 大家願意有四天早上比較早來, 以
參加 TDD 的工作坊.
我們如何處理測試框架和技術障礙
並非所有部分的程式都可以使用 TDD 來開發. 例如, 有些 GUI 的程式並不支援
TDD. 雖然我們知道怎樣解決這個問題, 但是開發必要的基礎架構需要花很多時間.
有些技術障礙或其他事情無法在短時間內處理掉. 因此我們有些折衷方法:
- 盡我們所能為可測性做設計
- 對於我們不能寫自動化測試的部分, 進行手動測試

10. 10
我們如何達到可以發佈的狀態
新的問題很快就浮現

11. 11
當原先的品質已經有所改進, 可是因後來提交的程式, 導致原先可運行的又失敗. 為
了解決這件事, 我們改變分支的政策.
我們要求兩個團隊都要這樣實作, 當一切都按部就班時, 可以幫助我們維持有穩定
的發佈. 趁問題還小時, 就把它處理掉.
小的改善徵兆
即使壓力很大, 但是微小的改善徵兆仍然浮現. 可以聽到像這樣的建言: “為什麼我
們的程式有這樣的東西?”, 團隊成員會主動開始去進行重構, 以解決品質的問題.
當專案經理從和客戶的會議回來時, 他告訴我說: "你知道嗎, 即使他們仍然感到有
壓力, 當你說我們正要交付一些東西時, 他們還是相信我們”.
這些小的指標, 都告訴我們, 我們在正確的軌道上.
我們如何讓持續改進繼續下去
目前我們已經就守備位置, 當問題浮現就擊退他們. 此外, 我們也有來自外面顧問
的支援. 但是我們還需要加強團隊的能力, 讓他們可以主動起作用.
這次團隊開始掌管 Kanban 白板, 增加政策(policies) 以及調整工作的狀態.

12. 12
我訓練團隊如何利用看板, 早點看出有什麼問題, 然後進行根本原因分析(root
cause ananlysis), 讓團隊來解決它. 團隊每週和專案經理一起, 進行持續改進的活
動. 每次活動都只著重一個簡單的事情, 也就是每週修復一個問題.
根本原因分析可以幫助我們, 從個人問題的觀點, 轉移到因果關係的整體了解.

13. 13
看問題如何開始浮現, 是件非常迷人的事情. 例如上面的範例顯示: “交付的編輯器
易用性不好” (畫面的原件少了些重要的功能). 這個案例, 專案經理已經知道這個
問題, 不過把它揭露出來也沒有用, 因為還沒有好的方法去解決它. 等到被揭露後,
會立即訓練團隊了解目前的程式架構, 去解決這個問題.
我們如何解決跨團隊的問題
在持續改進的會議中,
有個問題被提出:
“我們如何和客戶團隊合作,
並且將這樣合
作模式的教給客戶團隊?”
為了解決這個問題,
我們誘使開發人員主導去安排每週
的電話會議,
一起來解決共同的問題.
我們也開始進行開發人員的交換活動,
讓客
戶團隊的工程師花時間和我們一起工作;
我們也從他們身上,
去學習到他們的來龍
去脈.

14. 14
我們如何在最後一周還保持專注
在最後兩個禮拜,
經理們和團隊緊密合作,
處理可能會阻礙發行的問題.
例如,
我
們的
CEO
便擔保某個資深工程師,
在接近發佈時,
會全職在這個專案,
以加速某個
核心模組的修復.
所以...
我們有完成這個專案嗎?
是的,
團隊有守住最後期限.
在兩個月前,
這看起來還是不可能的目標,
我記得當通
過終點時,
我還是跟平常一樣,
並沒有特別興奮.
在發佈完後,
客戶覺得沒問題,
在
一個禮拜後便發出正式的通知給我們.

15. 15
我們都知道不可能去達到這麼艱難的期限.
真的,
所有你能做的就是大量加班.
:)
所以,
讓我感到真的高興的,
是在發佈完後專案經理的評論:
"你知道嗎?
團隊不用再超時工作了."
回顧
我發現很難找出"單一事情”就讓我們成功.
而是很多小事情合起來,
加速彼此的效
果.
看板真的有幫助的地方,
是顯示出我們哪裡有問題(或是哪裡沒有問題).
但是解決
問題是要靠我們自己.
好消息是這樣的資訊的獲得是很”便宜”.
我們要做的,
只是擺一個白板在牆壁上,
然
後去使用它.
不需要要求其他改變事情.
我們還是繼續用
Jira,
我們專案的架構或
是進行方式還是不變.
但是很快地,
問題被發現,
我們就專心去修復它.
為什麼
Scrum
對我們來說不可行?
無疑的,
我們
Scrum
的執行狀況並不是這麼完美.
我想這也強調了,
要做到很棒
的
Scrum
是件不容易的事.
例如,
如果其他組織可以決定你的軟體,
何時可以測試,
或是何時可以發佈,
你不太可能去實施嚴格的做完的定義.
但是,
還是有其他的原因導致我們的
Scrum
不可行.
無法及時在 sprint 完成的功能所產生的浪費
每個功能預計是要在一個
sprint
內完成.
但是當開發開始時,
開發人員發現它太大
了,
因此在後期將它們切小,
重新規劃要做的範圍.
在下個
sprint
時,
便會有另一
個功能便會被移掉.
當這樣的事情一直重複時,
原先的專案計劃變得不太可靠.
後
來我們轉向
Kanban
後,
我們便允許這個功能一直待到做完為止.
這個功能完成後,
便放到下一個即將到來的發佈中.

16. 16
重構常常被阻止不要做止
在排定功能的優先順序時,
通常需要考量兩件事情:
功能的商業價值,
以及客戶那
邊不斷來的壓力.
這通常會導致大家只想專案準時交付,
而重要的重構便會被排除
在外.
如果團隊說服管理階層去嘗試重構,
但是卻無法在單一
sprint
內就完成這
個功能.
如此一來,
客戶的管理階層就會認為重構是浪費錢,
是血本無歸的事情.
解決問題需要和其他利害關係人合作
在某個機會中,
團隊需要重構由外面廠商所寫的重要元件.
這需要透過我們團隊,
平台專家,
管理階層,
和客戶一起合作.
因此,
即使團隊發現問題,
也需等到每個利

17. 17
害關係人拋下一切事情,
問題才能被解決.
所以要解決像這樣的問題,
重點是要邀
請所有利害關係人.
如果把團隊孤立在
sprint
內,
這將會沒有任何幫助.
評估是件浪費資源的事
….
評估不會增任何準確度.
讓我們正視這件事,
它並不是只跟
Scrum
有關.
有好幾個面向需要一起考量,
才能
確保軟體專案成功.
那其他的解法如何?
對於任何一個問題,
通常都存在一個以上的解法.
所以讓我們來思考一些事情.
“所以看起來你很痛苦,
為什麼你不把
sprint
拉長一點?”
這也是個選項,
問題是我們沒有信心,
告訴客戶我們要這樣做.
我不確定像
”我們要
做比較久的
sprint,
我們做事的時候,
請不要來煩我們”,
這樣的訊息會產生正面的
回應.
“那什麼是你做完的定義?"
確實我們是以
ScrumBut
的方式在做事.
但是我們不是專案中唯一的一群,
例如,
我們不能控制客戶那邊的開發程序.
要改變做完的定義,
必須要求客戶一起接受這
樣的結論.
事實上,
我們有做類似的事情,
像是提供較長的可見度,
可以看到價值鏈
的下游部分.
那有什麼數據?

18. 18
速度/生產量
在五月時平均的生產量是每週
7.25
個故事.
到九月時是每週
13.50
個故事
(紅
線)
速度/
人天
如果我們看的是人天的生產量,
五月的平均值是
0.64.
在九月是
1.04
(綠線,
在圖
形中縱軸的值是百分比)
我們今天在哪?
團隊很努力並且已經完成,
大部分他們想要加進去的測試框架.
我提過之所以會這
樣做,
是為了證明可以克服技術上的困難,
以及專案管理對外銷售的問題.
我們從
沒想到,
當初我們還要找時間去把這個改進給放進去,
但是到現在我們已經做到了.
大部份團隊所學到的技術,
已經轉移給客戶的開發團隊.
現在的挑戰,
是如何將這
些知識教導給客戶的
IT
組織和專案管理團隊.
一個團隊成員的觀點
“最難的部分是訓練自己擁抱新的思維.
能夠真的了解到,
程式碼寫完,
不代表
這個工作就完成了.
看板讓我們重心放在思考品質上面.
當你看到白板上有個欄位叫做”功能測試”
時,
你很難去忽略它.
:)
它強迫我們離開只有寫程式,
寫程式,
寫程式的輪迴中.

19. 19
我想我們學到最棒的教訓,
就是隨時要考量到品質”
-­‐
開發人員,
Mariana.
Kanban
變得狂熱
在專案的後期,
一位來自
H&R
的女孩子來找我,
問我是否有任何想法,
可以減低她
所遭遇到的壓力.
我一開始有點懷疑,
但是告訴她一開始所做的
-­‐
頻繁去調整優先
順序,
是其中一個有問題的地方,
我們討論了一些可行方案,
然後我在她座位旁邊
的玻璃牆壁上,
畫了一個簡單的看板流程.
我要求她去告訴委託她的利害關係人,
把
他們的需求依據優先順序,
放到”
in
queue”
欄位中,
但是不要和已經開始處理的混
在一起.
一個禮拜後,
我經過她的辦公室,
發現到整個牆壁上有很多看板系統.
看板系統已
經開始被她的同事們使用
-­‐
包括財務,
行銷部門和
IT
部門.

20. 20
我希望你可以從這裡學到一些東西.
至少我學到不少.
Mattias
Skarin
斯德哥爾摩,
四月
2010