敏捷开发方法有哪些
敏捷开发方法有：1.极限编程（eXtreme Programming，XP） ；2.RUP（Rational Unify Process，Ratioanl 统一过程） ；3.Lean（精益软件开发方法）；4.Scrum
1.极限编程（eXtreme Programming，XP）
极限编程的思想源自 Kent Beck 和 Ward Cunningham 在软件项目中的合作经历。在这里，“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP 注重的核心在于“沟通、简明、反馈和勇气”，用一句话来概括 XP 的这 4 个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简单明了；同时通过客户经常性的反馈，生产出符合客户要求的软件产品，并且有勇气迎接需求的改变。 另外，极限编程者还总结出一系列经典的实践，形成了 XP 的 12 个主要实践方法，这些方法对极限编程具有指导性的意义，分别是：客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。
2.RUP（Rational Unify Process，Ratioanl 统一过程）
RUP 试图总结现代软件开发过程中所有好的实践经验，形成一种有很强适应性的软件开发过程。它包括了软件开发中的 6 大经验，分别是：迭代式开发、管理需求、可视化建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。
RUP 的 9 个核心工作流分别是：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。 RUP 的基本原理是：以满足客户需求、为客户创造价值为最终目标；尽可能早且不断地化解重大风险；把注意力放在可工作的软件上；在项目执行过程中尽可能早地适应变化；在项目早期设计、实现并测试一个可执行的架构；使用组件来构造系统；建立高效、协作的团队；要始终重视产品质量，否则追悔莫及。
3.Lean（精益软件开发方法）
精益生产的概念首先出现在制造业中，由日本的丰田公司提出。大规模制造理论认为，一定程度的浪费、一定程度的废品是正常的和被允许的。而在软件开发中，资源浪费、成本居高不下也同样成为软件开发的一大障碍。处于变革的十字路口的软件开发行业，总是能不断地从其他行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程（Lean Programming）。
Lean 方法的主要思路有：消除浪费，将所有的时间花在能够增加客户价值的事情上；延迟决策，在一个复杂多变的环境中进行软件开发，需要根据实际情况保持可选方案的开放性，但时间不能过长；尽早交付，软件交付的周期越快，用户的需求就会越清晰，软件应对需求变化的灵活性就越高，让客户的需求来推动工作的进展；加强学习，承认变化的存在及其不可预见性，加强反馈和交流，在实践中发现问题、解决问题，并最终形成解决方案；授权给团队，正确的决策取决于准确的信息，让开发团队参与决策，让团队成员充分发挥自己的潜力。
无数的经验和教训都已经证明，软件开发中一个巨大的浪费源头就是不注重质量而导致的返工。人们常常为了追赶工期而降低对质量的要求，殊不知这会带来更大的损失。
Lean 强调消除浪费，这正是为了避免低质量和返工造成的浪费。尽管这样做一开始看起来似乎有些麻烦，但它所带来的收益是实实在在的。如果采用 Lean 方法，还要注意不要钻牛角尖。消除浪费并不意味着扔掉所有的文档；尽量推迟决策并不意味着拖延决策，不能晚到错过了时机、耽误了工作才作出决策；尽快交付并不意味着匆忙交付和马虎行事，否则会为日后的系统维护带来更多的麻烦和浪费，这恰恰是与消除浪费的原则背道而驰的；授权给团队也并不意味着放弃领导。
4.Scrum
Scrum是一种灵活的敏捷软件开发管理过程，这个名词来源于英式橄榄球。Scrum 方法由 Ken Schwaber 和 Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的较高目标——发布产品的重要性高于一切，团队高度自治，成员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着较高目标推进，而且每隔 2～4 周，每个团队成员都能看到能实际工作的软件，并且据此决定是发
布这个版本还是继续开发以加强它的功能。
对于那些功能需求可能经常发生变化的项目来说，Scrum 是最为理想的选择之一。
在一个采用 Scrum 的项目中，首先要将所有需要完成的工作列在一个 Product Backlog中，项目开发过程中需求的改变也要写进去。在每个 Sprint 开始之前，要召开一个 Sprint计划会议。在这个会上，产品责任人（Product Owner）为 Product Backlog 中的各项功能需求确定优先级。随后，Scrum 开发团队按照优先级，从 Product Backlog 中挑选出他们认为能在这个 Sprint 中完成的任务，并把这些任务从 Product Backlog 中挪到Sprint Backlog 中去。在 Sprint 的进行过程中，Scrum 团队每天都要举行一个简短的每日 Scrum 会议，以便团队成员了解开发进度。一个 Sprint 结束之后，需要召开 Sprint评审会议和 Sprint 回顾会议。开发团队在 Sprint 评审会议上把这个 Sprint 的开发成果展示给大家。而在 Sprint 回顾会议上，团队成员们会回顾刚刚过去的这个 Sprint，从中总结经验和教训。
