在这篇文章中， 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. 可持续性。
