敏捷框架比較：Scrum vs Kanban vs Lean vs XP

07-09

在這篇文章中， Alesia Krush將對四種最流行的敏捷開發方法進行比較，給出了每種方法的優缺點。

市場上有各種各樣的面向實踐的敏捷框架，其中最受歡迎的是Scrum、Kanban、Lean和XP。雖然這是一個比較類文章，但分析這些框架卻有點像拿蘋果與橙子做比較，因為其中的一些方法可以相互支持或補充(尤其是當它們適用於開發生命周期不同部分時)。

Scrum

Scrum完全可以被稱為敏捷軟體開發的框架。Alesia Krush分享了一個經歷：「某次我遇到了一個朋友，並告訴他我的新工作是關於「敏捷」的。他提出的一個問題就是，你每天都在做Scrum之類的事情嗎?「。在很多人看來，Scrum就是敏捷的代名詞。

首先，Scrum是一個管理框架。Scrum明確地規定了一個模型，根據這個模型，開發人員計劃工作、更新計劃並分析過程。該框架介紹了角色Scrum Master，Scrum Master是一個專門為流程提供便利、並確保遵循這一流程的角色。

人工品

Scrum的主要「人工品」(信息傳播者)是：

1. User Story。一小部分功能是，團隊將在一個被稱為Sprint的時間段內工作。通常的格式是：作為[用戶角色]，希望[系統做這個和那個]，以便[交付這樣和這樣的商業價值]。它必須有一個「完成的定義」，用來確定故事是否已經正確執行。

2. Task。它可以與用戶故事相關或不相關。例如，設置新的開發環境或研究CPU內存問題是與用戶故事無關的任務。

3. Backlog。用戶故事和未來Sprint任務的列表。

4. Sprint backlog。從Backlog的當前Sprint中挑選用戶故事和任務列表(又名「工作項目」)。

5. Product increment。在Sprint結束時交付的一種潛在可交付功能塊。

6. Extensions。像Burndown Chart、Velocity等的報告，用於跟蹤團隊的進展。

角色

1. 開發團隊。包括開發人員、QA工程師、UI/UX設計師、業務分析師以及其他需要的人員。Scrum團隊通常有3到9名成員。當9個人還不夠時，團隊就一分為二了。

2. Scrum Master。主持每日Scrum會議、策劃/更新/回顧會議，並幫助團隊成員解決溝通問題。Scrum Master不是團隊成員，所以他們可以同時與多個團隊合作。

3. 產品所有者。利益相關者的代表，將Scrum團隊的願景(作為用戶故事的基礎)傳達給Scrum團隊，在每個Sprint結束時優先考慮用戶故事，並接受或拒絕他們。

價值

1. 承諾(在Sprint中實現目標)。

2. 勇氣(做您認為正確的事)。

3. 重點(在當前Sprint中的工作項目)。

4. 開放(關於面臨的任何挑戰)。

5. 尊重(相信其他人的能力)。

Kanban

Kanban框架是由豐田工程師Taiichi Ohno發明的。在20世紀40年代後期，豐田代表們觀察到超市是如何根據貨架上的貨物重新進貨。這促使豐田建立了一個供應體系，生產計劃將由實際消耗驅動。

Kanban的關鍵思想之一是避免產生過剩。Kanban通過使用Kanban卡和Kanban板來可視化資源在生產周期中的移動。這使每個人都能夠最大程度地了解流程，並幫助管理人員實時解決盈餘/短缺問題。

Kanban系統還引入了「pull」與「push」的概念，工人可以根據自己的能力進行工作，而不是在傳送帶上或在待辦事項列表形式中工作。

在軟體工程中，Kanban意味著一次可以進行的工作量是有限的。換句話說，Kanban上的「進行中」欄內可以擁有卡片是有上限的，這樣做是為了增加焦點並減少上下文切換。

Kanban開發的另一個方面是，活動始終與客戶需求緊密相關，並與客戶保持持續的溝通。除非在經濟上有利於客戶，否則什麼都不會產生。

原則

1. 專註—減少多任務;

2. 減少浪費;

3. 客戶的需求放在第一位(即他們的業務需求-ROI);

實踐

1. 可視化;

2. 限制工作進展;

3. 流程管理(可以通過管理隊列或限制工作來完成);

4. 明確政策;

5. 使用反饋循環;

6. 實驗演變;

Kanban和Scrum的關鍵區別在於：Kanban是連續的，而Scrum是迭代的。Kanban更適合在Sprint期間有大量計劃外工作(支持問題;緊急修復;緊急功能請求)的團隊。通過這種方式，團隊可以隨時重新排序任務，不再需要等待Sprint結束。

Lean

Lean開發者，Mary Poppendieck在她的事業生涯中取得了巨大的成功，她帶領她與Tom Poppendieck共同編寫了Lean軟體。因為Lean大量借用了Kanban，兩種方法之間有許多相似之處。

就像Kanban一樣，Lean盡量避免浪費，最大限度地為客戶帶來價值。與Kanban不同的是，Lean有一些關於工程實踐的規定(例如TDD)。與此同時，Lean對交付時間的要求不那麼嚴格，團隊可能隨時準備部署。

XP - 極限編程

極限編程始於Kent Beck的一個實驗，他的想法是把編程實踐做到極致，看看會發生什麼。例如，代碼審查代替代碼檢查。後來，隨著越來越多的公司開始採用這種方法，例如日常集成測試等，某些嚴格的規則開始被忽略。

與傳統的觀念相反，XP不只是簡單的平等配對編程，XP還提供了一個流程管理演算法。

需要注意的另一點是，理想情況下，所有的XP操作都應該一起使用，否則他們將無法正常工作。

XP的管理方面受到了一些項目經理批評。例如，持續存在的客戶被認為是壓力的來源。另外，沒有任何要求和設計系統可能是無效的。

值

XP值與Scrum中的值相關。見表格：

就像Kanban和Lean，XP也很注重浪費問題。

實踐

1. 計劃遊戲;

2. 測試驅動開發(「先寫單元測試」);

3. 配對編程;

4. 團隊(客戶/程序的實際用戶可用於反饋);

5. 持續集成;

6. 重構設計改進;

7. 小版本;

8. 編碼標準;

9. 集體代碼所有權;

10. 設計簡單;

11. 系統隱喻(以程序員、客戶和其他人理解的方式命名事物);

12. 可持續性。