极限编程 - 活动和工件

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

XP – 活动

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

  • 编码

  • 测试

  • 听力

  • 设计

编码

在结对编程中，编码被认为是开发的核心。你编码是因为如果你不编码，到最后你就什么也没做。

测试

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

听力

在结对编程中，您通过倾听来知道要编码什么或要测试什么。如果你不倾听，你就不知道要编码什么或要测试什么。

设计

在结对编程中，您的设计是为了可以无限期地进行编码、测试和监听，因为好的设计允许扩展系统，而只需在一处进行更改。

这些活动在以下期间进行 -

  • 发布计划

  • 迭代计划

  • 执行

发布计划

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

发布计划分为三个阶段 -

  • 探索阶段

  • 承诺阶段

  • 转向阶段

发布计划 - 探索阶段

在探索阶段 -

  • 客户提供系统高价值需求的候选清单。

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

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

积极倾听在此阶段非常重要，因为

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

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

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

  • 获得清晰度

  • 避免歧义

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

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

发布计划 – 承诺阶段

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

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

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

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

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

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

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

在此阶段，积极倾听非常重要，因为 -

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

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

发布计划 – 指导阶段

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

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

  • 来调整计划。

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

  • 以适应变化。

积极倾听在这个阶段很重要，

  • 要理解 -

    • 有待补充的新要求。

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

    • 删除任何现有需求会对现有系统产生影响。

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

    • 到目前为止所做的工作。

    • 有待补充的新要求。

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

迭代计划

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

迭代规划分为三个阶段 -

  • 探索阶段。

  • 承诺阶段。

  • 转向阶段。

迭代规划——探索阶段

在探索阶段，

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

  • 任务记录在任务卡上。

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

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

迭代计划 - 承诺阶段

在承诺阶段，

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

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

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

  • 负载平衡是在团队内的所有开发人员分配完任务后完成的。

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

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

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

迭代计划 – 指导阶段

在转向阶段，

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

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

执行

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

极限编程神器

极限编程并不是反文档，而是鼓励做真正需要的最少的事情。分布式共享、历史需求、总结等需要时的文档。

基本的极限编程工件是 -

  • 用户故事卡

  • 验收测试

  • 估计

  • 发布计划

  • 迭代计划

  • 任务卡

  • 设计

  • 单元测试用例

  • 客户与开发者沟通记录

用户故事卡

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

  • 用户故事卡 -

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

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

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

    • 应该只提供足够的细节来估计故事的实施需要多长时间。

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

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

  • 推动验收测试的创建。

验收测试

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

预估 – 发布计划

将在发布计划中使用的故事的工作量和持续时间估计 -

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

  • 规划指导阶段的调整。

发布计划

发布计划包含 -

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

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

  • 承诺的目标发布日期。

任务卡

任务卡 -

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

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

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

估算——迭代计划

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

迭代计划

迭代计划包含 -

  • 为迭代选择的用户故事

  • 任务分配

  • 任务估计

设计

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

单元测试用例

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

客户与开发者沟通记录

客户和开发人员讨论这个故事以详细说明细节。可能的话采用口头形式，但需要时记录下来。