冲刺 (sprint) 计划
作者：Mitch Lacey。 所有者，Mitch Lacey & Associates，Inc，一家专门从事 Agile 和 Scrum 的采用和改进的咨询公司。
2012 年 1 月。
冲刺 (sprint) 计划不再让人头疼。 通过一起协作来回答“我们可以承诺什么？”这一问题，通常可获得乐趣并使整个 Scrum 团队建立友情。在本文中，作者提供了让冲刺 (sprint) 计划变得集中而有效的示例和策略，并且详细介绍了一些团队在计划冲刺 (sprint) 时遇到的常见问题的潜在解决方案。
应用于
应用程序生命周期管理；Team Foundation Server
本文内容：
简介
预测与承诺
什么是冲刺 (sprint) 计划？
我们如何完成它？
常见问题
情况：团队不能承诺产品所有者要求的所有情景。
情况：产品所有者不是有备而来的。
情况：第 1 部分超过了其固定时长。
情况：第 2 部分超过了其固定时长。
情况：产品所有者不在场。
情况：团队没有它需要的验收条件。
情况：产品所有者不知道已执行的操作的含义。
情况：Scrum 主管或产品所有者正在估计/影响团队的估计/工作。
我们不制定计划。 我们在做 Scrum，因此我们只是执行。
我一直听到这样的话。 人们认为 Scrum 和 Agile 意味着没有计划、没有估计、没有会议、没有任何东西！ 这不是事实。 我们在 Agile 项目中进行各种级别的计划：每日计划或每日执行情况、每周计划（冲刺 (sprint) 或者迭代、积压工作 (backlog)）、发布计划（产品积压工作 (backlog)），而且可能更多。
让我们侧重于计划冲刺 (sprint)。
预测与承诺
在 2011 年夏天，Ken Schwaber 和 Jeff Sutherland 修改了他们的 Scrum 指南。 其中，他们去除了 Scrum 已知的一种长期形成的行为，即团队对产品所有者和客户作出的承诺。 他们将承诺替换为预测。 他们说，团队可能预测他们的工作，但不能承诺它。
虽然我了解他们的逻辑，但我更喜欢承诺，原因如下：
承诺某事会将团队置于不同于只是预测的观念。 如果团队进行预测，则这暗示着若达不到他们所说的可以实现的一切，也是可以接受的行为。 虽然团队可能从他们的预测中学到东西，最终有较少的估计偏差，但我发现与承诺的团队相比，预测的团队将花费较长的时间来减少偏差。
预测或估计适合于产品积压工作 (backlog)。 但是，当团队将情景从产品积压工作 (backlog) 移动到冲刺 (sprint) 积压工作 (backlog) 并将它们进行分解时，他们就是在增加另一个级别的粒度，并找出允许他们询问自己“我们可以对此承诺吗？”的较小细节。如果团队改为“我们只需要预测，我们错过一些东西是可以的，我们可以以后再了解这一切”，那么预测就会面临退回到懒惰状态的风险。
举一个轻松的例子，设想如果你对你的妻子、丈夫或合作伙伴说：“我预计我们会在一起十年”，这相对于“我把我自己交给你”来说，后者会更受欢迎。
最后，Scrum 与常识相关。 我建议你尝试这两种承诺方法和预测方法。 它们全部与学习相关，而不是关于你使用哪些词，所以聪明一点，将这两个方法都试验一下，而且使用对于你、你的团队和你的公司来说最佳的方法。
什么是冲刺 (sprint) 计划？
我们召开冲刺 (sprint) 计划会议以规划团队将在即将到来的冲刺 (sprint) 中生成什么以及团队将如何生成它。 尽管我们称它为冲刺 (sprint) 计划会议，但它实际上由两个非常不同的部分组成。 第 1 部分侧重于要求团队构建什么，以及产品所有者和团队应共同参加什么。 第 2 部分侧重于团队如何计划以构建所需的功能。 尽管整个团队必须参加第 2 部分，但产品所有者是否出席是可选的。 如果出于任何原因，产品所有者不能参加第 2 部分，则应保持能够答复问题。
在冲刺 (sprint) 计划会议的第 1 部分中，产品所有者有机会对团队描述所需的一组情景。 这是情景的哪一部分的深层次会话。 产品所有者呈现了情景，显示了事物如何进行交互并演示了接口。 此外，他们还可能评审基础结构或体系结构项。 我们的目标是将足够的信息填充到团队成员的集体头脑中，这些信息使他们可以开始了解如何构建功能。 团队将询问各种问题，以便为如何开会而收集信息 - 这些问题类似于：
“所有这些情景的验收条件是什么？”
“你认为我们使用的是什么数据源？”
“接口应该如何查看待此组件？”
在冲刺 (sprint) 计划会议的第 2 部分中，团队将注意力转移到生成冲刺 (sprint) 积压工作 (backlog) - 冲刺 (sprint) 期间完成它们所需的情景和任务列表。 若要生成积压工作 (backlog)，团队将每个情景分解为产品所有者已要求的任务级别；给予每项任务以小时为单位的估计时间。 第 2 部分结束时，团队决定在冲刺 (sprint) 期间它可以承诺完成哪些情景。
冲刺 (sprint) 计划会议的这两部分加在一起可能需要二到八小时的时间。 我使用的一般规则是，对于冲刺 (sprint) 长度的每一周，每个部分应该需要一小时。 这意味着，如果我运行一周的冲刺 (sprint)，则会议将花费总共两个小时（第 1 部分一小时以及第 2 部分一小时）。 另一方面，如果我运行四周的冲刺 (sprint)，则会议将花费总共八个小时（第 1 部分四小时以及第 2 部分四小时）。
我们如何完成它？
只要团队离开冲刺 (sprint) 计划会议时承诺完成情景列表，该团队就已经完成了冲刺 (sprint) 计划的目的。 将团队转入正题，即每个团队成员感觉舒适地作出该承诺，但是，需要一点预先计划和促进。
产品所有者在冲刺 (sprint) 计划期间有一项任务：参加会议并能够描述一组所需的情景。 团队的目标是从产品所有者的角度来了解这些情景，以在产品所有者的愿景中分享。 Scrum 主管应确保团队提出足够的问题，并捕获所有结果数据，包括验收条件、草图以及任何假设。 Scrum 主管还应让产品所有者知道，开始将问题分解为任务后，团队可能有其他问题。 尽管产品所有者呈现其总分大致对应于团队历史速度的情景，但事实上该团队将最终决定它是否可以基于它在冲刺 (sprint) 计划会议的第 1 部分和第 2 部分期间所了解的信息，采用给定冲刺 (sprint) 中的所有情景。
团队从产品所有者处获取所有信息后，它必须将情景分解为任务并创建冲刺 (sprint) 积压工作 (backlog)，这将针对特定的冲刺 (sprint) 捕获所有情景、批注、验收条件、任务和估计。 虽然有很多方法可以实现此目的，但我采用以下方法，它利用了所有团队成员的想法，并给予每个人对任务分解的话语权。
Scrum 主管或会议参与实施者已经读完一个情景并且询问“每个人都了解它了吗？”团队只要花时间与产品所有者讨论它后，就应该了解它。 如果团队中有人不了解，则花些时间重新访问该情景，询问产品所有者任何必要的问题。
接下来，让每个团队成员抓取一个粘滞便笺簿。 要求每个团队成员在每张粘滞便笺上编写单个任务，并将它抛到桌子中间。
- 将每张粘滞便笺抛到桌子中间后，它的投掷者将公布该任务。 因此，如果写下“更新存储过程”，它将被大声读出来。 这一点很重要，因为它将引发思路并使其他人附和：“哦，是的，我们需要更新数据源。”此时，有人将在粘滞便笺上写下“更新数据源”，读出来，并把它扔到中间。 这种集体讨论活动会对清空所有关联的任务起到真正的作用。 不要担心此时会有重复。 对于每个情景，扔出所有的任务粘滞便笺通常需要大约五到十分钟。
当粘滞便笺都在桌子上时，就可以对它们进行排序了。 将它们都粘在墙上，退回一步进行查看 - 这么多粘滞便笺！ 首先标识所有重复便笺；重叠所有似乎重复的粘滞便笺。 然后，寻找似乎应分为一组的任务，或者是因为它们类似，或者是因为它们相互依赖。 例如，如果两个粘滞便笺有类似的关系，则将它们放在一起，但进行偏移，如下图所示：
.png "类似便条 - 偏移量")
如果两项任务如此紧密相关以至于几乎完全相同，则将它们基本上完全重叠，如下所示：
.png "类似便条 - 重叠")
通过将粘滞便笺排序，团队可以精选任务列表并且可视化保留的那些任务之间的关系。
当对这些任务进行排序时，就可以进行估计了。 我使用计划扑克方法来进行任务估计，但有一处不同：卡片上的数字表示小时而不是点。 我这样做是因为人们往往太过于纠缠小时数方面的不必要细节，尤其对于大型任务。 他们对此感到不安有充分的理由。 通常，公司使用估计的时间作为“棍棒”敲打团队。 “你说将需要 8 个小时，而你花了 12 个小时。 哪里出问题了？”或者“你说将需要 8 个小时，而你只花了 4 个小时。 你在填塞你的估计时间。”
以卡片帮助保持“情景-点”估计抽象的相同方式，将卡片用于任务估计将允许团队具有附带一组固定数字以从中选择的自由度，同时强制他们最终做出选择。 它还消除了某项任务是否应估计为 6 小时、6.5 小时或 7 小时的激烈讨论。
无论最终的估计如何，请记住，估计是由团队进行的，而且旨在只能由团队使用以帮助增加其信心，并确定它是否可以完成产品所有者基于速度要求的工作。 任务估计不是度量值而且不应这样使用。 从不使用估计作为针对团队的武器。
现在估计了任务，团队必须确定它是否有承担更多工作的能力。 若要实现该目的，你将需要知道团队的能力，以及冲刺 (sprint) 期间团队可用的总小时数。 如果你有完全专用的团队，则确定能力较容易，但是如果你有一个由跨多个项目拆分的非全职人员组成的团队，则会变得更难。 要求每个人写下每天对项目可以工作的小时数（或为每个冲刺 (sprint) 工作的总小时数）。 将所有数字加在一起，以获取可用于团队的总小时数。 假设团队的工作能力是 200 个小时。 如果估计某个情景的任务的总和要花费 30 小时，则询问团队：“我们是否可以选取更多的工作？”在这个早期阶段，答案是明显的“是”。
由于你有更多的工作能力来填充，因此进入下一个情景，并重复步骤 1 到 5。
（有关如何使用 Team Foundation Server 来完成此任务的信息，请参阅协作 [重定向]。）
某些时候，你将很难回答这个问题：“我们是否可以选取更多的工作？”这是因为你团队的工作能力正接近饱和。 当你完成此过程时，请考虑你不希望将此冲刺 (sprint) 占据所有工作能力。 如果用水倒满杯子直至边缘，则很有可能会溢出。 这同样适用于冲刺 (sprint)。 如果估计的小时数消耗所有可用时间，而且在之后的冲刺中确认了新任务，则事情就会溢出。 你必须为紧急任务留出空间。
当考虑冲刺 (sprint) 的承诺时，它有助于考虑过去的冲刺 (sprint) 的追溯数据。 是团队始终不得不持续引入更多的工作？ 团队可能能够在冲刺 (sprint) 计划期间承诺更多。 是团队始终无法完成冲刺 (sprint) 的所有工作？ 团队可能需要更保守的承诺，直到它解决了不完整冲刺 (sprint) 的根本原因。
将数字放入有关“如何充分填满你的杯子”问题的一种方法是考虑计划大小的增长。 计划大小的增长度量如何将花费的实际小时数与初始的估计进行比较。 例如，假设我们的团队有 200 小时的可用工作能力。 团队基于估计，认为需要 190 小时并进行承诺。 冲刺 (sprint) 结束时，团队计算出这些情景包含实际 240 小时的工作量，导致计划大小增长 20%。
发现此差异的团队应该在追溯期间花些时间调查原因：
是在执行期间发现有太多的任务在计划期间并未标识？
是团队基于当前技能低估了其任务吗？
团队高估了其工作能力？
等等。
当确定团队是否可以承诺某个情景时，它还应该在下一个冲刺 (sprint) 计划会议期间考虑其计划大小的增长。 返回到我们的示例，如果团队仍估计 200 小时的工作能力，则团队应该减去 20% 的顶峰，以弥补基于历史数据的“预期”计划大小的增长。 换言之，当团队到达 160 小时时，至少为了防止此冲刺 (sprint) 溢出，它应该声明自身的工作能力。
考虑计划大小的增长是量化冲刺 (sprint) 应该有多满的一种方式。 但是，请注意，目标不要完全匹配工作能力。 而是允许团队自信地承诺适当数量的情景 - 可推动团队而又不会使它负担过重的数量。 如果所有其他因素保持相等，则计划大小的增长只是一种用来确定下个冲刺 (sprint) 应该大约有多满的方法。
当已估计所有的情景或情景消耗了全部时间时，返回至产品所有者，并共享团队已承诺交付的冲刺 (sprint) 积压工作 (backlog)。 冲刺 (sprint) 现在开始，所以开始工作吧！
常见问题
在我为团队提供咨询以帮助他们采用 Scrum 的这些年中，我看到过许多妨碍成功的冲刺 (sprint) 计划的相同问题。 尽管冲刺 (sprint) 计划看起来很直接，但对 Scrum 刚入门的团队往往感到很困难。 许多这样的问题以及可能的解决方案详见本节。
情况：团队不能承诺产品所有者要求的所有情景。
这种情况通常会偶尔发生。 只要团队可以从本主题前面的步骤 4 和 5 备份对数据的承诺，该产品所有者就应该感到满意。 你将希望留意以确保这种承诺的失败不是过度填充或大型任务导致的结果。 Scrum 主管应该质询看起来过度保守的估计以确保它们精确。 产品所有者应该对有两位数估计的任何任务提出问题。 应该将估计需要超过两个工作日的任何任务分解为较小的任务，并对其重新估计。 这适用于所有项目，但对运行一周或两周的冲刺 (sprint) 的团队尤其麻烦。
情况：产品所有者不是有备而来的。
Scrum 的价值观之一是尊重。 未做好准备就去参加会议是失礼的。 如果产品所有者到场但没有团队需要的信息，那么团队该怎么办？ 尽管一种选择是推迟会议直至产品所有者准备就绪，但这样做只会鼓励相同的行为，因此要避免使用此方法。 另一种选择是取消冲刺 (sprint)。 尽管可以这样做，但很极端。
我发现最好的解决方法是双重的。 首先，产品积压工作 (backlog) 应该按某种优先级顺序排序，因此如果产品所有者不具有特定的一组情景，则团队和产品所有者可以只按优先级顺序讨论情景，直到他们认为他们将达到或超过工作能力为止。 然后团队可照常在会议的第 2 部分期间决定确切的承诺。
会后，Scrum 主管应该努力了解为什么产品所有者未做好准备。 如果问题是缺乏参与，则 Scrum 主管可以教导产品所有者，使其明白参加会议之前准备好一组情景的重要性。 另一方面，如果可能因为团队未能帮助梳理而使产品所有者无法准备，那么 Scrum 主管还应该帮助解决这些问题。
情况：第 1 部分超过了其固定时长。
另一个价值观是专注。 如果会议的第 1 部分进行得很粗略，那就是缺少专注的表现。 有时候，产品所有者因为缺少准备、优先级问题或尝试解释太多情景而不专注。 其他情况下，缺少专注可能是因为团队将“什么”对话与“如何”的细节脱离。
通过坚持让产品所有者将不能完全解释的任何情景制成表格，以及使团队对第 1 部分保持详细的实现讨论，Scrum 主管应帮助事情取得进展。 对于不专注的讨论的简单纠正办法是使用秒表或计时器。
情况：第 2 部分超过了其固定时长。
再次强调，专注。 如果你有一个高谈阔论的团队，则有时唯一需要的是用纪律来限制讨论，以将会议带回到正题。 带一个煮蛋计时器，并在任务估计之间使对话持续一到两分钟。 目标是准确性，但不是 100% 精确。
其他情况下，第 2 部分期间缺少专注是冲刺 (sprint) 执行期间缺乏产品积压工作 (backlog) 梳理的表现。 当团队可以查看未来情景并与产品所有者协作，以添加情景或附加工作来牵制设计方向或解决体系结构问题时，就是进行梳理的时候了。 如果没有定期的产品积压工作 (backlog) 梳理，则冲刺 (sprint) 积压工作 (backlog) 计划将变得难以操作和棘手。
情况：产品所有者不在场。
如果产品所有者由于任何原因不能参加会议，而且还没有指派代理，则视同产品所有者参加会议之前未做好准备工作。 完成优先级高的项目，并承诺为他们提供你所能提供的最好结果。 你可能很想更改会议的时间，以适应产品所有者的日程安排。 不要这样做。 改变会议的时间适应了一个人的需要，但以牺牲许多人的需要为代价。 这是不值得的。
情况：团队没有它需要的验收条件。
在第 1 部分期间我始终建议团队询问产品所有者：“对它的验收条件是什么？”或者“我们需要做什么来让你接受此工作？”如果这在第 2 部分中缺失，则当团队确定任务时，团队将不知道如何让该情景结束。 如果团队不得不基于它在第 1 部分中听到的信息进行猜测，则团队面临产品所有者在冲刺 (sprint) 结束时决定该情景还没有完成的风险。 从每个情景开始就询问验收条件。 Scrum 主管 - 指导你的产品所有者提供此数据。
情况：产品所有者不知道已执行的操作的含义。
与团队想要的验收条件类似，产品所有者值得通过“该情景已完成”等最新描述而了解团队的意思。这个完成列表应该突出发布、保持最新，而且对产品所有者始终可用。 过期的完成列表使它很难计划，因为对完成后的情景的样子没有共识。 确保更新完成列表是每个冲刺 (sprint) 检查或追溯的一部分。
情况：Scrum 主管或产品所有者正在估计/影响团队的估计/工作。
在会议的第 2 部分中，产品所有者是受欢迎的，但是第 2 部分中产品所有者的角色应限于阐明要求或解决特定的问题。 产品所有者应该从不干扰团队对如何实现情景的讨论，而且在任务估计中没有发言权。 产品所有者需要信任团队执行工作。
如果产品所有者在这些准则之外行动，则 Scrum 主管应该指导产品所有者充当更适当的角色。 如果产品所有者拒绝接受更被动的角色，则 Scrum 主管有权要求产品所有者离开。
冲刺 (sprint) 计划不再让人头疼。 通过一起协作来回答“我们可以承诺什么？”这一问题，通常可获得乐趣并使整个 Scrum 团队建立友情。请记住，如果你发现会议举行的时间很长，则可能是根源问题导致此现象。 如果你是 Scrum 主管，则通过确保产品所有者和团队梳理产品积压工作 (backlog) 而保持会议专注。 通过会议前准备好情景验收条件，可帮助产品所有者有备而来。 最后，帮助保持产品所有者和团队专注于所要执行的任务 - 确定他们可以对冲刺 (sprint) 承诺什么。