极限编程 - 简介
本章概述了极限编程。
什么是敏捷？
“敏捷”一词意味着：
能够快速轻松地移动身体。
能够快速清晰地思考。
在商业中，“敏捷”用于描述规划和开展工作的方式，其中理解到根据需要进行更改是工作的重要组成部分。企业的“敏捷性”意味着公司始终能够适应市场变化。
参考：剑桥在线词典。
在软件开发中，“敏捷”一词被用来表示“响应变化的能力——来自需求、技术和人员的变化”。
敏捷宣言
2001年，一个软件开发团队发布了敏捷宣言，强调了开发团队的重要性、适应变化的需求以及客户参与。
敏捷宣言指出：
我们正在通过实践和帮助他人实践来发现更好的软件开发方法。通过这项工作，我们已经开始重视：
个体和互动 高于 流程和工具。
工作的软件 高于 详尽的文档。
客户合作 高于 合同谈判。
响应变化 高于 遵循计划。
也就是说，虽然右边的项目也有价值，但我们更重视左边的项目。
敏捷的特性
以下是敏捷的特性：
敏捷软件开发中的敏捷性关注整个团队的文化，包括具有多学科、跨职能的、授权的和自组织的团队。
它促进共享责任和问责制。
促进有效的沟通和持续的协作。
全团队的方法避免了延迟和等待时间。
频繁和持续的交付确保了快速的反馈，这反过来又使团队能够与需求保持一致。
协作有助于及时地将不同的观点结合到实施、缺陷修复和适应变化中。
进度是持续的、可持续的和可预测的，强调透明度。
软件工程趋势
在软件工程中观察到以下趋势：
在开发开始之前收集需求。但是，如果稍后需要更改需求，则通常会注意到：
在开发后期抵制更改。
需要一个严格的变更流程，其中涉及一个变更控制委员会，甚至可能将变更推迟到以后的版本。
交付的产品需求已过时，无法满足客户的期望。
无法在预算内适应不可避免的领域变化和技术变化。
尽早发现并消除软件开发生命周期中的缺陷，以降低缺陷修复成本。
只有在编码完成后才开始测试，并且测试被认为是测试人员的责任，尽管测试人员不参与开发。
衡量和跟踪流程本身。由于以下原因，这变得昂贵：
在任务级别和资源级别进行监控和跟踪。
定义指导开发的度量标准并测量开发中的每个活动。
管理干预。
在开发之前详细阐述、分析和验证模型。
模型应该用作框架。然而，关注模型而不是关注至关重要的开发将不会产生预期的结果。
编码是开发的核心，但没有得到足够的重视。原因是：
负责生产的开发人员通常与客户没有持续沟通。
编码被视为设计的转换，而代码中的有效实现几乎从未循环回到设计中。
测试被认为是交付前检查缺陷的途径。
通过忽略测试需求来弥补早期开发阶段的进度延误，以确保按时交付。
这导致交付后修复缺陷的成本超支。
测试人员对产品质量负责，尽管他们在整个开发过程中没有参与。
限制资源（主要是团队）以适应预算会导致：
资源过度分配
团队倦怠。
团队能力的有效利用率下降。
人员流失。
极限编程——一种处理常见缺点的方法
软件工程涉及：
创造力
通过反复试验学习和改进
迭代
极限编程建立在这些活动和编码之上。它是详细的（并非唯一的）设计活动，通过有效的实施、测试和持续重构具有多个紧密的反馈循环。
极限编程基于以下价值观：
沟通
简洁
反馈
勇气
尊重
什么是极限编程？
XP是一种轻量级、高效、低风险、灵活、可预测、科学且有趣的方式来开发软件。
极限编程 (XP) 的构思和开发是为了应对小型团队在面对模糊和不断变化的需求时软件开发的具体需求。
极限编程是敏捷软件开发方法之一。它提供价值观和原则来指导团队行为。团队应自行组织。极限编程提供具体的核心实践，其中：
每个实践都简单且自成一体。
实践的组合产生更复杂和涌现的行为。
拥抱变化
极限编程的一个关键假设是，更改程序的成本可以在一段时间内保持相对恒定。
这可以通过以下方式实现：
强调来自客户的持续反馈
短迭代
设计和重新设计
频繁编码和测试
尽早消除缺陷，从而降低成本
让客户参与整个开发过程
向客户交付可工作的产品
极限编程概览
极限编程包括：
在编程之前编写单元测试，并始终保持所有测试运行。单元测试是自动化的，可以尽早消除缺陷，从而降低成本。
从简单的设计开始，足以编写手头的功能，并在需要时重新设计。
结对编程（称为结对编程），两名程序员在一台屏幕上，轮流使用键盘。当其中一人在使用键盘时，另一人会不断审查并提供输入。
每天多次集成和测试整个系统。
快速将最小的工作系统投入生产，并在需要时进行升级。
始终让客户参与并获得持续反馈。
迭代有助于适应软件随着不断变化的需求而演变的变化。
为什么它被称为“极限”？
极限编程将有效的原则和实践提升到极致。
代码审查非常有效，因为代码会一直进行审查。
测试非常有效，因为存在持续的回归和测试。
设计非常有效，因为每个人都需要每天进行重构。
集成测试非常重要，因为每天都要进行多次集成和测试。
短迭代非常有效，因为有用于发布计划和迭代计划的计划游戏。
极限编程的历史
Kent Beck、Ward Cunningham和Ron Jeffries于1999年制定了极限编程。其他贡献者包括Robert Martin和Martin Fowler。
在80年代中期，Kent Beck和Ward Cunningham在Tektronix启动了结对编程。在80年代和90年代，Smalltalk文化产生了重构、持续集成、持续测试和紧密的客户参与。这种文化后来被推广到其他环境。
在90年代初期，核心价值观在模式社区、Hillside Group中得到发展。1995年，Kent在Smalltalk最佳实践中总结了这些内容，1996年，Ward在剧集中总结了这些内容。
1996年，Kent在Hewitt增加了单元测试和隐喻。1996年，Kent承担了克莱斯勒C3项目，Ron Jeffries被添加为教练。这些实践在C3上得到完善，并在Wiki上发布。
Scrum实践被纳入并改编为计划游戏。1999年，Kent出版了他的著作《极限编程详解》。同年，Fowler出版了他的著作《重构》。
从那时起，极限编程一直在发展，并且这种发展持续至今。
行业成功
遵循极限编程实践的项目的成功归功于：
快速开发。
对客户不断变化的需求做出即时响应。
关注低缺陷率。
系统持续向客户提供一致的价值。
高客户满意度。
降低成本。
团队凝聚力和员工满意度。
极限编程的优势
极限编程解决了软件开发项目中经常遇到的以下问题：
进度延误——可实现的开发周期确保按时交付。
项目取消——专注于持续的客户参与确保与客户的透明度以及任何问题的立即解决。
更改产生的成本——广泛且持续的测试确保更改不会破坏现有功能。始终运行的工作系统始终确保有足够的时间来适应更改，从而不会影响当前操作。
生产和交付后缺陷：重点在于——单元测试以尽早检测和修复缺陷。
误解业务和/或领域——让客户成为团队的一部分，确保持续沟通和澄清。
业务变更——变更被认为是不可避免的，并且可以在任何时候进行调整。
员工流动——密集的团队协作确保热情和善意。多学科的凝聚力培养了团队精神。