软件开发方法

创建软件并不是一件简单的事情：通常，开发应用程序需要不同技能的团队协同努力。如果没有战略管理，这种复杂性很快就会陷入混乱。因此，实施结构化开发方法对于高效完成任何软件项目至关重要。

软件开发中有多种流行的方法论，它们都具有吸引人的特点。我们将讨论六种最常用的软件开发方法。

虽然这些方法有很大不同，但它们都很受欢迎。

瀑布方法

瀑布方法是我们将讨论的最传统的开发方法，包括一系列连续执行的阶段。从概念化到构建、实施和维护，每个阶段都流向下一个阶段（因而得此名称）。

该过程由有序进展定义：一旦一个阶段完成，通常不鼓励重复修改。虽然一些团队喜欢既定轨迹的清晰性和一致性，但批评者认为这种方法僵化，且不切实际。

事实上，瀑布式流程适用于具有明确和不变要求的简单项目，而不是涉及许多支点和潜在陷阱的工作。 ‍

优势

• 规划清晰：通过为每个项目预先确定的轨迹，经理和团队成员可以在每个阶段规划他们的贡献。
• 交错执行的机会：如果您的团队同时处理多个项目，瀑布方法可能允许不同的团队成员，在不同阶段专注于单独的项目。
• 所有利益相关者的简单性：因为瀑布方法相对简单，所以很容易传达给团队成员、经理和客户。您不需要丰富的开发经验就可以理解项目所在的位置。
  

敏捷法

敏捷最好被理解为一种思维方式，而不是一种单一的软件开发方法。事实上，许多其他方法都受到敏捷哲学的启发，敏捷哲学是作为对瀑布模型的明确对立，而发展起来的。

从本质上讲，敏捷方法要求开发人员优先考虑迭代改进，而不是谨慎的爬行启动。最初的目标是生成“最小可行产品”，并根据有关用户需求和偏好的不断变化的信息不断改进它。

在敏捷模型中，软件开发团队通常会确定一个问题或优先事项，在有时间限制的“冲刺”中协同工作，以实现解决方案，然后继续迎接下一个挑战。

与瀑布式方法相比，团队的开发过程没有缓慢的、固定的进展。该团队灵活地处理增强和变化，响应新出现的需求。

优势

• 对变化的响应：如果用户需要决定新的优先级或内部方向发生变化，使用敏捷方法的团队可以相应地进行调整。
• 支持战略优先级排序：当整个团队专注于一个优先事项时，将会在重要领域产生结果。不再将团队分散得太细，让紧急需求得不到解决。
• 流程不会阻碍生产力：开发人员喜欢解决问题，但严格的流程要求会阻止他们这样做。敏捷方法旨在阻止官僚主义，让团队做最擅长的事情。

敏捷软件开发原则

敏捷软件开发有十二个原则：

• 更快地，持续地交付有价值的软件，提高客户满意度。
• 欢迎不断变化的需求，即使是在后期开发中。
• 频繁交付工作软件（数周而不是数月）
• 业务人员和开发人员之间密切、日常的合作
• 项目是围绕积极的个人建立的，他们应该被信任
• 面对面交谈是最好的交流方式（共址）
• 工作软件是进度的主要衡量标准
• 可持续发展，能够保持恒定的步伐
• 持续关注卓越的技术和良好的设计
• 简单性是必不可少的
• 最佳架构、需求和设计来自组织团队
• 团队定期反思如何提高效率，并做出相应调整

激进（Scrum）

如果敏捷方法是一个广义的概念导向，那么Scrum可以理解为它的具体应用。使用 Scrum 框架，团队将软件项目分解为要完成的特定工作增量。然后，这些目标在有时间限制（通常为 2 到 4 周）内完成，在此期间，团队成员将注意力集中在手头的特定挑战上。

在这些冲刺之后，团队和主要利益相关者审查进展，注意到必要的改进和关键学习。 Scrum 团队然后转移到另一个冲刺，这可能与他们的最后一个冲刺直接相关，也可能不相关。

Scrum 方法需要纪律，因为它鼓励您的团队始终专注于给定的工作。一些专业人士喜欢这种不受干扰的自由；其他人更喜欢在优先级之间切换的能力。

优势

• 全神贯注：通过将团队的精力集中在设定的时间段内，Scrum 方法将开发人员从对时间的外围需求中解放出来。
• 协作友情：Scrum 团队不断地沉浸在共同的优先事项中。因此，他们在追求共同目标时，相互帮助和依赖。 ‍
• 频繁的反馈：因为每个特定工作，都以建设性的审查结束，所以 Scrum 团队不断地适应利益相关者的需求。如果发生需求变化或沟通不畅，很快就会发现。

极限编程

极限编程是敏捷方法的另一个分支，它强调限时循环中的迭代开发。然而，与 Scrum 框架相比，极限编程对软件开发实践提出了更具体的建议，包括编写和审查代码的方式。

极限编程的精神和名称反映了这种方法论强调在“极端”程度上实现广泛接受的价值观。对于接受其规则的程序员来说，极限编程似乎是合理开发原则的典范。

例如，基于频繁的代码审查，限制错误影响，极限编程建议团队成对编码，以在错误发生时捕捉错误。同样，基于频繁测试使代码与客户需求保持一致的想法，极限编程要求开发人员在编写代码以后，进行测试之前，设计测试。

这个过程是多方面的，而且非常微妙，所以在选择这种方法之前，你应该考虑做大量的研究。

优势

• 综合指南：极限编程提供如何进行编程的详细指南。对于一些团队来说，这是非常有建设性的。
• 强调持续改进：极限编程的核心原则之一是，承诺定期更新代码。随着小的改进不断发生，每个人都可以从最新版本开始工作，团队可以从持续进步中获得鼓励。
• 提高团队参与度：与某些方法不同，极限编程有明确的说明，可以与其他团队成员合作并促进反馈。软件开发过程的这些元素与工作的技术方面一样重要。

精益

精益方法是敏捷方法的另一个产物，旨在减少软件开发过程各个阶段的浪费。常见的浪费来源包括不必要的功能和臃肿的代码、错误的沟通和重复的工作、模糊表达的需求以及破坏后续进展的质量问题。

为了应对这些常见挑战，使用精益方法的团队经常使用极限编程中的一些相同技术，包括对编程和测试驱动开发。它还强调持续改进和快速交付可行的产品。

但是精益方法包括它自己的概念，例如随着项目的推进，推迟重大决策，以保持团队的选择开放。另一个关键组成部分是尊重开发人员的自主权。精益方法领导者不是强迫他们的团队遵循自上而下的指令，而是允许开发人员创建自己的解决方案。

优势

• 强调效率：精益方法将每个人的注意力转向精简核心流程。在开发团队中，这种精神可以成为强大的促进剂。
• 向前迈进的灵活性：精益团队从一开始就不会承诺对他们的项目有一个坚定的愿景。相反，他们将备选方案摆在桌面上，直到必须做出决定。在不断变化或不确定的环境中，这种适应性对团队成员和利益相关者都非常有价值。
• 尊重团队：开发人员可以做的不仅仅是执行他人的指令。精益方法认为他们的洞察力至关重要，并赋予他们独立解决问题的能力。

看板

看板方法是一种用于组织和执行软件开发任务的系统，可以独立使用，也可以与我们已经讨论过的方法结合使用。看板是一种可视化识别和解决出现的瓶颈的方法，改编自最初用于汽车制造的工作流管理系统。

这种方法的关键元素是看板，它由表示给定目标生命周期中，不同阶段的列组成，例如“编码”、“代码审查”和“代码修订”。

当团队成员完成一个阶段时，他们会将目标移到下一列。此可视化突出显示工作流程中的中断并促进调整。事实上，当指定数量的目标被卡在一个列中时，团队必须集中解决这些问题。

优势

• 共享的进步参考点：无论是物理的，还是数字的，看板让每个人都对团队的努力保持一致。
• 公平分配：如果团队的工作量分布不均，看板会清楚地说明这个问题。此外，团队成员可能会改变他们的工作重点来帮助他们负担过重的团队成员。
• 可访问视觉处理器：许多程序员和其他创意人员都是以视觉为导向的思想家。看板以电子表格或口头更新可能无法满足的方式满足他们的需求。

迭代

迭代开发方法是一种将大型应用程序的软件开发分解为更小的块的方法。在迭代开发中，特征代码是在重复循环中设计、开发和测试的。在每次迭代中，都可以设计、开发和测试附加功能，直到有一个功能齐全的软件应用程序准备好部署给客户。

通常，迭代开发与增量开发结合使用，在增量开发中，较长的软件开发周期被拆分为相互构建的较小部分。

迭代和增量开发是敏捷开发方法中的关键实践。在敏捷方法中，较短的开发周期，称为迭代或冲刺，是有时间限制的（限于一定的时间增量，例如两周）。在迭代结束时，预计可以为客户演示工作代码。

迭代开发与传统的瀑布方法形成对比，在传统的瀑布方法中，软件开发生命周期的每个阶段都是“门控”的。在整个软件应用程序的设计完成并通过阶段门审查之前，不会开始编码。同样，在编码完成并通过必要的阶段门审查之前，测试不会开始。

迭代工作的目的是为更改提供更大的灵活性。当主要应用程序的需求和设计以传统方法（有时称为 BDUF 或 Big Design Up Front）完成时，可能会出现无法预料的问题，直到开发开始。通过迭代工作，项目团队会经历一个循环，他们对每次迭代进行评估，并确定需要进行哪些更改才能产生令人满意的最终产品。

增量模型

在增量模型中，整个需求分为不同的构建。多个开发周期在这里发生，使生命周期成为“多瀑布”循环。周期被分成更小、更容易管理的模块。增量模型是一种软件开发模型，如 V 模型、敏捷模型等。

在这个模型中，每个模块都经历了需求、设计、实现和测试阶段。软件的工作版本是在第一个模块期间生成的，因此您在软件生命周期的早期就有了工作软件。该模块的每个后续版本都会向先前版本添加功能。该过程一直持续到实现完整的系统。

然后，他开始构建它，在第一次迭代中，应用程序或产品的第一个模块完全准备就绪，可以向客户演示。

同样，在第二次迭代中，另一个模块已准备就绪并与第一个模块集成。同样，在第三次迭代中，整个产品已准备就绪并已集成。因此，产品一步一步准备就绪。

增量模型的缺点：

• 需要良好的规划和设计。
• 需要对整个系统进行清晰完整的定义，然后才能对其进行分解和增量构建。
• 总成本高于瀑布。
• 何时使用增量模型：

当完整系统的需求被明确定义和理解时，可以使用该模型。