常用敏捷开发方法

摘自《轻松Scrum之旅》

1、极限编程（eXtreme Programming，XP） 

极限编程的思想源自 Kent Beck 和 Ward Cunningham 在软件项目中的合作经历。在这里，“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP 注重的核心在于“沟通、简明、反馈和勇气”，用一句话来概括 XP 的这 4 个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简单明了；同时通过客户经常性的反馈，生产出符合客户要求的软件产品，并且有勇气迎接需求的改变。

 

另外，极限编程者还总结出一系列经典的实践，形成了 XP 的 12 个主要实践方法，这些方法对极限编程具有指导性的意义，分别是：客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。 

2、RUP（Rational Unify Process，Ratioanl 统一过程） 

RUP 试图总结现代软件开发过程中所有好的实践经验，形成一种有很强适应性的软件开发过程。它包括了软件开发中的 6 大经验，分别是：迭代式开发、管理需求、可视化建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。

RUP 将软件开发周期按时间和 RUP 的核心工作流划分为一个二维空间，如下图
所示。

从图中的横轴来看，RUP 把软件开发的生命周期划分为多个循环迭代，每个迭代生成产品的一个新版本，每个迭代由 4 个连续的阶段组成，分别是：初始阶段，了解项目的大致需求，建立业务模型，确定系统范围；细化阶段，设计、确定系统的体系结构，制定工作计划；构造阶段，构造产品并继续演进需求、体系结构、计划直至产品提交；移交阶段，完成产品的最终版本并交付给用户使用。 

从图纵轴来看，RUP 的 9 个核心工作流分别是：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。 

RUP 的基本原理是：以满足客户需求、为客户创造价值为最终目标；尽可能早且不断地化解重大风险；把注意力放在可工作的软件上；在项目执行过程中尽可能早地适应变化；在项目早期设计、实现并测试一个可执行的架构；使用组件来构造系统；建立高效、协作的团队；要始终重视产品质量，否则追悔莫及。 

以上 RUP 的基本原理构成了 RUP 的灵魂，在这些指导原则下，RUP 又给出了其他一些最佳实践，比如：为了化解业务风险，它始终以用例为中心；不是逃避变化，而是直面变化；为了化解时间风险，它采取迭代开发，尽量在早期探知到时间的延迟，以便采取更灵活的策略；为了化解技术风险，它强调架构设计；为了化解质量风险，它强调测试优先。而这些也恰好是 RUP 的主要特点。在这些最佳实践之后，才是具体的过程组织形式：具体由哪几个阶段组成？而每个阶段又包括哪些工作流，要产出哪些产品？而且这些形式不是固化的。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，从中总结经验和教训。

Scrum 的总体结构如图所示