什么是敏捷软件开发？敏捷宣言与方法详解

敏捷是一种用于描述软件开发方法的术语，强调增量交付、团队协作、持续规划和持续学习，而不是在接近结束时一次性交付所有内容。

敏捷注重保持流程精简，并创建最小可行产品（MVP），在最终结果出现之前经历多次迭代。持续收集并实施反馈。简而言之，这是一个更动态的过程，每个人都在朝着共同目标努力。

敏捷软件开发

Scrum及其他主流敏捷方法

敏捷是一种心态——一套价值观和原则。它是一种思考和行动的方式。敏捷意味着短周期、迭代和增量交付、快速失败、获取反馈、尽早交付业务价值，并关注人员、协作和互动。敏捷是一种透明、检查与适应的心态。然而，敏捷并不包含任何角色、事件或工件。它是一种心态。例如，Scrum是敏捷框架中广泛使用的一种，帮助你变得更加敏捷。但敏捷运动还包括许多其他框架，例如看板、XP、水晶等，如下所示：

Scrum 敏捷伞

Scrum

Scrum是一种框架，人们用它来解决复杂适应性问题，同时高效且创造性地交付高价值产品。它用于管理软件项目以及产品或应用程序的开发。其重点在于适应性产品开发策略，即跨职能团队在2至4周内（冲刺）内共同努力实现共同目标。它由一系列价值观、工件、角色、仪式、规则和最佳实践组成。

精益

精益起源于丰田生产体系（TPS），在20世纪50年代、60年代及以后彻底改变了实物产品生产。尽管精益在制造业中保持了其地位，但它也在知识工作中找到了新的应用，帮助各行各业的企业**消除浪费、改进流程并促进创新**。软件开发与精益方法天然契合，因为它与制造业一样，通常遵循既定流程，有明确的验收标准，并带来可交付的有形价值。指导所有精益实践的关键概念被称为精益支柱。它们是：

• 持续改进
• 尊重人员
• 轻量级领导

看板

看板是一种高度可视化的流程管理方法，在精益团队中被广泛采用。事实上，83%的精益生产团队使用看板来可视化并积极管理产品创建，专注于持续交付，同时避免给开发团队带来过度负担。与Scrum类似，看板是一种旨在帮助团队更高效协作的流程。

看板基于三个核心原则：

• 可视化你今天的工作（流程）： 将所有项目放在一起上下文查看，可以提供丰富而深刻的洞察信息。
• 限制进行中的工作（WIP）： 这有助于平衡基于流程的方法，使团队不会立即开始并承诺过多工作。
• 改进流程： 当一项任务完成后，待办事项中优先级最高的下一项将被激活。

看板通过定义最佳团队工作流程来促进持续协作，并鼓励积极、持续的学习与改进。

动态系统开发方法（DSDM）

DSDM 是一个由八个原则组成的框架，包括生命周期与产品、角色与职责，以及多种最佳实践技术。这些原则支持并促进战略性重要业务效益的早期交付，从而为组织提供最佳的投资回报率（ROI）。

DSDM 是一种将规划和质量置于功能之上的方法。它从一开始就确定成本、质量和时间，并使用 MoSCoW 优先级划分技术将项目需求分为四类：

• M必须要有
• S应该要有
• C可以要有
• W不要有

DSDM Atern 的八个支持性原则指导团队必须采取的态度和思维模式，以持续交付价值。

1. 聚焦业务需求
2. 按时交付
3. 协作
4. 绝不妥协质量
5. 从坚实的基础逐步构建
6. 迭代开发
7. 持续清晰的沟通
8. 展示控制力

极限编程（XP）

最初由肯特·贝克提出，极限编程（XP）已成为最受欢迎且最具争议的敏捷方法之一。XP 是一种有纪律的方法，用于快速且持续地交付高质量软件。它旨在提高软件质量，并增强对客户不断变化需求的响应能力。它提倡高度的客户参与、快速反馈周期、持续测试、持续规划以及紧密的团队协作，以非常频繁的间隔交付可工作的软件（通常每1至3周一次）。

该方法的名称来源于从传统软件工程实践中汲取有益元素并将其推向“极端”程度的理念。例如，代码审查被认为是一种有益的做法。在极端形式下，通过结对编程实践持续检查代码。

原始的XP框架基于四个核心价值观——简单性、沟通、反馈和勇气。

它还包括十二项支持性实践：

• 计划游戏
• 小型发布
• 客户验收测试
• 简单设计
• 结对编程
• 测试驱动开发
• 重构
• 持续集成
• 集体代码所有权
• 编码规范
• 隐喻
• 可持续开发

极限编程

特性驱动开发（FDD）

特性驱动开发（FDD）由杰夫·德卢卡于1997年在一家大型新加坡银行的软件开发项目中提出。它是一种迭代式和增量式的软件开发过程，也是构建软件的一种敏捷方法。FDD将许多广受认可的行业最佳实践整合成一个整体。这些实践从客户价值的角度出发——即特性。其主要目标是按时、反复交付可交付的、可工作的软件。使用FDD的一个关键优势是，由于“适度设计”（JEDI）的概念，它能够扩展到大型团队。由于其以特性为中心的流程，FDD是控制敏捷、增量且本质上复杂的项目的一种绝佳解决方案。它包含五个核心活动：

1. 建立整体模型
2. 构建特性列表
3. 按特性规划
4. 按特性设计
5. 按特性构建

特性驱动开发（FDD）

每个项目都有其独特的模型，该模型生成特性列表。最后三个活动是短期迭代，每个持续不超过两周。如果某项任务超过两周，则将其分解为更小的特性。

水晶

水晶方法由阿利斯泰尔·柯克本在20世纪90年代中期开发，是一系列方法（水晶家族）。这些方法源于柯克本多年的学习和团队访谈。柯克本的研究表明，他访谈的团队虽然没有遵循正式的方法论，但仍成功交付了项目。水晶家族是柯克本记录这些成功团队做法的方式。水晶方法主要关注：

• 人员
• 互动
• 社区
• 技能
• 天赋
• 沟通

敏捷宣言

“敏捷”这一术语是在2001年的《敏捷宣言》中提出的。该宣言旨在确立指导更优软件开发实践的原则。《敏捷宣言》包含四项核心价值观。阅读《敏捷宣言》并不意味着右侧的事项毫无价值——相反，敏捷更重视左侧的事项。

敏捷宣言

现在让我们来分析《敏捷宣言》的第一行。这一行指出，我们更重视人、他们的互动、沟通与协作，而非各种广泛的过程和工具。当然，过程和工具是有价值的，但当它们真正支持人们协同工作以交付高质量产品时，其价值会进一步提升。在许多组织中，我们常常看到过程和工具本身变成了目标。从敏捷的视角来看，我们有不同的看法。过程和工具应支持人们协同工作，为客户创造价值。

敏捷原则

作为《敏捷宣言》的补充，敏捷联盟还定义了一套12项原则，为宣言之外提供了指导和更详细的解释：

敏捷宣言原则

1. 我们最重要的目标是通过尽早且持续地交付有价值的软件来满足客户。
2. 欢迎需求变更，即使在开发后期也是如此。敏捷过程利用变更来为客户提供竞争优势。
3. 频繁交付可用的软件，从几周到几个月不等，且更倾向于较短的时间周期。
4. 业务人员和开发人员在整个项目期间必须每天协作。
5. 围绕有动力的个人构建项目。为他们提供所需的环境和支持，并信任他们完成任务。
6. 在开发团队内部及团队之间传递信息最有效的方法是面对面交流。
7. 可用的软件是衡量进展的主要标准。
8. 敏捷过程促进可持续发展。发起人、开发人员和用户应能够无限期地保持稳定的工作节奏。
9. 持续关注技术卓越与良好设计，有助于提升敏捷性。
10. 简洁——最大限度减少不必要的工作——至关重要。
11. 最佳的架构、需求和设计源自自组织团队。团队应定期反思如何提升效率，并据此调整自身行为。

总结

敏捷开发是软件开发行业中的一个流行术语——一种管理软件开发项目的替代方式。它并非特定的软件开发方法论，而是一系列基于《敏捷宣言》中所表达的价值观和原则的方法与实践的集合。解决方案通过自组织、跨职能团队之间的协作不断演进，利用适合其情境的实践。