我是敏捷scrum团队的一员，负责软件产品发布。冲刺持续时间为2周（约10天）。
这里使用了一个特殊的度量标准，称为"中期冲刺接受度"。从本质上讲，期望scrum团队在sprint中提交和计划的一半用户故事点需要在sprint中期完成。他们说，这会导致积分的线性消耗，这是短跑进行得很好的有力指标。
作为一个团队，我们在sprint中期的接受度通常很差，但众所周知，我们会在sprint结束时完成所有提交的用户故事点。
我有以下问题：
1） 中期冲刺验收是有效的敏捷/SRUM实践吗？它在其他地方使用吗？
2） 期望在一半的时间内完成一半的工作类似于将其视为"工厂车间"工作，手头工作的性质和复杂性是完全确定的。由于软件开发是一个"创造性"的过程，在敏捷等高度灵活的方法论中，这种严格的度量标准是无关紧要的。你觉得怎么样？
3） 尽管我的scrum团队及时完成了我们的所有承诺，但我们在冲刺中期的接受度指标很差，因此受到了质疑。在其他地方的scrum团队中，只在冲刺结束时履行承诺是完全正常的吗？
非常感谢。
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?
由于您提到的原因，任何严格的指标通常都不是与开发人员一起使用的好主意。同样，对于潜在的开发人员来说，他们更感兴趣的是在任何正在测量的东西中获得及格分数，而不是生产高质量的产品。这是Joel Spolskys的bug熊之一-这里，这里和这里
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团队应该在冲刺结束时完成他们承诺要做的所有事情。燃尽图应该是可见的，以指导实现这一目标的进展，当然在冲刺的后半段，它将表明冲刺是否可能成功。在我参与的成功冲刺中，在完成用户故事方面取得稳步进展是正常的，但这不能反映为在一半的时间内完成一半的用户故事，我建议不要采用这种衡量标准。
你有没有试着限制你正在进行的工作量。如果你让所有团队专注于几个故事，直到这些故事结束才继续，你应该会看到你的消耗变得更加线性。
也许还值得一看这些故事的规模。我个人不喜欢看到一个故事从开始到结束需要几天以上的时间。
这不是Scrum实践。它可以被解释为一个度量，但却是一个糟糕的度量。关于你的疑虑，你是对的。
Scrum有一个完美的工具来跟踪进展——燃尽图。无需添加任何任意里程碑。
你的管理层似乎不了解短跑的基本概念，他们应该得到一些咨询或进行基本训练。如果一周内完成的工作对你的管理层来说仍然很重要，那么试着建议把冲刺时间缩短一半。
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时间度量中完成任务，但现在您需要细化任务，使其在sprint中期时间度量中达到50%。将任务分解成更小的任务，就可以获得所需的（线性）消耗图。
这是一个非标准的术语，但您的经理所说的是有道理的。
一个消耗量很大的图表（也就是说，在图表的很大一部分保持高位，然后在最后突然减少）表明了一种实践，即任务是粗粒度的——也就是说一个任务可能需要整个冲刺才能完成——并由单个开发人员完成。使用这种模式，所有任务都将保持不完整状态，直到sprint结束。
这真的不是它应该的工作方式：如果积压工作是按优先顺序进行的，那么为什么没有最高优先级的问题要被处理呢？此外，这将每个任务的"总线数"设置得非常低，这会显著增加任务在冲刺结束时仍未完成的风险。
为了解决这个问题，应该将任务分解成更小的块。如果你正在进行计划扑克，并且一项任务被估计为8分或更多，那么很可能是该任务没有被指定。它必须被分解。如果可能的话，尽量保持在2秒和3秒（或更小！）。通过这种方式，你可以让几个开发人员独立地为同一个总体目标工作，即使完成了同样的工作，你的燃尽图也应该开始看起来更流畅、风险更小。
Mid Sprint接受不是一种敏捷实践，或者在现实中不起作用。如果你对每个用户故事和任务都有正确的估计（例如在Rally中），那么燃尽图可以清楚地显示冲刺工作是否符合计划，是否能够及时完成。只有在Development&测试用户故事而非任务。