敏捷开发方法论——敏捷

敏捷模型

灵活（敏捷）方法通过将工作流移动到几个小周期中来帮助降低软件开发的风险。这些周期称为迭代，通常持续两到三周。

迭代就像一个由任务组成的小型软件项目，每个任务都会改进功能。其中包括：制定计划、评估需求、就项目达成一致、编写代码、测试和创建技术文档。

对于一个完整的软件版本来说，一次迭代通常是不够的。然而，敏捷的好处是项目的一小部分在每次迭代结束时都准备好进行评估。这允许团队成员更改优先级以进行进一步的工作，而无需等待最终版本。

应用“敏捷”开发方法，您可以在每次迭代后看到具体的结果。即开发者可以了解自己的工作结果是否满足要求。这是灵活模式的重要优势之一。

至于缺点，在使用敏捷时，有时很难估计劳动力资源成本和项目预算。如果我们选择灵活模型的实际应用，那么其中最著名的就是极限编程（XP）。

XP 基于每天举行的团队成员简短会议和定期会议（每周一次或更少）。在每日集会（每日站会）中，通常会讨论：

• 目前的工作成果；
• 每个团队成员要完成的任务列表；
• 遇到的困难和解决的办法。

宣言

敏捷是开发的一个整体方向，因此它的工作规则在一个特殊的文件中声明 - 敏捷宣言。这包括团队工作应遵循的实践和原则。

敏捷宣言包含 4 个基本思想和 12 个原则。

关键思想：

• 开发人员之间的协作比工具更重要；
• 产品的工作版本优先于文档；
• 团队与客户之间的相互理解比合同条款更重要；
• 如有必要，可以随时更改原始计划。

至于敏捷的 12 条原则，它们是：

• 主要优先事项是完成的程序符合客户的期望；
• 允许在任何阶段改变条件，即使是在开发的最后阶段（如果这可以提高软件的质量和竞争力）；
• 定期交付软件产品的工作版本（每 14 天、每月或每季度一次）；
• 成功的关键是客户和开发人员之间的定期互动（最好是每天）；
• 项目应该建立在对项目感兴趣的人中间，应该为这些人提供必要的工作条件和各种支持；
• 在团队中共享信息的最佳方式是个人会议；
• 软件的工作版本是进度的最佳指示器；
• 所有利益相关者必须能够在整个软件开发过程中保持预期的工作节奏；
• 技术改进和良好的设计提高了灵活性；
• 保持简单而不是过度创造很重要；
• 最好的结果来自那些能够自组织的团队；
• 团队成员应该定期思考如何通过改变工作流程来提高效率。

根据敏捷宣言，一个好的软件开发过程直接取决于参与这个过程的人。为此，您需要尽可能有效地组织他们的互动，创建最有条理的团队。

方法论

敏捷宣言中也有几个方法论解释了价值观和原则：

• 敏捷建模；
• 敏捷统一过程；
• 敏捷数据方法
• 快速应用程序开发（DSDM）；
• 必要的统一过程；
• 极限编程；
• 功能驱动开发；
• 变得真实；
• 打开;
• 敏捷。

敏捷建模是一组原则、术语和实践，可以加速和简化软件模型和文档的开发。

敏捷建模的目标是改进建模和文档。请务必注意，这不包括编码、测试或与项目控制、部署和支持相关的问题。但是，此方法包括代码审查。

Agile Unified Process 是一种让用户很容易去近似（模型）的方法论。通常用于开发商业软件。

敏捷数据方法——几种类似的方法，其中客户条件是通过几个团队的合作来实现的。

DSDM - 这种方法与其他方法的不同之处在于，未来产品的用户与开发人员一起积极参与其中。

特性驱动开发是一种有时间限制的开发方法：“每个特性的实现时间不得超过两周。”

值得考虑的是，如果用例很小，它可以被认为是一个特性。如果它很重要，那么它必须分为几个功能。

Getting Real 是一种迭代方法，首先开发程序界面，然后才开发其功能。

OpenUP是一种将项目周期分为四个阶段的开发方法：开始、细化、构建和移交。

根据敏捷的原则，无论工作持续时间长短，都需要为所有利益相关者和团队成员提供一种认识和决策的方式。因此，可以有效地控制情况并及时评估中间结果。项目计划定义了生命周期，最终结果应该被认为是应用程序的稳定发布。

至于 Scrum，它规定了管理开发过程的规则，并允许您应用现有的编码实践，并有可能调整条件或进行更改。使用这种方法，您可以在开发的早期阶段看到并消除与预期结果的偏差。

让我们更详细地看一下这个......