Scrum vs Kanban，如何選擇？

兩大方法

雖然敏捷誕生只有20年的時間，但卻幫助了很多企業取得了成功，在這期間也出現了各種敏捷方法論和思想體系，這篇文章，我們試圖去討論一個問題：對於準備實施敏捷的團隊，在Scrum和Kanban兩種方法之間如何選擇？（特別說明：有人會說Kanban其實是一套思想體系，不是方法論，這裡我們不想陷入概念之爭，只想解釋他們適用的場景，所以下文中都會稱呼他們為方法，而不會刻意加以區分）。

Scrum和Kanban兩者都作為符合精益思想和敏捷的思考結果，他們之間必然會有一些相似點：

• 兩者都限制開發中工作數目

• 兩者都是通過透明度來驅動過程改進

• 兩者都提倡提及時且穩定的交付價值

• 兩者都基於自組織型團隊

• 兩者都要求把工作細分

• 兩者都是基於經驗資料持續優化

再來看看兩者之間的一些區別：

下面結合例項來演示Scrum和Kanban這兩種方法如何在Worktile Agile中體現。

Scrum

在標準的Scrum流程定義中，有兩個關鍵的產物：Product Backlog和Sprint Backlog，以及四個關鍵的會議：計劃會議、每日立會、評審會議和回顧會議。 在Worktile Agile產品中，我們把Product Backlog分為需求和缺陷，其中需求部分使用Epic-Feature-User Story三級體系來表示。

• Epic：史詩，表示比較大的特性，開發週期一般是1-3月，用於產品路線圖的規劃

• Feature：特性，表示相對小一些的特性，開發週期一般是1-3周，用於產品版本的規劃

• User Story：使用者故事，表示最小的使用者場景，開發週期一般是1-3天，用於迭代規劃。

圖1 Worktile Agile中需求管理

在每個迭代開始時會召開計劃會議，全員都會參加，這個會議最重要的事情就是確定Sprint Backlog，由Product Owner按照優先順序介紹Product Backlog，然後團隊決定是否把某一個條目放入當前迭代。

圖2 Worktile Agile中迭代規劃

迭代進行的時間內，每天都會有10-15分鐘的站立會議，團隊中每個成員基於Worktile中的迭代任務板介紹前一個工作日所做的事情，以及遇到的問題。

圖3 Worktile Agile中的迭代任務板

迭代結束時召開評審會議，在評審會議上每個人基於產品演示自己在這個迭代中所完成的成果，團隊成員可以針對完成的事項提一些建議。在評審會議結束後，團隊成員會一起召開迭代回顧會，回顧會是Scrum迭代實踐中的最後一環，也是最重要的一環，迭代回顧會將整個迭代形成了閉環。回顧會上大家提出的問題通過迭代回顧皮膚記錄。

圖4 Worktile Agile中的迭代回顧皮膚

在Scrum實踐中，大部分團隊都會忽視版本管理，迭代是針對Scrum團隊的活動行為，而版本管理是針對產品的，它定義的是一個批量的概念，用於版本進度管理和交付風險管理，明確在一個版本中的最終交付物，Worktile Agile中你可以建立版本並把它與迭代關聯，或者只是單純的設定某個使用者故事/缺陷屬於某個版本

圖5 Worktile Agile中的版本管理

Kanban

對於一個團隊採用Kanban方法來管理是否能夠成功，取決於使用Kanban後能否為你的團隊帶來以下幾點改進：

• 幫助團隊視覺化整個鏈條的價值流動

• 幫助團隊識別價值流動中的風險點

• 幫助團隊度量價值流動中的各種浪費，並加以消除

基於這些考慮，在Worktile Agile中的Kanban專案型別，目前支援以下的能力：

• 能夠清晰定義在製品WIP

• 能夠清晰定義在製品限制WIP Limit

• 明確定義DoD

• 支援多泳道分割

圖6 Worktile Agile中的Kanban專案

在Worktile Agile中的同一個專案中，支援同時建立多個看板，便於你根據業務場景的不同，或者團隊角色的不同定義多個看板，並且可以針對每個看板的需要進行個性化的配置。

圖7 根據團隊的需要個性化你的看板

因地制宜

講完了Scrum和Kanban的基礎知識，以及在Worktile Agile中對於Scrum和Kanban的支援，我們來看看在實際團隊落地時，如何結合實際情況在二者之間選擇。

1. 如果你的團隊是產品導向型的，推薦使用Scrum；如果是研究導向型的，比如效能優化、編碼優化等不確定性非常大的，推薦使用Kanban。
2. 團隊規模適中，5-9人左右，並且有跨功能團隊成員，推薦使用Scrum；相反如果你的團隊規模比較小，只有2-5人左右，推薦使用Kanban，相對效率較高。
3. 產品或者專案交付是按照一定的週期來計算，比如每2周或每個月要求有一個新的版本，推薦使用Scrum；如果產品或者專案的交付不是按週期來計算，而是按照某個特定的事件為標誌，比如效能提升了10%釋出一個新版，推薦使用Kanban。 當然這些只不過是一點經驗之談，具體還要看團隊的實際情況，因地制宜，來推動敏捷在團隊的真正落地，而不是流於形式。

本作品採用《CC 協議》，轉載必須註明作者和本文連結