极限编程 - 简介

本章概述了极限编程。

什么是敏捷?

"敏捷"一词的意思是 −

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

• 能够快速清晰地思考。

在商业中，"敏捷"用于描述规划和开展工作的方式，其中人们认为根据需要进行更改是工作的重要组成部分。商业"敏捷性"意味着公司始终能够考虑市场变化。

参考:剑桥在线词典。

在软件开发中，"敏捷"一词被改编为"响应变化的能力 −需求、技术和人员的变化。'

敏捷宣言

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

敏捷宣言指出 −

我们通过实践和帮助他人实践，发现了更好的软件开发方法。通过这项工作，我们开始重视 −

• 个人和互动 胜过流程和工具。

• 可工作的软件 胜过详尽的文档。

• 客户协作 胜过合同谈判。

• 响应变化 胜过遵循计划。

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

敏捷性的特征

以下是敏捷性 −

• 敏捷软件开发中的敏捷性侧重于整个团队的文化，包括多学科、跨职能的团队，这些团队被授权并自我组织。

• 它促进共同的责任和义务。

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

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

• 频繁和持续的交付确保快速反馈，从而使团队能够满足要求。

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

• 进步是持续的、可持续的和可预测的，强调透明度。

软件工程趋势

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

• 在开发开始之前收集需求。但是，如果稍后要更改需求，则通常会注意到以下情况 −

  • 在开发后期对变更的抵制。

  • 需要严格的变更流程，其中包括变更控制委员会，甚至可能将变更推至后续版本。

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

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

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

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

  • 衡量和跟踪流程本身。这会因为−而变得昂贵。

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

  • 定义测量以指导开发并测量开发中的每一项活动。

  • 管理干预。

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

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

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

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

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

• 测试被认为是交付前检查缺陷的途径。

• 通过忽视测试要求以确保及时交付来补偿开发早期阶段的进度超支。

• 这导致交付后修复缺陷的成本超支。

• 尽管测试人员没有参与整个开发过程，但他们要对产品质量负责。

• 限制资源(主要是团队)以适应预算限制至 −

  • 资源过度分配

  • 团队倦怠。

  • 团队能力的有效利用丧失。

  • 人员流失。

极限编程 − 一种处理常见缺点的方法

软件工程涉及 −

• 创造力

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

• 迭代

极限编程建立在这些活动和编码之上。它是通过有效的实施、测试和不断重构而形成的具有多个紧密反馈循环的详细(而非唯一)设计活动。

极限编程基于以下价值观 −

• 沟通

• 简单

• 反馈

• 勇气

• 尊重

什么是极限编程?

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

极限编程 (XP) 的构想和开发是为了满足小团队在面对模糊且不断变化的软件开发环境时的特定需求。要求。

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

• 每项实践都很简单且可自我完善。

• 实践组合可产生更复杂和突发的行为。

拥抱变化

极限编程的一个关键假设是，更改程序的成本可以随时间基本保持不变。

这可以通过 − 实现

• 强调来自客户的持续反馈

• 短迭代

• 设计和重新设计

• 频繁编码和测试

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

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

• 向客户交付可用的产品

极限编程概述

极限编程涉及 −

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

• 从一个简单的设计开始，仅足以编写手头的功能，并在需要时重新设计。

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

• 每天多次集成和测试整个系统。

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

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

随着软件随着需求的变化而发展，迭代有助于适应变化。

为什么叫"极限"?

极限编程将有效的原则和实践发挥到了极致。

• 代码审查之所以有效，是因为代码经过了审查时间。

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

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

• 集成测试很重要，因为每天要进行多次集成和测试。

• 短迭代是有效的，因为发布计划和迭代计划的规划游戏。

极限编程的历史

1999 年，Kent Beck、Ward Cunningham 和 Ron Jeffries 提出了极限编程。其他贡献者包括 Robert Martin 和 Martin Fowler。

20 世纪 80 年代中期，Kent Beck 和 Ward Cunningham 在 Tektronix 发起了结对编程。在 80 年代和 90 年代，Smalltalk 文化产生了重构、持续集成、持续测试和密切的客户参与。这种文化后来推广到其他环境。

20 世纪 90 年代初，Hillside Group 模式社区内开发了核心价值观。1995 年，Kent 在 Smalltalk 最佳实践中总结了这些内容，1996 年，Ward 在章节中总结了这些内容。

1996 年，Kent 在 Hewitt 添加了单元测试和隐喻。 1996 年，Kent 接手了克莱斯勒 C3 项目，Ron Jeffries 被任命为该项目的教练。这些实践在 C3 上得到改进，并在 Wiki 上发布。

Scrum 实践被纳入并改编为规划游戏。1999 年，Kent 出版了他的书《极限编程解析》。同年，Fowler 出版了他的书《重构》。

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

行业成功

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

• 快速开发。

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

• 专注于低缺陷率。

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

• 高客户满意度。

• 降低成本。

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

极限编程优势

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

• 延误的时间表 − 和可实现的开发周期确保及时交付。

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

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

• 生产和交付后缺陷:重点是 −单元测试可以尽早发现和修复缺陷。

• 误解业务和/或领域 − 让客户成为团队的一部分可确保持续沟通和澄清。

• 业务变化 − 变化被认为是不可避免的，并可随时适应。

• 员工流动 − 密集的团队协作可确保热情和善意。多学科的凝聚力可培养团队精神。