本章概述了极限编程。

什么是敏捷?

“敏捷”一词的意思是-

• 能够快速轻松地移动您的身体。

• 能够快速清晰地思考。

在业务中，“敏捷”用于描述计划和完成工作的方式，其中可以理解，根据需要进行更改是工作的重要组成部分。业务“敏捷性”意味着公司始终可以考虑市场变化。

参考：在线剑桥词典。

在软件开发中，“敏捷”一词的含义是“响应变更的能力-需求，技术和人员的变更”。

敏捷宣言

一组软件开发人员于2001年发布了《敏捷宣言》，着重强调了开发团队的重要性，适应不断变化的需求和客户参与。

敏捷宣言指出-

我们正在探索通过开发和帮助他人来开发软件的更好方法。通过这项工作，我们实现了价值-

• 在流程和工具上的个人和互动。

• 工作软件覆盖全面的文档。

• 客户通过合同谈判进行协作。

• 响应按照计划进行的转换。

也就是说，尽管右侧的项目有价值，但我们更重视左侧的项目。

敏捷性特征

以下是敏捷性的特点-

• 敏捷软件开发中的敏捷性着眼于整个团队的文化，拥有跨学科，跨职能的团队，这些团队具有能力并具有自组织能力。

• 它促进了分担责任和问责制。

• 促进有效的沟通和持续的协作。

• 整个团队的方法避免了延迟和等待时间。

• 频繁和连续的交付可确保快速反馈，从而使团队能够顺应需求。

• 协作有助于在实施，缺陷修复和适应变更时及时地结合不同的观点。

• 进展是持续，可持续和可预见的，强调透明。

软件工程趋势

在软件工程中观察到以下趋势-

• 在开发开始之前收集需求。但是，如果以后要更改要求，通常会注意以下几点：

  • 在开发的后期阶段抵抗变化。

  • 需要严格的变更过程，其中涉及变更控制板，甚至可能会将变更推送到更高版本。

  • 交付的产品过时要求不符合客户的期望。

  • 无法在预算范围内适应不可避免的领域变更和技术变更。

• 在开发生命周期的早期发现并消除缺陷，以减少缺陷修复成本。

  • 测试仅在编码完成后才开始，尽管测试人员不参与开发，但测试仍被视为测试人员的责任。

  • 测量和跟踪过程本身。由于-

  • 在任务级别和资源级别进行监视和跟踪。

  • 定义度量以指导开发并度量开发中的每个活动。

  • 管理干预。

• 在开发之前详细阐述，分析和验证模型。

  • 应该将模型用作框架。但是，只关注模型而不关注至关重要的开发将不会产生预期的结果。

• 作为开发核心的编码没有得到足够的重视。原因是-

  • 负责生产的开发人员通常与客户保持不间断的沟通。

  • 编码被视为设计的翻译，并且几乎没有将代码中的有效实现循环回到设计中。

极限编程-解决常见缺点的一种方法

软件工程涉及-

• 创造力

• 通过反复试验学习和改进

• 迭代

极限编程基于这些活动和编码。这是详细(并非唯一)的设计活动，通过有效的实施，测试和连续重构，具有多个紧密的反馈循环。

极限编程基于以下值-

• 通讯

• 简单

• 反馈

• 勇气

• 尊重

什么是极限编程?

XP是一种轻巧，高效，低风险，灵活，可预测，科学且有趣的方式来开发软件。

E X德特雷姆P AGC软件(XP)的设计和开发由模糊和不断变化的需求，面对小团队，以解决软件开发的特定需求。

极限编程是敏捷软件开发方法之一。它提供了指导团队行为的价值观和原则。团队有望自我组织。极限编程提供了特定的核心实践，其中-

• 每种练习都是简单而完整的。

• 实践的结合会产生更加复杂和紧急的行为。

迎接改变

极限编程的一个关键假设是，随着时间的推移，更改程序的成本几乎可以保持恒定。

这可以通过-实现

• 强调客户的持续反馈

• 短迭代

• 设计和重新设计

• 经常进行编码和测试

• 尽早消除缺陷，从而降低成本

• 在整个开发过程中让客户参与

• 向客户交付工作产品

简而言之，极限编程

极限编程涉及-

• 在编程之前编写单元测试，并始终保持所有测试运行。单元测试是自动化的，可以尽早消除缺陷，从而降低了成本。

• 从简单的设计入手，足以对现有功能进行编码，并在需要时进行重新设计。

• 成对编程(称为成对编程)，在一个屏幕上有两个程序员，轮流使用键盘。当其中一个在键盘上时，另一个不断查看并提供输入。

• 每天几次对整个系统进行集成和测试。

• 快速将最小的工作系统投入生产，并在需要时进行升级。

• 始终保持客户的参与并获得持续的反馈。

随着软件随着不断变化的需求而发展，迭代简化了适应性变化。

为什么称其为“极端”?

极限编程将有效的原理和实践带到了极限。

• 代码审查一直有效，因为代码一直都在审查中。

• 测试是有效的，因为有连续的回归和测试。

• 设计是有效的，因为每个人都需要每天进行重构。

• 集成测试非常重要，因为一天要进行多次集成和测试。

• 短迭代作为发布计划和迭代计划的计划游戏非常有效。

极限编程的历史

Kent Beck，Ward Cunningham和Ron Jeffries在1999年制定了极限编程。其他贡献者是Robert Martin和Martin Fowler。

80年代中期，肯特·贝克(Kent Beck)和沃德·坎宁安(Ward Cunningham)在泰克公司开始了结对编程。在80年代和90年代，Smalltalk Culture进行了重构，持续集成，持续测试和密切的客户参与。这种文化后来被推广到其他环境。

在90年代初，核心价值观是在Hillside Group的Patterns Community中发展起来的。在1995年，Kent在Smalltalk Best Practices中总结了这些内容，在1996年，Ward在情节中总结了这些内容。

1996年，肯特(Kent)在休伊特(Hewitt)添加了单元测试和隐喻。 1996年，肯特接受了克莱斯勒C3项目，罗恩·杰弗里斯(Ron Jeffries)被任命为教练。该实践在C3上得到了完善，并在Wiki上发布。

Scrum实践被纳入并改编为计划游戏。肯特(Kent)在1999年出版了他的著作《极限编程解释》。同年，福勒出版了他的《重构》一书。

从那时起，极限编程一直在发展，并且一直持续到今天。

行业成功

遵循极限编程实践的项目的成功归功于-

• 快速发展。

• 立即响应客户不断变化的需求。

• 关注低缺陷率。

• 系统向客户返回恒定和一致的价值。

• 较高的客户满意度。

• 降低成本。

• 团队凝聚力和员工满意度。

极限编程优势

极限编程解决了软件开发项目中经常遇到的以下问题-

• 日程安排的缩短以及可实现的开发周期可确保及时交付。

• 已取消的项目-专注于持续的客户参与可确保与客户保持透明并立即解决任何问题。

• 变更产生的成本-广泛且持续的测试确保变更不会破坏现有功能。运行中的工作系统始终确保有足够的时间来适应更改，以使当前的操作不受影响。

• 生产和交付后的缺陷：重点是-单元测试，以及早发现并修复缺陷。

• 对业务和/或领域的误解-使客户成为团队的一员会确保持续的沟通和澄清。

• 业务变更-变更是不可避免的，并且可以在任何时间接受。

• 员工流动–团队的紧密合作确保了热情和良好的意愿。多学科的凝聚力可以培养团队合作精神。