每个企业都应根据自己的优先事项和发展项目决定组织公司内部的工作流程。我的目标是告诉您现有的方法类型以及您可以获得的结果。我收集了不同案例和不同公司使用的最着名的软件开发方法。他们都有自己的优点和缺点。但看板没有列入这个名单，因为我已经写了很多有关它之前。

以下是前6种方法的列表：

1. 敏捷

2. 瀑布

3. Scrum

4. 极限编程

5. 快速应用程序开发方法

6. 螺旋

敏捷

敏捷软件开发是承担软件工程项目的概念框架。有许多像Scrum这样的敏捷软件开发方法论（我们将在本文中更多地介绍它），Crystal方法和动态系统开发模型。

敏捷方法的主要目标是通过在短时间内开发软件来降低风险，称为迭代，通常会持续一到四周。每个时间盒就像一个迷你软件项目，包括发布新增功能的所有必要任务：

• 规划，

• 需求分析，

• 设计，

• 编码，

• 测试和

• 文档。

迭代可能不会增加足够的功能来保证发布产品，但是敏捷软件项目打算在每次迭代结束时发布新软件。在此迭代之后，团队重新评估项目优先级。敏捷方法强调工作产品是进度的主要衡量标准。相对于其他方法，敏捷产生很少的书面文档 – “实时”是更好的通信类型。大部分开发团队成员（以及企业主）都位于附近，可以面对面沟通。

敏捷软件开发方法学的主要原则：面对面会议，持续合作，早期和持续交付工作软件，透明度。每当客户端或内部发生意外或频繁的变化时，该模型就成为经理和团队领导者的最佳选择。

优点

• 自适应方法对变化做出有利的回应

• 允许直接沟通以保持透明度

• 通过快速查找和修复缺陷并提前识别期望不匹配来提高质量

缺点

• 专注于使用软件并缺乏文档效率

• 结果不一致的机会不明确

瀑布

瀑布模型是一种循序渐进的开发方法，其中开发被视为通过几个阶段稳步向下（如瀑布），通常：

• 分析

• 软件需求说明软件设计

• 软件设计

• 测试

• 整合（如果有多个子系统）

• 部署（或安装）

• 维护

该方法的线性和刚性特性使其易于理解和管理。所以对于经验不足的经理和团队来说，这是理想之选 在这种方法中，完成了不同的目标。在进入下一个阶段之前，每个阶段必须完成100％，不要回头修改项目或方向。从理论上讲，这个过程导致项目按时交付，因为每个阶段都有详细的计划。它可以用于目标明确，需求稳定的项目。

但在实践中，瀑布式开发通常不能达到预期，因为它不包含大多数项目所必需的不可避免的变化和修订。当一个应用程序正处于测试阶段时，很难回头去改变在概念阶段没有想到的东西。

重点是一次性规划，时间安排，目标日期，预算和整个系统的实施。在开始下一阶段之前，通过大量书面文件，正式评审以及用户的批准/签收和大多数阶段结束时发生的信息技术管理，在项目的整个生命周期内保持严密的控制。书面文件是每个阶段的明确可交付成果。

尽管缺乏灵活性和过时的想法，但这种方法旨在摆脱不必要的文书工作，耗时的定期会议和积压。因此，对于预先了解开发的所有方面的小型项目而言，这是一个很好的选择，对于复杂项目来说这是一个不好的解决方案，因为它非常不灵活。

在您有明确要求和解决方案的情况下，您不需要定义流程来开发最终产品。您只需在完成项目时设定截止日期，并以您自己的方式完成项目。

优点

• 易于理解和功能

• 简单到足以处理模型是僵化的

• 节省大量的时间

• 允许简单的测试和分析

• 它允许部门化和管理控制

缺点

• 只匹配精确的需求

• 不适用于维护项目

• 不允许在测试阶段进行编辑

• 无法知道项目的可能结果

• 对于长期和正在进行的项目来说不是很好

Scrum

Scrum是一个用于管理产品开发的迭代式和增量式敏捷软件开发框架。它定义了一个灵活的整体产品开发策略，开发团队作为一个单元实现共同目标。这种方法使团队能够通过鼓励所有团队成员的实际共同定位或紧密的在线协作以及所有团队成员和所涉及的学科之间的日常面对面交流来自我组织。

Scrum的一个关键原则是双重认识，即客户会改变他们想要或需要的东西（需求波动）并且会改变他们的想法。Scrum采用基于证据的经验方法 – 接受事先不能充分理解或定义的问题，而是集中关注如何最大限度地提高团队的快速交付能力，响应新兴需求，并适应不断发展的技术和变化在市场条件下。

Scrum的主要特点：

• 积极进行优先工作

• 完成一系列短迭代或冲刺中的固定积压项目

• 一个简短的每日会议（“scrum”）来解释进展情况，描述即将开展的工作和可能的障碍

• 一个简短的计划会话，其中将定义sprint的积压项目

• 当所有团队成员反思过去的冲刺时，一个简短的心跳回顾

Scrum由Scrum master提供，它的主要工作是消除阻碍团队实现冲刺目标的能力。Scrum的主人并不是团队的领导者（因为他们是自组织的），而是团队与任何不稳定影响之间的生产力缓冲区。

该方法鼓励所有团队成员以及项目涉及的所有学科进行口头交流。

与看板不同，Scrum更具时间框架和计划性。整个项目被分成称为Sprints的时间框，并且所有团队坐在一起并为每个Sprint计划需要完成的任务列表或用户故事列表。一旦团队同意并承诺在给定的时间框架内完成某些任务，开发团队应该坚持承诺并完成Sprint中的所有任务。

如果延迟成本很高，最后期限应尽可能延迟，Scrum最适合。当最终产品不清楚或者需求没有得到客户的正确反馈时，经常会使用Scrum。在这里，客户参与整个过程，确定并关注需要完成的某些sprint产品待办事项（与团队一起）。Scrum取代了灵活的方法论，适合长期发展，并且频繁更改需求。换句话说，它适用于需要300多个小时的开发项目。

与瀑布不同的是，Scrum模型采用更灵活的规则，可以适应最后时刻的变化。团队合作，检查和透明度是Scrum方法的关键因素。

结构：

• 产品积压（一组允许尽快建立MVP的最高优先级任务）

• 冲刺积压（包含开发人员将在2-4周后处理的高优先级功能）

• 冲刺本身

这种增长方法用于快速开发软件，其中包括一系列迭代以生成所需软件。它使有意推进的项目步入正轨。

优点

• 决策权掌握在团队的手中

• 业务需求文档被认为是不重要的

• 轻轻控制的方法empathizing与不断更新

缺点

• 处理方法因成本波动而受损

• 不适合大型项目

• 需要高度专业的团队，这对新手来说没有任何地方

极限编程

极限编程方法（XP）指的是敏捷软件工程方法论。它是为了避免开发目前不需要的功能而创建的。它旨在创造一流的最终产品，而不考虑需求的频繁变化。这种方法的另一个目的是降低软件必需品的成本。为了实现这一点，应用持续测试和计划。

与其他方法相比，XP需要更多时间和人力资源。至于XP主要用于在非常不平衡的环境中制作软件，并在建模过程中提供更好的易用性，这对于复杂的项目来说是完美的。如果您的客户有最后期限来交付产品，但没有清楚地了解其工作方式，并且风险更高，那么这是最佳选择。XP技术的设立是为了解决和缓解风险并提高成功的可能性。

与瀑布方法不同的是，系统的需求被确定并且通常被“冻结”，XP意味着在项目后期阶段改变需求的成本可能非常高。

极限编程核心实践：

精细的反馈

• TDD（测试驱动开发）

• 计划游戏

• 整个团队

• 配对编程

连续的过程而不是批次

• 持续集成

• 设计改进

• 小版本

共同理解

• 简单的设计

• 系统隐喻

• 集体代码所有权

• 编码标准或编码惯例

程序员福利

• 可持续的步伐（即每周四十小时）

XP团队应该在现场设立一个客户，为团队指定工作的优先次序，以及谁可以在问题出现时立即回答问题。

简单的代码更有可能工作。因此，极端的程序员只能编写代码来满足当前项目中的实际需求。为了回顾XP程序员编写的代码，共享一个屏幕和键盘（这也改善了通信），以便在编写代码时对所有代码进行审阅。

在极限编程中，测试是在编写代码之前编写的。代码在通过测试时被认为是完整的（但是之后需要重构以消除复杂性）。尽管人们认为XP只能在少于12人的小团队中工作，但它已被成功应用于超过一百名开发人员的团队。

优点

• 它着重于客户参与

• 制定合理的计划和时间表

• 开发人员特别致力于该项目

• 配备高质量软件的现代化方法

缺点

• 有效性取决于涉及的人员

• 需要频繁召开会议以提高总成本

• 需要过度的发展变化

• 确切的可能性和未来的结果真的是未知的

螺旋

螺旋方法扩展了瀑布模型，增加了快速原型，以结合自上而下和自下而上的概念。它在重点领域重点考虑迭代风险分析。它适合于大型复杂系统。对于大型，昂贵和复杂的项目，螺旋通常选择瀑布方法。

螺旋生命周期模型是一个复杂的生命周期模型，重点在于及早识别和减少项目风险。一个螺旋型项目从小规模开始，探索风险，制定一个处理风险的计划，然后决定是否采取下一步的项目（做下一轮迭代）。它源于不断降低项目风险水平带来的快速发展收益。成功使用螺旋生命周期模型取决于认真，细心和知识渊博的管理。

您可以在螺旋模型中找到以下步骤：

• 新的系统要求详细定义

• 初步设计创建

• 初步设计构建了新系统的第一个原型

• 第二个原型使用四个步骤演变： – 第一个原型的评估; – 确定第二个原型的要求; – 计划和设计第二个原型; – 构建并测试第二个原型

• 如果风险很大，项目可能会中止。风险因素可能涉及开发成本超支

• 现有原型的评估方式与之前的原型相同，如果需要，还可以从中开发另一个原型

• 重复前面的步骤直到客户满意

• 最终系统的构建（基于精制原型）

• 最终的系统经过彻底的评估和测试

• 日常维护是持续进行的，以防止大规模故障并最大限度地减少停机时间

重点在于风险评估以及通过将项目分解成更小的部分并在开发过程中提供更多的易变性来降低项目风险。开发者打算制定一个迭代螺旋的计划。每个周期都涉及产品各个部分的相同步骤以及每个层次的细化。任何螺旋生命周期模型的完成都基于对项目的一致，细致和熟悉的管理。

优点

• 风险因素大大减少

• 非常适合大型和复杂的项目

• 稍后允许其他功能

• 适用于各种业务需求的高风险项目

缺点

• 昂贵的软件开发模式

• 风险分析阶段失败可能会损害整个项目

• 不适合低风险项目

• 可能会继续，永远不会完成