Kanban VS Scrum：哪一個是最好的敏捷項目管理框架

「咱們使用敏捷開發。」在與軟件開發團隊交流時，你會聽到不少這樣的說法。根據統計，2018年全球約有90％的開發人員在使用敏捷開發。Choerodon豬齒魚團隊也是其中之一。

可是，敏捷並不統一。做爲組織工做流程的通常方法，敏捷軟件開發設定了共同的價值觀和原則，旨在精簡開發流程，敏捷有效地響應變化。這些價值觀和原則能夠在敏捷宣言中找到，當中就提供了一些創建開發流程的建議。

在實際應用中，幾種軟件開發框架已經體現了這些敏捷原則。其中Kanban 和 Scrum是最受歡迎和常用的。這兩種方法都有一個共同的目標，即建立一個有效的工做流程。今天這篇文將圍繞他們之間的差別進行討論。

Scrum和Kanban的基礎知識

在深刻研究Scrum和Kanban之間的差別以前，先看一下兩個框架的主要概念，以便以後能夠更輕鬆地進行Kanban與Scrum的比較。雖然它們都旨在創建一個自組織團隊的流動，可是有些方法不一樣。

▌Scrum是什麼？

Scrum的名字來自橄欖球術語，表示「爭球」的動做。在軟件開發中，Scrum是指採起組織團隊合做的方法，以便更高效地開發複雜的軟件產品。

Scrum基於開發團隊在開始時不知道項目的結果這個假設，他們會隨着工做的進展不斷學習和適應。Scrum旨在經過每次迭代開始時重置優先級來簡化這種適應，這在Scrum術語中稱爲「Sprint」。

在這裏，你們來看一個Scrum的核心概念——衝刺（Sprint），衝刺是用2到4周的時間來完成必定量的工做。Sprint有助於將項目範圍分解爲更容易管理的任務，並更頻繁地交付組件正常運行的軟件。

在衝刺階段，開發團隊只需專一於每一個sprint中應完成的任務，這爲項目規劃階段提供了極大的靈活性。新衝刺開始時，開發團隊會從新規劃本次衝刺的任務，規劃時須要考慮到上個衝刺任務的完成狀況以及項目的新需求。

▌Kanban是什麼？

Kanban最早由Toyota 提出，旨在優化其工廠庫存。在日語中，「Kanban」是指板或卡。在最初的應用中，一個庫存愈來愈少的工廠部門會向倉庫發送「Kanban」來請求補貨。而後，倉庫將「Kanban」發送給供應商以訂購更多庫存。

從這個例子中，你們能夠看到Kanban專一於當前容量，這也是用在軟件開發的主要概念。與Scrum不一樣，Kanban沒有時間限制，相反，它限制了能夠同時執行的工做量。

看板的主要指標之一是「正在進行的工做」 。Kanban表示，爲了實現最高效率，正在進行的工做應進行限制以與團隊的能力相匹配，從而下降任何出現瓶頸的風險。

看板也能很好地響應變化，由於能夠在項目的任何階段進行更改並添加到要執行的任務列表中。

Choerodon豬齒魚團隊就是使用敏捷Kanban方法來提高交付效率，具體如何使用可參考Choerodon豬齒魚博客文章：豬齒魚團隊如何使用敏捷Kanban方法提高交付效率

Scrum與Kanban的主要區別

若是想比較Scrum和Kanban，你們須要看兩個框架組織工做流的方式以及它們使用的主要實例和定義。

角色

角色的分配是Scrum和Kanban之間的第一個重大區別。在Scrum中，團隊主要分三個角色：

產品負責人：負責產品的人。產品負責人分析客戶對產品的需求，並將其轉化爲團隊的任務。產品負責人還肯定任務的優先級，並決定什麼時候能夠發佈特定的功能組件。

Scrum Master：負責Scrum過程的人。首先，Scrum Masters將Scrum原則引入其團隊成員並協助他們實施。此外，Scrum Masters管理衝刺所需的人力資源分配。

開發團隊：負責實際開發工做的人。由具有自我管理能力的人組成的跨職能團隊。

反過來，Kanban對團隊角色沒有嚴格的要求，可能有一個產品負責人監督項目中積壓的任務，但除此以外，團隊是自組織的。

工做流程

正如上文提到的，Scrum開發在迭代中進行，定義了每次迭代中要完成的工做，而Kanban旨在限制當前正在進行的工做，沒有特定的時間限制。下面列出這兩種方法在實際應用中的含義。

▌Scrum流程

項目規劃從定義項目待辦事項開始，即爲了交付產品而須要完成的用戶故事列表。在這種狀況下，Scrum使用如下主要概念來幫助使用者理解工做的計劃和分配方式：

Product backlog：表明團隊的主要「待辦事項」列表。Product Backlog包括項目中須要完成的全部功能和bug修復。待辦事項列表根據新需求或檢測到的錯誤而不斷更新。產品負責人負責Product backlog的工做，以便客戶的反饋和建議與團隊的工做進度保持同步。Product backlog的一些任務能夠根據優先級排序，一些能夠在需求改變時添加，一些能夠刪除。

Sprint backlog：要在衝刺中完成的任務清單。Sprint backlog的任務須要在sprint結束時交付已完成的功能或組件。雖然sprint backlog也容許必定的靈活性和修改，但sprint的目標應該保持不變，而且應該將更改保持在最低限度。

increment：sprint結束後可交付的可用產品。一般，sprint以已完成的功能或組件的演示爲結束。在這方面，一個重要的概念是「完成」，它指的是每一個用戶故事都要考慮其完整性。「完成」的定義可能根據用戶故事而有所不一樣：它可能包括多個任務，例如開發，測試，設計，文檔和演示，也可能涉及不一樣的團隊成員。

每一個sprint都從規劃階段開始，在該階段中計劃下一個sprint的任務。對於規劃，一般會有整個團隊，包括產品負責人和Scrum Master在場。團隊決定在sprint結束時他們能夠提供什麼，並從Product backlog中選擇相應的用戶故事。這樣就造成了Sprint backlog 。

在衝刺期間，團隊天天會開「daily scrum」（即每日站立會議），討論他們的進展以及他們可能遇到的問題。站立會議的目的是儘早發現問題並快速找到解決方案，以避免破壞衝刺流程。

在衝刺以後，利益相關者將審查完成的功能。在sprint review期間 ，團隊有機會收到有關其工做的反饋或變動建議。

與此同時，團隊進行sprint retrospective meeting（回顧會議），分析他們所完成的衝刺並找到須要改進的問題。回顧以後，重置過程，新的sprint從規劃階段開始。

▌Kanban流程

在Kanban中，沒有規定時間段來完成必定量的工做，相反，Kanban專一於平衡團隊的能力與當前正在進行的工做。

Kanban流程從待辦事項清單開始，包括應該完成的全部任務。每一個團隊成員從待辦事項中領取一個任務，並專一於完成它。任務完成後，成員選擇下一個，依此類推，直到待辦事項完成爲止。待辦事項按照優先級排序，最緊急的任務放在最頂層，由團隊優先選擇。

在Kanban中， 項目期間正在進行的工做量不超過團隊的能力這點相當重要 。即kanban中的限制在製品原則。出於這個目的，能夠根據成員工做能力爲任何類型的工做設置限制。

產品負責人能夠根據須要儘量多地設置和更改待辦事項中的優先級，由於backlog management對團隊的績效沒有影響。團隊只須要關心正在進行的工做，只有在當前任務完成後才返回待辦事項。

每項任務都沿着「待辦事項」 - 「正在進行的工做」 - 「完成」路線行進。固然，Kanban也支持「完成」概念（即每一個任務被接受的標準）的自定義。

最終，完成的任務造成完成的組件，能夠計算交付它們所需的時間。在Kanban中，它被稱爲 「cycle time」，週期的計算能提供許多優化點。固然，全部團隊都在努力縮短週期，並尋找解決瓶頸的方法（若是有的話）。

在Choerodon豬齒魚中，可對任務進行故事點與時間的評估，並在燃盡圖中能很好的看到迭代工做時間的預期值與剩餘值。

在這種狀況下，讓團隊成員具備重疊技能相當重要。若是隻有一我的擁有某種技能，例如若是你只有一個測試人員，那就是瓶頸，全部測試任務將排隊等待產品交付過程當中的延遲。

總而言之，Scrum目標是在指定時間內完成預約工做，而Kanban監控以確保正在進行的工做永遠不會超過設定限制。

選擇哪個？

若是您一直在等待這個問題的肯定答案，答案可能會讓您失望。到目前爲止，本文列出這兩種方法都有其優勢，而且二者都有助於創建敏捷開發流程。下面將提供了一些指南，能夠幫助您選擇最適合您團隊的方法。

使用Scrum：

• 你能夠相對輕鬆地將工做範圍劃分爲可在兩週內完成的邏輯塊。
• 你須要對整個項目具備高度的可預測性。Scrum專一於將sprint中的更改保持在最低限度。
• 團隊中有不少新成員。使用Scrum，他們將更容易理解團隊紀律並進行改進。

使用Kanban：

• 你但願項目中有不少頻繁的更改。
• 很難離析出可在兩週內交付的產品組件。
• 你的團隊訓練有素，能夠信任地在沒有嚴格截止日期的狀況下安排他們的活動。

然而，好消息是你能夠隨時結合！甚至還有一種名爲 Scrumban 的方法，其中包含了Scrum和Kanban的方法。在Scrumban，你能夠在短時間迭代中完成工做，並將進行中的任務數量保持在必定限度內，一旦進行中的任務低於限度時會觸發新的迭代。

如你所見，選擇項目管理方法能夠像你但願的那樣靈活和自由。沒有固定規則，您能夠根據本身的項目進行調整，混合和匹配。實際上，選擇過程當中的主要標準應始終是您的項目成功和團隊對工做流程的滿意度。

Choerodon豬齒魚團隊就結合了Scrum和Kanban方法，關於團隊的敏捷實踐相關信息，組織Sprint計劃會議、每日站立會議、評審會、回顧會等敏捷會議可參考Choerodon豬齒魚敏捷管理實踐（三）：敏捷會議，結合Choerodon平臺敏捷管理模塊進行衝刺管理可參考Choerodon豬齒魚敏捷管理實踐（二）——衝刺管理。

本文譯者 | 林巖芳 原文地址：https://da-14.com/blog/kanban-vs-scrum-choosing-best-agile-project-management-framework

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源企業服務平臺，基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。

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

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信公衆號：Choerodon豬齒魚
• 微博：Choerodon豬齒魚