敏捷开发方法的历史根源与极限编程实践探索

### 敏捷开发方法的历史根源与极限编程实践探索 #### 敏捷方法的起源故事 敏捷宣言作者之一阿利斯泰尔·科伯恩（Alistair Cockburn）在 1991 年，受 IBM 咨询集团委托，为对象技术项目编写方法论。他通过采访项目团队发现，实际项目情况与方法论书籍中描述的不同。他指出“密切沟通、团队士气以及与最终用户的接触，是区分成功项目和失败项目的关键因素”。科伯恩将这些理念应用于一个价值 1500 万美元、固定价格和范围、有 45 人参与的项目，并基于项目访谈和实践经验，构建了敏捷方法 Crystal。有趣的是，与大多数敏捷宣言作者不同，他是“出于对效率的需求，而非应对快速变化的需求”而走向敏捷原则的。 #### 敏捷原则的新旧探讨 下面我们来详细分析每个敏捷原则及其根源： | 原则 | 是否新颖及证据 | | --- | --- | | 我们的最高优先级是通过尽早并持续交付有价值的软件来满足客户。 | EVO 首要原则：向真正的最终用户交付成果。 | | 欢迎需求的变更，即使在开发后期。敏捷过程利用变更为客户创造竞争优势。 | 相对较新，问题一直存在，但此前缺乏真正的解决方案。 | | 频繁交付可工作的软件，周期从几周到几个月不等，更倾向较短的周期。 | 在 EVO 中，频繁且早期交付至关重要，RAD 也推荐快速交付。 | | 业务人员和开发人员必须在整个项目中每天协同工作。 | 相对较新，虽然有些方法建议与客户建立良好关系，但每日沟通和现场客户的理念是新的。 | | 围绕有动力的个体来构建项目。为他们提供所需的环境和支持，并信任他们能够完成工作。 | 1985 年出版的《计算机编程心理学》一书中提出了这些观点，作者强调了动机作为内在驱动力的重要性，还提到丰富的环境具有自我维持的特性，能抵御外部强加的变化。 | | 向开发团队内部以及团队之间传达信息最有效率和效果的方法是面对面交谈。 | 上述书籍强调了工作空间如何影响社交互动，进而影响工作，尤其指出面对面交流有助于传递有用信息。 | | 可工作的软件是衡量进度的主要标准。 | EVO 第二原则：从所有标准维度衡量对用户的附加值。 | | 敏捷过程倡导可持续开发。赞助者、开发者和用户应能够无限期地保持恒定的工作节奏。 | 在《死亡行军》一书中，爱德华·尤登（Edward Yourdon）指出了管理和控制进度的重要性，并提出了“每日构建”的概念来实现这一目标。 | | 持续关注技术卓越和良好设计可提升敏捷性。 | 可能在迪杰斯特拉（Dijkstra）的著名文章《谦逊的程序员》中能找到关于做好编程工作（技术卓越）重要性的相同观点。 | | 简洁——使未做的工作量最大化的艺术——是至关重要的。 | 关于设计简洁性的著名表述来自安托万·德·圣埃克苏佩里（Antione de Saint - Exupery）：“完美不是在没有更多东西可添加时达到，而是在没有东西可去除时实现。” | | 最佳的架构、需求和设计出自自组织团队。 | 我们可以在与敏捷方法大致同期出现的开源项目中找到自组织团队的理念。在《大教堂与集市》一文中，雷蒙德（Raymond）将开发者描述为自带资源参与项目的人。 | | 团队定期反思如何提高效率，然后相应地调整和优化自身行为。 | 过程改进的理念在 CMMI 5 级中有所体现，但不同的是，在敏捷方法中，整个团队都会反思过程改进，而不仅仅是管理层。 | 从这些分析可以看出，虽然敏捷方法整体上是新的，但它的原则和理念早已存在。那些批评传统方法的人提出的替代方法实际上就是敏捷理念，只是这些替代方法之前未得到足够重视。 #### 极限编程（XP）在谢菲尔德大学的实践背景 在过去约 7 年里，敏捷开发方法受到了广泛关注，许多软件开发组织试图采用这些理念，但关于采用这些技术的长期效益，缺乏严格的研究数据。谢菲尔德大学的软件工程观测站致力于在可控条件和尽可能真实的环境中研究现代软件工程实践的各种问题。 该观测站依托大学公司开展的大量商业软件开发项目进行研究，它是计算机科学系和工作心理学研究所的合作项目。这使得研究能够关注软件开发的多个方面，特别是与“人”相关的问题，如团队凝聚力、员工福祉、冲突和个性，以及这些因素如何影响软件质量。 在过去 20 年里，计算机科学系的课程中包含了一个名为“软件小屋”的二年级模块。该模块持续