敏捷开发方法（敏捷开发方式有哪些）

本文目录

• 敏捷开发方式有哪些
• 如何通过“敏捷开发”模式开发MVP产品

敏捷开发方式有哪些

敏捷开发包括一系列的方法，主流的有如下七种：
XP
XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
FDD
FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
ASD
ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDM
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUP
RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。

如何通过“敏捷开发”模式开发MVP产品

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行产品开发。在敏捷开发中，产品项目在构建初期被切分成多个子产品，各个子产品的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大产品分为多个相互联系，但也可独立运行的小产品模块或功能，并分别完成，在此过程中产品一直处于可使用状态。

在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件。这份文件基本上代表了不同敏捷方法论的共同点，我们称之为“敏捷宣传”，也叫做敏捷软件开发宣言，是指导以人为中心的迭代软件开发方法，具体四个核心价值内容如图5-14所示。

图5-14 敏捷开发宣传

1. 个体和互动高于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。虽然，过程和工具都是好东西，但是它们有时也会成为障碍。面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多。当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

2. 工作的软件高于详尽的文档

可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文件)为客户和也会[张乐飞1] 传递了高价值。一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的。但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的。敏捷通过寻求“刚好足够”的文档来避免这种情况。其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

3. 客户合作高于合同谈判

这个[张乐飞2] 价值观的核心是越接近你的客户越好。客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误。在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的。定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

4. 响应变化高于遵循计划

任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。即使底层的技术也在快速变化，新的途径和可能性在不断的被打开。对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。

当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。除了敏捷宣言之外，还有12条准则的支持文件，为敏捷宣言提供了更多的扩充细节。

l准则1：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值。

l准则2：欢迎对需求提出变更，即使在项目开发后期；要善于利用需求变更，帮助客户获得竞争优势。传统项目管理中地一个原则是设法去影响和控制会导致变化地因素。敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期。迅速应对和适应变化能给客户带来显著地竞争优势，从而应对新的机遇。

l准则3：要不断交付可用的软件，周期从几周到几个月不等，且越短越好。不同的敏捷方法论采用不同的迭代周期，但都是相对较短的。关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报。较短的迭代周期可以使团队持续关注客户的价值。[张乐飞3]

l准则4：在项目过程中，业务人员、产品经理与开发人员必须在一起。敏捷项目管理，让业务人员、产品经理和开发人员彼此靠近，并时常让他们在同一个地方一起工作，通过这样的方式让业务人员和开发人员之间没有隔阂。是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。

l准则5：要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式。敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么。提供相关资源，给予鼓励，相信团队能够完成任务。

l准则6：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍。其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率。面对面沟通是敏捷项目管理的精髓。这种沟通是公开的，任何团队成员都可以自由参与对话。

l准则7：可用的软件是衡量进度的主要指标。计划和文件可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值。传统项目往往极其纠结的是，项目的不断更新使得文件成为一种负担。真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。

l准则8：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工。理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。

l准则9：对技术的精益求精及对设计的不断完善将提升敏捷性。设计的越完善，维护起来就越简单，即使遇到变化。稳定和优质的项目会比劣质的项目更加允许团队快速应对变化。

l准则10：要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术，被所有的敏捷方法所拥护，尤其是精益方法。[张乐飞4] 关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动。保持简单不只是一种愿望，它使最基本的原则。

l准则11：最佳的架构、需求和设计出自自我组织的团队。自我组织是敏捷团队的核心元素之一。当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定。不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的。

l准则12：团队要定期反省如何能够做到更有效，并相应的调整团队的行为。敏捷项目中最可预见的事情就是变更。传统项目里当项目或阶段完成时开会总结是最常见的做法。而敏捷试着通过更频繁的回顾来完成这项工作。在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法。每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。

敏捷开发的业务目标是更早的交付价值，价值的交付不仅仅是早晚上线两天的问题，而是更早上线能够给自己和客户带来更大的价值越晚交付，价值越低。更快不是绝对速度的快，而是指时间上的早，即通过迭代交付实现分批和更早的交付。同时灵活地响应变化，当今世界跨界颠覆的案例数不胜数，一个企业的核心能力不再是已有的能力有多强，而是灵活响应变化，快速学习的能力有多好。