多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix〕。设计过程充斥着短期的、即时的决定，而无完整的规划。 这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加 入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典 型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期 之感，从而对项目的完成产生严重的影响……
【软件工程新方法学】指的是近年来在软件开发领域中逐渐兴起的一种更为灵活和高效的方法论。传统的软件开发模式，特别是“边写边改”（code and fix）的方式，虽然适用于小型系统的开发，但在应对大型复杂系统时往往暴露出诸多问题，如不断增加的错误和难以调试的故障，以及漫长的测试阶段，严重影响项目的进度。
为了改善这种情况，人们尝试引入了“正规方法”或称“工程方法”，这些方法强调严格的规划和详细的规范，期望通过标准化流程提高可预测性和效率。然而，工程方法由于其繁琐的官僚性质，并未在业界获得广泛的成功，反而因为过多的文档和规则限制了灵活性。
【敏捷方法】正是对传统方法的回应，它强调轻量级、适应性和以人为本。不同于工程方法追求详尽的预先规划，敏捷方法注重迭代开发和快速响应变化。例如，极限编程（XP）是一种代表性的敏捷方法，它提倡频繁的代码发布、持续集成和客户需求的密切沟通，以确保开发过程能够快速适应变化。此外，还有Cockburn的水晶系列、开放源码项目中的敏捷实践、适应性软件开发（ASD）、SCRUM、功能驱动开发（FDD）、动态系统开发方法（DSDM）等不同形式的敏捷方法。
敏捷方法的核心理念包括：
1. **适应性**：敏捷方法不抵制变化，而是欢迎变化，并且设计出能够随着需求变化而调整的过程。这要求开发团队能够快速响应并适应新的需求和环境变化。
2. **以人为本**：敏捷方法强调开发人员的专业责任和团队协作，认为开发过程应当以人为主导，而非被过程所束缚。团队成员的技能和创造力是项目成功的关键，因此管理过程应更多地关注于支持和激发团队潜力。
3. **迭代和增量开发**：敏捷方法通过短周期的迭代来实现软件的构建，每个迭代都包含设计、编码、测试和评审，从而能够在早期发现问题并及时调整。
4. **简洁文档**：敏捷方法不推崇过度文档化，认为源代码是最重要的文档。尽管文档仍然重要，但只创建必要的文档以支持团队之间的沟通和系统的理解。
5. **客户参与**：敏捷方法鼓励客户的持续参与，以便及时反馈需求变化，确保开发方向与实际需求保持一致。
在决定是否采用敏捷方法时，开发者和管理者需要考虑团队的文化、项目特性、客户关系以及对变化的容忍度等因素。敏捷方法并非适用于所有情况，但其灵活性和适应性使其在快速变化的软件开发环境中展现出巨大价值。
值得注意的是，像统一过程（RUP）这样的框架也可以通过调整来实现一定的敏捷性，这表明敏捷不仅仅是一个独立的方法学，而是一种可以融入多种软件开发框架中的核心原则。通过理解和应用这些原则，开发者可以创建出更有效、更适应现实世界挑战的软件产品。
