顺序开发与敏捷开发

本章及下一章简介
《敏捷到底有何不同？》和《应对复杂性与不确定性的挑战》这两章介绍了敏捷软件开发的基础概念，这些内容在课程后续章节中被频繁引用。如果你跳到后面的章节，请记住，那些讨论都建立在本章和下一章所提出的思想基础之上。

如果你想先从整体视角了解课程内容，可以跳转至《结语》章节，阅读《享受你的劳动成果》和《核心原则总结》。

大多数以“敏捷到底有何不同？”为标题的敏捷课程，会立即深入探讨2001年发布的敏捷宣言及其相关的20年前的敏捷原则。
这些文件在20年前确实发挥了重要作用，但自那以后，敏捷实践持续演进，而这两份历史文献已无法准确反映当今敏捷最具价值的核心内涵。

那么，如今的敏捷究竟有何不同？
敏捷运动早期主要与瀑布式开发形成对比。当时宣称，瀑布式开发试图在项目初期完成100%的规划、100%的需求分析、100%的设计工作等等。这种描述虽然准确反映了字面意义上的“瀑布式”开发，但其实质上并非广泛存在的开发模式。各种形式的“分阶段开发”才是普遍现象。

真正意义上的瀑布式开发主要存在于早期美国国防部的项目中，而当敏捷宣言发布时，这类原始实现早已被更成熟的生命周期模型所取代。

顺序开发与敏捷开发之间的核心差异

如今，与敏捷开发最具意义的对比对象是顺序开发。尽管存在一些误解，但两者的主要区别如下表所示：

以下是各项差异的进一步说明：

• 短周期发布 vs. 长周期发布：采用敏捷实践的团队以天或周为单位交付可用的软件；而采用顺序开发的团队则以月或季度为单位衡量开发周期。

• 小批次完成端到端开发工作 vs. 大批次集中处理：敏捷开发强调以小批量方式完成完整开发流程——包括详细需求、设计、编码、测试和文档等，每次只推进少量功能或需求。顺序开发则倾向于将整个项目的全部需求、设计、编码和测试一次性大规模推进。

• 按需即时规划 vs. 事前详细规划：敏捷开发通常仅做少量事前规划，大部分细节规划留待实际需要时再进行。优秀的顺序开发也强调按需规划，但诸如挣值管理等顺序开发方法更加强调事前详尽规划。

• 按需即时需求分析 vs. 事前完成需求分析：敏捷开发尽量减少事前的需求工作（侧重广度而非深度），并将绝大多数详细需求分析推迟到项目启动后才进行。顺序开发则倾向于在项目初期就定义好所有需求细节。

  在需求管理方面，现代敏捷实践已经超越了2000年代初对敏捷的理解。相关内容将在《更有效的敏捷需求创建》和《更有效的敏捷需求优先级排序》两章中深入探讨。

• 演进式设计 vs. 事前设计：如同规划和需求分析一样，敏捷开发将详细设计工作推迟到真正需要时才展开，对事前架构设计的投入较少。顺序开发则更强调在前期构建更高程度的详细设计。

  承认某些事前设计与架构工作的价值，正是现代敏捷在理念上超越2000年代初期敏捷哲学的重要体现之一。

• 持续自动化测试并融入开发流程 vs. 开发结束后单独测试：敏捷开发强调测试与编码同步进行，有时甚至在编码之前完成。测试由包含开发人员和测试专家的集成团队共同执行。顺序开发则将测试视为与开发分离的独立活动，通常发生在开发完成后。敏捷开发特别重视测试自动化，以便让更多人更频繁地运行测试。

• 频繁结构化协作 vs. 不频繁结构化协作：敏捷开发强调频繁且有结构的协作。这些协作往往时间短（如每日站会仅15分钟），但已被系统地融入敏捷工作的日常节奏中。顺序开发并非禁止协作，但并不特别鼓励此类互动。

• 基于实证、响应迅速、注重改进 vs. 理想化、预先安排、强调控制：敏捷团队强调实证方法，关注从真实世界经验中学习。顺序团队也尝试从经验中学习，但更倾向于制定计划并强加秩序于现实，而不是观察现实并持续适应变化。

敏捷开发与顺序开发的共通之处

对敏捷与顺序开发的比较，常常陷入“好的敏捷 vs. 差的顺序”或反之的误区。这种对比既不公平也不具参考价值。无论采用哪种方法，成功的项目都依赖于良好的管理、高水平的客户协作，以及高质量的需求、设计、编码和测试工作。

优秀的顺序开发同样可以取得良好效果。然而，如果你仔细研究上述表格中的差异，并结合自身项目经验进行反思，就会发现为何在许多场景下，敏捷开发比顺序开发更具优势。