在本文中，AlesiaKrush比较了四种最好的敏捷开发方法，给出了每种方法的优缺点。市场上有各种面向实践的敏捷框架，最著名的有Scrum、Kanban、Lean和XP。虽然这是一篇比较文章，但分析这些框架有点像比较苹果和橘子，因为一些方法可以相互支持或互补（尤其是当它们应用于开发生命周期的不同部分时）。ScrumScrum可以称为敏捷软件开发的框架。AlesiaKrush分享了一个经历：“有一次我遇到一个朋友，告诉他我的新工作是关于‘敏捷’的。他问的一个问题是，你每天都做Scrum什么的吗？”.在很多人眼里，Scrum就是敏捷的代名词。首先，Scrum是一个管理框架。Scrum明确规定了开发人员计划工作、更新计划和分析过程所依据的模型。该框架引入了ScrumMaster角色，该角色致力于促进流程并确保遵循流程。工件Scrum的主要“工件”（信息传播者）有：1.用户故事。一小部分功能是团队将在称为Sprint的时间段内工作。通常的格式是：作为[用户角色]，您希望[系统做这做那]以便[交付这样那样的商业价值]。它必须有一个“完成的定义”来确定故事是否已正确执行。2.任务。它可以与用户故事相关或不相关。例如，设置新的开发环境或调查CPU内存问题是与用户故事无关的任务。3.积压。用户故事和未来Sprint任务的列表。4.冲刺积压。从当前Sprint的待办列表中挑选用户故事和任务列表（也称为“工作项”）。5、产品增量。在Sprint结束时交付的潜在可交付功能块。6.扩展。像燃尽图、速度等报告来跟踪团队的进度。角色1.开发团队。包括开发人员、QA工程师、UI/UX设计师、业务分析师和其他需要的人员。Scrum团队通常有3到9名成员。9人不够用，就分成两队。2.敏捷大师。主持每日Scrum会议，计划/更新/回顾会议，并帮助团队成员解决沟通问题。ScrumMaster不是团队成员，因此他们可以同时与多个团队合作。3.产品负责人。干系人代表，将Scrum团队的愿景（作为用户故事的基础）传达给Scrum团队，在每个Sprint结束时确定用户故事的优先级，并接受或拒绝。价值1.承诺（在Sprint中实现目标）。2.勇气（做你认为正确的事）。3.Focus（当前Sprint中的工作项）。4.开放（关于你面临的任何挑战）。5.尊重（相信他人的能力）。看板看板框架是由丰田工程师TaiichiOhno发明的。在20世纪40年代后期，丰田代表观察了超市如何根据货架上的商品重新进货。这促使丰田创建了一个供应系统，其中生产计划将由实际消费驱动。看板的关键思想之一是避免产生过剩。看板通过使用看板卡和看板可视化资源在生产周期中的移动。这使每个人都能最大程度地了解流程，并帮助管理人员实时解决盈余/短缺问题。看板系统还引入了“拉”与“推”的概念，工人可以根据自己的能力工作，而不是在传送带上或以待办事项列表的形式工作。在软件工程中，看板意味着一次可以完成的工作量是有限的。换句话说，看板的“进行中”栏中可以显示哪些卡片是有限制的，这样做是为了增加关注度并减少上下文切换。看板开发的另一个方面是活动始终与客户的需求密切相关，并与客户保持不断的沟通。除非在经济上对客户有利，否则不会生产任何东西。原则1.专注——减少多任务处理；2.减少浪费；3.将客户需求放在首位（即他们的业务需求-ROI）；练习1.可视化；2.限制工作进度；3.进程管理（可以通过管理队列或者限工来完成）；4.明确政策；5.使用反馈回路；6.进化实验；看板和Scrum之间的主要区别在于：看板是连续的，而Scrum是迭代的。看板更适合在Sprint期间有大量计划外工作（支持问题；紧急修复；紧急功能请求）的团队。这样，团队可以随时重新安排任务，不再需要等待Sprint结束。精益开发人员MaryPoppendieck在职业生涯中取得了巨大的成功，她与TomPoppendieck共同编写了精益软件。因为精益大量借鉴了看板，所以这两种方法有很多相似之处。就像看板一样，精益试图避免浪费，为客户创造最大价值。与看板不同，精益有一些关于工程实践（例如TDD）的规则。同时，精益对交付时间没有那么严格，团队可以随时准备部署。XP-ExtremeProgramming极限编程最初是KentBeck的一项实验，他的想法是让编程实践达到最佳状态，然后看看会发生什么。例如，代码审查取代代码检查。后来，随着越来越多的公司开始采用这种方式，比如日常集成测试等，一些严格的规则开始被忽略。与传统观念相反，XP不仅仅是简单的对等编程，XP还提供了进程管理算法。另一件需要注意的事情是，理想情况下，所有XP操作都应该一起使用，否则它们将无法正常工作。一些项目经理批评了XP的管理方面。例如，顽固的客户被认为是压力的来源。此外，没有任何要求和设计系统可能是无效的。ValueXP值与Scrum中的价值观有关。见表：与看板和精益一样，XP也关注浪费问题。练习1.策划游戏；2.测试驱动开发（“先写单元测试”）；3.结对编程；4.团队（客户/程序的实际用户可用于反馈）；5、持续集成；6.重构设计改进；7.次要版本；8.编码标准；9.集体代码所有权；10、设计简洁；11.系统隐喻（以程序员、客户和其他人理解的方式命名事物）；12.可持续性。
