---

Extreme Programming - 快速指南

极限编程 - 简介

本章概述了极限编程。

什么是敏捷?

"敏捷"一词的意思是 −

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

• 能够快速清晰地思考。

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

参考:剑桥在线词典。

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

敏捷宣言

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 出版了他的书《重构》。

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

行业成功

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

• 快速开发。

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

• 专注于低缺陷率。

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

• 高客户满意度。

• 降低成本。

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

极限编程优势

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

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

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

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

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

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

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

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

极限编程 - 价值观和原则

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

极限编程价值观

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

• 沟通

• 简单

• 反馈

• 勇气

• 尊重

沟通

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

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

• 开发人员可能不会向客户提出正确的问题，因此关键领域决策会失败。

• 经理可能不会向开发人员提出正确的问题，因此项目进度会被误报。

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

极限编程强调团队成员、经理和客户之间的持续和持续沟通。极限编程实践(例如单元测试、结对编程、简单设计、常见隐喻、集体所有权和客户反馈)注重沟通的价值。

XP 聘请了一名教练，其工作是注意人们何时不沟通并重新介绍他们。面对面沟通是首选，可通过结对编程实现，并且客户代表始终在现场。

简单

极限编程相信"今天做一件简单的事情，明天多花一点钱去改变它，比"今天做一件可能永远不会用到的更复杂的事情"要好。

• 做需要和要求的事情，但仅此而已。

  • "做最简单的可能有用的事情"DTSTTCPW 原则。

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

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

  • 使用当前功能集将系统重构为最简单的代码。这将最大化迄今为止的投资所创造的价值。

• 采取简单的小步骤实现目标，并在发生故障时减轻故障。

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

• 永远不要实现你现在不需要的功能，即"你不需要它"(YAGNI)原则。

沟通和简单相互支持。

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

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

反馈

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

在极限编程中，确保在不同时间尺度的各个层面都有反馈 −

• 客户告诉开发人员他们对哪些功能感兴趣，这样开发人员就可以只关注这些功能。

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

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

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

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

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

• 充当变革的催化剂

• 指示进度

• 让开发人员相信他们做对了track

勇气

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

• 只关注需要的内容

• 沟通和接受反馈

• 如实说明进度和估计

• 重构代码

• 随时适应变化

• 丢弃代码(原型)

这是可能的，因为没有人是独自工作的，教练会不断指导团队。

尊重

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

• 每个人都尊重彼此，视对方为宝贵的团队成员。

• 每个人都贡献出热情等价值。

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

• 管理层尊重开发人员承担责任和获得自身工作权力的权利。

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

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

• 简单支持勇气，因为有了简单的系统，您就可以更加勇敢。您不太可能在不知情的情况下破坏它。

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

• 具体的反馈支持勇气，因为如果您看到测试在最后变成绿色，您会觉得尝试对代码进行彻底修改会更安全。如果任何测试没有变成绿色，您就知道可以丢弃代码了。

极限编程原则

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

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

极限编程的基本原则是 −

• 快速反馈

• 假设简单

• 渐进式变化

• 拥抱变化

• 高质量工作

快速反馈

快速反馈是尽快获得反馈、理解反馈并将学习成果重新投入到系统中。

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

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

假设简单

假设简单就是将每个问题都视为可以用简单。

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

"假设简单"意味着"今天做好解决今天的工作，并相信你有能力在将来需要时增加复杂性。"在极限编程中，你被告知要做好工作(测试、重构和沟通)，专注于今天重要的事情。

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

• 遵循 YAGNI(你不需要它)。

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

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

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

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

增量更改

在任何情况下，一次性进行大更改都是行不通的。任何问题都可以通过一系列最小的、能产生影响的改变来解决。

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

• 设计每次改变一点。

• 计划每次改变一点。

• 团队每次改变一点。

即使采用极限编程也必须循序渐进。

拥抱变化

最好的策略是保留最多的选项，同时真正解决最紧迫的问题。

高质量工作

每个人都喜欢做好工作。他们努力创造令自己引以为豪的高质量。团队

• 工作顺利

• 享受工作

• 生产出有价值的产品感觉很好

极限编程 - 实践

极限编程中有四个基本活动。它们是 −

• 编码

• 测试

• 聆听

• 设计

这四个基本活动需要根据极限编程原则进行构建。为了实现这一点，我们定义了极限编程实践。

这 12 种极限编程实践实现了极限编程目标，如果其中一种实践薄弱，其他实践的优势就会弥补。

《极限编程解析》的作者 Kent Beck 将 12 种极限编程实践定义为如下 −

• 规划游戏

• 短期发布

• 隐喻

• 简单设计

• 测试

• 重构

• 结对编程

• 集体所有权

• 持续集成

• 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 小时 - 可持续的节奏

以可以无限期维持的速度工作。可持续的节奏确保人类对项目成功的贡献，考虑到−

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

• 开发不会因短跑而停止，而应该瞄准长期目标

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

• 确切的工作时间并不像执行能力那么重要。

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

极限编程 - 流程周期

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

极限编程是一个敏捷过程，因为它−

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

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

  • 与客户(现场客户和验收测试)

  • 用于发布计划(客户和开发人员参与估算)

• 极限编程聘请了一名教练，其工作是注意人们何时不沟通并重新介绍他们。

• 用−接受变化

  • 频繁迭代(短版本)

  • 轻松设计和重新设计(简单设计)

  • 持续编码和测试(结对编程)

  • 让客户持续参与(在线客户)

• 在短迭代中向客户交付可用的产品(短版本)。

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

  • 代码审查

  • 单元测试

  • 集成每组更改和测试

极限编程过程周期

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

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

• 产品生命周期

• 发布

• 迭代

• 任务

• 开发

• 反馈

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

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

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

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

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

• 开发生产产品。

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

产品生命周期

这也称为探索阶段。它涉及功能集定义和规划。客户提出高价值需求，这些需求以用户故事的形式给出。

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

发布

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

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

  • 审查进度。

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

  • 客户提出故事。

  • 讨论故事。

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

• 客户确定故事的优先级并选择目标发布时间框。

• 客户和开发人员承诺要包含的功能和下一个版本的日期。

• 开发人员 −

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

  • 包括上一个版本的验收测试中的缺陷修复。

  • 开始迭代。

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

迭代

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

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

开发人员 −

• 确定详细的技术方法。

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

• 开始开发。

• 尽可能地部署系统

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

任务

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

开发

开发人员结对，这可能是一个持续而动态的活动。

每对 −

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

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

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

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

• 经常审查进度。

反馈

结对的人不断进行内部沟通，也向团队外部沟通。在线客户也持续参与沟通。某些团队会每天召开站立会议，快速讨论团队整体状态，并在必要时进行可能的重新同步和微观规划。

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

• 开发事件可能导致重新考虑任务。

• 任务开发可能导致重新考虑故事。

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

• 迭代结果可能导致发布计划更改。

极限编程过程周期如下所示。

极限编程 - 结对编程

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

一名程序员，称为驱动程序，控制键盘/鼠标并积极实施代码或编写测试。另一名程序员，称为导航员，持续观察驱动程序的工作以发现缺陷，并战略性地思考工作的方向。

必要时，两名程序员会就任何具有挑战性的问题进行集思广益。两位程序员定期交换角色，平等合作开发软件。

结对编程 - 优势

结对编程的显著优势是 −

• 许多错误是在输入时发现的，而不是在 QA 测试或现场发现的。

• 最终缺陷内容在统计上较低。

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

• 团队解决问题的速度更快。

• 人们更多地了解系统和软件开发。

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

• 人们学会一起工作，更频繁地交流，从而提供更好的信息流和团队动态。

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

结对编程实验

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

结对编程研究表明 −

• 结对编程所用的工时并不比单人多。

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

• 结对编程产生代码行更少。

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

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

• 结对编程比个人编程多花费 15% 的时间。

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

• 结对编程始终用更少的代码行实现个人编程产生的相同功能。

• 在可以快速获得切实成果的环境中学习如何编程很有趣，而且可以让人学得更快。

适应结对编程

大多数程序员习惯于单独工作，并且经常抵制向结对编程的过渡。但是，通过练习，他们最终可以实现这一转变。

根据 Laurie A. Williams 和 Robert R. Kessler 在他们的书《我真正需要知道的关于结对编程的一切都是我在幼儿园学到的》中的说法，书中很好地解释了如何培养我们在幼儿园学到的技能，以建立团队凝聚力，特别是结对编程。

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

以下部分摘录自本出版物，可帮助您成为有效的结对程序员。

幼儿园课程

在幼儿园，我们学到了以下内容 −

• 分享一切

• 公平竞争

• 不要打人

• 把东西放回原处

• 自己收拾烂摊子

• 不要拿不属于你的东西

• 伤害别人时要说对不起

• 吃饭前要洗手

• 冲水

• 热饼干和冷牛奶对你有好处

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

• 每天下午小睡一下

• 当你走出家门时，注意交通，牵着手并团结一​​致

• 意识到奇迹

接下来，我们在上述教导的背景下研究结对编程的原则。

分享一切

在结对编程中，

• 两个程序员坐在一起，共同生产一个工件(设计、算法、代码等)

• 一个人打字或写作，另一个人不断审查工作。双方

  • 是流程中的平等参与者

  • 负责工件的每个方面

  • 拥有一切

公平竞争

在结对编程中，

• 一个人负责，即控制键盘或记录设计想法，而另一个人则不断审查工作。

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

• 当负责的人考虑实施时，另一个人则不断审查代码，思考可能的更简单的设计，以及当前的开发如何适应整个系统日期。

不要打你的搭档

在结对编程中，

• 确保你的搭档保持专注并专注于任务。

• 你保持专注并专注于任务。

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

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

• 每个人都要让搭档专心致志，毫不懈怠。

• 每个工件在生产过程中都会不断接受检查，以确保质量。

把东西放回原位

在结对编程中，

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

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

• 你需要有信心−

  • 只要有可能落后，你都可以立即从你的搭档那里得到帮助。

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

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

清理你的烂摊子

在结对编程中，使用"肩上监视"技术，

• 你会发现，你的搭档注意到了多少明显但未被注意到的缺陷，这真是令人惊讶。

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

• 表征缺陷预防和缺陷消除效率。

不要把事情看得太严肃

让合作伙伴持续客观地审查设计和编码是结对编程的一个非常有益的方面。在结对编程中，你需要确保在工作中既没有过多的自我，也没有过少的自我。

这是必要的，因为，

• 过度的自我可以通过两种方式表现出来:

  • "要么听我的，要么滚蛋"的态度会阻止程序员考虑别人的想法。

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

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

• 另一方面，一个总是同意合作伙伴的意见以避免制造紧张局面的人也会最大限度地减少合作的好处。为了实现良好的思想交流，在必要时应该有一些健康的分歧/辩论。

因此，在表现过多和过少的自我之间保持微妙的平衡是必要的。有效的结对程序员会在最初的调整期内培养这种平衡，这段调整期可能需要数小时或数天，具体取决于个人、工作性质和他们过去的结对编程经验。

在搬动家具时伤到别人时要说声抱歉

程序员必须能够并肩坐在一起编程，同时查看计算机屏幕并共享键盘和鼠标。极限程序员有一条"滑动键盘/不要移动椅子"的规则。

为了确保有效的沟通，无论是在协作组内还是与其他协作组之间，程序员都需要毫不费力地看到对方，互相提问并就集成问题等问题做出决定。程序员还可以从偷听其他对话中受益，他们可以在其中做出重要贡献。

开始之前放弃怀疑

为了成功进行结对编程，合作伙伴双方都必须了解协作在编程中的价值、好处和体验的乐趣。任何对此的怀疑都应该从一开始就被阻止。

经验表明，如果有一个非常积极和/或有结对编程经验的程序员，那么他们就可以成功带领这对程序员成为一个团结协作的团队。

• 这样的团队的生产力要高于以非团结形式工作的相同人员。

• 考虑到工作本身的性质，人们从工作中获得的乐趣比你想象的要大。

• 一旦团队开始团结起来，成功的可能性就会大大增加。

Flush

结对程序员可以独立完成某项工作。但是，当他们重新加入时，他们必须在合并之前审查独立工作，或者刷新并重写独立工作，同时不断审查工作，以识别其他缺陷。

未经合作伙伴审查，切勿合并任何独立工作。这是因为研究表明，与配对完成的工作相比，独立工作存在缺陷。

热饼干和冷牛奶对你有好处

结对程序员让彼此持续专注并专注于任务。这可能非常紧张和精神疲惫。因此，定期休息一下以保持体力，以进行另一轮富有成效的结对编程。

在休息期间，最好断开与任务的连接，并在重新开始时以新鲜的心态对待它。建议的活动包括查看电子邮件、打电话、浏览网页或休息一会儿吃点零食。

过上平衡的生活

定期与他人交流是过上平衡生活的关键。与您的合作伙伴和其他程序员进行非正式讨论可以交换有效的想法并高效地传递信息。

每天下午一起工作时休息一下

不必每天下午单独工作，但 10-50% 的时间单独工作是可以接受的。这是因为−

• 许多程序员喜欢独自进行实验性原型设计、艰难、高度集中的问题和逻辑思考。

• 简单、定义明确和常规的编码更适合由一个程序员单独完成，然后与合作伙伴一起审查。

注意交通，手拉手，团结一致

在结对编程中，

• 两者之间不应该有竞争。双方必须齐心协力，就像一件艺术品是由一个人的头脑制作的一样。

• 合作伙伴需要信任彼此的判断力和对团队的忠诚度。

• 合作伙伴永远不应该因为任何问题或缺陷而责怪对方。

意识到两个大脑的力量

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

• 这些知识和技能的共同集合使他们能够有效地沟通。

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

两人一起合作将−

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

• 更快地缩小范围以找到最佳解决方案。

• 更快地实施，质量更高。

因此，结对编程是一种强大的技术，因为有两个大脑始终专注于同一个问题。它迫使一个人全神贯注于手头的问题。

极限编程 - 角色

在极限编程中，重点是整个团队的协作、共置和持续沟通。

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

极限编程中的角色

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

• 开发人员(某些团队也称之为程序员)
• 客户
• 经理(也称之为跟踪者)
• 教练

开发人员

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

• 开发人员权利

  • 您有权知道需要什么，并明确说明优先顺序。

  • 您有权随时提供高质量的工作。

  • 您有权向同事、上级和客户寻求和接受帮助。

  • 您有权制定和更新自己的估算。

  • 您有权接受自己的职责，而不是让别人分配给您。

• 您将要负责的主要职责 −

  • 估算故事

  • 从故事中定义任务

  • 估计任务

  • 编写单元测试

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

  • 执行单元测试

  • 重构

  • 持续集成

• 开发人员技能

  • 结对编程

  • 沟通 - 必要且足够详细

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

  • 仅编写所需的代码。

  • 维护简单性

• 集体所有权

  • 如果有人更改了您编写的代码，无论在系统的哪个部分，您都必须信任这些更改并学习。如果更改是错误的，您有责任让事情变得更好，但要小心不要责怪任何人。

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

• 在团队中扮演不同的开发人员角色，例如 −

  • 程序员。

  • 架构师和设计师。

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

  • 数据库设计师和 DBA。

  • 运营和网络设计师。

• 有时，开发人员必须担任测试员。

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

  • 定期运行功能测试。

  • 报告测试结果。

  • 确保测试工具运行良好。

客户

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

这触发了客户角色需要某些技能−

• 将所需的故事写得足够详细。

• 培养一种态度，以实现项目的成功项目。

• 影响项目但无法控制它。

• 根据所需功能的范围不时做出必要的决策。

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

• 编写功能测试。

在极限编程中，客户需要与团队保持持续沟通并以单一声音向团队讲话。这是必需的，因为 −

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

• 客户可能是一个社区。<​​p>

• 客户并不总是委托人(代理人)。

• 客户可以是一个团队，包含以下潜在​​成员 −

  • 产品经理

  • 市场营销、销售

  • 业务分析师

  • 最终用户及其经理

  • 业务/系统运营

客户的主要职责是 −

• 写用户故事

• 编写功能测试

• 设定故事的优先级

• 解释故事

• 确定故事的问题

客户对这些责任负责。

经理

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

• 定义规划游戏规则。

• 让团队和客户熟悉规划游戏规则。

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

• 安排和进行发布规划和迭代规划会议。

• 在他们进行估算是为了提供反馈，说明现实情况如何符合他们之前的估算，无论是在团队层面还是个人层面，最终帮助他们下次做出更好的估算。

• 确保团队在迭代过程中按照承诺的时间表和功能努力发布下一个版本。

• 跟踪功能测试缺陷。

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

• 适应获取所有必需信息的能力，而不会干扰团队的工作。经理对这些职责负责。

教练

极限编程是团队中每个人的责任。但是，如果团队刚接触极限编程，教练的作用就至关重要。

教练的职责是 −

• 深入了解极限编程在项目中的应用。

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

• 即使其他人都惊慌失措，也要保持冷静。

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

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

• 随时准备提供帮助。

极限编程 - 活动和工件

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

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 和移动应用程序。开发人员、测试人员和业务用户可以使用此工具来生成验收测试。

极限编程 - 工具

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

ExtremePlanner

ExtremePlanner 是一个基于浏览器的敏捷项目管理解决方案，专门用于支持敏捷方法，包括 Scrum 和极限编程。

ExtremePlanner 专注于规划和跟踪对客户具有实际商业价值的功能(或用户故事)的进度。

ExtremePlanner 的主要功能是 −

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

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

• 在一个应用程序中管理功能、缺陷、测试用例和开发任务地点。

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

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

有关更多信息 − 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 管理工具

Plone Extreme 管理工具提供支持极限编程方法的项目管理。

Plone Extreme 管理工具提供 −

• 内容类型 −

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

  • 迭代 − 项目将通过迭代进行规划。迭代是 1 到 3 周的时间段，在此期间将实现多个故事。

  • 报价 − 包含客户希望在此项目中实现的故事。它用于捆绑客户的愿望并初步表明项目规模。

  • 故事 − 客户可以通过在故事中描述这些功能来定义新功能。

  • 任务 − 员工可以通过定义任务来估计故事。

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

• 工作流程。

• 时间跟踪器。

• 发布计划。

• 迭代汇总。

Java 开发人员的 XP 工具

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

面向 .Net 开发人员的 XP 工具

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

在您的组织中采用 XP

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

以项目的最低限度基本极限编程规则启动项目。允许规则不断发展以实现更好的实施。考虑极限编程实践之间的协同作用。留出足够的时间让团队扩展学习曲线。管理团队文化和变革。

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

---