在敏捷/SCRUM中，"中冲刺"接受是一个有效的概念吗？[关闭]

Question

已关闭.这个问题是 意见为本.它目前不接受答案。

---

想改善这个问题吗？ 更新问题，以便通过以下方式用事实和引用来回答 编辑这篇文章.

已关闭 两年前.

我是敏捷scrum团队的一员，负责软件产品发布。冲刺持续时间为2周（~10天）。

这里使用了一个特殊的度量标准，称为'中短跑验收'.从本质上讲，期望的是，由scrum团队在sprint中承诺和计划的一半用户故事点需要在该sprint的中间完成。他们说，这会导致点的线性燃尽，这是冲刺进行得很好的有力指标。

作为一个团队，我们的冲刺中期接受通常很糟糕，但众所周知，我们会在冲刺结束时完成所有提交的用户故事点。

我有以下问题:

1）冲刺中期接受是有效的敏捷/SCRUM实践吗？它在其他地方使用吗？

2）期望一半的工作在一半的时间内完成，就像把它当作"工厂车间"的工作一样，手头工作的性质和复杂性是完全确定的。由于软件开发是一个"创造性"的过程，在敏捷等高度灵活的方法中，这种严格的指标是无关紧要的。你認為如何?

3）虽然我的scrum团队及时完成了我们所有的承诺，但我们因为糟糕的冲刺中期验收指标而受到质疑。在其他地方的scrum团队中，只有在冲刺结束时才履行他们的承诺是完全正常的吗？

非常感谢提前。

Answer 1

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

我以前没有听说过冲刺中期接受。我不相信这是一个有效的敏捷/Scrum实践。 本网站 似乎同意"一旦团队致力于工作，产品所有者就不能添加更多的工作，在冲刺中期改变课程，或者 微观管理."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

出于您提到的原因，任何严格的指标通常都不是与开发人员一起使用的好主意。此外，对于可能的开发人员来说，他们更感兴趣的是在任何正在测量的东西中获得合格分数，而不是生产高质量的产品。这是乔尔*斯波斯基的一只臭虫熊 - 这里, 这里 和 这里

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

一个成功的Scrum团队应该在sprint结束时完成他们承诺要做的所有事情。燃尽图应该是可见的，以指导朝着这个目标的进展，当然在冲刺的后半部分将表明冲刺是否可能是成功的。在成功的冲刺中，我参与了完成用户故事的稳步进展是正常的，但这不能反映在一半的时间内完成一半的用户故事，我会建议反对这种指标。

Answer 2

你有没有试图限制你正在进行的工作量。如果你让所有的团队都专注于几个故事，而不是继续，直到这些故事完成，你应该看到你的燃尽变得更加线性。

也许也值得看看故事的大小。我个人不喜欢看到一个故事，需要超过几天的时间来完成开始到结束。

Answer 3

这不是Scrum实践。它可以被解释为一个指标，但一个坏的。关于你的怀疑，你是对的。

Scrum有一个完美的工具来跟踪进度-燃尽图。无需添加任何任意里程碑。

看来你的管理层不了解冲刺的基本概念，他们应该得到一些咨询或遵循基本的培训。如果在一周内完成的工作对您的管理层仍然很重要，请尝试建议将冲刺长度减少一半。

Answer 4

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

是的，是的。

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

如果你把任务分解成很小的任务，你就可以获得一个很好的工作进化指标。因此，设计任务在一个工作日内完成，您可以实现良好的燃尽指标使用。如果你有长时间的不可预测的任务，燃尽指标是无关紧要的，正如你所说。

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

问题不在于团队，而在于任务设计。问题在于任务粒度。您的团队可以在冲刺时间指标中完成工作，但现在您需要将任务细化到其中50％在冲刺中期时间指标中完成。将任务分解为更小的任务，您可以实现所需的（线性）燃尽图。

Answer 5

这是非标准的术语，但你的经理在说什么。

一个结束沉重的燃尽图（即在图表的很大一部分保持高位，然后在结束时突然结束）表明了一种做法，即任务是粗粒度的-也就是说，一个任务可能需要整个冲刺才能完成-并且由单个开发人员完成。在这种模式下，所有任务都保持不完整，直到冲刺结束之前。

这真的不是它应该工作的方式:如果积压工作是按优先级顺序进行的，那么为什么没有最高优先级的问题正在处理？此外，这将每个任务的"总线编号"设置得非常低，这可以显着增加在冲刺结束时任务保持未完成的风险。

为了解决这个问题，任务应该被分解成更小的块。如果你正在做规划扑克，并且一个任务估计在8点或更多，那么很可能是任务被低估了。它必须被分解。尝试并将其保持为2s和3s（或更小！）如果可能的话。通过这种方式，您可以让几个开发人员在同一个总体目标上独立工作，并且您的燃尽图应该开始看起来更平滑，风险更小，即使相同的工作正在完成。

Answer 6

中期冲刺验收不是一个敏捷实践，或者它在现实中不起作用。如果您对每个用户故事和任务都有正确的估计（例如在拉力赛中），那么burndown图表清楚地显示sprint工作是否与计划一致，并且可以及时完成。验收仅在用户故事的开发和测试结束时完成，而不是任务。