從Scrum到Kanban的團隊之旅

翻譯 | 高鈺淋

本文翻譯自《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)入羣

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：choerodon.io
• 論壇：forum.choerodon.io
• Github：github.com/choerodon
• 碼雲：gitee.com/choerodon