极限编程 - 快速指南

---

---

极限编程 - 简介

本章概述了极限编程。

什么是敏捷？

“敏捷”一词意味着 -

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

• 能够快速清晰地思考。

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

参考：剑桥在线词典。

在软件开发中，“敏捷”一词被用来表示“能够应对变化 - 来自需求、技术和人员的变化”。

敏捷宣言

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

敏捷宣言指出 -

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

• 个体和互动高于流程和工具。

• 可工作的软件高于详尽的文档。

• 客户合作高于合同谈判。

• 响应变化高于遵循计划。

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

敏捷的特点

以下是敏捷的特点 -

• 敏捷软件开发中的敏捷侧重于整个团队的文化，拥有赋权且自组织的多学科、跨职能团队。

• 它培养了共同的责任和问责制。

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

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

• 频繁且持续的交付确保了快速反馈，这反过来又使团队能够与需求保持一致。

• 协作有助于及时将不同的视角结合到实施、缺陷修复和适应变化中。

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

软件工程趋势

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

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

  • 在开发后期抵制更改。

  • 需要一个严格的变更流程，该流程涉及变更控制委员会，甚至可能将变更推迟到以后的版本。

  • 交付具有过时需求的产品，无法满足客户的期望。

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

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

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

  • 衡量和跟踪流程本身。这变得昂贵，因为 -

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

  • 定义指导开发的度量标准，并在开发中衡量每个活动。

  • 管理干预。

• 在开发之前详细说明、分析和验证模型。

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

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

  • 负责生产的开发人员通常与客户没有持续沟通。

  • 编码被视为设计的翻译，代码中的有效实现很少回馈到设计中。

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

  • 开发早期阶段的进度延误通过忽略测试要求来弥补，以确保按时交付。

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

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

• 限制资源（主要是团队）以适应预算会导致 -

  • 资源过度分配

  • 团队倦怠。

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

  • 人员流失。

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

软件工程涉及 -

• 创造力

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

• 迭代

极限编程建立在这些活动和编码的基础上。它是详细的（而非唯一的）设计活动，通过有效的实现、测试和持续重构来实现多个紧密的反馈循环。

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

• 沟通

• 简单性

• 反馈

• 勇气

• 尊重

什么是极限编程？

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

极限编程 (XP) 的构思和开发是为了解决小型团队在面对模糊和不断变化的需求时软件开发的特定需求。

极限编程是敏捷软件开发方法之一。它提供价值观和原则来指导团队行为。团队预计会进行自我组织。极限编程提供具体的核心实践，其中 -

• 每个实践都简单且自成一体。

• 实践的组合产生了更复杂和涌现的行为。

拥抱变化

极限编程的一个关键假设是，更改程序的成本可以在一段时间内保持大致恒定。

这可以通过以下方式实现 -

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

• 短期迭代

• 设计和重新设计

• 频繁编码和测试

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

• 让客户始终参与开发

• 向客户交付可工作的产品

极限编程概览

极限编程涉及 -

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

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

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

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

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

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

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

为什么称之为“极限”？

极限编程将有效的原则和实践推向极致。

• 代码审查非常有效，因为代码始终会被审查。

• 测试非常有效，因为存在持续的回归和测试。

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

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

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

极限编程的历史

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

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

在 90 年代初，核心价值观在模式社区、山坡小组中发展起来。1995 年，Kent 在 Smalltalk 最佳实践中总结了这些内容，1996 年，Ward 在剧集中总结了这些内容。

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

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

极限编程自那时以来一直在发展，并且这种发展一直持续到今天。

行业成功

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

• 快速开发。

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

• 专注于低缺陷率。

• 系统持续向客户提供一致的价值。

• 高客户满意度。

• 降低成本。

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

极限编程的优势

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

• 计划延误 - 可实现的开发周期确保按时交付。

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

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

• 生产和交付后缺陷：重点在于 - 单元测试以尽早检测和修复缺陷。

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

• 业务变更 - 变更被认为是不可避免的，并且可以在任何时候进行调整。

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

极限编程 - 价值观和原则

XP 旨在通过引入基本价值观、原则和实践来降低变更成本。通过应用 XP，系统开发项目应该在变更方面更加灵活。

极限编程价值观

极限编程 (XP) 基于五个价值观 -

• 沟通

• 简单性

• 反馈

• 勇气

• 尊重

沟通

沟通在项目的成功中起着重要作用。项目问题通常是由于缺乏沟通造成的。许多情况都可能导致沟通中断。一些常见问题包括 -

• 开发人员可能不会将设计中的关键更改告知其他人。

• 开发人员可能没有向客户提出正确的问题，因此错过了关键的领域决策。

• 经理可能没有向开发人员提出正确的问题，导致项目进度被错误地报告。

• 开发人员可能忽略了客户传达的一些重要信息。

极限编程强调团队成员、经理和客户之间持续不断的沟通。极限编程实践，例如单元测试、结对编程、简单设计、通用隐喻、集体代码所有权和客户反馈，都关注沟通的价值。

XP 采用教练的角色，其工作是观察人们是否没有进行沟通，并在必要时重新引导他们。面对面沟通是首选，可以通过结对编程来实现，并且客户代表始终在场。

简单性

极限编程认为“今天做一件简单的事情，明天花一点额外代价来修改它”，比“今天做一件可能永远不会被使用到的复杂的事情”更好。

• 做需要做的事情和被要求做的事情，但不要做更多。

  • “做最简单的能起作用的事情”——DTSTTCPW 原则。

  • 以最简单的方式实现新的功能。也称为 KISS 原则，“保持简单，傻瓜！”。

  • 当教练看到极限编程开发人员做一些不必要复杂的事情时，可能会说 DTSTTCPW。

  • 重构系统，使其成为具有当前功能集的最简单的代码。这将最大化迄今为止所做投资所产生的价值。

• 朝着目标迈出小而简单的步伐，并在发生故障时进行缓解。

• 创造一些你感到自豪的东西，并以合理的成本长期维护它。

• 永远不要实现你现在不需要的功能，即“你不会需要它”（YAGNI）原则。

沟通和简单性相互支持。

你沟通得越多，就能越清楚地看到需要做什么，并且对真正不需要做什么的事情更有信心。

你的系统越简单，你就需要沟通的内容越少，需要的开发人员也越少。这将带来更好的沟通。

反馈

每次迭代的承诺都会通过交付可工作的软件来认真对待。软件尽早交付给客户，并获取反馈，以便在需要时进行必要的更改。关于系统当前状态的具体反馈是无价的。反馈的价值在于一个持续运行的系统，该系统以可靠的方式提供关于自身的信息。

在极限编程中，在不同时间尺度上的所有级别都确保了反馈 -

• 客户告诉开发人员他们感兴趣的功能，以便开发人员可以只专注于这些功能。

• 单元测试告诉开发人员系统的状态。

• 系统和代码向经理、利益相关者和客户提供关于开发状态的反馈。

• 频繁发布使客户能够执行验收测试并提供反馈，并使开发人员能够根据该反馈开展工作。

• 当客户编写新的功能/用户故事时，开发人员会估算交付更改所需的时间，以便与客户和经理设定期望。

因此，在极限编程中，反馈 -

• 充当变革的催化剂

• 指示进度

• 让开发人员确信他们走在正确的道路上

勇气

极限编程以以下方式为开发人员提供勇气 -

• 专注于所需内容

• 沟通并接受反馈

• 如实告知进度和估算

• 重构代码

• 适应发生的任何变化

• 丢弃代码（原型）

这是可能的，因为没有人单独工作，并且教练持续指导团队。

尊重

尊重是一个深层的价值观，它存在于其他四个价值观的表面之下。在极限编程中，

• 每个人都尊重彼此作为宝贵的团队成员。

• 每个人都贡献价值，例如热情。

• 开发人员尊重客户的专业知识，反之亦然。

• 管理层尊重开发人员接受责任并对其自身工作拥有权威的权利。

结合沟通、简单性和具体反馈，勇气变得极其宝贵。

• 沟通支持勇气，因为它为更多高风险、高回报的实验打开了可能性。

• 简单性支持勇气，因为对于简单的系统，你可以承担更大的勇气。你不太可能在不知情的情况下破坏它。

• 勇气支持简单性，因为一旦你看到简化系统的可能性，你就会尝试它。

• 具体反馈支持勇气，因为如果你能看到测试最终变绿，你会觉得尝试对代码进行激进的修改更加安全。如果任何测试没有变绿，你就知道可以丢弃该代码。

极限编程原则

价值观很重要，但它们很模糊，从某种意义上说，可能无法确定某件事是否有价值。例如，从某人的角度来看很简单的事情，从其他人的角度来看可能很复杂。

因此，在极限编程中，基本原则源于价值观，以便可以根据这些原则检查开发实践。每个原则都体现了价值观，并且更具体，例如快速反馈 - 你要么拥有它，要么没有。

极限编程的基本原则为 -

• 快速反馈

• 假设简单性

• 增量变化

• 拥抱变化

• 高质量工作

快速反馈

快速反馈是为了获取反馈，理解它，并尽快将学习成果反馈到系统中。

• 开发人员设计、实现和测试系统，并在几秒钟或几分钟内使用该反馈，而不是几天、几周或几个月。

• 客户审查系统以检查它如何才能做出最佳贡献，并在几天或几周内提供反馈，而不是几个月或几年。

假设简单性

假设简单性就是将每个问题都视为可以用简单的方式解决。

传统上，你会被告知要为未来计划，为重用而设计。这种方法的结果可能变成“客户今天需要的没有得到满足，最终交付的内容可能已经过时且难以更改。”

“假设简单性”意味着“做好今天工作的准备，并相信你能够在未来需要的地方添加复杂性。”在极限编程中，你会被告知要做好工作（测试、重构和沟通），专注于今天重要的事情。

• 有了良好的单元测试，你可以轻松地重构代码以进行其他测试。

• 遵循 YAGNI（你不会需要它）。

• 遵循 DRY（不要重复自己）原则。例如，

  • 不要有多个相同（或非常相似）代码的副本。

  • 不要有多个冗余的信息副本。

  • 不要浪费时间和资源在可能不需要的事情上。

增量变化

在任何情况下，一次性进行的重大更改都无法奏效。任何问题都可以通过一系列最小的更改来解决，这些更改会带来变化。

在极限编程中，增量变化以多种方式应用。

• 设计每次都稍作更改。

• 计划每次都稍作更改。

• 团队每次都稍作更改。

即使是极限编程的采用也必须分步骤进行。

拥抱变化

最佳策略是在实际解决最紧迫问题的同时保留最多的选项。

高质量工作

每个人都喜欢做好工作。他们试图产生他们感到自豪的质量。团队

• 工作良好

• 享受工作

• 在生产有价值的产品时感觉良好

极限编程 - 实践

极限编程中有四项基本活动。他们是 -

• 编码

• 测试

• 倾听

• 设计

根据极限编程原则对这四项基本活动进行结构化。为了实现这一点，定义了极限编程实践。

这 12 种极限编程实践实现了极限编程的目标，并且在其中一种实践薄弱的情况下，其他实践的优势将弥补不足。

《极限编程解释》的作者肯特·贝克将 12 种极限编程实践定义如下 -

• 计划游戏

• 短迭代

• 隐喻

• 简单设计

• 测试

• 重构

• 结对编程

• 集体代码所有权

• 持续集成

• 40 小时工作制

• 现场客户

• 编码规范

极限编程的四个领域

极限编程实践可以分为四个领域 -

• 快速、精细的反馈 -

  • 测试

  • 现场客户

  • 结对编程

• 持续流程 -

  • 持续集成

  • 重构

  • 短迭代

• 共享理解 -

  • 计划游戏

  • 简单设计

  • 隐喻

  • 集体代码所有权

  • 编码规范

• 开发人员福利 -

  • 40 小时工作制

在本章中，您将详细了解极限编程实践以及每种实践的优势。

极限编程实践一览

下图显示了极限编程是如何围绕极限编程实践展开的 -

计划游戏

极限编程中的主要计划流程称为计划游戏。游戏是在每次迭代（通常每周一次）进行的会议。计划游戏的目的是通过结合业务优先级和技术估算，快速确定下一次发布的范围。随着现实超越计划，更新计划。

业务和开发需要同步做出决策。业务决策和开发的技术决策必须相互一致。

业务人员需要决定 -

• 范围 - 为使系统在生产中具有价值，必须解决多少问题？业务人员能够理解什么是不够的，什么太多了。

• 优先级 - 如果给您一个选择，您想要哪个？业务人员能够确定这一点，而不是开发人员，但需要客户的输入。

• 发布构成 - 在业务从软件中获得比没有软件更好的收益之前，需要做多少或多做多少？开发人员对这个问题的直觉可能完全错误。

• 发布日期 - 在哪些重要的日期软件（或部分软件）的存在会产生重大影响？

技术人员需要决定 -

• 估算 - 实现一项功能需要多长时间？

• 后果 - 只有在了解技术后果的情况下，才应做出战略性业务决策。开发需要解释后果。

• 流程 - 工作和团队将如何组织？团队需要适应其运营的文化。软件必须写得好，而不是保留封闭文化的非理性。

• 详细调度 - 在发布范围内，哪些故事应该首先完成？开发人员需要自由地首先安排最冒险的开发部分，以降低项目的整体风险。在该约束下，他们仍然倾向于将业务优先级提前到开发中，从而降低了由于时间限制而不得不放弃重要故事的可能性，这些故事可能在发布开发结束时被放弃。

因此，计划是客户、业务人员和开发人员之间协作的结果。

计划游戏 - 优势

计划游戏具有以下优势 -

• 减少浪费在无用功能上的时间

• 提高客户对功能成本的认识

• 减少计划中的猜测

短迭代

你应该快速将一个简单的系统投入生产，然后以非常短的周期发布新版本。每次发布都应该尽可能小，以便于它能够−

• 在短周期内实现

• 包含最有价值和最直接的业务需求

• 成为一个可工作的系统

短周期的持续时间可能会因需要构建的软件而异。但是，需要确保选择尽可能短的持续时间。

短周期发布 - 优势

短周期发布的优势在于−

• 频繁的反馈

• 跟踪

• 降低整体项目延期的可能性

隐喻

根据剑桥在线词典 - 隐喻是一种表达方式，通常见于文学作品中，它通过指代被认为具有与该人物或物体相似特征的事物来描述一个人或物体。例如，“思想是海洋”和“城市是丛林”都是隐喻。

你应该用一个简单的共享故事来指导整个开发过程，这个故事讲述了整个系统是如何工作的。你可以将隐喻视为要构建的系统的架构，以便所有参与开发的人员都能轻松理解。

隐喻由特定领域的元素组成，并展示了它们之间的相互联系。使用的语言是领域语言。为了识别技术实体，需要一致地使用隐喻中的词语。

随着开发的进行和隐喻的成熟，整个团队将从检查隐喻中获得新的灵感。

良好架构的目标是为每个人提供一个连贯的故事来开展工作，这是一个既可以被业务人员，也可以被技术人员轻松共享的故事。因此，在极限编程中，通过要求一个隐喻，我们更有可能获得一个易于沟通和阐述的架构。

隐喻 - 优势

隐喻的优势在于−

• 鼓励为系统使用一套通用的术语

• 减少流行语和行话

• 一种快速简便的解释系统的方法

简单设计

在任何给定时刻，系统都应该尽可能简单地设计。一旦发现额外的复杂性，就将其移除。

在任何给定时间，软件的正确设计是−

• 运行所有测试

• 没有重复的逻辑，例如并行的类层次结构

• 陈述对开发人员至关重要的所有意图

• 具有尽可能少的类和方法

为了获得简单的设计，请消除任何可以消除的设计元素，但不要违反前三个规则。这与“今天实现，明天设计”的建议相反。如果你认为未来是不确定的，并且你可以快速增强设计，那么不要基于猜测添加任何功能。

简单设计 - 优势

简单设计的优势在于−

• 不会浪费时间添加多余的功能

• 更容易理解正在发生的事情

• 重构和集体所有权成为可能

• 帮助程序员保持正轨

测试

开发人员持续编写单元测试，开发需要通过这些测试才能继续进行。客户编写测试以验证功能是否已实现。测试是自动化的，因此它们成为系统的一部分，并且可以持续运行以确保系统的正常工作。结果是能够接受更改的系统。

测试 - 优势

测试的优势在于−

• 单元测试促进了测试的完整性

• 测试先行为开发人员提供了一个目标

• 自动化提供了一套回归测试

重构

在实现功能时，开发人员总是会问是否有办法更改现有代码以简化功能的添加。在添加功能后，开发人员会问他们现在是否可以看到如何使代码更简单，同时仍然运行所有测试。他们重构系统而不改变其行为以消除重复、改进沟通、简化或增加灵活性。这称为重构。

重构 - 优势

重构的优势在于−

• 促使开发人员主动改进整个产品

• 提高开发人员对系统的了解

结对编程

在结对编程中，整个代码由两名开发人员在一台机器上编写，使用一个键盘和一个鼠标。

每对中都有两个角色−

• 第一个开发人员（拥有键盘和鼠标的人）思考如何在这里正确实现此方法。

• 另一个开发人员则从更策略的角度思考

  • 这种整体方法是否有效？

  • 可能还有哪些其他测试用例尚未通过？

  • 是否有办法简化整个系统，以便当前问题消失？

结对是动态的。这意味着两个角色 A 和 B 可以交换位置，或者他们可以与其他团队成员配对。更常见的是，团队中的任何人都可以作为搭档。例如，如果你负责一个你不熟悉的领域的任务，你可能会要求最近有经验的人与你配对。

结对编程 - 优势

结对编程的优势在于−

• 三个臭皮匠，胜过一个诸葛亮

• 专注

• 两个人更有可能回答以下问题−

  • 这种整体方法是否有效？

  • 可能还有哪些测试用例尚未通过？

  • 有没有办法简化它？

集体代码所有权

在极限编程中，整个团队对整个系统负责。尽管每个人都对每个部分都有一些了解，但并非每个人都对每个部分都同样了解。

如果一对开发人员正在工作，并且他们发现有机会改进代码，他们就会继续改进它。

集体所有权 - 优势

集体所有权的优势在于−

• 有助于减轻离职团队成员造成的损失。

• 促使开发人员对整个系统负责，而不是对系统的一部分负责。

持续集成

代码每天集成和测试多次，每次一组更改。一个简单的方法是有一台专门用于集成的机器。一对准备集成的代码−

• 在机器空闲时开始工作。

• 加载当前版本。

• 加载他们的更改（检查并解决任何冲突）。

• 运行测试，直到它们通过（100% 正确）。

一次集成一组更改有助于了解谁应该修复失败的测试。答案是当前的开发人员对，因为上一对开发人员将测试留在了 100%。他们可能不得不放弃他们所做的事情并重新开始，因为他们可能没有足够的知识来编写该功能。

持续集成 - 优势

持续集成的优势在于−

• 缩短了原本漫长的持续时间。

• 由于发布前所需的时间最少，因此能够实现短周期发布的实践。

40 小时工作制

极限编程强调每个团队成员每周的工作时间有限，基于他们的可持续性，最多每周 45 小时。如果某人工作时间超过此时间，则被视为加班。加班最多允许一周。此实践是为了确保每个团队成员都保持精力充沛、富有创造力、谨慎和自信。

40 小时工作制 - 优势

40 小时工作制的优势在于−

• 大多数开发人员在工作超过 40 小时后效率会下降。

• 重视开发人员的福祉。

• 迫使管理层找到真正的解决方案。

现场客户

在团队中包含一个真实的、活生生的用户，全天候可用，以回答问题、解决争议并设定小规模的优先级。此用户可能不必仅将 40 小时用于此角色，并且也可以专注于其他工作。

现场客户 - 优势

拥有现场客户的优势在于−

• 可以对真实的开发问题给出快速且有见地的答案。

• 确保开发出的内容是需要的。

• 功能的优先级排列正确。

编码规范

开发人员根据强调以下内容的规则编写所有代码：

• 通过代码进行沟通。

• 尽可能少的工作量。

• 与“一次且仅一次”规则一致（没有重复代码）。

• 整个团队自愿采用。

在极限编程中，这些规则是必要的，因为所有开发人员−

• 可以从系统的一部分切换到系统的另一部分。

• 每天交换几次搭档。

• 不断重构彼此的代码。

如果不遵循这些规则，开发人员将倾向于拥有不同的编码实践集，代码随着时间的推移变得不一致，并且无法确定团队中的谁编写了哪些代码。

编码标准 - 优势

编码标准的优势在于−

• 减少开发人员花费在重新格式化其他人代码上的时间。

• 减少对内部注释的需求。

• 要求代码清晰、明确。

极限编程 - 支持性实践

如果单独实施极限编程实践，可能会很薄弱，因此可能会失败。在极限编程中，所有实践都需要作为一个整体来考虑，以便它们相互支持。一个实践的弱点会被其他实践的优势所弥补。

在本章中，我们将重点关注如果单独实施每个实践可能存在的弱点。我们将了解极限编程如何支持此实践，以便在与其他实践结合使用时克服弱点。

计划游戏 - 来自其他 XP 实践的支持

在本节中，我们将了解计划游戏的弱点以及其他 XP 实践如何支持它。

计划游戏 - 缺点

计划游戏的缺点是，你不可能只用一个粗略的计划就开始开发，并且你不能不断更新计划，因为这会花费太长时间并让客户感到不安。

计划游戏与其他XP实践

其他XP实践以以下方式支持计划游戏：

• 在计划游戏中，客户也参与到基于开发人员提供的估算更新计划的过程中。

• 你进行短迭代发布，以便计划中的任何错误最多只会造成几周或几个月的影响。

• 你的客户与团队一起工作，因此他们可以快速发现潜在的变化和改进机会（现场客户）。

• 持续测试帮助开发人员和客户决定立即需要什么。

因此，你可以用一个简单的计划开始开发，并在开发过程中不断完善它。

短迭代发布 - 其他XP实践的支持

短迭代发布 - 缺点

你不可能在几个月后就投入生产。你当然不可能以每天到每两个月为周期发布新版本。这是因为你需要时间来吸收新的需求，并将更改整合到当前代码中。

短迭代发布与其他XP实践。

其他XP实践以以下方式支持短迭代发布：

• 计划游戏帮助你处理最有价值的故事，因此即使是一个小型系统也将具有业务价值。

• 持续集成使打包发布的成本最小化。

• 测试将缺陷率降低到足以使发布前不需要冗长的测试周期的程度。

• 你可以做一个简单的设计，足以满足本次发布的需求，而不是永远适用。

因此，你可以在开发开始后不久就进行短迭代发布。

隐喻 - 其他XP实践的支持

你不可能只用一个隐喻就开始开发。它可能没有足够的细节，而且你可能是错的。

隐喻与其他XP实践

其他XP实践以以下方式支持隐喻：

• 通过结对编程，你将从已实现的代码和测试中获得关于隐喻是否正常工作的快速具体反馈。

• 你的现场客户可以轻松地使用隐喻来谈论系统。

• 持续重构允许你改进你对隐喻在实现中含义的理解。

• 简单设计帮助你与隐喻建立映射关系。

因此，你可以只用一个隐喻开始开发。

简单设计 - 其他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 实践以以下方式支持现场客户。

他们可以为项目创造价值 -

• 在计划游戏（Planning Game）中，为开发人员做出优先级和范围决策。

• 使用隐喻（Metaphor），为开发人员提供领域清晰度。

• 在测试中，通过编写验收测试并在每次短发布后执行验收测试。

因此，他们可以通过为项目做出贡献，为组织创造更多价值。

编码标准 – 来自其他 XP 实践的支持

编码标准 – 缺点

您不可能要求团队按照共同的标准进行编码，因为开发人员通常是个人主义者。

编码标准与其他 XP 实践

其他 XP 实践以以下方式支持编码标准 -

• 结对编程使他们能够轻松地适应必要的编码标准。

• 持续集成强制他们遵循标准，以便代码保持一致。

• 集体代码所有权鼓励他们与标准保持一致，以便在需要时进行更改。

极限编程 - 演进实践

极限编程自诞生以来一直在不断发展，并且发现极限编程实践在其他敏捷方法中也同样有效。

下表显示了极限编程实践是如何演变的。

现场客户 – 完整团队

极限编程依赖于一个项目社区，强调以团队为中心的方法。所有对极限编程项目做出贡献的人，包括客户，都是一个团队。

客户提供需求，设置优先级并指导项目。这使客户能够了解开发的实际细节，并相应地设置优先级和期望。这从“按客户要求开发”转变为“按客户理解并与开发合作”。

项目目标是共同的责任，开发是在整个团队中进行的持续对话。这是一场发明和沟通的合作游戏。人们发现面对面的沟通是开发过程中最高效、最有效的方法，并且消除了等待时间和延迟。

计划游戏 – 发布和迭代计划

增量项目计划被证明是有效的，因为它促进了准确的计划。随着开发的进展，基于实际性能，会学习到更多更好的信息。首先制定一个粗略的计划，然后逐步细化它。

发布计划设定长期目标，并掌握整体的大局观。客户提出所需的功能，开发人员进行估算，并共同商定和承诺发布日期。由于发布计划在每次发布后都会进行修订，因此随着项目的进展，它会变得更加精确。

迭代计划设置短期时间框，包括迭代，通常从 1 周到 1 个月不等。迭代计划的主要目标是在每次迭代结束时获得一个可工作的软件。开发人员选择迭代的功能/故事，将其分解成任务，估计任务并承诺完成分配的任务。通过平衡团队中的负载因素，并考虑 40 小时工作制，确保可持续的节奏。

验收测试

客户为一个功能编写一个或多个自动验收测试，以确保系统正确地实现了所需的功能。验收测试与故事一起编写，并在实施之前提供。

团队自动化这些测试，以验证功能是否正确实现。一旦测试运行，团队确保它此后继续正确运行，在回归时，通过执行到那时为止实施的所有验收测试。

验收测试提供了功能需求的明确规范。此外，通过验收测试的百分比衡量了发布完成情况，没有最后一刻的意外。

系统始终改进，永不倒退。

单元测试

开发人员编写单元测试，并具有足够的覆盖率，包含代码模块和方法的意图和用法。单元测试是自动化的，具有明确的通过/失败结果。大多数语言都有一个 xUnit 框架（例如，nUnit、jUnit）。

所有单元测试都非常频繁地执行，并且在所有单元测试通过之前，代码不能被签入。单元测试结果还有助于重构。

测试驱动开发

测试驱动开发被认为是最具创新性的极限编程实践。

在测试驱动开发中，开发人员在编写代码之前编写单元测试。目的是使单元测试失败。由于代码尚未实现，因此单元测试失败。开发人员编写足够多的代码以使单元测试通过，然后，开发人员进行重构以确保代码简单干净（没有重复和复杂性）。

开发人员迭代直到编码完成并且验收测试通过。

所有单元测试都收集在一起，每次结对集成并将代码发布到存储库时，结对都需要确保每个测试都正确运行。如果任何测试失败，则结对知道是他们的代码需要更正，因为之前的集成在没有任何缺陷的情况下通过了。

测试驱动开发倾向于导致 100% 的单元测试覆盖率，并确保代码简单且最少。

重构 – 设计改进

重构允许设计逐步发展，使其保持简单，在您注意到时消除重复和复杂性。它通过重构改进现有代码的设计，而不改变其功能。

重构应由从新实现中学习来驱动。建议在编写新代码后立即进行重构。重构将代码推向更高级别的设计模式，并得到测试的支持。

40 小时工作制 – 可持续节奏

以可以无限期持续的速度工作。可持续节奏确保人力对项目成功的贡献，考虑到以下事实 -

• 疲劳和压力会降低生产力和产品质量。它可能导致员工流失。

• 开发不会随着冲刺而停止，它应该以长期目标为目标

• 除非团队就期望达成一致，否则不会有承诺和责任感。

• 确切的小时数并不像执行能力那样重要。

• 应避免微观管理，同时确保在需要时可用。

极限编程 - 过程周期

极限编程是一种敏捷过程。

极限编程是一种敏捷过程，因为它 -

• 强调大量的沟通和反馈 -

  • 团队内部（结对编程、集体代码所有权、简单设计）

  • 与客户（现场客户和验收测试）

  • 对于发布计划（客户和开发人员参与估算）

• 极限编程聘用了一位教练，其工作是注意人们何时没有进行沟通并重新引入沟通。

• 拥抱变化 -

  • 频繁迭代（短发布）

  • 轻松设计和重新设计（简单设计）

  • 持续编码和测试（结对编程）

  • 让客户持续参与（在线客户）

• 以短迭代向客户交付可工作的产品（短发布）。

• 尽早消除缺陷，从而降低成本（结对编程）

  • 代码审查

  • 单元测试

  • 每次更改集的集成和测试

极限编程过程周期

极限编程是迭代和增量的，并由时间盒周期驱动。因此，极限编程过程的节奏至关重要。

极限编程具有以下活动级别 -

• 产品生命周期

• 发布

• 迭代

• 任务

• 开发

• 反馈

每个活动级别都提供下一级别所需的最小输入。它们是 -

• 产品生命周期活动为发布周期提供输入。

• 发布计划会议为迭代周期提供输入。

• 迭代计划会议为任务周期提供输入。

• 任务开发为开发阶段提供输入。

• 开发产生产品。

反馈是贯穿整个项目和所有上述活动级别的持续活动。

产品生命周期

这也被称为探索阶段。它涉及功能集的定义和计划。客户确定高价值需求，并将需求作为用户故事提供。

故事是此级别活动的首要交付成果。

发布

这也被称为承诺阶段。在此活动中 -

• 整个团队聚集在一起，以便 -

  • 审查进度。

  • 可以添加新的需求和/或更改或删除现有的需求。

  • 客户提出故事。

  • 讨论故事。

• 开发人员确定技术方法和风险。他们提供第一级估计和选项。

• 客户对故事进行优先级排序并选择目标发布时间框。

• 客户和开发人员承诺要包含的功能以及下一次发布的日期。

• 开发人员 -

  • 将故事安排到可能的迭代中。

  • 包含来自先前发布的验收测试的缺陷修复。

  • 开始迭代。

发布计划是此级别活动的首要交付成果。

迭代

这也被称为指导阶段。整个团队聚集在一起，以便审查进度并调整计划。客户提出迭代的故事，并更详细地讨论这些故事。

迭代计划是此活动的首要交付成果。

开发人员 -

• 确定详细的技术方法。

• 为每个故事创建任务列表。

• 开始开发。

• 部署系统到

可部署系统是此活动的最终交付成果。

任务

开发人员注册任务并开始开发阶段以实施故事。他们确保迭代的任务已完成。开发人员还确保迭代的故事已完成验收测试。

开发

开发人员组成结对，这可以是一个持续的和动态的活动。

每对 -

• 验证他们对故事的理解。

• 确定详细的实施方法，确保简单设计。

• 开始测试驱动开发，即编写单元测试，实现代码以通过单元测试，重构以使代码简单。

• 在适当的间隔将他们的代码集成到系统代码库中。

• 经常审查进度。

反馈

结对在内部以及向团队外部进行持续沟通。在线客户也持续参与沟通。某些团队采用每日站立会议，以便快速讨论整体团队状态以及必要的重新同步和微观计划。

迭代和发布审查提供整体状态和流程调整和改进的要点。

• 开发阶段可能会导致对任务的重新思考。

• 任务开发可能会导致对故事的重新思考。

• 故事重新估算可能导致迭代更改或恢复。

• 迭代结果可能会导致发布计划发生变化。

极限编程流程周期如下图所示。

极限编程 - 成对编程

成对编程是一种编程风格，其中两位程序员并排坐在一台电脑前，共享一个屏幕、键盘和鼠标，持续协作完成相同的设计、算法、代码或测试。

一位程序员，称为**驾驶员**，控制键盘/鼠标并主动实现代码或编写测试。另一位程序员，称为**领航员**，持续观察驾驶员的工作以识别缺陷，并从战略上思考工作的方向。

如有必要，两位程序员可以一起头脑风暴任何具有挑战性的问题。两位程序员定期轮换角色，并平等合作开发软件。

结对编程 - 优势

成对编程的显著优势包括：

• 许多错误在输入时就被检测到，而不是在质量保证测试或现场检测到。

• 最终缺陷数量在统计上较低。

• 设计更好，代码长度更短。

• 团队解决问题更快。

• 人们对系统和软件开发的了解显著增加。

• 项目最终会有多人理解系统的每个部分。

• 人们学会一起工作并更频繁地交流，从而改善信息流和团队动态。

• 人们更享受他们的工作。

成对编程实验

成对编程实践的使用已被证明可以提高软件产品的生产力和质量。

成对编程研究表明：

• 成对编程的人工时不超过单人编程。

• 成对编程产生的缺陷更少。

• 成对编程产生的代码行数更少。

• 成对编程的人更享受他们的工作。

犹他大学对成对编程进行了实验。结果表明：

• 成对编程的团队在程序上花费的时间比个人多 15%。

• 成对编程编写的代码始终通过的测试用例多于个人编写的代码。

• 成对编程始终使用更少的代码行实现了个人实现的相同功能。

• 在能够快速获得切实结果的环境中学习编程很有趣，并且可以让人更快地学习。

适应成对编程

大多数程序员习惯于独自工作，并且常常抵制向成对编程的转变。但是，通过实践，他们最终可以实现这种转变。

根据 Laurie A. Williams 和 Robert R. Kessler 在他们的书《我在幼儿园学到的关于成对编程的所有知识》中，很好地解释了如何培养我们在幼儿园学到的技能，以建立团队凝聚力，尤其是在成对编程中。

作为一名成对程序员的转变和持续成功通常涉及练习日常礼仪。

以下部分摘自此出版物，可帮助您成为高效的成对程序员。

幼儿园课程

在幼儿园，我们学习了以下内容：

• 分享一切

• 公平竞争

• 不要打人

• 把东西放回原处

• 清理自己的垃圾

• 不要拿不属于你的东西

• 当你伤害别人时说对不起

• 饭前洗手

• 冲水

• 暖烘烘的曲奇和冰牛奶对你有益

• 过平衡的生活——每天学习一些，思考一些，画画，唱歌，跳舞，玩耍和工作。

• 每天下午小睡一下

• 当你走出去的时候，注意交通，手牵手，团结在一起

• 感知奇迹

接下来，我们从上述教诲的角度来看成对编程的原则。

分享一切

在成对编程中，

• 两位程序员坐在一起，共同制作一个工件（设计、算法、代码等）。

• 一个人在打字或书写，另一个人在持续审查工作。两者

  • 都是流程中平等的参与者

  • 对工件的各个方面负责

  • 拥有所有权

公平竞争

在成对编程中，

• 一个人驾驶，即控制键盘或记录设计思路，另一个人持续审查工作。

• 他们定期轮换这些角色，即使其中一个人比另一个人经验丰富得多，以确保平等参与。

• 当驾驶员思考实现时，另一个人持续审查代码，思考可能的更简单的设计，当前开发如何融入当前的整体系统。

不要打你的搭档

在成对编程中，

• 确保你的搭档保持专注和任务导向。

• 你也要保持专注和任务导向。

• 确保你的搭档遵循规定的编码标准，从而维护对团队其他成员的承诺。

在成对编程调查中，发现实现了巨大的生产力提升和质量改进。这是因为：

• 每个人都让他们的搭档保持专注和任务导向，没有懈怠的可能性。

• 每个工件在生成时都会持续审查，确保质量。

把东西放回原处

在成对编程中，

• 你需要相信自己的技能和你搭档的技能。这方面的任何负面想法都应该扔进垃圾桶。

• 你必须确保你表达你所知道的，并在需要时愿意向你的搭档学习。你可以通过观察他或立即获取他的反馈来向你的搭档学习。

• 你需要有信心：

  • 无论何时有落后的可能性，你都可以立即从你的搭档那里接手。

  • 作为一对，你们可以解决自己无法解决的问题。

  • 你们可以帮助提高彼此的技能。

清理你的垃圾

在成对编程中，使用“肩并肩观察”技术，

• 你会发现，知道你的搭档发现了多少明显但未被注意的缺陷是一件令人惊奇的事情。

• 你可以消除这些缺陷，而不会在正式的检查会议中产生可能产生的自然敌意。

• 描述缺陷预防和缺陷消除效率。

不要把事情看得太严重

拥有一个搭档来持续客观地审查设计和代码是成对编程的一个非常有益的方面。在成对编程中，你需要确保你在工作中没有过度的自我或过少的自我。

这是必要的，因为

• 过度的自我可以表现为两种方式：

  • 拥有“我的方式或高速公路”的态度可能会阻止程序员考虑他人的想法。

  • 具有防御性可能会导致程序员不接受建设性批评或将这种批评视为不信任。

这两种自我表现方式都会损害合作关系。

• 另一方面，一个总是同意搭档意见以避免产生紧张气氛的人也会最大限度地减少协作工作的益处。为了进行有利的想法交流，在需要时应该有一些健康的意见分歧/辩论。

因此，需要在表现出太多自我和太少自我之间取得微妙的平衡。有效的成对程序员在最初的调整期内培养这种平衡，根据个人、工作性质和他们过去在成对编程方面的经验，调整期可能需要几个小时或几天。

当你搬动家具时，如果不小心伤害了别人，要道歉

程序员必须能够并排坐在一起编程，同时查看电脑屏幕并共享键盘和鼠标。极限程序员有一个“滑动键盘/不要移动椅子”的规则。

为了确保有效沟通，无论是在协作对内部还是与其他协作对之间，程序员都需要能够看到彼此，互相提问并在诸如集成问题等方面做出决策，而无需付出太多努力。程序员还可以从听到其他对话中受益，因为他们可以对这些对话做出至关重要的贡献。

在你开始之前放弃怀疑

为了成对编程的成功，有必要让两位搭档都理解编程中协作的价值、益处和体验的乐趣。这方面任何怀疑都必须在开始时就停止。

经验表明，拥有一位非常积极和/或经验丰富的成对程序员可以带领这对搭档成为一个团结协作的团队，最终取得胜利。

• 这样一个团队的产出大于相同人员以非团结形式工作时的产出。

• 人们从工作中获得的乐趣大于你根据工作本身的性质所期望的乐趣。

• 一旦团队开始凝聚，成功的可能性就会大幅上升。

冲水

成对程序员可以独立地完成某些工作。但是，当他们重新加入时，他们必须在合并之前审查独立的工作，或者冲洗并重写独立的工作，并持续审查工作，从而识别额外的缺陷。

在没有搭档审查的情况下，永远不要合并任何独立的工作。这是因为研究表明，与成对产生的工作相比，独立工作存在缺陷。

暖烘烘的曲奇和冰牛奶对你有益

成对程序员让彼此持续保持专注和任务导向。这可能非常激烈且精神上令人筋疲力尽。因此，定期休息以保持体力，以便进行另一轮富有成效的成对编程。

在休息期间，最好断开与任务的连接，并在重新开始时以新鲜感来处理它。建议的活动包括查看电子邮件、打电话、浏览网页或进行零食休息。

过平衡的生活

定期与他人沟通是过平衡生活的关键。与你的搭档和其他程序员进行非正式的讨论，可以交流有效的想法和高效地传递信息。

每天下午休息一下，不要一直一起工作

没有必要每天下午都分开工作，但可以接受单独工作 10-50% 的时间。这是因为：

• 许多程序员更喜欢单独进行实验性原型设计、艰难的、需要高度集中注意力的难题和逻辑思考。

• 简单、定义明确和例行的编码由单独的程序员完成效率更高，然后与搭档一起审查。

注意交通，手牵手，团结在一起

在成对编程中，

• 两者之间不应该存在竞争。两者必须一起工作，仿佛工件是由一个人的思想产生的。

• 搭档需要信任彼此的判断和对团队的忠诚。

• 搭档永远不应该为任何问题或缺陷责怪另一个搭档。

意识到两个大脑的力量

当两个人一起工作时，每个人都有自己的一套知识和技能，包括：

• 他们能够有效沟通的共同知识和技能集。

• 允许他们为完成任务做出贡献的独特技能。

总之，一对搭档将：

• 想出比两人单独工作时多出两倍以上的解决方案。

• 更快地缩小到最佳解决方案。

• 更快地实现它，并且质量更高。

因此，成对编程是一种强大的技术，因为有两个大脑始终专注于同一个问题。它迫使一个人完全集中精力解决手头的问题。

极限编程 - 角色

在极限编程中，重点是整个团队的协作，团队成员在同一个地点并保持持续沟通。

然而，极限编程项目的运作需要一些特定的角色，而承担这些角色的人员则承担相应的责任，并对其对这些角色的贡献负责。建议为这些角色分配合适的人员，而不是试图改变人员以适应这些角色。

极限编程中的角色

在极限编程中发现有效的角色有：

• 开发人员（一些团队也称为程序员）
• 客户
• 经理（也称为跟踪者）
• 教练

开发人员

开发人员的角色是极限编程中最重要的角色之一。要在极限编程中成为一名开发人员，您需要熟悉以下内容：

• 开发人员权利

  • 您有权了解需要什么，并有明确的优先级声明。

  • 您有权始终交付高质量的工作。

  • 您有权向同行、上司和客户寻求并获得帮助。

  • 您有权进行并更新自己的估算。

  • 您有权承担自己的责任，而不是被分配责任。

• 您将对此负责的主要责任：

  • 估算用户故事

  • 从用户故事中定义任务

  • 估算任务

  • 编写单元测试

  • 编写代码以通过编写的单元测试

  • 执行单元测试

  • 重构

  • 持续集成

• 开发人员技能

  • 结对编程

  • 沟通 - 必要且细节充分

  • 始终使用隐喻来使用正确的名称

  • 仅编写所需代码。

  • 保持简单

• 集体代码所有权

  • 如果有人更改了您编写的代码，无论系统中的哪个部分，您都必须信任这些更改并学习。如果更改方向错误，您有责任改进情况，但要小心，不要责怪任何人。

  • 准备好承认你的恐惧。记住，您是团队的一员，勇气是极限编程成功的必要条件。

• 在团队中以开发人员的身份佩戴不同的帽子，例如：

  • 程序员。

  • 架构师和设计师。

  • 界面架构师/UI设计师。

  • 数据库设计人员和DBA。

  • 运维和网络设计人员。

• 有时开发人员之一必须戴上测试人员的帽子。

  • 帮助客户选择和编写功能测试。

  • 定期运行功能测试。

  • 报告测试结果。

  • 确保测试工具正常运行。

客户

在极限编程中，客户角色与开发人员角色一样至关重要，因为客户应该知道要编程什么，而开发人员应该知道如何编程。

这引发了客户角色某些技能的必要性：

• 以必要和充分的细节编写所需的故事。

• 培养对项目成功的态度。

• 在无法控制项目的情况下影响项目。

• 不时做出关于所需功能范围的决策。

• 愿意随着产品发展而改变决策。

• 编写功能测试。

在极限编程中，要求客户与团队保持持续沟通，并以单一的声音与团队交流。这是因为：

• 客户可能是多个利益相关者。

• 客户可能是一个社区。

• 客户并不总是负责人（代理人）。

• 客户可以是一个团队，其成员包括：

  • 产品经理

  • 市场营销、销售

  • 业务分析师

  • 最终用户、他们的经理

  • 业务/系统运维

客户的主要责任：

• 编写用户故事

• 编写功能测试

• 设置故事的优先级

• 解释故事

• 决定关于故事的问题

客户对这些责任负责。

经理

在极限编程中，经理的主要职责：

• 定义计划游戏的规则。

• 使团队和客户熟悉计划游戏的规则。

• 监控计划游戏，修复任何偏差，并在需要时修改规则。

• 安排和主持发布计划和迭代计划会议。

• 在团队进行估算时参与其中，以提供关于现实如何符合他们先前估算的反馈，无论是在团队层面还是个人层面，这最终有助于他们在下次提出更好的估算。

• 确保团队在他们通过迭代推进的过程中朝着下一个版本努力，并保持承诺的进度和承诺的功能。

• 跟踪功能测试缺陷。

• 跟踪每个团队成员的实际花费时间。

• 培养获取所有所需信息而不干扰团队工作的能力。经理对这些责任负责。

教练

极限编程是团队中每个人的责任。但是，如果团队是极限编程的新手，那么教练的角色至关重要。

教练的职责：

• 深入了解将极限编程应用于项目。

• 确定在出现任何问题时有帮助的极限编程实践。

• 即使在其他人恐慌时也要保持冷静。

• 默默观察团队，只有在预见到重大问题时才干预，并让团队也看到问题。

• 确保团队能够自力更生。

• 随时准备提供帮助。

极限编程 - 活动与工件

在本章中，我们将了解极限编程的活动和工件。

XP – 活动

在极限编程中，四个基本活动是：

• 编码

• 测试

• 倾听

• 设计

编码

在结对编程中，编码被认为是开发的核心。你编写代码，因为如果你不编写代码，在一天结束时你什么也没做。

测试

在结对编程中，需要进行测试以确保编码已完成。如果你不测试，你就不知道什么时候完成了编码。

倾听

在结对编程中，你倾听以了解要编写什么代码或要测试什么。如果你不听，你就不知道要编写什么代码或要测试什么。

设计

在结对编程中，你进行设计以便你可以无限期地继续编码、测试和倾听，因为良好的设计允许扩展系统，并且只在一个地方进行更改。

这些活动在以下期间执行：

• 发布计划

• 迭代计划

• 实施

发布计划

在发布计划中，客户和开发人员共同制定下一个版本的计划，商定该版本的和下一个版本的发布日期的用户故事。

发布计划有三个阶段：

• 探索阶段

• 承诺阶段

• 指导阶段

发布计划 - 探索阶段

在探索阶段：

• 客户提供系统的高价值需求的短名单。

• 开发人员收集需求并估算每个需求的工作影响。

需求记录在用户故事卡片上。为了编写故事，客户将在与开发人员的会议中提出一个问题。开发人员将尝试定义此问题并获取需求。根据此讨论，客户将编写一个故事，指出他们希望系统的一部分执行的操作。重要的是开发人员对这个故事没有影响。

主动倾听在这个阶段非常重要，因为

• 开发人员需要了解“客户的要求”和“哪些需求具有高价值”。

• 客户需要与开发人员一起了解哪些场景有助于这些价值来编写故事。

虽然客户在用户故事卡片上编写需求，但您需要倾听

• 获得清晰度

• 避免歧义

• 如果理解方面存在可能的差距，请表达自己

这只有通过口头交流才能实现。

发布计划 - 承诺阶段

在承诺阶段，客户和开发人员将承诺包含的功能以及下一个版本的日期。

此阶段涉及确定成本、收益和进度影响。在此阶段，

• 客户按业务价值对用户故事进行排序。

• 开发人员按风险对故事进行排序。

• 开发人员确定实施故事所需的工作量和持续时间（估算）。

• 将选择将在下一个版本中完成的用户故事。

• 根据用户故事和估算，确定发布日期。

主动倾听在这个阶段非常重要，因为：

• 开发人员需要了解他们需要为当前版本编写什么功能以及交付此功能所需的工作量和持续时间（估算）。

• 客户和开发人员需要了解对下一个版本日期的承诺的可行性。

发布计划 - 指导阶段

在指导阶段，客户和开发人员“指导”：

• 更改单个用户故事和不同用户故事的相对优先级。

• 调整计划。

• 如果估算被证明是错误的。

• 以适应更改。

主动倾听在这个阶段非常重要，

• 以了解：

  • 要添加的新需求。

  • 现有需求需要进行哪些更改。

  • 如果删除任何现有需求，对现有系统的影响。

• 得出调整计划所需的估算，考虑

  • 迄今为止完成的工作。

  • 要添加的新需求。

  • 必须更改或删除的现有需求。

迭代计划

在迭代计划中，开发人员参与计划迭代的活动和任务。在此，客户不参与。

迭代计划有三个阶段：

• 探索阶段。

• 承诺阶段。

• 指导阶段。

迭代计划 - 探索阶段

在探索阶段，

• 需求将被转换为不同的任务。

• 任务记录在任务卡上。

• 开发人员估算实施每个任务所需的时间。

• 如果开发人员无法估算任务，因为任务太小或太大，则需要组合或拆分任务。

迭代计划 - 承诺阶段

在承诺阶段，

• 任务分配给开发人员。

• 开发人员接受其负责的任务。

• 开发人员估算完成任务所需的时间，因为开发人员现在负责该任务，并且他或她应该给出任务的最终估算。

• 在团队中的所有开发人员都被分配了任务后，进行负载平衡。

• 本文档对任务的估计时间和负载因子进行了比较。

• 负载因子代表在一个迭代中，假设每周工作40小时，每个开发人员理想的实际开发时间。

• 然后，任务在开发人员之间进行平衡。如果某个开发人员的任务量过大，其他开发人员必须接手他/她的一些任务，反之亦然。

迭代计划 – 方向阶段

在方向阶段，

• 开发人员会获得其中一项他/她已承诺的任务的任务卡。

• 开发人员将与另一位开发人员一起实施此任务，遵循结对编程的实践。

实施

任务的实施工作完成。实施包括设计、编写单元测试、编码、单元测试、重构、持续集成到代码库、集成测试和验收测试，这些都基于任务卡和用户故事卡。

极限编程制品

极限编程并非反文档，而是鼓励只做真正需要做的最少工作量。文档在需要用于分布式共享、历史记录需求、总结等情况下创建。

基本的极限编程制品包括：

• 用户故事卡

• 验收测试

• 估算

• 发布计划

• 迭代计划

• 任务卡

• 设计

• 单元测试用例

• 客户和开发人员沟通记录

用户故事卡

用户故事卡具有以下特点：

• 用户故事卡：

  • 包含从客户角度描述系统行为的简短描述。

  • 必须由客户编写，而不是由开发人员编写。

  • 使用客户的术语，不使用技术术语。

  • 仅应提供足够的细节，以便估算实现故事所需的时间。

• 系统中的每个主要功能对应一张卡。

• 用于创建发布计划的时间估算。

• 驱动验收测试的创建。

验收测试

验收测试必须是一项或多项测试，用于验证故事是否已正确实施。

估算 – 发布计划

将用于发布计划的故事的工作量和持续时间估算：

• 在探索阶段确定目标发布日期。

• 在方向阶段计划调整。

发布计划

发布计划包含：

• 为本次发布选择的用户故事。

• 工作量和持续时间估算。

• 已承诺的目标发布日期。

任务卡

任务卡：

• 包含实施用户故事所需的任务。

• 每个用户故事对应一张任务卡。

• 构成任务估算和任务分配的基础。

估算 – 迭代计划

基于用户故事的任务的工作量和持续时间估算将用于迭代计划，用于承诺阶段的任务分配和负载平衡。

迭代计划

迭代计划包含：

• 为本次迭代选择的用户故事

• 任务分配

• 任务估算

设计

设计包含一个简单的设计，足以满足用户故事的实施需求。

单元测试用例

包含驱动编码和单元测试的单元测试用例。

客户和开发人员沟通记录

客户和开发人员讨论故事以详细说明细节。尽可能口头沟通，必要时进行记录。

极限编程 - 规则

考虑你参与的任何运动。你需要遵守该运动或游戏的规则。同样，在极限编程中，由于整个项目是由团队成员之间以及与业务方（代表客户）的协作驱动的，因此需要在项目开始时就制定出某些规则。这些规则应与极限编程实践保持一致。

这些规则为团队中的每个人提供了一个共同的参考，以便提醒每个人在事情顺利进行时以及事情进展不顺利时需要做什么以及如何做。

我们在极限编程中提到的游戏是计划游戏。

计划游戏的规则

在极限编程中，计划游戏从第一次发布计划会议开始，到最终发布结束。

您必须在第一次发布计划会议之前根据极限编程实践定义计划游戏的规则，并将规则告知业务方和团队。您必须管理项目，确保遵守规则。

但是，在软件开发中，不可能有一套简单的规则适用于每个项目。它们可能需要根据业务和团队进行调整，但不能影响极限编程实践。因此，可以最初制定一套具有必要目标的规则，并且只有在需要时才能在开发过程中修改它们。

游戏的目标是最大化团队生产的软件的价值。从软件的价值中，您必须扣除其开发成本以及开发过程中产生的风险。

团队的策略是尽可能少地投入，以尽可能快地将最有价值的功能投入生产，并结合设计和编码策略来降低风险。

根据第一个可运行系统的技术和业务经验教训，业务方清楚地了解了现在最有价值的功能是什么，团队会快速将其投入生产。

此过程将持续进行迭代和发布，直到整个开发完成。

计划游戏的基本规则可以分为以下几个方面：

• 计划

• 管理

• 设计

• 编码

• 测试

计划

计划在发布计划和迭代计划期间进行。两者的规则相同。

在发布计划中，

• 业务方和团队是参与者。

• 使用故事卡。

• 用户故事由客户在故事卡上编写。

• 用户故事由客户在故事卡上编写。

• 业务方决定要实施的功能的优先级。

• 团队根据故事卡提供估算。

• 计划进行短期的（频繁的小型）发布

• 发布计划需要双方达成一致。

• 下一个发布将被划分为多个迭代。

每次迭代开始时都会进行迭代计划。

在迭代计划中，

• 团队成员是参与者。

• 使用任务卡。

• 为迭代中选择的每个故事生成任务卡。

• 团队成员必须根据任务卡估算任务。

• 每个团队成员都被分配了任务卡。

• 然后，每个团队成员必须根据其分配情况重新估算，以：

  • 接受工作。

  • 承担完成工作的责任。

  • 获得关于实际花费时间的反馈。

  • 改进估算。

  • 尊重这些估算。

因此，谁可以进行和更改估算的规则是明确的。

• 最终分配是在假设每周工作40小时和负载因子的基础上完成的。

管理

• 团队获得一个专门的开放式工作区。

• 每个工作站的布置应使两位开发人员能够并排坐在一起，并轻松滑动键盘和鼠标。

• 设定并管理可持续的节奏（每周工作40小时，并且加班时间不超过一周）。

• 执行计划游戏的规则。

• 修复任何违反极限编程实践的行为。

• 确保团队之间的沟通。

• 避免以下沟通：

  • 无帮助的

  • 不合时宜的

  • 过于详细的

• 鼓励人们四处走动。

• 定期测量实际时间并传达给团队，以便每个团队成员都能了解其绩效与预测的对比。这确保了团队成员在估算方面有所改进。

• 根据需要为团队提供食物。

设计

设计的规则包括：

• 为系统选择一个隐喻，并在开发过程中不断发展它。

• 保持设计的简单性。

• 不要过早添加功能。

• 现在只构建满足当前需求所需的架构，并相信以后可以添加更多。

• 尽可能地进行重构。

编码

编码的规则包括：

• 业务方（代表客户）应始终可用。

• 开发人员应根据强调代码沟通的规则编写所有代码。

• 应确保结对编程。

• 应遵循编码规范。

• 所有代码都必须有单元测试。

• 在为系统的每一部分编写代码之前，先编写单元测试，这样创建代码就会更容易、更快。创建单元测试和创建一些代码使其通过所需的时间与直接编写代码所需的时间大致相同。这简化了回归测试。

• 在编码时，你应该只戴以下四顶帽子之一：

  • 添加新功能，但仅更改实现。

  • 添加新功能，但仅更改接口。

  • 重构代码，但仅更改实现。

  • 重构代码，但仅更改接口。

• 为整个团队提供一个专门的集成工作站。

• 一次只有一对开发人员集成代码，并确保所有测试都通过。

• 应经常进行集成。

• 应使用集体所有权。

测试

测试的规则包括：

• 所有代码在发布之前都必须通过所有单元测试。

• 发现缺陷时编写测试。

• 应经常运行验收测试。

极限编程 - 其他功能

在本章中，我们将学习极限编程的一些其他功能。

反馈循环

极限编程的魅力在于持续的反馈，它让每个人都保持专注，开发工作持续朝着正确的方向发展，不会出现任何延迟。

在极限编程中，反馈是在不同的级别上完成的，并达到必要和足够的细节。这在迭代和发布中也持续不断地进行。

下表说明了反馈事件和反馈持续时间。

项目管理

在极限编程中，项目管理没有得到强调，并且管理者的角色执行最少且最基本的管理活动。

然而，这些活动包含了项目管理的要求。

• 发布计划

  • 范围由用户故事卡片中的用户故事定义。

  • 估算为故事估算，可以以故事点为单位。

  • 交付里程碑由发布计划捕获。

  • 发布被划分为迭代。

• 迭代计划

  • 故事在任务卡片中分解成任务。

  • 估算为任务估算。

  • 任务分配通过平衡团队中的负载因子来完成。

  • 任务验收由团队承诺和责任制来完成。

• 跟踪

  • 速度以项目级别的实际实施时间的故事点表示。

  • 生产力以开发人员级别的实际实施时间的任务估算表示。

  • 缺陷跟踪

极限编程 - 行业经验

从业界执行的极限编程项目中，有一些对团队有用的经验教训。

XP实践的经验教训

在以下章节中，您将了解这些经验教训。

• 简单设计 - 简单设计高效、易于构建和维护。

• 隐喻 - 使用隐喻的主要目的是在整个开发过程中使用特定于领域的名称，这使得客户也可以积极参与开发。

• 集体所有权 - 每个人都为自己的优秀代码感到自豪。通过协作，每个人都为每个人的代码感到自豪。

• 计划 - 如果团队在一个迭代中完成了许多用户故事，则使迭代更小。让团队达成共识以更改计划。

扩展极限编程

最初，极限编程被认为在较小的团队中有效，团队规模最多为 12-16 名开发人员。

后来，人们观察到可以将极限编程扩展到 40-50 人的团队。但是，建议通过构建递归团队来进行扩展。首先构建一个小型团队，然后逐步扩大团队规模，使用第一个团队来为递归团队提供种子。

文档

极限编程不反对任何文档。它鼓励记录所需的内容，何时需要以及仅记录所需和足够的细节。这可能因项目而异，由项目决定文档的范围。但是，极限编程实践不允许跳过文档。

应用XP的优势

极限编程在以下情况下被发现是有利的 -

• 高度不确定的环境

• 内部项目

• 合资企业

应用XP的劣势

极限编程在以下情况下被发现是不利的 -

• 环境庞大而复杂。

• 需求得到了很好的理解。

• 客户距离较远或无法联系。

XP的误解

关于极限编程有一些误解。下表给出了存在的误解的澄清。

Scrum + 极限编程

极限编程是最早出现的敏捷方法之一，并且在不断发展。肯特·贝克（Kent Beck），极限编程的创始人，在开发它时，其前提是使用最佳编程实践并将它们发挥到极致。

极限编程在当前情况下专注于目前业界流行的最佳实践，并将它们发挥到极致。最普遍的例子是测试驱动开发、全团队方法、可持续节奏等。

XP – 灵活性作为技术

极限编程如此受欢迎的原因之一是其灵活的特性。此外，极限编程更多的是关于技术而不是流程，因此与以流程为中心的方案很好地融合。因此，您可以轻松地将极限编程的功能与其他想法结合起来，无论何时

• 一些极限编程实践在流程中是互补的。

• 极限编程本身不适合实施。

但是，请记住，您选择的任何极限编程实践都应将其核心内容贯彻到底。否则，您不能声称您正在使用极限编程。

事实上，对于您采用的任何流程，这一点都是正确的。允许混合搭配，但前提是您正在使用互补的功能，并且您没有损害所用功能的价值。

目前最流行的极限编程混合方案是Scrum + 极限编程混合方案。我们将从最基本且仍然流行的软件开发方法论 - 瀑布模型开始。

瀑布模型

在瀑布模型中，开发按阶段进行，在完成前一阶段之前，任何阶段都不能开始。

瀑布模型在许多组织中仍在使用，尽管有些人将其视为传统方法论。如果需求在开发开始之前完全已知，则它是一种成熟且有效的方法论。该过程简单明了，不需要任何培训或指导。

您需要记住的是，没有哪种方法论适用于所有情况，每种方法论都有其自身的优缺点。因此，您必须了解哪种方法论适合您的环境、您的客户利益。

让我们看一下瀑布方法论的缺点 -

• 由于所有需求都必须在开发开始之前知道，因此当需求不完整或含糊不清时，它不适用。

• 由于该方法论是单向的，因此无法将任何阶段的反馈带回到任何较早的阶段，尽管关于最终产品的清晰度有所提高。

• 测试仅在开发完成后进行，由未参与早期阶段（如需求收集或开发）的开发人员团队进行。这种“最后测试”方法通常会导致缺陷包含、高缺陷率、交付给客户的高未发现缺陷。

• 在开发结束之前，不会提供可工作的产品，因此没有人会知道是否正在构建正确的东西，即使它正在正确地开发。

• 缺陷修复和需求更改难以被吸收，因为有很大的可能破坏设计，并且产生的成本也很高。

如果您在开发中预测到此类情况，则敏捷方法论最适合。

敏捷方法论

敏捷方法论提倡 -

• 频繁发布可工作的产品增量，使反馈能够在正确的时间流入。

• 以团队为中心的方法，使每个人都对最终产品负责。

• 灵活的计划，专注于为客户交付价值，满足客户期望，投资回报。

• 随时准备接受更改，以便交付的最终产品不会过时。

出现了多种敏捷方法论，其中Scrum变得越来越流行，并且被广泛使用。

Scrum如何发挥作用？

在Scrum中，项目被分解成发布和时间盒式的短冲刺。对于每个冲刺，您将只承担客户优先级最高并且您可以在一个冲刺中交付的必要和足够的功能。在每个冲刺结束时，您将拥有一个可以发布的可工作的产品。

需求称为积压项目，迭代称为冲刺。将采用持续测试和测试优先方法。开发人员和测试人员也参与用户故事的编写，这些用户故事就是积压项目。这使团队中的每个人都能提前了解产品的行为，也有助于在冲刺开始时就确定验收标准。

正如我们之前所说，Scrum在其定义中，在某些情况下是有效的，但与任何其他开发方法论一样，它也存在自身的缺点。

• 时间盒式的冲刺不允许在发布计划中有任何灵活性，这会阻碍开发和测试。

• Scrum本身不提供开发方向。

因此，Scrum通常与其他更侧重于开发策略的敏捷方法论结合使用。

Scrum + 极限编程混合

Scrum被频繁地使用，并结合了互补的极限编程实践，极限编程侧重于工程方面，如持续沟通、频繁的反馈循环、重构、集体所有权、持续集成、测试驱动开发等，而Scrum侧重于冲刺的固定范围、燃尽图等。

• 由于Scrum是一种定义明确的方法论，因此从项目的第一天起就更容易适应。

• 由于极限编程更侧重于沟通和团队凝聚力，因此团队更专注于开发。

因此，Scrum + 极限编程混合被发现是有效的。

Scrum + XP混合项目的工具

SpiraTeam和Rapise等工具适用于Scrum + 极限编程混合项目。SpiraTeam在一个整合的视图中提供关键项目质量和进度指标的报告仪表板，该视图专为Scrum和极限编程项目量身定制。

一些指标包括 -

• 需求测试覆盖率
• 任务进度
• 项目速度
• 主要风险和问题

Rapise工具是一个测试自动化解决方案，可以完全集成到您的开发流程中，并可以适应您不断变化的需求。您可以使用它来测试桌面、Web和移动应用程序。开发人员、测试人员和业务用户可以使用此工具生成验收测试。

极限编程 - 工具

在本章中，我们将学习一些在极限编程中使用的工具。

极限计划

极限计划是一种基于浏览器的敏捷项目管理解决方案，专为支持包括Scrum和极限编程在内的敏捷方法而设计。

极限计划专注于规划和跟踪对客户具有实际业务价值的功能（或用户故事）的进度。

极限计划的关键功能包括 -

• 支持整个团队，包括项目经理、开发人员、质量保证、技术支持和利益相关者。

• 通过拖放轻松地估算和计划软件发布。

• 在一个地方管理功能、缺陷、测试用例和开发任务。

• 具有集成的问题跟踪功能，可以从头到尾管理客户请求。

• 提供最新的更改，并通过电子邮件通知和项目活动报告。

更多信息 - www.extremeplanner.com

项目计划与跟踪系统

PPTS是一个基于Web的环境，支持选择根据敏捷方法论Scrum和/或极限编程开发软件的团队。

PPTS功能包括 -

• 项目、迭代和资源属性的管理

• 可优先级排序的产品待办事项

• 工作分解结构（冲刺待办事项）

• 指标（速度和估算/实际工作量）

• 燃尽图和进度图表

• 日历

• 资源分配

• 基于整体角色（管理员或用户）或项目中的角色（项目负责人、开发人员或客户）对信息进行细粒度访问控制

• 菜单和语言自定义（提供英语和荷兰语）

• 与PR/CR工具集成

更多信息 - http://ses-ppts.sourceforge.net/

Targetprocess

Targetprocess 是一款可视化项目管理软件，使您能够直观地管理复杂的工作并专注于重要事项。

Targetprocess 为您的整个组织提供所需的可见性和透明度。从看板和Scrum到几乎任何运营流程，Targetprocess都能灵活地适应您的管理方法和组织结构。

Targetprocess 提供 -

• 用于计划和进度跟踪的看板。看板视图提供了许多选项，可以无缝处理大量卡片。

• 可与任何人共享的看板，以在外部广播信息。它们非常灵活。

• 可以使用拖放操作移动多个卡片。

• 用于项目层次结构的列表，并轻松管理待办事项。

• 完全自定义、内联编辑和精美设计。

• 图形报表。

• 时间线。

• 自定义视图。

• 仪表盘。

更多信息 - www.targetprocess.com

Plone Extreme Management Tool

Plone Extreme Management 工具提供项目管理功能，支持极限编程方法。

Plone Extreme Management 工具提供 -

• 内容类型 -

  • 项目 - 项目经理可以添加多个项目。对于每个项目，客户和员工都可以添加迭代和用户故事。

  • 迭代 - 项目将按迭代进行计划。迭代是一段1到3周的时间，在此期间将实施多个用户故事。

  • 需求 - 包含客户希望在这个项目中实现的用户故事。它被用作捆绑客户愿望并初步指示项目规模的一种方式。

  • 用户故事 - 客户可以通过描述这些功能来定义新的功能。

  • 任务 - 员工可以通过定义任务来估算用户故事。

  • 工时记录 - 在处理任务时，员工可以跟踪时间并在一天结束时轻松记录这些时间。

• 工作流程。

• 时间跟踪器。

• 发布计划。

• 迭代总结。

Java 开发人员的 XP 工具

下表列出了 Java 开发人员用于相关活动的工具列表。

.Net 开发人员的 XP 工具

与 Java 一致，.Net 有 NAnt、NUnit、CruiseControl.NET。Visual Studio 拥有许多重构工具。

在您的组织中采用 XP

如果您计划在您的组织中采用极限编程，首先选择一个适合极限编程的项目和团队。获得一位经验丰富的教练。让团队习惯极限编程实践、估算和团队沟通。

使用项目所需的最小极限编程规则启动项目。允许这些规则演变以实现更好的实施。考虑极限编程实践之间的协同效应。为团队提供足够的时间来克服学习曲线。管理团队文化和变化。

建议首先采用内部项目。一旦您成功实施该项目，您将拥有团队和管理层支持您将其扩展到其他合适的项目。