极限编程 - 活动与工件

---

---

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

XP – 活动

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

• 编码

• 测试

• 倾听

• 设计

编码

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

测试

在结对编程中，需要进行测试以确保代码的正确性。如果你不测试，你就不知道何时完成编码。

倾听

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

设计

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

这些活动在以下阶段执行：

• 发布计划

• 迭代计划

• 实现

发布计划

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

发布计划包含三个阶段：

• 探索阶段

• 承诺阶段

• 指导阶段

发布计划 – 探索阶段

在探索阶段：

• 客户提供系统高价值需求的简短列表。

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

需求被记录在用户故事卡片上。为了编写故事，客户将在与开发人员的会议中提出问题。开发人员将尝试定义这个问题并获得需求。基于此次讨论，客户将编写一个故事，指出他们希望系统的一部分做什么。重要的是，开发人员对这个故事没有任何影响。

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

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

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

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

• 获得清晰度

• 避免歧义

• 如果理解方面存在可能的差距，请表达你的想法

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

发布计划 – 承诺阶段

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

此阶段涉及确定成本、效益和进度影响。在这个阶段：

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

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

• 开发人员确定实现故事所需的努力和持续时间（估算）。

• 将选择在下一次发布中完成的用户故事。

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

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

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

• 客户和开发人员需要了解下一次发布日期承诺的可行性。

发布计划 – 指导阶段

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

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

• 调整计划。

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

• 以适应变化。

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

• 以了解：

  • 需要添加的新需求。

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

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

• 确定调整计划所需的估算，考虑

  • 迄今为止完成的工作。

  • 需要添加的新需求。

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

迭代计划

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

迭代计划包含三个阶段：

• 探索阶段。

• 承诺阶段。

• 指导阶段。

迭代计划 – 探索阶段

在探索阶段：

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

• 任务记录在任务卡上。

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

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

迭代计划 - 承诺阶段

在承诺阶段：

• 任务分配给开发人员。

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

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

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

• 比较任务的估计时间和负载系数。

• 负载系数表示假设每周 40 小时工作制的情况下，每个开发人员在一个迭代中理想的实际开发时间量。

• 然后在开发人员之间平衡任务。如果一个开发人员的任务过多，其他开发人员必须接管他或她的一些任务，反之亦然。

迭代计划 – 指导阶段

在指导阶段：

• 开发人员获得他或她已承诺的任务之一的任务卡。

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

实现

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

极限编程工件

极限编程并非反对文档，而是鼓励只做真正需要做的最少的事情。文档在需要进行分布式共享、历史记录需求、总结等情况下使用。

基本的极限编程工件包括：

• 用户故事卡片

• 验收测试

• 估算

• 发布计划

• 迭代计划

• 任务卡

• 设计

• 单元测试用例

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

用户故事卡片

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

• 一张用户故事卡片：

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

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

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

  • 只应提供足够的细节，以便估算实现故事需要多长时间。

• 系统中每个主要功能一张。

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

• 推动验收测试的创建。

验收测试

验收测试必须是一个或多个测试，以验证故事是否已正确实现。

估算 – 发布计划

将用于发布计划的故事的努力和持续时间估算：

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

• 在指导阶段调整计划。

发布计划

发布计划包含：

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

• 努力和持续时间估算。

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

任务卡

一张任务卡：

• 包含实现用户故事所需的必要任务。

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

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

估算 – 迭代计划

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

迭代计划

迭代计划包含：

• 为迭代选择的用户信息故事

• 任务分配

• 任务估算

设计

设计包含一个简单的设计，足以实现用户故事。

单元测试用例

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

客户和开发人员沟通记录

客户和开发人员讨论故事以详细说明细节。如果可能，则采用口头方式，如果需要，则进行记录。