软件开发方法论

你好。在最后两次采访中，我被问及方法论。这不是最重要或最困难的问题，但最好有一个答案的备忘单。在这篇文章中，我将尝试给出什么是开发方法论的概念，并比较我亲自遇到或被问到的那些方法论。 软件开发方法论是描述如何开发特定产品的过程，即组织团队开发的方法之一。这样一个过程有很多不同的模型，每种模型都描述了自己的方法，并且不能说其中有一个需要在每个项目中使用，一切都纯粹是情境性的。我建议更详细地考虑其中三个。

瀑布

瀑布（级联、瀑布）是最古老的方法之一，意味着所有阶段严格按顺序执行，每个阶段必须在下一个阶段开始之前完成。也就是说，进入下一阶段意味着上一阶段工作的全面完成。如图所示，首先我们分析任务（记录任务，讨论难点），然后进行设计（此阶段项目结构形成），然后编码和测试。后续阶段不予退款。建议在小型项目中使用这样的系统，因为这些项目的需求是预先知道的，并且它们改变的可能性很小。 优点：

• 每个阶段的完整且一致的文档；
• 使用方便;
• 稳定的要求。
• 预算和期限已预先确定

缺陷：

• 大量的文档；
• 不是一个非常灵活的系统；
• 客户无法查看产品的演示版；
• 没有办法后退一步。

Scrum

Scrum 是一个基于将整个过程划分为迭代的软件开发系统，在每个迭代结束时，团队准备提供产品的演示版本。该图显示团队并行地经历了开发的所有阶段，这使我们能够在每次迭代结束时完成项目的一部分。 我将尝试用简单的语言简要解释该方法论的本质，但这里有很多术语。我认为最重要的是理解本质，术语随着经验就会记住。所有开发都分为多个冲刺（通常为 2-3 周）。整个开发周期和每个冲刺都有一个待办事项列表（任务列表）。每个任务都有自己的故事点（难度等级）。该过程中的每个参与者都有一个角色：

• Scrum 团队是一个致力于项目的团队（开发人员、测试人员、设计人员）。
• Scrum Master 是确保 Scrum 原则得到遵守的人。
• 产品所有者——客户。

由于这个系统强调的是沟通，所以有大量的集会：

• 站立会议是一个简短的会议，每天举行，所有团队成员都参加，每个参与者回答 3 个问题：你做了什么？它会做什么？阻碍因素是什么？
• 规划——在冲刺开始时举行，在这次会议上确定下一个冲刺应完成哪些任务。
• 回顾是在冲刺结束时进行的，其本质是找出哪些方面做得好，哪些方面可以改进。

优点：

• 客户可以在开发过程中观察结果。
• 对开发过程的日常控制。
• 能够在开发过程中进行调整。
• 与所有团队成员建立良好的沟通。
• 少量文档。

缺陷：

• 难以估计开发所需的劳动力和成本
• 在开发开始之前很难确定最大的瓶颈。
• 需要让每个人都参与其他团队成员的发展。

看板

看板是一个基于可视化完成团队任务的过程而构建的系统。该系统的主要思想是减少当前正在进行的任务数量（在“进行中”栏中）。在 Scrum 中，团队专注于成功完成冲刺；在看板中，任务是第一位的。适合处于支持阶段的项目，该阶段的主要功能已经开发完毕，并且仍保留很少的改进和错误修复。在看板中，任务是单独提交的。无论其他任务如何，该任务都会经历板上的所有阶段，一旦完成就可以向客户展示。看板由多个列组成，每个列代表一个单独的开发过程。某些列（例如，正在进行中）对可以存在的任务数量施加限制。这有助于轻松快速地找到任务分配中的问题区域。图片显示了这种简单板的示例。列数和名称可能有所不同，但我将列出最常见的：

• 待办事项 - 需要完成的任务列表
• 进行中 – 当前正在处理的任务
• 代码审查——已完成并送审的任务
• 测试中 – 准备测试的任务
• 完成——已完成的任务。

优点：

• 使用方便。
• 可视化（有助于发现瓶颈，简化理解）
• 团队对流程本身的高度参与。
• 开发灵活性高。

缺陷：

• 任务列表不稳定。
• 难以用于长期项目。
• 没有严格的最后期限。

关于软件开发方法的总结

在我看来，担任管理职位或渴望担任管理职位的人需要对软件开发方法有透彻的了解，但建议每个人至少了解基础知识。这是开发过程中不可或缺的一部分，不仅用于 IT 领域。感谢您花时间阅读我的文章，希望您觉得它有所帮助。我试图尽可能清晰、简短地描述要点，因此本文并不详尽。我很高兴听到您对此的看法并回答您的问题。一切顺利！