极限编程 - 快速指南
极限编程 - 简介
本章概述了极限编程。
什么是敏捷？
“敏捷”这个词的意思是 -
能够快速轻松地移动身体。
能够快速而清晰地思考。
在商业中，“敏捷”用于描述规划和工作的方式，其中根据需要进行更改是工作的重要组成部分。商业“敏捷性”意味着公司始终能够考虑市场变化。
参考：剑桥在线词典。
在软件开发中，“敏捷”一词被用来表示“响应变化的能力——来自需求、技术和人员的变化”。
敏捷宣言
一个软件开发团队于 2001 年发布了敏捷宣言，强调了开发团队、适应不断变化的需求和客户参与的重要性。
敏捷宣言指出 -
我们通过实践并帮助他人开发软件，从而发现更好的软件开发方法。通过这项工作，我们认识到了价值 -
个人以及流程和工具上的交互。
工作软件胜过全面的文档。
客户协作 胜过合同谈判。
响应变化而不是遵循计划。
也就是说，虽然右侧的项目有价值，但我们更看重左侧的项目。
敏捷的特点
以下是敏捷的特点 -
敏捷软件开发中的敏捷性侧重于整个团队的文化，其中包括多学科、跨职能的团队，这些团队被授权和自组织。
它促进共同的责任和问责。
促进有效沟通和持续协作。
整个团队的方法避免了延误和等待时间。
频繁和持续的交付可确保快速反馈，从而使团队能够满足需求。
协作有助于在实施、缺陷修复和适应变更时及时结合不同的观点。
进步是持续的、可持续的和可预测的，强调透明度。
软件工程趋势
在软件工程中观察到以下趋势 -
在开发开始之前收集需求。但是，如果稍后要更改要求，通常会注意到以下内容 -
对发展后期变化的抵制。
需要严格的变更流程，其中涉及变更控制委员会，甚至可能将变更推送到以后的版本。
交付的产品具有过时的要求，无法满足客户的期望。
无法在预算内适应不可避免的领域变化和技术变化。
在开发生命周期的早期发现并消除缺陷，以降低缺陷修复成本。
测试仅在编码完成后开始，并且测试被视为测试人员的责任，尽管测试人员不参与开发。
测量并跟踪流程本身。这变得昂贵是因为 -
在任务级别和资源级别进行监视和跟踪。
定义衡量标准以指导开发并衡量开发中的每项活动。
管理干预。
在开发之前详细阐述、分析和验证模型。
模型应该用作框架。然而，只关注模型而不关注至关重要的开发不会产生预期的结果。
作为开发核心的编码没有得到足够的重视。原因是 -
负责生产的开发人员通常不会与客户保持持续沟通。
编码被视为设计的翻译，代码中的有效实现几乎不会循环回到设计中。
测试被认为是交付前检查缺陷的门户。
开发早期阶段的进度超支可以通过忽略测试要求来补偿，以确保及时交付。
这会导致交付后修复缺陷的成本超支。
测试人员虽然没有参与整个开发过程，但他们要对产品质量负责。
限制资源（主要是团队）以适应预算会导致 -
资源过度分配
团队倦怠。
无法有效利用团队能力。
磨损。
极限编程——解决常见缺点的方法
软件工程涉及 -
创造力
通过尝试和错误来学习和改进
迭代
极限编程建立在这些活动和编码的基础上。它是详细的（不是唯一的）设计活动，通过持续有效的实施、测试和重构，具有多个紧密的反馈循环。
极限编程基于以下值 -
沟通
简单
反馈
勇气
尊重
什么是极限编程？
XP 是一种轻量级、高效、低风险、灵活、可预测、科学且有趣的软件开发方式。
e X treme编程(XP) 的构思和开发是为了满足小型团队在面对模糊和不断变化的需求时的软件开发特定需求。
极限编程是敏捷软件开发方法之一。它提供了指导团队Behave的价值观和原则。该团队有望自组织。极限编程提供了具体的核心实践，其中 -
每个练习都是简单且自我完成的。
实践的结合会产生更复杂和更紧急的Behave。
迎接改变
极限编程的一个关键假设是，随着时间的推移，更改程序的成本可以基本保持不变。
这可以通过以下方式实现 -
强调来自客户的持续反馈
短迭代
设计和重新设计
经常编码和测试
尽早消除缺陷，从而降低成本
让客户参与整个开发过程
向客户交付工作产品
简而言之极限编程
极限编程涉及 -
在编程之前编写单元测试并保持所有测试始终运行。单元测试是自动化的，可以尽早消除缺陷，从而降低成本。
从一个简单的设计开始，足以对手头的功能进行编码，并在需要时重新设计。
结对编程（称为结对编程），两个程序员在一个屏幕上，轮流使用键盘。当其中一个人坐在键盘上时，另一个人不断地审查并提供输入。
每天对整个系统进行多次集成和测试。
将最小工作系统快速投入生产并在需要时进行升级。
让客户始终参与并获得持续的反馈。
随着软件随着需求的变化而发展，迭代有助于适应变化。
为什么叫“极限”？
极限编程将有效的原则和实践提升到了极限。
代码审查是有效的，因为代码一直在审查。
测试是有效的，因为有持续的回归和测试。
设计是有效的，因为每个人都需要每天进行重构。
集成测试很重要，因为每天要集成和测试多次。
短迭代对于发布计划和迭代计划来说是有效的计划游戏。
极限编程的历史
Kent Beck、Ward Cunningham 和 Ron Jeffries 在 1999 年提出了极限编程。其他贡献者是 Robert Martin 和 Martin Fowler。
80 年代中期，Kent Beck 和 Ward Cunningham 在 Tektronix 发起了结对编程。在 80 年代和 90 年代，Smalltalk 文化产生了重构、持续集成、持续测试和密切的客户参与。这种文化后来被推广到其他环境。
20 世纪 90 年代初，Hillside Group 的模式社区开发了核心价值观。1995 年，Kent 在《Smalltalk 最佳实践》中总结了这些内容，1996 年，Ward 在剧集中总结了这些内容。
1996 年，Kent 在 Hewitt 增加了单元测试和隐喻。1996年，肯特接手了克莱斯勒C3项目，罗恩·杰弗里斯被任命为该项目的教练。这些实践在 C3 上进行了完善并发布在 Wiki 上。
Scrum 实践被纳入并调整为规划游戏。1999 年，肯特出版了他的书《极限编程解释》。同年，福勒出版了他的书《重构》。
从那时起，极限编程就一直在发展，并且这种发展一直持续到今天。
行业成功
遵循极限编程实践的项目的成功是由于 -
快速发展。
立即响应客户不断变化的需求。
专注于低缺陷率。
系统为客户返回持续一致的价值。
客户满意度高。
降低成本。
团队凝聚力和员工满意度。
极限编程的优势
极限编程解决了软件开发项目中经常遇到的以下问题 -
进度落后和可实现的开发周期确保及时交付。
取消的项目- 注重客户的持续参与，确保客户的透明度并立即解决任何问题。
变更产生的成本- 广泛且持续的测试可确保变更不会破坏现有功能。运行中的工作系统始终确保有足够的时间来适应变化，从而不影响当前的操作。
生产和交付后缺陷：重点是- 单元测试以尽早检测和修复缺陷。
误解业务和/或领域- 让客户成为团队的一部分可确保持续的沟通和澄清。
业务变化- 变化被认为是不可避免的，并且可以在任何时间点进行调整。
员工流动- 密集的团队合作确保了热情和良好意愿。多学科的凝聚力培养团队精神。
极限编程 - 价值观与原则
XP 致力于通过引入基本价值观、原则和实践来降低变革成本。通过应用 XP，系统开发项目对于变化应该更加灵活。
极限编程价值观
极限编程（XP）基于五个值 -
沟通
简单
反馈
勇气
尊重
沟通
沟通对于项目的成功起着重要作用。项目的问题常常是由于缺乏沟通而出现的。许多情况都可能导致沟通中断。一些常见问题是 -
开发人员可能不会告诉其他人设计中的重大变化。
开发人员可能不会向客户提出正确的问题，因此关键的领域决策就会失败。
经理可能没有向开发人员提出正确的问题，项目进度也会被误报。
开发人员可能会忽略客户传达的一些重要信息。
极限编程强调团队成员、经理和客户之间持续不断的沟通。单元测试、结对编程、简单设计、通用隐喻、集体所有权和客户反馈等极限编程实践注重沟通的价值。
XP 聘请了一位教练，他的工作是注意人们何时不沟通并重新介绍他们。首选面对面沟通，通过结对编程实现，并且客户代表始终在场。
简单
极限编程相信“今天做一件简单的事情，明天多花一点钱来改变它”比“今天做一件可能永远不会被使用的更复杂的事情”要好。
做需要和要求的事情，但仅此而已。
“做可能有效的最简单的事情”DTSTTCPW 原则。
以最简单的方式实施新功能。也称为 KISS 原则“保持简单，愚蠢！”。
当教练看到极限编程开发人员做一些不必要的复杂事情时，他可能会说 DTSTTCPW。
将系统重构为具有当前功能集的最简单的代码。这将使迄今为止的投资创造的价值最大化。
采取简单的小步骤来实现您的目标，并在失败发生时减少失败的发生。
创造令您引以为豪的东西，并以合理的成本长期维护它。
永远不要实现您现在不需要的功能，即“您不会需要它”(YAGNI) 原则。
沟通和简单是相辅相成的。
你沟通得越多，你就越能清楚地看到需要做什么，并且你对真正不需要做的事情更有信心。
您的系统越简单，您需要的开发人员就越少，沟通的次数就越少。这会带来更好的沟通。
反馈
通过交付可工作的软件，我们认真对待每一次迭代承诺。该软件会尽早交付给客户并获取反馈，以便在需要时进行必要的更改。关于系统当前状态的具体反馈是无价的。反馈的价值在于一个持续运行的系统，能够以可靠的方式传递有关自身的信息。
在极限编程中，确保在不同时间尺度的各个级别提供反馈 -
客户告诉开发人员他们感兴趣的功能，以便开发人员可以只关注这些功能。
单元测试告诉开发人员系统的状态。
系统和代码向管理者、利益相关者和客户提供有关开发状态的反馈。
频繁的发布使客户能够执行验收测试并提供反馈，并且开发人员可以根据该反馈进行工作。
当客户编写新功能/用户故事时，开发人员会估计交付更改所需的时间，以便与客户和经理设定期望。
因此，在极限编程中，反馈 -
充当变革的催化剂
表示进展
让开发人员相信他们走在正确的轨道上
勇气
极限编程通过以下方式为开发人员提供勇气 -
只关注需要的内容
沟通并接受反馈
真实地讲述进度和估计
重构代码
随时适应变化
扔掉代码（原型）
这是可能的，因为没有人单独工作，教练不断指导球队。
尊重
尊重是一种深刻的价值观，它低于其他四种价值观的表面。在极限编程中，
每个人都互相尊重，视为有价值的团队成员。
每个人都贡献热情等价值。
开发人员尊重客户的专业知识，反之亦然。
管理层尊重开发人员接受责任并接受其工作权力的权利。
与沟通、简单和具体的反馈相结合，勇气变得极其宝贵。
沟通支持勇气，因为它为更多高风险、高回报的实验提供了可能性。
简单性支持勇气，因为使用简单的系统你可以变得更加勇敢。您在不知不觉中破坏它的可能性要小得多。
勇气支持简单性，因为一旦你看到简化系统的可能性，你就会尝试它。
具体的反馈支持勇气，因为如果你能看到测试最后变成绿色，你会觉得尝试对代码进行彻底修改会更安全。如果任何测试没有变绿，您就知道可以扔掉代码。
极限编程原理
这些价值观很重要，但它们很模糊，因为可能无法确定某物是否有价值。例如，从某人的角度来看很简单的事情从其他人的角度来看可能很复杂。
因此，在极限编程中，基本原则是从价值观中衍生出来的，以便可以根据这些原则来检查开发实践。每条原则都体现了价值观并且更加具体，即快速反馈——您要么拥有它，要么没有。
极限编程的基本原则是 -
快速反馈
假设简单
渐进式改变
拥抱变化
优质工作
快速反馈
快速反馈就是获取反馈、理解反馈，并尽快将学到的知识放回到系统中。
开发人员设计、实施和测试系统，并在几秒钟或几分钟内使用反馈，而不是几天、几周或几个月。
客户审查系统以检查它可以如何最好地做出贡献，并在几天或几周内而不是几个月或几年内提供反馈。
假设简单
假设简单性就是将每个问题视为可以通过简单性解决。
传统上，你被告知要为未来做计划，为重用而设计。这种方法的结果可能会变成“客户今天的要求没有得到满足，最终交付的可能已经过时且难以改变”。
“假设简单”意味着“今天做好解决今天的工作，并相信你有能力在未来需要的地方增加复杂性。” 在极限编程中，你被告知要做好工作（测试、重构和沟通），专注于当前重要的事情。
通过良好的单元测试，您可以轻松重构代码以执行其他测试。
关注 YAGNI（你不需要它）。
遵循 DRY（不要重复自己）原则。例如，
不要拥有相同（或非常相似）代码的多个副本。
不要有冗余的信息副本。
不会在不必要的事情上浪费时间和资源。
渐进式改变
在任何情况下，一次性做出重大改变都是行不通的。任何问题都可以通过一系列产生影响的最小改变来解决。
在极限编程中，增量变更有多种应用方式。
设计每次都会改变一点。
计划每次都会改变一点。
团队每次都会发生一些变化。
即使采用极限编程也必须分步进行。
拥抱变革
最好的策略是在实际解决最紧迫问题的同时保留最多选择的策略。
优质工作
每个人都喜欢做好工作。他们努力生产令他们引以为豪的品质。团队
效果很好
享受工作
生产有价值的产品感觉良好
极限编程 - 实践
极限编程有四种基本活动。他们是 -
编码
测试
听力
设计
这四项基本活动需要根据极限编程原则来构建。为了实现这一目标，定义了极限编程实践。
这 12 种极限编程实践实现了极限编程的目标，只要其中一种实践的弱点，其他实践的优势就会弥补。
《极限编程解释》一书的作者 Kent Beck 定义了 12 种极限编程实践，如下所示：
规划游戏
简短版本
隐喻
简单的设计
测试
重构
结对编程
集体所有制
持续集成
每周 40 小时
现场客户
编码标准
极限编程的四个领域
极限编程实践可以分为四个领域 -
快速、精细的反馈 -
测试
现场客户
结对编程
连续过程 -
持续集成
重构
简短版本
共同理解 -
规划游戏
简单的设计
隐喻
集体所有制
编码标准
开发者福利 -
每周四十小时
在本章中，您将详细了解极限编程实践以及每种实践的优点。
极限编程实践概览
下图显示了极限编程是如何围绕极限编程实践编织的 -
规划游戏
极限编程中的主要规划过程称为规划游戏。该游戏是每次迭代发生一次的会议，通常每周一次。规划游戏是为了通过结合业务优先级和技术估算来快速确定下一个版本的范围。当现实超越计划时，更新计划。
业务和开发需要同时做出决策。业务决策和开发的技术决策必须相互协调。
商界人士需要决定 -
范围- 必须解决多少问题才能使系统在生产中有价值？商人能够了解多少是不够的，多少是太多。
优先级- 如果给你一个选择，你想要哪个？业务人员比开发人员更有能力根据客户的意见来确定这一点。
版本的组成- 在使用该软件比不使用该软件的业务效果更好之前，需要做多少工作？开发人员对这个问题的直觉可能是非常错误的。
发布日期- 软件（或某些软件）的存在会产生重大影响的重要日期是什么？
技术人员需要决定 -
估计- 功能需要多长时间才能实现？
后果- 只有在了解技术后果后才应做出战略业务决策。发展需要解释后果。
流程- 工作和团队将如何组织？团队需要适应其运作所在的文化。软件必须写得好，而不是保留封闭文化的非理性。
详细的计划- 在一个版本中，应该首先完成哪些故事？开发人员需要首先自由地安排风险最高的开发部分，以降低项目的整体风险。在这种限制下，他们仍然倾向于在开发的早期阶段转移业务优先级，从而减少由于时间限制而在版本开发结束时不得不放弃重要故事的机会。
因此，计划是客户、业务人员和开发人员之间协作的结果。
规划游戏——优势
规划游戏具有以下优点 -
减少时间，浪费在无用的功能上
客户更加欣赏某项功能的成本
减少规划中的猜测
简短版本
您应该将一个简单的系统快速投入生产，然后在很短的周期内发布新版本。每个版本都应该尽可能小，以便它 -
可在短周期内实现
包含最有价值、最直接的业务需求
一个工作系统
短周期的持续时间可能因需要构建的软件而异。然而，需要确保选择尽可能短的持续时间。
简短版本 – 优点
简短版本的优点是 -
频繁反馈
追踪
减少整体项目延误的可能性
隐喻
根据剑桥在线词典，隐喻是一种经常出现在文献中的表达方式，通过引用被认为与该人或物体具有相似特征的事物来描述一个人或物体。例如，“思想是海洋”和“城市是丛林”都是隐喻。
您应该通过一个关于整个系统如何工作的简单共享故事来指导整个开发。您可以将隐喻视为要以参与开发的每个人都容易理解的方式构建的系统架构。
该隐喻由特定领域的元素组成，并显示了它们的互连性。使用的语言是域语言。为了识别技术实体，隐喻中使用的词语需要保持一致。
随着开发的进行和隐喻的成熟，整个团队将从研究隐喻中找到新的灵感。
一个好的架构的目标是为每个人提供一个连贯的工作故事，一个可以轻松地被业务和技术成员共享的故事。因此，在极限编程中，通过要求一个隐喻，我们很可能获得一个易于沟通和阐述的架构。
比喻——优点
隐喻的优点是 -
鼓励系统使用一组通用术语
减少流行语和行话
一种快速简单的方法来解释系统
简单的设计
在任何给定时刻，系统的设计都应该尽可能简单。额外的复杂性一旦被发现就会被消除。
在任何给定时间，软件的正确设计是 -
运行所有测试
没有像并行类层次结构那样的重复逻辑
陈述对开发人员重要的每一个意图
具有尽可能少的类和方法
要获得简单的设计，请在不违反前三个规则的情况下消除任何可以消除的设计元素。这与“为今天实施，为明天设计”的建议相反。如果你相信未来是不确定的，并且你可以快速增强设计，那么就不要对任何功能进行猜测。
简单的设计 – 优点
简单设计的优点是 -
时间不会浪费在添加多余的功能上
更容易理解发生了什么
重构和集体所有权成为可能
帮助程序员保持正轨
测试
开发人员不断编写单元测试，需要通过这些测试才能继续开发。客户编写测试来验证功能是否已实现。测试是自动化的，因此它们成为系统的一部分，并且可以连续运行以确保系统的工作。结果是一个能够接受变化的系统。
测试 – 优点
测试的优点是 -
单元测试促进测试完整性
测试优先为开发人员提供了一个目标
自动化提供了一套回归测试
重构
在实现某个功能时，开发人员总是会询问是否有一种方法可以更改现有代码以使添加功能变得简单。添加功能后，开发人员询问他们现在是否可以了解如何使代码更简单，同时仍然运行所有测试。他们在不改变系统Behave的情况下重组系统，以消除重复、改善沟通、简化或增加灵活性。这称为重构。
重构——优点
重构的优点是 -
促使开发人员主动改进整个产品
增加开发人员对系统的了解
结对编程
在结对编程中，整个代码由两名开发人员在一台机器上编写，使用一个键盘和一个鼠标。
每对有两个角色 -
第一个开发人员（拥有键盘和鼠标的开发人员）在这里思考实现此方法的最佳方式。
另一个开发商的思考更具战略性
这整个方法会起作用吗？
还有哪些其他可能无法正常工作的测试用例？
有没有什么方法可以简化整个系统，从而使当前的问题消失？
配对是动态的。这意味着A和B这两个角色可能会交换位置，也可能会与其他团队成员配对。更多时候，团队中的任何人都会充当合作伙伴。例如，如果您负责一个您不熟悉的领域的任务，您可能会要求最近有经验的人与您结对。
结对编程——优点
结对编程的优点是 -
三个臭皮匠顶个诸葛亮
重点
两个人更有可能回答以下问题 -
这整个方法会起作用吗？
有哪些测试用例可能还无法工作？
有没有办法简化这个？
集体所有制
在极限编程中，整个团队对整个系统负责。尽管每个人都对每个部分有所了解，但并非每个人都同样了解每个部分。
如果两人正在工作并且他们看到了改进代码的机会，他们就会继续改进它。
集体所有制——优点
集体所有制的优点是 -
有助于减轻离开团队成员的损失。
促进开发人员对系统整体而不是系统的某些部分负责。
持续集成
代码每天会集成和测试多次，一次进行一组更改。一个简单的方法是拥有一台专门用于集成的机器。一对已准备好集成的代码 -
当机器空闲时坐下。
加载当前版本。
加载他们的更改（检查并解决任何冲突）。
运行测试直到通过（100%正确）。
一次集成一组更改有助于了解谁应该修复失败的测试。答案是当前的一对，因为最后一对的测试结果为 100%。他们可能不得不放弃已经做过的事情并重新开始，因为他们可能还没有足够的知识来编写该功能。
持续集成——优点
持续集成的优点是 -
减少持续时间，否则会很长。
启用短期发布实践，因为发布前所需的时间很短。
每周 40 小时
极限编程强调每个团队成员每周的工作时间有限，根据其可持续性，每周最多 45 小时。如果有人工作的时间超过这个时间，就被视为加班。最多允许加班一周。这样的做法是为了确保每个团队成员都充满新鲜感、创造力、细心和自信。
每周 40 小时 – 优势
每周工作 40 小时的优点是 -
大多数开发人员在 40 小时后就会失去效率。
开发商的福祉受到重视。
管理层被迫寻找真正的解决方案。
现场客户
在团队中包含一名真实的实时用户，他可以全职回答问题、解决争议并设置小规模的优先事项。该用户可能不必只在这个角色上花费 40 小时，还可以专注于其他工作。
现场客户 – 优势
拥有现场客户的优势是 -
能够对真正的开发问题给出快速且知识渊博的答案。
确保开发的内容正是需要的。
功能的优先级正确。
编码标准
开发人员按照以下规则编写所有代码：
通过代码进行通信。
尽可能少的工作量。
符合“一次且仅一次”规则（无重复代码）。
整个团队自愿采用。
这些规则在极限编程中是必要的，因为所有开发人员 -
可以从系统的一个部分更改为系统的另一部分。
每天交换几次伙伴。
不断重构彼此的代码。
如果不遵守规则，开发人员将倾向于采用不同的编码实践，随着时间的推移，代码会变得不一致，并且无法确定团队中的谁编写了哪些代码。
编码标准 – 优点
编码标准的优点是 -
减少开发人员重新格式化其他人的代码所花费的时间。
减少内部评论的需要。
需要清晰、明确的代码。
极限编程——支持实践
如果单独实施极限编程实践可能会很弱，因此可能会失败。在极限编程中，所有的实践都需要作为一个整体来考虑，这样它们才能相互支持。一个人的弱点会被别人的优点所掩盖。
在本章中，我们将重点讨论每种实践如果单独实施可能存在的弱点。我们将看到极限编程如何支持这种实践，以克服与其他实践结合实施时的弱点。
规划游戏 – 来自其他 XP 实践的支持
在本节中，我们将了解规划游戏的弱点以及其他 XP 实践如何支持它。
规划游戏——缺点
规划游戏的缺点是你不可能只用一个粗略的计划来开始开发，并且你无法不断更新计划，因为这会花费太长时间并让客户感到不安。
规划游戏与其他 XP 实践
其他 XP 实践通过以下方式支持规划游戏 -
在规划游戏中，客户还根据开发人员提供的估计参与更新计划。
您发布的版本较短，因此计划中的任何错误最多只会产生几周或几个月的影响。
您的客户与团队坐在一起，因此他们可以快速发现潜在的变化和改进的机会（在线客户）。
持续测试可以帮助开发人员和客户立即决定需要什么。
因此，您可以从一个简单的计划开始开发，并在开发过程中不断完善它。
简短版本 – 来自其他 XP 实践的支持
简短版本 – 缺点
几个月后你不可能投入生产。您当然不能以每天到每几个月的周期发布系统的新版本。这是因为您需要时间来吸收新的需求以及对当前代码的更改。
与其他 XP 实践的简短版本。
其他 XP 实践通过以下方式支持短版本 -
规划游戏可以帮助您处理最有价值的故事，因此即使是小型系统也将具有商业价值。
持续集成使打包发布的成本降至最低。
测试足以降低缺陷率，因此发布前不需要漫长的测试周期。
您可以进行一个简单的设计，足以满足此版本的需要，但不适用于所有时间。
因此，您可以在开发开始后不久制作简短版本。
隐喻——来自其他 XP 实践的支持
你不可能仅仅用一个比喻来开始开发。它可能没有足够的细节，你可能是错的。
与其他 XP 实践的比喻
其他 XP 实践通过以下方式支持 Metaphor -
通过结对编程，您将从已实现的代码中获得快速的具体反馈，并测试隐喻是否正常工作。
您的现场客户很乐意用比喻来谈论系统。
持续重构可以让您更好地理解隐喻在实现中的含义。
简单的设计可以帮助你与隐喻建立映射。
因此，您只需一个比喻就可以开始开发。
简单的设计 – 来自其他 XP 实践的支持
简单的设计 - 缺点
您不可能为当今的代码提供足够的设计，并且您的设计可能无法继续改进系统。
简单设计与其他 XP 实践。
其他 XP 实践通过以下方式支持简单设计 -
重构允许您进行更改。
有了整体的比喻，你可以确信未来的设计变化将趋于遵循一条收敛的路径。
结对编程可以帮助您确信自己正在制作一个可行的简单设计。
每周 40 小时可以帮助您专注于正确的设计。
持续的单元测试和客户测试可确保您的简单设计步入正轨。
因此，您可以为今天做最好的设计，而无需猜测。
测试 – 来自其他 XP 实践的支持
测试 - 缺点
你可能会认为 -
您不可能编写所有这些测试。
编写测试可能需要太多时间。
开发人员不会编写测试。
使用其他 XP 实践进行测试
其他 XP 实践支持通过以下方式进行测试 -
简单的设计使编写测试变得容易。
重构允许您决定哪些测试是必要的。
通过结对编程，即使您想不出其他测试，您的合作伙伴也可以。您可以让您的合作伙伴通过键盘来运行测试，当您看到测试全部运行时，您会感到自信。
集体所有权确保具有所需技能的开发人员能够处理任何复杂的编码和测试部分。
持续集成并立即对一对所做的每组更改运行测试可确保 -
如果 100% 测试通过，新代码就可以工作，或者
如果任何测试失败，则该对的代码会导致系统失败，以便可以立即撤消更改，并且两人可以重新开始编码，并清楚地了解他们正在实现的功能。
简短的版本可确保客户可以使用工作系统来运行测试并提供反馈。
在线客户将有时间运行所有测试并立即提供有关工作系统的反馈。
规划游戏确保在测试后获取客户的反馈来规划下一个版本。
因此，开发人员和客户将编写测试。此外，测试是自动化的，以确保极限编程的其余部分正常工作。
重构——来自其他 XP 实践的支持
重构 - 缺点
你不可能一直重构系统的设计。它将 -
时间太长了。
太难控制了，而且
最有可能破坏系统。
与其他 XP 实践一起重构
其他 XP 实践通过以下方式支持重构 -
有了集体所有权，您就可以在任何需要的地方进行更改。
使用编码标准，您无需在重构之前重新格式化。
通过结对编程，您可以有勇气应对艰难的重构。
设计简单，重构就更容易。
有了隐喻，你就可以轻松地交流。
通过测试，您不太可能在不知情的情况下破坏某些东西。
通过持续集成，如果您不小心破坏了某些东西，或者您的重构与其他人的工作发生冲突，您会在几个小时内知道。
每周工作 40 小时，您会得到休息，因此您会更有勇气，也不太可能犯错误。
因此，只要有机会，您就可以重构-
让系统更简单
减少重复
沟通更清晰
结对编程 – 来自其他 XP 实践的支持
结对编程 - 弱点
您不可能成对编写所有代码。会太慢。如果两个人相处得不好，情况就会变得很困难。
结对编程与其他 XP 实践。
其他 XP 实践通过以下方式支持结对编程 -
编码标准减少了冲突。
40个小时的工作，每个人都精力充沛、专注，进一步减少了不必要的讨论。
两人一起编写测试，让他们有机会在处理实现部分之前统一理解。
隐喻帮助两人在命名和基本设计方面做出决定
简单的设计使两人能够达成共识。
重构有助于两人讨论并做出综合决策，使系统变得简单。
持续集成为双方提供了纠正错误的机会，因此当对方进行一些实验时，合作伙伴不会反对。
集体所有制使团队能够混合搭配，并让他们保持亲切的关系。
因此，您可以成对编写所有代码。另一方面，如果团队单独工作，他们更有可能犯错误、过度设计并忽视其他实践。
集体所有权——来自其他 XP 实践的支持
集体所有制——缺点
你不可能让每个人都改变系统中任何地方的任何东西。因为，有可能在不知不觉中破坏系统，并且集成成本将急剧上升。
集体所有权与其他 XP 实践
其他 XP 实践通过以下方式支持集体所有权 -
持续集成减少了冲突的机会。
测试减少了意外破坏事物的可能性。
通过结对编程，您破坏代码的可能性较小，并且开发人员可以更快地了解他们可以进行有利可图的更改。
使用编码标准，您将不会在代码上出现冲突。
通过重构，您可以保持系统简单，以便每个人都能理解。
因此，当任何人看到有机会改进代码时，您可以让任何人在系统中的任何位置更改代码。另一方面，如果没有集体所有权，设计的演变速度就会急剧减慢。
持续集成 - 来自其他 XP 实践的支持
持续集成——缺点
您不可能在仅仅几个小时的工作后就进行集成，因为集成需要很长时间，并且存在太多冲突和意外破坏某些东西的机会。
与其他 XP 实践的持续集成
其他 XP 实践通过以下方式支持持续集成 -
快速测试可以帮助您知道您没有破坏任何东西。
通过结对编程，需要集成的变更流数量减少了一半。
通过重构，可以将各个部分变得更小，从而减少冲突的可能性。
有了编码标准，代码就会一致。
简短的发布确保了系统的即时反馈。
集体所有权确保任何更改代码和集成的人都将拥有系统的整体视图。
因此，您可以在几个小时后进行整合。另一方面，如果不快速整合，那么冲突的可能性就会增加，整合的成本也会急剧上升。
每周 40 小时 – 来自其他 XP 实践的支持
每周 40 小时——缺点
你不可能每周工作 40 小时。你无法在 40 小时内创造足够的商业价值。
每周 40 小时与其他 XP 实践
其他 XP 实践通过以下方式支持每周 40 小时 -
规划游戏为您提供了哪些更有价值的工作要做。
计划游戏和测试的结合确保您只需要按照您的想法进行工作。
简单的设计和重构可以让您保持专注并按时完成。
结对编程可以帮助您完成自己能做的事情，并与您的合作伙伴分担其他工作。
整个练习可以帮助你以最快的速度发展，因此你无法走得更快。
因此，您可以在每周 40 小时内创造足够的商业价值。另一方面，如果团队不能保持新鲜感和活力，那么他们将无法执行其余的实践。
现场客户 – 来自其他 XP 实践的支持
现场客户 – 缺点
你不可能让真正的客户全职加入团队而不产生任何价值。他们可以为其他地方的业务创造更多的价值。
具有其他 XP 实践的现场客户
其他 XP 实践通过以下方式支持现场客户。
他们可以为项目创造价值 -
在规划游戏中，通过为开发人员做出优先级和范围决策。
使用 Metaphor，为该领域的开发人员带来清晰度。
在测试中，通过编写验收测试并在每次简短发布后执行验收测试。
因此，他们可以通过为项目做出贡献为组织创造更多价值。
编码标准 – 来自其他 XP 实践的支持
编码标准 – 缺点
您不可能要求团队按照通用标准进行编码，因为开发人员通常都是个人主义的。
编码标准与其他 XP 实践
其他 XP 实践通过以下方式支持编码标准 -
结对编程使他们能够轻松适应必要的编码标准。
持续集成强制他们遵循标准，以便代码保持一致。
集体所有制鼓励他们遵守标准，以便在必要时随时随地进行更改。
极限编程 - 不断发展的实践
极限编程自诞生以来一直在不断发展，人们发现极限编程实践在其他敏捷方法中也很有效。
下表显示了极限编程实践是如何发展的。
| 极限编程实践 | 进化 |
|---|---|
| 现场客户 | 整个团队 |
| 规划游戏 |
发布计划 迭代计划 |
| 测试 |
验收测试 单元测试 测试驱动开发 |
| 重构 | 设计改进 |
| 每周 40 小时 | 可持续的步伐 |
现场客户 – 整个团队
极限编程依赖于项目社区，强调以团队为中心的方法。极限编程项目的所有贡献者（包括客户）都是一个团队。
客户提供需求、设定优先级并指导项目。这使客户能够了解开发的实际细节并相应地设置优先级和期望。这由“按客户要求开发”转变为“按客户理解并配合开发”。
项目目标是共同的责任，开发是整个团队持续进行的对话。这是一个发明和交流的合作游戏。研究发现，面对面的沟通是发展道路上最高效、最有效的方法，消除了等待时间和延误。
规划游戏——发布和迭代规划
增量项目规划被发现是有效的，因为它可以促进准确的计划。随着开发的进展，基于实际性能，我们可以学到更多更好的信息。首先制定一个粗略的计划，然后逐步完善。
发布规划设定了长期目标，并掌握了总体情况。客户提出所需的功能，开发人员估计并共同商定并承诺发布日期。由于每次发布后都会修改发布计划，因此随着项目的进展，发布计划会变得更加精确。
迭代计划设置迭代的短期时间框，通常范围为 1 周到 1 个月。迭代计划的主要目标是在每次迭代结束时获得一个可工作的软件。开发人员选择迭代的功能/故事，将它们分解为任务，估计任务并提交分配的任务。考虑到每周工作 40 小时，通过平衡整个团队的负载系数来确保可持续的节奏。
验收测试
客户为一项功能编写一个或多个自动化验收测试，以确保系统正确实现所需的功能。验收测试与故事一起编写并在实施之前提供。
团队自动执行这些测试，以验证功能是否正确实现。测试运行后，团队通过执行在此之前实施的所有验收测试，确保测试在回归时保持正确运行。
验收测试提供了明确的功能需求规范。此外，验收测试通过的百分比衡量了发布的完成情况，没有最后一刻的意外。
系统始终在进步，永不倒退。
单元测试
开发人员编写具有足够覆盖范围的单元测试，结合代码模块和方法的意图和用法。单元测试是自动化的，有明确的通过/失败。大多数语言都有 xUnit 框架（例如 nUnit、jUnit）。
所有单元测试都执行得非常频繁，并且在所有单元测试通过之前无法签入代码。单元测试结果也有助于重构。
测试驱动开发
测试驱动开发被认为是最具创新性的极限编程实践。
在测试驱动开发中，开发人员在编写代码之前编写单元测试。目的是使单元测试失败。由于代码尚未实现，单元测试失败。开发人员编写足够的代码以使单元测试通过，然后开发人员进行重构以确保代码简单干净（没有重复和复杂性）。
开发人员迭代直到编码完成并且验收测试通过。
单元测试全部收集在一起，每次集成并将代码发布到存储库时，他们都需要确保每个测试都能正确运行。如果任何测试失败，两人就知道需要纠正他们的代码，因为之前的集成已顺利通过，没有任何缺陷。
测试驱动开发往往会导致 100% 的单元测试覆盖率，并确保代码简单且最少。
重构——设计改进
重构允许设计逐步发展，保持简单，消除您注意到的重复和复杂性。它通过重构改进了现有代码的设计，而不改变其功能。
重构应该通过学习新的实现来驱动。建议在编写新代码后立即进行重构。重构将代码推向更高级别的设计模式，并得到测试的支持。
每周 40 小时 – 可持续的节奏
以可以无限期持续的速度工作。考虑到以下事实，可持续步伐确保人类对项目成功的贡献 -
疲劳和压力会降低生产力和产品质量。这可能会导致员工流失。
发展不能止步于冲刺，而应着眼长远目标
除非团队就期望达成一致，否则就不会有承诺和责任。
确切的工作时间并不像执行能力那么重要。
应避免微观管理，同时确保需要时的可用性
极限编程-过程循环
极限编程是一个敏捷过程。
极限编程是一个敏捷过程，因为它 -
强调大量的沟通和反馈 -
团队内部（结对编程、集体代码所有权、简单设计）
与客户（现场客户及验收测试）
用于发布计划（客户和开发人员参与估算）
极限编程聘请了一位教练，他的工作是注意到人们不沟通的情况并重新介绍他们。
拥抱变化 -
频繁迭代（短版本）
轻松设计和重新设计（简单设计）
持续编码和测试（结对编程）
让客户持续参与（在线客户）
在短迭代（短版本）中向客户交付工作产品。
尽早消除缺陷，从而降低成本（结对编程）
代码审查
单元测试
集成每组更改和测试
极限编程过程周期
极限编程是迭代和增量的，并由限时周期驱动。因此，极限编程过程的节奏至关重要。
极限编程有以下活动级别 -
产品生命周期
发布
迭代
任务
发展
反馈
每个活动级别都提供下一个级别所需的最少输入。他们是 -
产品生命周期活动为发布周期提供输入。
发布计划会议为迭代周期提供输入。
迭代计划会议为任务周期提供输入。
任务开发为开发阶段提供输入。
开发产生产品。
反馈是整个项目和所有上述活动级别的持续活动。
产品生命周期
这也称为探索阶段。它涉及功能集定义和规划。客户提出高价值要求，并且这些要求以用户故事的形式给出。
故事是该级别活动的主要交付成果。
发布
这也称为承诺阶段。在本次活动中 -
整个团队聚集在一起，以便 -
审查进展情况。
可以添加新的要求和/或可以更改或删除现有的要求。
客户讲述故事。
故事被讨论。
开发人员确定技术方法和风险。他们提供一级估计和选项。
客户对故事进行优先级排序并选择目标发布时间框。
客户和开发人员承诺要包含的功能以及下一个版本的日期。
开发商 -
将故事排列成可能的迭代。
包括先前版本的验收测试中的缺陷修复。
开始迭代。
发布计划是该级别活动的主要可交付成果。
迭代
这也称为转向阶段。整个团队聚集在一起，以便审查进度并调整计划。客户提出迭代的故事，并且对这些故事进行更详细的讨论。
迭代计划是该活动的主要交付成果。
开发商 -
确定详细的技术方法。
为每个故事创建任务列表。
开始开发。
尽可能部署系统
可部署系统是本次活动的最终交付成果。
任务
开发人员注册任务并开始开发Plotly来实现故事。他们确保迭代的任务完成。开发人员还确保迭代的故事通过验收测试完成。
发展
开发人员结对，这可以是一项持续且动态的活动。
每对 -
验证他们对故事的理解。
确定详细的实现方法，确保设计简单。
开始测试驱动开发，即编写单元测试，实现代码以通过单元测试，重构使代码变得简单