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

XP –活动

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

• 编码

• 测试中

• 倾听

• 设计中

编码

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

测试中

在成对编程中，需要进行测试以确保编码已完成。如果不进行测试，则不知道何时完成编码。

倾听

在结对编程中，您会听着知道要编码什么或要测试什么。如果您不听，则不知道该编码什么或要测试什么。

设计中

在成对编程中，您可以进行设计，以便可以无限期地进行编码，测试和侦听，因为良好的设计可以扩展系统，并且仅在一个位置进行更改。

这些活动在-

• 发布计划

• 迭代计划

• 实作

发布计划

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

发布计划分为三个阶段-

• 探索阶段

• 承诺阶段

• 转向阶段

发布计划–探索阶段

在探索阶段-

• 客户为系统提供了高价值要求的清单。

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

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

在这一阶段，积极聆听非常重要，因为

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

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

尽管客户将需求写在用户故事卡上，但您需要听

• 获得清晰度

• 避免歧义

• 表达您的理解是否存在差距

只有通过口头交流才有可能。

发布计划–承诺阶段

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

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

• 客户按业务价值对用户故事进行分类。

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

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

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

• 基于用户故事和估计，确定发布日期。

在此阶段，积极聆听很重要，因为-

• 开发人员需要了解他们需要为当前版本编码哪些功能，以及交付该功能所需的工作量和持续时间(估计)。

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

发布计划–指导阶段

在转向阶段，客户和开发人员“转向”-

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

• 调整计划。

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

• 适应变化。

在这个阶段，积极聆听非常重要，

• 要了解-

  • 要添加的新要求。

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

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

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

  • 到目前为止，工作已经完成。

  • 要添加的新要求。

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

迭代计划

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

迭代计划分为三个阶段-

• 探索阶段。

• 承诺阶段。

• 转向阶段。

迭代计划–探索阶段

在探索阶段，

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

• 任务记录在任务卡上。

• 开发人员估计完成每个任务将花费的时间。

• 如果开发人员由于任务太小或太大而无法估计任务，则他们需要组合或拆分任务。

迭代计划-承诺阶段

在承诺阶段，

• 任务已分配给开发人员。

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

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

• 在分配了团队中的所有开发人员任务之后，完成负载平衡。

• 在估计的任务时间和负载因子之间进行比较。

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

• 然后，在开发人员之间平衡任务。如果开发人员的工作量过多，则其他开发人员必须接管其某些任务，反之亦然。

迭代计划–指导阶段

在转向阶段，

• 开发人员会获得他或她已执行的任务之一的任务卡。

• 开发人员将按照结对编程实践与另一个开发人员一起执行此任务。

实作

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

极限编程工件

极限编程不是反文档，而是鼓励尽量减少实际需要的工作量。分布式共享，历史需求，摘要等需要时的文档。

基本的极限编程工件是-

• 用户故事卡

• 验收测试

• 估算值

• 发布计划

• 迭代计划

• 任务卡

• 设计

• 单元测试用例

• 客户与开发人员的沟通记录

用户故事卡

用户故事卡具有以下功能-

• 用户故事卡-

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

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

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

  • 应该仅提供足够的细节来估计故事将花费多长时间来实施。

• 系统中的每个主要功能都有一个。

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

• 推动验收测试的创建。

验收测试

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

估算–发布计划

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

• 在探索阶段到达目标发布日期。

• 在转向阶段计划调整。

发布计划

发布计划包含-

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

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

• 承诺的目标发布日期。

任务卡

任务卡-

• 包含实施用户案例所需的任务。

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

• 形成任务估计和任务分配的基础。

估计–迭代计划

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

迭代计划

迭代计划包含-

• 为迭代选择的用户案例

• 任务分配

• 任务估计

设计

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

单元测试用例

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

客户与开发人员的通讯记录

客户和开发人员讨论该故事以详细说明细节。如果可能，它是口头的，但是在需要时记录下来。