翻譯 | 高鈺淋
本文翻譯自《From Scrum to Kanban–A Team’s Journey》，以第一人稱視角講述了移動廣告公司Marchex的團隊Kanban過渡經歷，從改變動機，到過渡過程，再到實踐經驗，希望能給大家帶來一些關於團隊敏捷實踐的啓發。
Marchex是一家移動廣告技術公司，2014年團隊從支持一個已經運行了7年以上的產品轉變去開發一個全新產品，當時Scrum實踐的效率並不高，想要成功執行sprint計劃越來越難，於是公司決定從Scrum轉換到Kanban，看看它是否有助於緩解團隊在sprint計劃中出現的一些問題。
有關Scrum和Kanban的區別，可閱讀《Kanban VS Scrum：哪個是最好的敏捷項目管理框架》
Marchex和敏捷
爲了使團隊的變更最小化，我們在從一個產品過渡到下一個產品時，儘量保持基本的Scrum結構，但事實證明，這個計劃並不像我們所希望的那麼順利。
Marchex對敏捷並不陌生，整個產品組織都以某種形式採用了敏捷，不過有些方法上的不同。2014年，在我們過渡到Kanban之前，我的團隊看起來像是XP + Scrumban的組合。我們採用了一些標準的XP實踐，例如TDD、DailyStandups、結對編程、演示和定期回顧。我們還使用白板通過看板跟蹤我們的sprint進度。到了2014年夏天，我們開始採用新的敏捷範例。
向Kanban過渡的動機
不熟悉的領域和技術
第一個面臨的問題是我們的故事定義和故事點的準確性。例如，我們有一組關於創建新服務的故事，其中一個故事被定義爲爲這個新服務創建一個API。這個故事的接受標準是模糊的，即創建一個客戶端應用程序可以用來獲取和推送數據的API。一些流程會被歸納在一個狀態中，難以準確識別進度，比如團隊與內部客戶交談，設計解決方案等，在整個故事中全部屬於“處理中”這一狀態。再者，我們沒有以前的數據比較來幫助我們使用準確地判斷故事的大小，所以我們的sprint計劃中經常有未完成的故事。因爲一個又一個sprint的故事都沒有按計劃交付，讓團隊十分受挫，日復一日，周復一週看着同樣的故事處於同樣的狀態，讓人感覺陷入了困境。
波動積壓
另一個問題是我們不穩定的任務積壓。對於從瀑布式轉換到敏捷的團隊，一週衝刺似乎是短暫而緊迫的。然而，我們發現在不斷髮展的新產品開發業務需求中，每週的衝刺時間過長。我們的業務開發團隊實時與潛在客戶討論產品，並進行反饋，相應的，我們也必須不斷調整產品需求列表的優先級，所以有時感覺我們每天都在改變優先級。
在這種環境下，sprint計劃顯得過於笨拙，不再適合我們的業務需求。所以在sprint邊界的剛性、不斷變化的backlog和不斷髮布特性增強和健壯性的需求之間，需要一個新的範例。
變更需求
在幾次回顧之後，我們發現自己無法完成sprint計劃，於是開始尋找如何緩解這些問題的方法。我們將電子Scrum板移到站立空間的一個大白板上，使任務更加顯眼。另外，我的團隊從一個單獨的開發團隊(主要是獨立工作)變成了三個團隊中的一個，3個團隊都被要求開發和交付這個新產品。
我採訪了一位協作團隊的開發人員，問她對Scrum到看板的轉變有什麼看法。她說她更喜歡看板風格有兩個原因：團隊只關注待辦事項列表中最重要的1或2個故事，當它們完成時，就會轉移到下一個故事。第二是她喜歡從積壓的故事中挑選最重要的故事，然後完成工作。她還提到，他們團隊的過程更容易管理，因爲故事範圍很小。在與她交談之後，我確定了團隊的正確方向。
不需要改變的事情
當我們考慮脫離Scrum時，我們堅信有一些實踐對團隊來說仍然是有效的。衆所周知，Scrum是一種組織項目的方法，而XP實踐主要是如何開發代碼。XP的擁護者經常採用Scrum+XP。同樣，我們決定繼續使用XP實踐，而使用Kanban作爲結構：
- 結對編程——2014年團隊採用了結對編程方法，我們發現，在採用新的Scala語言和學習搜索範式時，這兩種方法是成對的。編程是保持團隊生產力的必要條件，我們每天都在會上安排大家組隊，儘量一組人一起合作直到完成一個故事。
- 測試驅動開發——幾乎所有的新開發都是通過測試驅動開發創建的，我們認爲這種實踐仍然是開發軟件的最佳方式。
- 回顧——這是一個永遠不會消失的敏捷標準實踐，它是我們持續改進質量的方法。
- 故事點——我們改變了我們的故事點定義，但仍堅持使用點來估計故事的大小。我們會討論一個故事，就接受標準達成一致，然後通過小組投票分配點數。
過渡過程
我與團隊討論了遷移到Kanban的概念，並組織了一個Lean Coffee (leancoffee.org)風格的會議，以徵求反饋並解決團隊的關注點。
精益咖啡風格的會議通過要求參與者提交討論主題，明確地徵求每個人的反饋，然後通過分組投票確定優先級。會議中大家認爲最大的問題是故事的規模，如果所有的故事都更小、更一致，Kanban將工作得更好。在那次會議之後，我們決定採用以下流程來支持我們的新看板模型：
- 每週一次1小時的會議計劃。
- 每週五進行1小時的回顧。
- 如果我們在週中(也就是下週一計劃會議之前)故事量開始減少，我們會在每日站立會(daily standup)上做一個小計劃。
- 新的故事點“度量參考”：1個故事點=1/2的理想工作日爲一對程序員。以前，我們的量表是1個故事點= 一對程序員的理想工作日。這種縮減的規模幫助我們保持我們的故事更小，因爲5點故事意味着它應該在大約2.5天內完成，而不是5天。
- 如果在計劃過程中，我們給一個故事分配了超過8個點，我們會把它分成2個或更多的故事。
- 每日站會將專注於討論故事狀態，並將它們移動到Kanban上，而不是繞着圈子給出狀態。這意味着我們的週期更短，更專注於眼前的任務。這一變化似乎是我們轉向Kanban的自然延伸，因爲它強調了Kanban對工作和循環的重視，時間更爲明顯。
- 我們在迭代期間進行結對。我們不一定每天都會改變，尤其是在故事進行到一半時，但我們每天都要討論到每一對。考慮到我們的團隊規模，只花了一兩分鐘。
- 我們保留了第16分鐘的概念——也就是說，如果有人想更深入地討論某個問題，我們會把它寫在白板上，然後把它放在第16分鐘的討論中。在討論完板上的故事狀態和分配對之後，我們在第16分鐘討論項目。
- 團隊中每對開發人員的WIP爲1，即6名開發人員“開發中”的WIP爲3。我們還爲“QA”列指定了一個WIP爲3。
我們在sprint邊界完成了從Scrum到Kanban的過渡，也就是說，我們完成了當前的sprint，在下一次計劃會議上，我們創建了一個新的故事點“度量參考”，並開始像Kanban團隊一樣進行計劃。這意味着我們只需要爲下週的故事設定範圍和計劃，因爲計劃是在週一上午進行的。
對小故事的更改解決了我們現有的一個問題——尚未指定的故事。通過討論範圍較小的故事，我們自然也傾向於收緊接受標準，由於我們的故事是8點(4天)或更少，所以我們以更小的粒度討論了故事的目標。
例如，與簡單地爲新服務創建API的故事不同，新故事被分解爲更小的故事，如初始化、發佈、驗證、日誌記錄和最後定稿。
在爲每個較小的故事處理我們的驗收標準時，由於範圍更小，我們的驗收標準在範圍和粒度上也變得更加適中。例如，爲日誌記錄的故事創建接受標準變得非常具體，相反，爲創建API的故事創建的接受標準的類型要模糊得多。的確，創造更小的故事也意味着創造更多的故事，所以創建一個好的故事層次結構對於確保更大的特性得到充分的實現也非常重要。故事層次結構通常用於在範圍更廣的故事下組織子故事。更廣泛的故事通常被稱爲“史詩”。使用這種機制，我們可以圍繞大量較小範圍的故事創建一些順序。最後我們能夠在不到一個小時的時間裏輕鬆地計劃一週的工作量，這比我們之前的3h要少很多。
每週的sprint計劃會議，有人曾經深情地稱之爲“傷眼的日子”。不過，公平地說，我們以前的sprint計劃會議也包括回顧。現在，我們每個星期五都有一個單獨的回顧，把計劃和回顧分成兩個會議比一個更容易接受。每週會議，我們使用白板開始新的Kanban生活，沒有調整列名。
列名分別爲：
| 在開發 | 準備好QA | QA | 準備好發佈 | 完成 |
|---|
幾周後，我們開始使用電子板來進行我們的測試和計劃，方便團隊更容易看到backlog。此時，我們在現有的5列的左邊增加了4列：
| New | Bucket | Backlog | On Deck |
|---|
- NEW=新故事
- Bucket =無序積壓
- Backlog=優先級列表
- Start =團隊認爲已經準備好實現的故事，即良好的驗收標準和分配好故事點。
過渡非常順利，在9個月之後，團隊仍然對看板範例感到滿意。計劃更加及時，故事更短，也更容易處理，任何大於8點的故事都必須分解的規則迫使我們將故事保持在小範圍內。我們成功從Scrum轉向了Kanban。
此外，我們還發現，爲範圍更小的故事編寫接受標準可以更容易地編寫更具體的、不那麼模糊的接受標準。換句話說，我們的故事定義更加嚴格。在轉換之前和之後，我們從來沒有做過關於生產力的A/B比較，但是團隊感覺更有生產力，士氣也得到了提高，因爲我們能夠看到每天的進展。此外，我們與項目經理的溝通也得到了改善，因爲他對狀態變更和完成一個功能需要多長時間有了更好的瞭解。
持續學習
有幾個因素使我們的過渡相當順利。
經驗豐富的團隊領導
在我們從Scrum過渡到Kanban之後，角色變化最大的人是項目經理(扮演Scrum Master的角色)。在整理積壓的工作時，他必須至少領先團隊一步，考慮團隊不斷變化的業務需求，有足夠好的驗收標準來爲“Bucket”添加更多的故事，以防處理中的故事在我們下一次站會之前完成。
作爲項目經理的另一個挑戰是管理轉換本身，他指導團隊採用新的實踐，並幫助督促大家堅持下去。
成熟的敏捷組織
另一個使我們的轉換更加順暢的因素是組織已經擁有敏捷經驗,團隊的大多數成員都是經驗豐富的敏捷實踐者。團隊會時常進行回顧，在回顧中我們討論了當前流程的執行情況，並根據需要進行流程更改。所以一個基本的範例轉換對我們來說並不像對一個還沒有實踐敏捷的組織那樣可怕。
看板培訓
在我們向看板過渡的前一年，整個開發組織都通過了由Modus Cooperandi提供的看板培訓。瞭解了精益和看板的概念，如在製品(WIP)、週期時間等。所以當我們的團隊開始討論看板的採用時，我們對一些詞彙的含義已經很熟悉。
保持每週的節奏
每週一次的節奏有助於我們構建新的Kanban。我們每週都有回顧，所以如果出現問題，我們可以對我們的流程做一些小的調整。週一計劃一週的工作，週五回顧一週的工作，這有助於保持良好的節奏。即使我們取消了衝刺，保持每週的時間表仍然很有意義。
結果
在我們進行了9個月的轉換之後，我們在Kanban方面的實踐越來越熟練，我們的業務需求仍在頻繁地變化，但是團隊效率很高，並且持續穩定地發佈新功能，同時，JIT（及時）計劃也使我們所有的會議都更加高效和富有成效。敏捷有許多不同的實踐方法，每個團隊有自己的路徑，希望我們的經歷能對你有用。
關於Choerodon豬齒魚敏捷管理實踐的相關文章，點擊藍字閱讀 ▼
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源多雲技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺通過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。
Choerodon豬齒魚已開通官方微信交流羣，歡迎大家添加Choerodon豬齒魚微信(ID:choerodon-c7n)入羣
大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：