学习目标
完成这个单位后，你会知道：
- 发现Sprint Planning的细节
- 将Sprint计划划分为多个细分市场
- 审查整个过程
- 在实际示例中使用CA Agile Vision
sprint规划对Scrum至关重要。 Scrum在一系列称为sprint的迭代中攻击一个项目，并且在sprint期间工作完成。这就是为什么确保正确规划冲刺的重要原因 – 这就是您设置冲刺目标和选择故事的地方。在sprint结束时，团队应该有一个潜在的可交付产品呈现给客户。
这就是Scrum中项目的完成方式 – 您通过从产品积压中剥离任务开始Sprint Planning并将其移至Sprint积压 – 然后团队执行这些任务，然后在结束时向客户和产品负责人演示可交付成果。 -Sprint Review然后这个循环再次从sprint开始到sprint。以这种迭代方式，产品发展。
本章是关于规划sprint的。
设定您的目标：Sprint计划
Sprint是在Scrum开发中完成工作的地方，在开始sprint之前，您花了一天时间来规划sprint。这是Scrum的一项规则 – 每个sprint都以Sprint Planning会话开始。
Sprint Planning背后的想法是确定团队在该sprint期间将准确处理哪些故事。 Sprint Planning完成了以下事情：
- 它确保你知道你在sprint中关注的是什么。
- 结合Sprint End Sprint，Sprint Planning确保团队提供的服务与客户的需求和需求更紧密地结合在一起。
- 它可以及时做出决策。将Sprint计划与有效的故事编写实践相结合意味着可以在项目中更快地交付产品。
如果没有Sprint Planning，您将面临风险
- 显着降低对工作重点的关注，这可能导致优先级较低的工作取代优先级较高的工作
- 减少团队对工作的理解，并限制经常发生的澄清量
- 冲刺期间的澄清数量增加，降低团队速度和实际承诺的交付
- 缺乏对团队燃烧速度和估算数据的理解
Sprint Planning是所有与项目有关的人员（从产品负责人到团队成员）之间进行交流的绝佳场所。本次交流的参与者应遵循以下几条规则：
- 产品负责人不应强迫团队承诺更多的故事点，而不是他们对承诺感到满意。经过一系列冲刺后，团队的速度变得清晰。
- 在团队承诺冲刺后，冲刺不会改变：团队组成没有变化，冲刺要求也没有变化。当然，可以提供澄清。
- 团队可以执行任务并将其分解为两个或更多任务。团队可能会发现不需要给定任务，可以取消此任务。对于添加，编辑或删除的每项任务，团队会在Sprint Review期间讨论更改的原因，尤其是在他们无法完成sprint目标的情况下。
Sprint Planning看起来似乎有很多规则，因此在下一节中，我们会打破规划以帮助描绘流程。
两个不同细分的规划
Sprint计划发生在冲刺的第一天 – 您计划在开始冲刺工作之前。每个Sprint计划会议通常持续一整天，或八个小时。
每个Sprint计划会话由两个部分组成。每个细分市场设计为持续约半天，大约或约四小时。 （这样可以节省两个段之间方便的午休时间。）
虽然Scrum指南说Sprint Planning通常需要8个小时，并且分为两个四小时段，但这些时间可能会有所不同。许多因素会影响规划sprint的实际时间：
- sprint中要进行的复杂性和深度工作
- 团队的成熟程度（并且已经合作）
- 冲刺的长度
- 团队规模
- 积压的故事准备得多好
细分＃1：从产品待办事项中移动商品
Sprint Planning的第一部分专注于从Product积压中选择高优先级积压项目，并将其移至Sprint积压并定义Sprint目标。将Sprint Planning的这一部分限制为四小时，可确保有效地实现这两个目的。
谁来参加会议？
谁参加了Sprint规划的第一部分？产品负责人，Scrum Master，Scrum团队以及其他人员：
- 产品负责人：产品负责人必须出现在Sprint计划会议的第一部分。产品负责人负责根据团队的建议设置sprint目标。产品负责人还负责向团队提供产品积压中最高优先级的项目。
- Scrum Master：使计划会议按计划进行。 Scrum Master促进了产品负责人和Scrum团队之间的会议，确保不熟悉Scrum实践的任何人都能加快速度。
- Scrum团队：团队审查产品所有者优先考虑的产品积压项目，并询问有关不清楚项目的问题。最终，该团队的目的是估计每个故事所需的时间并承诺Sprint积压，因此他们必须知道他们正在做什么。他们必须分析每个故事并将其分解为可以执行的任务。整个团队必须承诺进行此迭代的工作，因此尽管产品负责人提供了产品待办事项中的项目，但团队需要对其进行适当的估算和提交。
- 其他：如果有其他人可以提供信息，其他人可以参加Sprint计划会议。他们只能以顾问身份行事，不能分配工作或指导。
识别高优先级产品待办事项
Sprint计划会议的第一部分将以产品负责人为中心开始。产品负责人必须在Sprint计划会话开始之前准备产品待办事项中的故事并确定其优先级。
产品负责人以故事格式向团队提供高优先级产品积压项目（这些故事可以分解为产品积压中的任务，通常将分解为Sprint积压中的任务）。这促进了产品负责人和Scrum团队之间的开放式沟通。
通常情况下，产品负责人需要准备并优先考虑比预期使用的Sprint计划会话多50％的故事。
每个故事都应附有一套验收标准（产品负责人应明确说明每个故事成功完成的内容，因为故事会呈现给团队）。估计实施每个故事的时间尚未进入图片中，除非粗略地说 – 在Sprint计划会议的第二部分中，Scrum团队负责完善这些估算（请参阅“第2部分：估算积压项目”一节） “）。
第一部分是关于产品负责人和Scrum团队之间的面对面沟通，ScrumMaster充当促进者。这个机会让团队有机会了解产品负责人在此sprint中的期望。
重要的是，每一方都要在这里理解另一方 – 尤其是在冲刺中实现每个故事的期望。如果合适，预计该团队会提出许多问题并提出建议。
因此，例如，产品负责人可能会出现这样的故事，“作为客户，我想将我的卡插入自动柜员机。”验收标准可以指定在一定的秒数内读取卡，并在某个特定的秒内验证秒数（并且可以指定如果客户无法验证卡片该怎么做），并且卡片会在另一秒钟内被推回给客户。
定义sprint的目标
有关sprint的所有内容必须尽可能在Sprint计划会议期间进行布局，包括sprint本身的目标。如果想要创建产品负责人想要的东西，了解Sprint目标对团队至关重要。始终坚持冲刺的目标对团队来说非常重要。
sprint可能有不止一个目标，但产品负责人应该将任何sprint的目标数量限制为三个 – 比这更多，sprint可能变得没有重点。
Sprint的目标在Sprint End的最终评论中进行了审核，以确保它已得到满足。因此，例如，sprint的目标可能是“通过使用客户的PIN与ATM完成卡验证过程”。
团队中的测试人员应特别关注sprint的目标，以确保迭代符合该目标，然后才能进行充分测试。
细分＃2： 估算积压物品
Sprint Planning的第二部分是关于磨练Sprint Backlog并更详细地了解积压项目。该部分有三个主要目的：
- 团队精心准备要传递的故事
- 团队估计工作
- 团队致力于工作和冲刺
全力以赴：团队精炼要传递的故事
此时，团队会考虑所有Sprint目标以及要从Product积压转移到Sprint积压的故事。这里的一个重要问题是，在为sprint分配的时间内是否可以满足sprint的总体目标。
我必须参加这次会议吗？
谁参加Sprint计划会议的第二部分？看看这个列表，看看你是否在上面：
- Scrum团队：团队在创建Sprint积压时改进积压项目，并将每个故事分解为任务。它还必须估计工作。该团队还致力于这一领域的工作。它从产品负责人和该细分市场中的其他来源寻求信息，但此时所有方向都取决于团队和Scrum Master。
- Scrum Master：Scrum Master确保流程顺利进行 – 创建Sprint积压，团队承诺冲刺，等等。如果团队需要更多信息，Scrum Master还可以充当其他人的联络人。
- 产品负责人：产品负责人的出席非常重要，并且需要根据团队的澄清需求而定。
该团队查看优先级积压项目，确保他们了解每个故事。成员通常将每个故事分解为Sprint积压中的任务。
故事或任务的每个接受标准也会转移到Sprint积压。如果团队认为需要进一步澄清任何验收标准，则可以与产品负责人进行协商。随着故事被分解为任务，接受标准也可能会发生变化。
在这个阶段完成后，Sprint的积压已经开始成为焦点，积压的故事和任务已经到位。如果故事足够清晰且范围足够小，故事可以从产品积压转移到Sprint积压 – 否则，它们将被分解为任务。
拿出你的时间表：团队估计工作
Sprint积压已经形成，团队必须知道在分配给sprint的时间内完成工作是否切合实际。
估计工作时间是一个棘手的过程，但却是必要的过程。 Scrum实践依赖于随着时间的推移而变得高效，并且团队越接近估计sprint中的所有任务所花费的时间越多越好。经验丰富的球队将比新手队更好。
时间估计的首选方法是在Scrum团队中使用Story Points。故事点是可以分配给每个任务的时间单位 – 通常，故事点是一个人工作的一天，但这是适应性的。大多数组织实际上使用相对大小来决定故事点。
在名为Planning Poker的过程中，团队成员估计每个故事或任务的故事点。这为每项任务分配了特定数量的工作和时间。
在计划会议的这个阶段之前，团队成员应该考虑：
- 他们在最后一次冲刺中提供了多少个故事点？这有助于设置在此sprint中可以完成多少工作的基线。
- 即将到来的冲刺计划是否有任何假期？这可以调整团队在冲刺中完成的总分数。
- 是否存在可能影响流程的重大里程碑/事件？这可能会影响可以交付的工作量。
然后该团队考虑冲刺速度目标。冲刺速度是完成冲刺所需的时间，并指示团队的开发能力。
在此尝试计划当前冲刺的速度时，查看团队的历史冲刺速度非常有帮助。通过将预测速度设置得过高，团队不应该过于雄心勃勃，这会让产品负责人（和团队）感到失望。
每个任务都会估计一段时间，通常是在故事点中，直到达到潜在的Sprint速度。通常，团队将首先从最高优先级的故事和任务开始，估计他们将花费的时间，然后继续使用较低优先级的故事和任务。
一些团队让每个成员负责故事或任务，估计故事或任务将采用多少故事点（或小时），然后比较他们的独立估计。如果估计数不够充分，则需要进行讨论。让让我们这样做：团队致力于工作和冲刺
这一阶段是Sprint Planning第二部分的最后一步。在将故事添加到Sprint积压工作之后，团队根据速度估算确定了什么适合冲刺，现在是团队承诺执行任务的时候了。
致力于工作是在逐个成员的基础上完成的。第二部分的这一部分由ScrumMaster提供便利，ScrumMaster审核每项任务并将其呈现给团队。
当提交任务时，团队成员自愿承担任务。如果多个团队成员承诺执行特定任务，ScrumMaster应该促进讨论（并且任务可能最终被共享）。
ScrumMaster通常以最高优先级的故事或任务开始，要求团队成员依次提交每个故障，然后在优先级较低的项目中继续执行优先级较高的项目。
通过这种方式，任务不会简单地分配给团队成员 – 团队成员必须前进才能接受任务。
这个承诺过程尽可能地对Scrum很重要。团队成员应该觉得他们做了一个
选择“拥有”某项特定任务，接受对其负责。
承诺过程有助于团队自治，确保团队可以对sprint的任务负责。自治对Scrum团队很重要，让成员选择承诺协助这个过程的任务。
一些低优先级的任务可能仍未提交 – 接近这个阶段的结束，并且由Scrum Master决定是否将它们分配给团队成员。如果这里有问题，团队应该讨论它们;任何团队成员都不应该公开强迫他们承担比他们认为他们在冲刺期间可以管理的工作更多的工作。
当Sprint积压中的所有故事和任务都已提交时，Sprint计划会话的第二部分结束。
为了获得额外的责任，每天都有一个站立式会议（Scrum），其中团队成员将他们所做的事情，他们将要做的事情以及他们面临的障碍联系起来。每日Scrum用于保持团队协调和正常进行。关于Daily Scrums的更多讨论可以在第5章找到。
该团队还通过在燃尽图上绘制完整的故事点来跟踪其进度。这些图表是设计的
显示团队在实现目标方面的表现。如燃烧图表所示，任何与预期速度的偏差都必须由ScrumMaster解决。
在Sprint计划会话结束时，团队应该能够检查表4-1中核对表中的所有项目。
| 表 4-1 | Sprint计划清单 |
| 清单项目完成？ | Y / N |
| 清除冲刺目标 | |
| Sprint Backlog中的积压项目（又名，故事） | |
| 每个故事/任务的接受标准 | |
| 估计的故事/任务 | |
| 团队成员对故事/任务的承诺 | |
所有事情都被考虑：Sprint的最终评论
当Sprint完成后，会有一个Sprint结束时的审查会议。 ScrumMaster，Scrum团队和产品负责人都参加了。产品负责人还排列了几位可以参加的客户。
该过程如下：
- 在End-of Sprint会议上审查sprint的目标，以查看是否已满足sprint。
列出每个故事和/或任务及其验收标准，以查看是否已满足这些标准。
- Sprint的结果将呈现给产品负责人（以及可用的客户）。
理想情况下，这是所需产品的潜在可交付成果。产品负责人确定Sprint End-End Review的结果是否可接受。
- 如果一切都可以接受，则计算Sprint速度作为未来冲刺的指导。
内部审视CA Agile Vision
使用CA Agile Vision进行Sprint计划非常简单。本节将向您介绍CA Agile Vision的内部视图，以及如何将故事从待办事项拖动到sprint以及如何跟踪Sprint进度。
如何将故事移至Sprint积压
您可以轻松地从产品backlog创建Sprint积压。只需按以下步骤操作：
- 在“待办事项”页面中，显示要使用的项目的待办事项。
- 单击“显示Sprint”链接以显示Sprint待办事项，并过滤视图以显示要使用的sprint的待办事项。
- 选择您计划的发布，冲刺和团队。
- 从项目待办事项中单击并拖动用户素材，然后将其放入sprint backlog中
用户素材将添加到sprint backlog并分配给选定的团队。团队的速度反映了新故事给团队的分配。
您可以在图4-1中的CA Agile Vision中看到Sprint待办事项创建的示例。
跟踪Sprint进度
CA Agile Vision为您提供了许多方法来跟踪Sprint进度并在团队的所有成员之间共享该信息。团队成员，产品负责人和管理人员可以通过执行以下操作来监控sprint任务并跟踪团队成员进度：
- 在“CA Agile Vision仪表板”页面中查看Sprint进度图表和报告，在“Sprint详细信息”页面中查看用户故事和图表
- 查看和更新Sprint信息和用户故事详细信息页面中的注释和注释。
- 监控项目虚拟墙的进度（见第5章）
Sprint详细信息页面上的故事和图表显示了图表，以提供冲刺进度的综合报告。视图可以通过项目，sprint和团队进行过滤。
例如，Sprint燃尽图表比较了团队在用户故事上燃烧的实际小时数与sprint的预期燃尽率。
x轴显示sprint中的天数。包括周末在内的所有日子都被视为有效的工作日。 y轴显示sprint中的任务小时数。剩余实际小时数显示为绿线。预期的燃尽或指南以红色显示。线上的每个点都是表示冲刺中一天的数据点;你可以在图4-2中看到一个例子。
