在每个冲刺开始时尽早执行子任务

我加入了一个使用敏捷/ Scrum的新团队，其开发过程如下：

1）开发人员在每次冲刺之前都要审查每个故事，以确保它不会遗漏任何关键内容。在工作流中有一个正式的状态。

2）在Sprint启动期间，整个团队都会对每个故事要花费多少故事点进行估算（扑克计划）。

3）最后，在每个sprint开始之后，每个开发人员都必须立即将所有分配的故事快速地分解为带有时间估计的子任务（与开始每个故事之前的子任务不同）。

最后一步的主要论点是，它有助于发现实施故事是否会比预期花费更长的时间，并警告Scrum主管有关缺少冲刺截止日期的潜在风险。

但是我发现这适得其反，主要是由于以下原因：

• 如果目的是提供粗略的估计，那么故事要点（步骤2）是做什么的。否则，为什么还要烦恼故事点呢？-尽早进行子任务。
• 如果目的是提供准确的估算值，那么这就是“ 认为有害的人类任务开关”中所描述内容的清晰示例。我认为，对于刚加入现有团队并参与大型项目的新开发人员而言，情况尤其如此，因为他们需要了解需要做什么才能花费多达50％的时间。您需要先进入故事1的详细信息，然后再进入故事2、3等等，等等，这会产生大量的信息流失。

有人告诉我，这种做法是“按书进行的”，甚至我都不打算讨论这一点。谁能提供这种做法的参考-Scrum圣经中是否明确定义了这种做法，并且/或者也许提供了任何额外的见解？

这与我们运行某些Scrum流程的方式并无不同。我们

1. 在“故事点”中估算待办事项顶部附近的故事
2. 根据我们认为将“组成”冲刺的故事点选择/解释故事
3. 将故事分解为更详细的技术任务
4. 估算技术任务，并将其与原始故事点估算值进行比较（我们大约知道一个故事点通常需要多少开发时间）

但是您想知道的是为什么我们要两次估算！

• 我们做一个粗略估计（基于故事），因为我们希望能够做出什么预测可能会在接下来的冲刺，甚至可能再下一个。最终，管理层必须能够与客户就可能的时间尺度进行沟通，因此，如果我们没有这种粗略的尺度估计，那么长期计划实际上是不可能的。
• 显然，这意味着我们不仅对当前的sprint做更多的粗略估计。因为不能保证下一个冲刺的积压顺序不会改变，所以我们不想在必要时花时间进行任务分解和精细估算。
• 我们将任务分解，以确保所有任务都已枚举，并且故事可以更轻松地并行处理。
• 我们进行精细的估算（基于任务），因为这样可以使我们的燃尽图更加平滑（特别是在没有简单的方法可以将大型故事分解为可行的“功能”的地方）。
• 因为我们两者都做，所以它们相互之间是健全性检查-明显的差异表明我们需要在需要识别的地方犯错误。这是有用的副产品，但它本身并不是我们估计“两次”的原因。

重新阅读您的问题和评论，我发现我们的工作流程与您的工作流程有所不同。

• 我们以团队的形式进行细目分类，尽管开销更大，但从中获得的技术讨论通常非常有价值，并且可以发现故事中的不足。当我们有经验，知识或能力上的差距时，这种讨论也是那些拥有更多知识的人可以帮助那些拥有更少知识的人（对新员工来说非常有用）的地方。
• 我们以团队为单位在任务级别上进行估算，“计划扑克”工作的原因之一是由于“人群的智慧”现象-正如我在评论中提到的那样，到此为止，估算任务所需的时间应少于30秒，因此开销可以忽略不计。

听起来您的团队执行任务分解和任务估计的目的是为了顺利完成任务-很好，这就是监视sprint进度并允许您的Scrum管理员尽早发现并解决问题的全部内容。如果需要此信息，则必须进行细分和估算，并且必须首先进行分类和估算。

我认为任务切换在这里对您来说不是问题，我不认为分解不同的任务实际上是一个任务切换，就好像从开发一个功能过渡到另一部分是任务切换一样。我认为，了解Sprint的整体“架构”可能是一件很有用的事情。

但是，我认为您可能还需要考虑其他一些问题。像往常一样，您应该确定存在的问题并提出解决方案，然后确定您的解决方案是否适用于追溯。这是构建适用于您的公司和团队的敏捷解决方案的关键。因此，您可能会遇到一些问题：

• 您正在单独进行故障分类-那么您的初级/初级团队成员如何向高级团队成员学习？当然，他们可能可以自己学习所有内容-但是如果受到指导，他们的学习速度会更快。初级团队成员是否需要花费很长时间来分解事情？从长远来看，他们是在犯错误还是遗漏了一些东西，从而浪费了团队时间？团队合作可以为您提供帮助。
• 您是在单独进行估算-与第一点相同，但是这些估算是否还不如预期准确？
• 听起来好像任务是在sprint开始时分配的，但是如果是这种情况，那么当您必须更改分配时，发现它的成本是多少？如果某人落后或生病，那么别人接管他们的任务有多容易？他们是否必须仔细阅读任务细目并尝试理解它们而不中断原始受让人？如果您分解并估计成一个团队，那么每个人都应该能够处理所有事情！
• 你的故事太大了吗？如果故障分解花费了50％的时间，那么这些故事听起来好像很有意思-也许可以将其缩小？我们将故事保持在一周的工作量之内。
• 您的任务太小了吗？如果您花费大量时间制作任务列表，也许您会涉及太多细节？我们的工作任务通常需要1到8个工时，因此在一天的工作中，每个人在下一次每日站立时都可以取得一些进展。

如果这是您的公司想要运行其开发并关闭讨论的方式，那么您的选择是有限的，或者至少会冒使人烦恼的风险。

鉴于敏捷的最终目标是有价值的工作软件，那么您可以尝试通过评估团队的交付能力（提供的点/估算的点，冲刺中的错误，测试数量，代码覆盖率，正常运行时间，所产生的销售-随你）。为所有结果做好准备-即使对您没有意义，也可能是这种工作方式对他们有效。如果您是对的，浪费将变得显而易见。

为流程着想，请警惕后续流程-这会浪费时间，但仍会带来不良的产品。一个优秀的敏捷团队进行实验，测量和学习。改变行为而不降低见解的最佳方法是基于证据的决策。

这也是我的看法。我建议您自己尝试一下并衡量结果-看看我在那儿做了什么:)

我认为您的Sprint启动活动是Sprint计划会议。我认为您的Scrum Master误解了这次会议的进行方式。您不仅可以决定要开发哪些故事，还可以向您的团队测试它们的定义，以确保它们不会遗漏任何东西（通常使用INVEST），还可以将这些故事细分为任务。引用Mike Cohn（Scrum联盟的创始人之一）；

冲刺积压是冲刺计划的另一个输出。冲刺积压是团队承诺交付的产品积压项目的列表，以及交付那些产品积压项目所需的任务的列表。通常还会估算sprint待办事项上的每个任务。

因此，对故事进行分解和估算是Sprint计划会议的全部内容；不是在计划会议结束之后，而是个别地。

为了提供更多见解，我们在Sprint Planning会议期间的工作流程如下：

1. 我们从产品积压订单的顶部获取一个故事，并将其分解为任务。根据经验，一项任务通常应该少于一天。

2. 根据我们已扣除的任务，我们可以估算故事。如果故事变大，我们会尝试将故事分成较小的故事。

3. 冲洗并重复直到我们达到估计的总点数

与Cohn所说的相反，我发现实际上没有必要分别估计每个任务，因为指定的任务小于一天。鉴于任务小于一天的工作量，您可以在“每日站立”期间轻松地注意到某任务所花费的时间比预期的要长，因为从事特定任务的人会说他仍在从事这项工作。

在冲刺过程中，团队将逐步处理故事，最后，团队应反思实际完成了多少工作。这就是Scrum回顾会议的目的。如果桌上还有故事，您可以推断出您的估计过于乐观，并针对下一个冲刺采取行动。另外，可能发生了某些事件，这些事件会影响您的工作量，等等。当您对这些估计值进行反思时，您会发现它们随着时间的推移会越来越好。

“按书”-那是你的问题。与在瀑布上工作相比，您淹没的过程更多。

没有敏捷的“书”，只有敏捷的宣言说：“不用花太多钱就能完成工作”。因此，如果您要估计大小，然后将故事分解为多个任务以重新估计它们，那么这将是无意义的过程开销，需要提高效率-这就是敏捷性。Scrum和其他所有东西都是开始敏捷的起点指南。在执行此操作时，您应该确定这些没有意义的要点，或者不能帮助您的团队更有效地工作，并且应该更改它们。

但是，有些人认为，无论工作多么愚蠢，被禁止的工作方式都必须一成不变，绝不可偏离。我会尝试在Scrum会议之前将故事分解为任务-您说开发人员需要审查每个故事，嗯，这是在审查的同时进行分解的机会。然后，您可以在Scrum会议中声明构成故事的任务（不要给他们分配时间！），然后让人们根据所包含的这些附加信息来决定故事的工作包大小（这绝不是一件坏事，明智的决策比猜测要好得多，只有在您有信息可用于决策时才可以这样做。

会议结束后，您仍然可以为任务分配时间（尽管我看不到这一点，冲刺不是基于时间，而是基于“您希望做多少事情”，以故事点来衡量） ，而不是时间。这是Scrum的一个常见问题，点并不等于时间，但是您必须每20周完成20点，因此2点= 1天的工作量，应该可以快速猜出要放置多少任务在sprint中，所以您既不会超负荷也不会工作，实际上并不会完成多少任务。最好的sprint是剩下几个任务的sprint，这表明您的估算是完美的。延迟在最后完成它们-均无效。

因此，简而言之，请打印出一份《敏捷宣言》的副本以及反敏捷版本。我敢打赌，您做的事多于敏捷。Scrum倾向于这样。解决此问题的唯一方法是与您的团队合作并争取改变。不要让管理层告诉您您的团队如何工作，这也不是敏捷的，这将写在《书》中。

在每个Sprint期间的某个时候，您都应该召开产品待办事项优化会议。在此会议上，您确保将产品待办事项列表的顶部充分分解，以便将该部分中的项目添加到下一个Sprint待办事项列表中。

如果产品待办事项列表细化管理得当，则Sprint计划会议可以更加高效。理想情况下，这将消除开发人员在Sprint启动后 “急于分解”故事的需求。

如果将产品待办事项项添加到Sprint待办事项列表中，然后再对其进行充分分解以进行实际估算，这将使得很难就要添加到Sprint中的内容做出正确的决定。