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、支付、數據、智能洞察、企業應用市場等業務組件,致力幫助企業聚焦於業務,加速數字化轉型。

大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性,以及參與社區貢獻:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章