敏捷方法的历史根源：“敏捷思维”从何而来？

### 敏捷方法的历史根源：“敏捷思维”从何而来？ #### 1. 引言 在过去的十五年里，敏捷方法的出现是软件过程思维中最显著的变化。然而，实际上许多“敏捷理念”早在 20 世纪 70 年代甚至更早便已存在。众多关于敏捷方法的研究和综述都将其出现归因于对传统方法的反应。但实际上，尽管敏捷方法作为一个整体是新事物，但其在软件工程的历史中有着深厚的根源。除了自 1957 年就开始使用的迭代和增量方法外，批评传统方法的人们所提出的替代方法实际上就是敏捷理念，例如对变化的响应、客户参与以及注重可工作的软件而非文档。 #### 2. 敏捷的含义 在实践中，对于“敏捷”一词的理解各不相同。而且，由于敏捷方法是一系列定义明确但实践有所差异的方法的统称，因此很难对其进行确切定义。不同的研究者从不同角度对敏捷方法进行了解释： - **哲学角度**： - Alistair Cockburn 认为：“敏捷意味着高效且灵活。敏捷过程既轻量级又足够有效。轻量级是为了保持灵活性，而有效性则是为了确保项目能够顺利进行。” - Barry Boehm 将敏捷方法描述为“快速原型和快速开发经验的产物，以及编程是一门手艺而非工业过程这一理念的复兴”。 - **基本实践角度**： - Craig Larman 指出：“由于具体实践各不相同，无法精确定义敏捷方法。但短周期迭代、对计划和目标进行适应性和渐进式改进是各种敏捷方法共有的基本实践。” - Barry Boehm 给出了更注重实践的定义：“一般来说，敏捷方法是非常轻量级的过程，采用短迭代周期；积极让用户参与需求的确定、优先级排序和验证；依靠团队内的隐性知识而非文档。” - **eWorkshop 角度**：在由实验软件工程中心（CeBASE）组织的敏捷方法电子研讨会上，参与者将敏捷方法定义为迭代、增量、自组织和涌现的。此外，他们还指出所有敏捷方法都遵循敏捷宣言的四个价值观和十二条原则。Barry Boehm 也提供了类似的定义，他认为真正的敏捷方法必须包含上述所有属性。 ##### 2.1 作者观点 作者认为，一个敏捷方法应具备以下特点： - **适应性**：敏捷方法欢迎技术和需求的变化，甚至愿意改变方法本身。它能够对之前工作的反馈做出响应。正如 Fowler 所说，适应性过程能够控制不确定性。 - **迭代和增量性**：软件通过多个迭代进行开发，每个迭代从规划到交付。在每个迭代中，系统的一部分被开发、测试和改进，同时新的部分也在开发中。随着每次发布，系统的功能逐渐增强。每次迭代后，都会向客户交付一个版本以获取反馈。 - **以人为本**：“人比任何过程都重要。优秀的人采用好的过程，其表现总是优于优秀的人没有过程的情况。”在敏捷方法中，人是项目成功的主要驱动力。因此，敏捷方法中过程的作用是支持开发团队确定处理工作的最佳方式。此外，敏捷方法强调团队内部以及与密切参与开发过程的客户进行面对面沟通，而非依赖书面文档。 综上所述，软件开发是一项具有不确定性的活动，因此需要一个适应性过程来控制这种不确定性。迭代和增量开发是控制这一过程的最佳方式，同时还需要富有创造力和才华的人员。 #### 3. 敏捷方法出现的背后原因 我们可以从以下三个方面来探讨敏捷方法出现的原因，并通过具体证据来分析哪些敏捷原则是新的，哪些是旧有的。 - **对传统方法和业务变化的反应** - **传统方法的局限性**：尽管迭代和增量方法早已存在，但许多资料仍推荐单阶段的软件开发生命周期，即瀑布模型。然而，研究人员认识到瀑布模型存在问题，并提出了如 V 模型、螺旋模型和 Rational 统一过程（RUP）等替代方法。但这些方法仍然是重量级、以文档和计划为驱动的方法。Fowler 认为这些方法是工程方法论，适用于建造桥梁，但不适用于软件开发，因为软件开发是一种不同类型的活动，需要不同的过程。敏捷方法正是对这些工程方法论官僚作风的回应。 - **业务环境的变化**：另一个推动敏捷方法出现的原因是业务环境的快速变化。Highsmith 和 Cockburn 指出，敏捷方法是从“反映当今动荡的业务和技术变化的视角”提出的。传统方法无法应对这种变化，因为它们假设在项目生命周期早期就能预见完整的需求集。但实际上，大多数需求和技术的变化都发生在项目的生命周期内。 - **复用历史理念** - **迭代和增量开发**：迭代和增量开发是敏捷方法的核心。早在 20 世纪 50 年代，NASA 和 IBM 联邦系统部门（FSD）就开始使用这种方法。例如，NASA 在 1961 - 1963 年的水星计划中采用了“半天短迭代”。同时，极限编程中的测试优先开发实践也得到应用，即先规划和编写测试，然后编写代码以通过测试。此外，每次小迭代都需要集成所有代码并通过测试，实现了持续集成。 - **替代方法的提出**： - **Non - Cyclical Hollywood 模型**：Gladden 在其论文“Stop the life - Cycle, I Want to get off”中提出了非循环好莱坞模型。该模型满足三个命题：系统目标比系统需求更重要，这符合敏捷理念中对系统有整体理解而非关注详细需求的观点；实物比书面规范传达更多信息，这体现了敏捷宣言中“可工作的软件胜过详尽的文档”的价值观；系统目标加上实物演示将产生成功的产品，即产品能实现预期功能并满足客户需求。Gladden 认为大多数用户对自己的需求并不明确，并且提出了需求缺失和变化的问题。 - **McCracken 和 Jackson 的建议**：他们在论文“Life Cycle Concept Considered Harmful”中提出了两种系统开发过程场景。一是原型法，建议在开发过程的早期构建原型，通过一系列原型或对第一个原型的修改逐步得到最终产品。这与敏捷开发中通过短迭代不断改进系统的方式一致。同时，他们建议与用户密切合作，“随着对用户自身环境和需求的了解逐步推进开发”。二是由最终用户和分析师按照“