敏捷开发框架都有哪些

敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

看板方法虽然是精益阵营中的一种重要方法，但人们也通常将其视为一种重要的敏捷框架，所以这里也将一并介绍。

一、敏捷开发框架介绍

1.SCRUM

Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。

Scrum 是:
• 轻量的
• 易于理解的
• 难以精通的

Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个 部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。

简言之，Scrum是一个迭代的、增量的框架，用于开发任何产品或管理任何工作。 允许团队在每次迭代中交付一组潜在的可交付功能，提供响应快速变化的需求所需的灵活性。是令人耳目一新的简单、以人为本的框架，基于诚实、开放、勇气、尊重、专注、信任、授权和协作的价值观。 大集团花很长时间建造巨大的东西，小团队花少量时间建造小东西……但定期整合才能看到整体。

2、Kanban（看板）方法

看板方法是由一位丰田公司叫大野耐一的工程师创建的（译者注：现代软件看板之父为 David J. Anderson）。

在上世纪40年代末期，丰田的经销商们目睹了大型超市们如何根据卖场的货物供销数据来安排库房中的库存比例。这使得丰田公司开始着力打造这样一种供应链体系，要根据汽车使用寿命周期中的零件损耗来评估存储和供应安排。

看板方法的主旨在抑制供应过剩。看板方法通过借助看板卡片和看板这些可视化的实物，将产品周期中的物资流动关系展示出来。这样的可视化管理最大程度地帮助人们看到整个流程的运转，辅助管理层及时准确地制定供应计划。

看板方法还引入了“pull”这个概念，相比较传统的“push”概念，让工人们在流水线上拿着固定薪水劳作或者强压给员工一系列的待办事项去完成，“pull”体现在能者多劳，多劳多得。

在软件开发中。看板方法意味着在许多代办事项中，一个事项只能同时有一个流程。换而言之，在一个团队看板上的“正在进行中”的这一列中，张贴的看板卡片数目是有上限的。这样做可以增加团队的专注度，同时还减少了大家相互沟通的障碍。

看板方法的另一个精髓就是严格的用户需求导向，并且要不间断地跟客户沟通交流。直到真正意义上为客户带来效益，才算开发周期的完结。

准则
1、专注：减少同时参与处理多项事情。
2、减少浪费。
3、客户需求第一位。（换而言之，要保证用户的投资回报有收益）

实践
1、可视化
2、在流程中把控工作
3、流程管理（主要体现在管理工作流程或者工作流程中的事项）
4、确保标准的清晰明了
5、使用用户反馈机制
6、实验优化迭代

看板方法和 Scrum 模型的主要区别是，看板方法是连续不间断的而 Scrum 是不断重复一个流程来达到迭代。看板方法更适合那些需要在开发周期中处理很多不确定的工作的团队（售后支持、紧急情况的处理，突发的重要请求等等）。

如此一来，不像 Scrum 必须要等待一个迭代结束，看板方法支持事项一出现就开始进行工作，甚至连安排任务的优先级这一步都省却了。

3、XP（极限编程）

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加。

极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。

极限编程方法的基本特征是：
1、增量和反复式的开发----一次小的改进跟着一个小的改进。
2、反复性，通常是自动重复的单元测试，回归测试。参见JUnit。
3、结对程序设计
4、在程序设计团队中的用户交互（在场的客户）
5、软件重构
6、共享的代码所有权
7、简单
8、反馈
9、用隐喻来组织系统
10、可以忍受的速度

4.FDD（功能驱动开发）

功能驱动开发，简称 FDD，是一个不那么流行和知名的敏捷框架。如果您正在处理一个长期运行的大型项目，特别是在敏捷仍然仅限于软件开发的组织中，FDD 可能是您最好的朋友。这个框架弥合了敏捷和传统瀑布方法中发现的紧急过程之间的差距。

什么时候需要 FDD？

与其他以纪律严明和技术熟练的开发人员小团队为中心的敏捷框架相比，FDD 主要专注于大型团队。此外，无论他们采用何种敏捷方法，较小的团队可能更容易管理并且更有可能成功。

另一方面，在大型团队中，并不是每个团队成员都纪律严明、技能娴熟。该框架使用所谓的“刚好够用”技术来确保 FDD 可以应用于大型团队。使用这种技术，审查人员和规划人员可以更改和审查功能集和开发人员类别的分配。

请记住，并非所有类都同时签名，仅够用，并且随着项目的发展，类会不断增加。
总而言之，如果您从事长期、复杂和大型项目，您将需要 FDD 敏捷。毕竟，它是为此目的而创建的。因此，FDD 被认为是一种功能性解决方案，旨在支持大型项目的管理。

功能驱动开发的优缺点

如果您的项目对于较小的团队来说太大而无法处理，您可能需要考虑使用 FDD 框架。正是因为这个原因，敏捷特性驱动的方法更适合那些不断改变并在迭代中添加特性的团队。

请记住，FDD 完全可以从小型跨职能团队扩展到大型跨职能团队，因为这种方法旨在满足客户的需求。现在，让我们探讨一些功能驱动开发的优缺点。

优点：
1、FDD 使团队能够很好地理解他们的期望，并让他们深入了解项目的背景和范围。
您不必花时间在会议上。虽然 Scrum 使用日常会议，但 FDD 并非如此。他们依靠文档进行交流。

2、以用户为中心的方法，在这种情况下，客户就是最终用户。
FDD 非常适合大型和长期项目。这个框架是可扩展的，它可以随着您的组织的发展而增长。

3、在 FDD 的帮助下，您可以将功能分解为更小的块，这将使您更容易快速周转、降低风险、修复编码错误并跟踪您的进度。

缺点：

1、FDD 不适合较小的项目，也不适用于仅涉及开发人员的项目。

2、这在很大程度上取决于需要担任导师、首席设计师和协调员的首席程序员。

3、它不向客户提供书面文档，尽管团队成员中有很多文档圈。

4、它更侧重于个人代码所有权。

5、它可能不适用于其他系统。

4.水晶开发（Crystal Clear）

20世纪 90年代末， AlistairCockburn提出水晶方法论。自 2001年的敏捷宣言提出以来，以极限编程为首的一系列敏捷方法逐渐走入大众视野，这其中当然包括水晶方法（ Crystal Method）。

在发展的过程中，各个敏捷方法论在特性及原则上逐渐都有所偏向。而 Alistair Cockburn将水晶方法细化为透明水晶方法论（ Crystal Clear）、黄色水晶方法论（ Crystal Yellow）、橙色水晶方法论（ Crystal Orange）以及红色水晶方法论（ Crystal Red）。

这几种水晶方法论按照项目重要程度以及参加人员规模进行划分，一般来讲，透明水晶方法，适用于一个小团队来进行敏捷开发，人数在 6人以下为宜。相比于同样适用于小规模团队的 XP，水晶方法的纪律性较弱，但其管理运作与团队产出相协调。

水晶方法有七大体系特征

1、经常交付：

敏捷方法对交付成果要求很高，注重频繁小批次交付，水晶方法也不例外。通过经常交付以及时获得客户、产品经理的反馈，从而提升客户价值，使产品价值最大化。

2、反思改进：

对于在迭代开发过程中出现的问题和在交付成果中发现的问题，团队要进行及时的反思。把握住问题的关键，快速地找到解决方案。当问题发现不及时，或者团队并未 进行反思改进时，常常会导致问题的叠加，最终影响可用产品的交付。

3、渗透式交流：

在两个或多个成员进行交流的时候，与他们同处于一个空间范围内的其他人员会或多或少地获取他们的对话信息。因此，这种接收并非有意创造的信息来源的方式称为 渗透式交流，成员根据自己的当前工作可以选择忽略，也可以选择接收。

4、个人安全：

个人安全类似于极限编程强调的“勇气”，当个人产生问题困惑的时候，选择指出问题而不是隐瞒问题，且自己的人身安全受到保障。首先，只有坦然面对不足，才能及 时改正，促使自身与团队不断得到提升。其次，人身安全又是团队中互相信任的表现，只有相互信任，才能更好地完成团队协作。

5、焦点：

焦点就是首要计划。团队制定出要完成的计划，然后安排时间
所谓“焦点”，就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚的了解他们自己最重要的任务是什么，确保他们能够有充分的时间去 完成这些任务。

6、与专家用户建立方便的联系：

建立方便的联系是保证专家、用户、团队能够形成一个短周期反应链，对于小批次交付成果的、用户需求变动建立一个快速反馈机制，提高团队工作效率。

7、配有自动测试、配置管理和经常集成功能的技术环境：

自动化测试可以对代码进行自动测试，减少了人工成本，是工作变得高效、快捷；
配置管理简单来说，就是可以返回上一步，可以通过撤销新操作出现的失误来解决问题；

经常集成功能使团队对系统快速集成，以及时发现错误、纠正错误。

5.动态系统开发方法（DSDM）

DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。

实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。

DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

二、这些敏捷开发框架的共同特征

所有这些方法都具有以下共同特征：

1、迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2、增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3、开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4、持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。

5、开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

推荐阅读：

了解敏捷：什么是敏捷开发 | 敏捷宣言及其解读 | 敏捷开发模式与瀑布开发模式对比 | 敏捷开发适合什么样的团队 | 敏捷开发框架 | Scrum团队内部的角色与分工 | 待续...

敏捷实践分享：中小团队如何落地敏捷开发 | 国内外十大顶级敏捷开发项目管理工具盘点 |待续...