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