如何处理比平均冲刺差50％的速度？

如果我正确理解Scrum，这就是我确定团队在下一个冲刺中可以从事的工作的方式：

1. 我平均了过去几个冲刺的完成点数。

2. 这个量是我们的平均速度。在下一个冲刺中，我们要讲很多故事。

这是一个平均数，因此，如果历史重演，则此冲刺是我们承担的故事点过多的可能性为50％，而我们承担的故事点过多的可能性为50％。

在50％的情况下，我们承担了太多的故事要点，我们可以：

• 无法完成冲刺。这意味着我们将有一半时间无法实现冲刺承诺。

• 额外工作以赶上。问题在于，棘轮只有一种方式。我们将完成冲刺，完成的故事点数将反映出这一点。由于我们总是会结束，所以随着时间的流逝，我们的平均水平将趋于上升，直到我们总是完成大量的故事点并熬夜。

我对平均速度和冲刺承诺的理解正确吗？

如果是这样，对于落后于平均水平的50％的冲刺，我们应该怎么做？

如果没有，我怎么了？

我对平均速度和冲刺承诺的理解正确吗？

是的，你有主旨。

如果没有，我怎么了？

您忽略的是，故事要点就是您要做的事情。直到冲刺结束，每个人都不可能处理故事。如果您做得正确，那么在测试故事时，大多数开发人员将“闲置”几天（随着开发的全面展开，您的测试人员将处于冲刺的中间）。

我不加引用，因为您的开发人员不会坐在附近看猫视频，他们正在修正错误，完善一些代码/单元测试，在流程周围添加一些文档，考虑积压的故事设计或其中之一。开发团队可以从中受益的其他数十种有用的东西，但它们并不能很好地融入故事中。

因此，尽管您会在50％的时间里猜测过多，在50％的时间里猜测不足，但这并不意味着您将使冲刺失败或必须加班。这意味着您将没有太多时间来完成这项杂项工作（除非您确实错过了估计）。但这没什么大不了的，因为杂项工作对时间不敏感，从长远来看，事情甚至会变得平淡。

我对平均速度和冲刺承诺的理解正确吗？

不幸的是，您对有关Scrum中的Sprint计划的一些事情误解了。首先，开发团队（DT）

由组织机构组织和授权以组织和管理自己的工作。- 的Scrum指南

这个词是自组织的。这包括预测将在给定Sprint中完成的工作。不会告诉DT在每个Sprint上将执行什么操作，而是有权选择自己的工作。DT可能需要诸如历史速度，完善的产品待办事项列表以及下一个Sprint的DT容量等信息来创建预测。最终，是由DT确定在Sprint中可以完成和不能完成的事情，这是他们的预测中应该占优势的；不应该告诉他们他们将做多少工作。

还要注意，预测而不是承诺。该c词已从Scrum指南中删除，因为它被用来滥用开发团队。预测是首选术语。

关于错过低端或高端Sprint预测的可能性，我认为这并不重要。在某些时候，更多的分析并不能带来更好的准确性，我认为我们现在已经超出了这一点。

另外，只能“取消” Sprint；它永远不会失败。仅当冲刺的目标变得完全过时且不相关时，才取消冲刺。这种情况很少发生。如果预测不正确，您只需保持冷静，然后继续Scrum。你回顾了。下次冲刺，您的预测会更好:)。

首先，您的速度来自先前的冲刺，有时是最近几次冲刺（昨天的天气）的平均值，而不是过去所有冲刺的平均值。当然，如果您没有团队或公司的历史数据，则需要为第一个冲刺提供合理的价值。在第二个Sprint中，将完成的故事点放入Sprint中。如果要对其进行绘图，则可能会看到前几个冲刺的变化（例如，第一个冲刺为17，第二个冲刺为22，第三个冲刺为26，第四个冲刺为24）。在正常化团队合作和评估过程以及更好地了解项目（技术，领域）的过程中，这是可以预期的。

这并不是说您不适应。例如，如果您有一个星期是假期周，请确保考虑到工作关闭的假期。如果您知道团队成员正在休假，请计划减少工作人员。当然，计划外事件也会发生，但是您可以在sprint回顾中解释这些事件，并且可以决定如何影响您带入下一个sprint的故事点的数量。

在处理方面，“未能完成冲刺”与“我们没有完成所有故事”不同。对我来说，冲刺失败意味着您最终没有生产出可发货的产品-您的故事没有一个完整的故事，您没有构建，您无法向客户展示任何附加价值，或者用户。

不管您做什么，都不要随着时间的推移而迟到或过度工作。这就是所谓的可持续发展步伐（敏捷联盟，Scrum联盟）。

可能存在问题的指标是：

• 您的团队工作进度不可持续。您需要加班以完成为冲刺计划的故事点。使您的Sprint变小以按时完成任务，而不会增加压力。
• 随着时间的流逝，您的速度不会正常化。没有人期望速度永远不会改变，但是如果您发现尖峰或摆动，请处理冲刺回顾中的那些。找出导致它们的原因并解决根本原因。

敏捷方法因公司而异，在一种实现中，它可能与另一种实现有很大不同。我曾在两家公司的Agile领导下工作过。在第一家公司中，我当时非常认真地对待他们的指标，而在第二家公司中，我一点也不认真。因此，对于您所知的所有人，没人会关注您的指标。

话虽如此，这听起来像是您在担心未达到冲刺目标，或者估算不正确时会发生什么。我认为这种关注和看法很普遍，但并不是特别重要。最重要的是，敏捷是一种软件开发系统，它执行以下操作：

1. 让开发人员不断前进
2. 增加透明度
3. 允许反思并逐步改进流程

归根结底，如果您错误地估计了一个冲刺，或者使一个冲刺失败，那实际上就没什么大不了的。在您公司中高于团队的人员可能更担心您的团队不断前进，并且正在按计划完成项目。

作为敏捷下的个人，您应该最关注与团队其他成员相关的有效工作量。如果您是新手，那么您就不会期望自己生产力过高，但是在您任职的某个时候，您应该至少与团队中的某些人保持一致。如果您不输出工作，那么您实际上并不是在做您的工作。

我对平均速度和冲刺承诺的理解正确吗？

你的平均速度是准时的。以我的经验，这对于完成工作的长期估计非常有用-假设您有大量积压；但是对于Sprint计划承诺没有太大用处。

我看到的用于冲刺计划的过程是从待办事项列表中提取故事，然后让团队决定是否可以实现。团队根据直觉，分解到1/2天的任务，产品负责人的压力，冲刺目标的调整，最佳猜测（基于速度）或所有这些的组合来决定。

有时，产品负责人允许跳过几个项目，以便可以添加更多项目。

有时，团队和产品负责人会事先商定要拉伸的物品。

这是一个很好的问题，对于团队改进非常重要。该主题具有欺骗性，并且被广泛误解。故事指点的最初目的是找到一种快速且可接受的准确方法来估算完成故事中定义的功能所需的工作量（LOE）。总体目标：为团队提供一种预测方法或预测完成一项工作（例如一个项目）所需的时间。您对Velocity的理解是正确的：它是完成每个Sprint的AVERAGE点（真正完成）。因此，如果您有一个要交付的项目，即250分，而您的团队平均每个冲刺25分，那么该项目将花费大约10个冲刺，加上或减去一些缓冲时间。

肯·施瓦伯（Ken Schwaber）等一些学者建议，速度和点仅用于中长期预测。他们建议将工作时间作为第二次“合理性检查”，以检查冲刺中实际可以完成的工作。因此，每个冲刺中的点数可能会因容量而异。其他人（包括我自己）相信，一个成熟的团队将适应一个非常一致的规模确定模式，该模式可以准确地预测产能，最终工作时间将成为无用的额外负担。（恕我直言，对于新团队来说，至少要进行6到12个冲刺，这是至关重要的，直到团队对要点和故事大小的理解准确为止。）

您的第一个小错误是您说团队应该了解速度并引入很多故事点。实际上，教练鼓励团队扣除10％到20％并承诺*达到该水平。因此，如果您的团队倾向于每个冲刺完成25分，则不要将冲刺填满25分，而是停在20到22分。请记住：在完成其他工作时带上故事是很不错的。因此，您可以“提交” 22分并完成28分。那太好了。只是要小心，不要鼓励团队“沙袋”并不断投入工作。伸展运动看我们是否可以做更多没有什么错。

现在，您要谈谈Sprint之间的差异。看到一支球队先完成20分，然后是50分，然后是22分，然后是45分，然后是15分，然后是60分，这是非常普遍（但不是最佳）的模式。如果计算偏差，则摆动幅度可能为50％冲刺后达到100％冲刺。为什么团队一次冲刺只完成15分，而第二次冲刺只完成60分？

这可能意味着团队真的不知道他们能做什么。（嘿，我们在上一个冲刺中完成了50分，我们可以在这个冲刺中再做一次）。

或者，这可能表明产品所有者正在迫使团队过度投入，或者在冲刺开始后正在添加工作，等等。这些仅仅是一些ANTI-PATTERNS，可能会导致完成点的这种疯狂波动。

这种可预测性措施是Scrum管理员观察并引起团队注意的重要措施。 通常，他们在一个冲刺中完成几分，然后在下一个冲刺中完成许多分的原因就是我所说的“工作不完善的滚动波”。这是一个非常常见的模式：

产品负责人承受着约会的压力。因此，团队认为有必要尝试完成许多工作。他们是从一个新团队开始的，不确定他们实际上能完成什么。

因此，冲刺1，他们计划冲刺，并且由于它们处于形成阶段，因此无法完成所有工作。实际上，他们的不完整工作多于完成的工作。未完成的工作已开始，但不完整。它被移至下一个冲刺，这一次他们完成的工作多于未完成的工作。在下一个冲刺中，大量未完成的工作落入DONE，团队的信心也随之飙升。

产品负责人很兴奋，因此他们又增加了负荷。在此冲刺结束时，他们有大量的未完成工作，并且有令人失望的DONE工作。

在这里，您开始看到冲刺完成后与不完整冲刺之间的波动。如果团队不知道发生了什么，这种模式可能会持续数月。但平均而言，他们每个冲刺可以完成约24分。那么，当他们退出过度承诺时会发生什么呢？

您会注意到他们仍然可以完成24到26分，但是结转工作减少了。现在，团队不必为完成不可能完成的工作而感到不知所措，这也会破坏团队的士气，而团队可以开始改善其流程。

随着时间的流逝，速度将开始增加，而“完成与未完成”相对于“未完成”则不会出现巨大波动。

如果您不允许团队留出一些“闲暇时间”，那么他们将永远没有时间去执行使他们变得更苗条，更快，更好的工作。例如，Dev-Ops不可能发生。测试自动化-谁有时间！但是，这些正是团队需要努力以提高速度的事情。