我是一名致力于软件产品发布的敏捷Scrum团队的成员。冲刺持续时间为2周（约10天）。
此处使用了一种特殊的指标，称为“中间冲刺接受”。从本质上讲，期望是sprint团队在sprint中承诺和计划的用户故事点数的一半需要在sprint的中间完成。他们说，这会导致点线性燃烧，这是冲刺进展良好的一个强有力的指标。
作为一个团队，我们的中期冲刺接受通常很糟糕，但我们知道在冲刺结束时完成所有承诺的用户故事点。
我有以下问题：
1）中期冲刺是否接受有效的敏捷/ SCRUM练习？是否在其他任何地方使用？
2）期望在一半时间内完成的工作的一半类似于将其视为“工厂底层”工作，其中手头工作的性质和复杂性是完全确定的。由于软件开发是一个“创造性”过程，因此像Agile这样高度灵活的方法中的这种严格的度量标准是无关紧要的。你觉得怎么样？
3）尽管我的scrum团队正好赶上sprint的所有承诺，但我们正在质疑我们糟糕的中期冲刺接受指标。在其他地方的scrum团队中，只有在冲刺结束时才能履行承诺，这是完全正常的吗？提前非常感谢。
答案 0 :(得分：5)
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
我之前没有听说过冲刺中期。我不相信这是一个有效的敏捷/ Scrum实践。 This site似乎同意“一旦团队承诺工作，产品负责人就无法添加更多工作，改变课程中期冲刺或 微观管理 。”
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 Spolskys虫熊之一 - 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结束时完成他们承诺要做的所有事情。燃烧图表应该是可见的，以指导实现这一目标的进展，当然在冲刺的后半部分将指示冲刺是否可能成功。在成功的冲刺中，我参与了在完成用户故事方面取得稳步进展是正常的，但这不能反映在一半的时间内完成一半的用户故事，我会反对这种指标。
答案 1 :(得分：1)
您是否尝试过限制您正在进行的工作量。如果你让所有的团队专注于几个故事而不是继续前进，那么你应该看到你的燃尽变得更加线性。
也许值得一看这些故事的大小。我个人不喜欢看到一个花费超过两天的故事来完成从头到尾。
答案 2 :(得分：1)
这不是Scrum练习。它可以被解释为一个指标，但却是一个糟糕的指标。关于你的疑虑，你是对的。
Scrum有一个完美的工具来跟踪进展 - 烧毁图表。无需添加任何任意里程碑。
您的管理层似乎不了解冲刺的基本概念，他们应该接受一些咨询或遵循基本培训。如果您的管理层在一周内完成的工作仍然很重要，请尝试建议将冲刺长度减少一半。
答案 3 :(得分：0)
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中间时间度量标准下完成。将任务分解为较小的任务，您可以实现所需的（线性）燃尽图表。
答案 4 :(得分：0)
这是非标准的术语，但是你的经理会说些什么。
最重的燃烧图表（即图表的大部分位置保持高位，然后在结尾突然停止）表示任务粗粒度的实践 - 即，任务可能需要整个冲刺才能完成 - 并由个别开发人员完成。使用此模式，所有任务在sprint结束之前仍然不完整。
这真的不是它应该工作的方式：如果积压按优先顺序排列，那么为什么没有最高优先级的问题会被处理？此外，这将每个任务的“总线编号”设置得非常低，这可能会显着增加在冲刺结束时任务保持不完整的风险。
要解决此问题，应将任务细分为更小的块。如果您正在计划扑克，并且任务估计为8分或更多，那么该任务很可能未被指定。必须打破它。如果可能的话，尝试将其保持为2s和3s（或更小！）。通过这种方式，您可以让多个开发人员在相同的总体目标上独立工作，并且即使在完成相同的工作时，您的燃尽图也应该开始看起来更平滑，风险更小。
答案 5 :(得分：0)
Mid Sprint接受不是一种敏捷实践，或者它在现实中不起作用。如果您对每个用户故事和任务有正确的估计（例如在拉力赛中），那么燃尽图清楚地显示了冲刺工作是否与计划保持一致并且可以及时完成。只有在开发和结束时才接受验收。测试用户故事而不是任务。