0 敏捷开发

1、敏捷是一种思维方式和行为方式。
2、敏捷是一种心态，是一套价值观和原则。
3、敏捷是关于短周期、迭代和增量交付、快速失败、获得反馈、尽早向客户交付业务价值以及人员、协作和交互。
4、敏捷是一种思考透明度、检查和适应的方式。但是，敏捷不包含任何角色、事件或工件。这是一种心态。。

1 类型分类

1.1. Scrum

这是一种非常流行的方法，它借用了足球scrum的名称并将其用作以下隐喻：

1、每日站立会议，
2、Scrum 的迭代很短。每次迭代都专注于交付由 Scrum 团队开发的工作软件，
3、Sprint和产品有严格的优先级“积压”，并且分配了“产品所有者”角色来设置优先级。
4、维护敏捷最佳实践的“ Scrum Master ”

1. 2.极限编程（XP）

XP是一套工程实践。开发人员必须超越他们的能力来实施这些实践。团队计划少量工作并在短时间内构建，称为 1-4 周迭代。

XP 与其他迭代框架的主要区别在于 XP 侧重于需要达到极端水平的软件工程实践。例如，XP 将代码审查视为极端，并鼓励通过结对编程 100% 的时间进行同行审查。

1. 3. 快速应用程序开发 (RAD)

Rap不仅是一系列敏捷迭代方法的总称，也是 James Martin (1991) 所描述的一种方法。Rad 负责分析、设计、构建和测试阶段，并迭代开发原型和增加功能的版本。

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

DSDM 是一种敏捷的软件开发方法。它是一种迭代和增量方法，主要基于快速应用程序开发（RAD）方法。然而，RAD 方法通常是非结构化的，并且 rad 团队之间没有共同的流程。因此，每个组织都建立了自己的方法和框架，标准也各不相同，因此很难招募到有经验的 rad 从业人员。为了解决这个问题，DSDM应运而生。该方法提供了一个四阶段的框架，包括：
1、可行性和商业研究
2、功能模型/原型迭代
3、设计和构建迭代执行

1.5.统一流程（UP）

Up是一个迭代和增量框架，具有多种实现，包括 RUP、Open-UP 和 Agile-UP。一个高度可定制的框架，具有以架构为中心和以风险为中心的 rad 方法。UP的每个阶段被称为初始阶段、细化阶段、构建阶段和过渡阶段，每个阶段都有不同的侧重点。

1. 6. 精益方法

精益起源于 1970 年代的制造业。Mary 和 Tom Popendieck (2003) 在他们的《精益软件开发》一书中将精益原则应用于软件开发。精益专注于为客户提供价值并消除流程中的浪费。

1. 7. 看板

看板：一种起源于精益制造的方法，由 David Anderson (2010) 进一步发展。看板基于工作流可视化，通常在物理板上，解决导致问题的问题，限制团队正在进行的工作并平衡对团队的需求。

1. 8.FDD（功能驱动开发）

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

什么时候需要 FDD？

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

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

请记住，并非所有类都同时签名，仅够用，并且随着项目的发展，类会不断增加。

总而言之，如果您从事长期、复杂和大型项目，您将需要 FDD 敏捷。毕竟，它是为此目的而创建的。因此，FDD 被认为是一种功能性解决方案，旨在支持大型项目的管理。

功能驱动开发的优缺点

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

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

优点：
FDD 使团队能够很好地理解他们的期望，并让他们深入了解项目的背景和范围。
您不必花时间在会议上。虽然 Scrum 使用日常会议，但 FDD 并非如此。他们依靠文档进行交流。
以用户为中心的方法，在这种情况下，客户就是最终用户。
FDD 非常适合大型和长期项目。这个框架是可扩展的，它可以随着您的组织的发展而增长。
在 FDD 的帮助下，您可以将功能分解为更小的块，这将使您更容易快速周转、降低风险、修复编码错误并跟踪您的进度。

缺点：
FDD 不适合较小的项目，也不适用于仅涉及开发人员的项目。
这在很大程度上取决于需要担任导师、首席设计师和协调员的首席程序员。
它不向客户提供书面文档，尽管团队成员中有很多文档圈。
它更侧重于个人代码所有权。
它可能不适用于其他系统。

1.9.水晶开发（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、与专家用户建立方便的联系：