“中期冲刺”接受是敏捷/SCRUM 中的一个有效概念吗？ [关闭]答案

【问题标题】：Is 'mid-sprint' acceptance a valid concept in Agile/SCRUM? [closed]“中期冲刺”接受是敏捷/SCRUM 中的一个有效概念吗？ [关闭]
【发布时间】：2012-03-09 17:36:26
【问题描述】：

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

这里使用了一个特殊的指标，称为“mid-sprint 接受度”。从本质上讲，期望是 Scrum 团队在 sprint 中承诺和计划的一半用户故事点需要在该 sprint 的中间完成。他们说，这会导致积分的线性燃尽，这是冲刺进展顺利的有力指标。

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

我有以下问题：

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

2) 期望在一半的时间内完成一半的工作类似于将其视为“工厂车间”工作，其中手头工作的性质和复杂性是完全确定的。由于软件开发是一个“创造性”的过程，因此高度灵活的方法（如敏捷）中的这种刚性指标是无关紧要的。你怎么看？

3) 尽管我的 Scrum 团队在 sprint 中及时完成了我们所有的承诺，但我们仍因糟糕的中期 sprint 验收指标而受到质疑。在其他地方的 Scrum 团队中，仅在冲刺结束时才履行承诺是否完全正常？

非常感谢。

【问题讨论】：

标签： agile scrum agile-processes

【解决方案1】：

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

我以前没有听说过中期 sprint 接受。我不相信这是一种有效的敏捷/Scrum 实践。 This site 似乎同意“一旦团队致力于工作，产品负责人就不能添加更多工作、在冲刺中期改变路线或微观管理。” p>

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?

出于您提到的原因，任何严格的指标通常都不适合与开发人员一起使用。此外，对于可能的情况，开发人员更感兴趣的是在所测量的任何内容中获得及格分数，而不是生产优质产品。这是 Joel Spolsky 的一只臭虫熊 - here、here 和 here

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 结束时完成他们承诺要做的所有事情。燃尽图应该是可见的，以指导实现这一目标的进展，当然在 sprint 的后半部分将表明 sprint 是否可能成功。在我参与的成功冲刺中，在完成用户故事方面取得稳步进展是正常的，但这不能反映在一半的时间内完成一半的用户故事，我建议反对这种指标。

【讨论】：

【解决方案2】：

您是否尝试过限制正在进行的工作量。如果您让所有团队都专注于几个故事，并且在这些故事完成之前不继续前进，您应该会看到您的燃尽图变得更加线性。

也许还值得看看故事的规模。我个人不喜欢看到一个故事需要超过几天才能完成。

【讨论】：

【解决方案3】：

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

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

您的管理层似乎不了解冲刺的基本概念，他们应该接受一些咨询或接受基本培训。如果一周内完成的工作对您的管理层仍然很重要，请尝试建议将 sprint 长度减半。

【讨论】：

【解决方案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?

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

【讨论】：

问题是大约一半的故事是在冲刺的中间交付的，而不是一半的任务。如果问题是时间消耗，任务设计可以纠正它；但问题与故事燃尽有关，这可能无法实现，具体取决于故事的内容。
@darlington：你知道一个使用冲刺中期验收的地方吗？我同意更小、更细化的任务将帮助我们实现这一目标。但我不想，因为我觉得我们只是在追逐时间和分数，而不是做高质量的工作。我同意 antlersoft 的观点，我们谈论的是故事，而不是任务。此外，设计和采用这一指标的不是 Scrum 团队，而是管理人员。
我同意你的观点。故事是由任务实现的，所以当我说任务设计问题时，它可以是故事设计，无论是燃尽图的概念设计。我们有故事，但我们追踪任务——这对我们来说很重要。我在 NDA 下，所以我不能为你提供他们使用它的名字，但重点是管理风格。从技术的角度来看，这一切都无关紧要 - 这是一个管理问题。

【解决方案5】：

这是非标准术语，但你的经理所说的话是有道理的。

一个末端重的燃尽图（即，在图表的大部分时间里保持高位，然后在最后突然下降）表明任务是粗粒度的——也就是说，任务可能需要整个 sprint 才能完成 - 并由单个开发人员完成。使用这种模式，所有任务在 sprint 即将结束之前都不会完成。

这确实不是它应该的工作方式：如果积压是按优先级顺序排列的，那么为什么要处理没有最高优先级的问题？此外，这会将每个任务的“总线编号”设置得非常低，这会显着增加任务在 sprint 结束时仍未完成的风险。

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

【讨论】：

【解决方案6】：

接受中期 Sprint 不是一种敏捷实践，或者它在现实中行不通。如果您对每个用户故事和任务（例如在 Rally 中）有正确的估计，那么燃尽图会清楚地显示 sprint 工作是否与计划一致并且可以按时完成。验收仅在用户故事而非任务的开发和测试结束时完成。

【讨论】：