在敏捷/SCRUM中，“中间冲刺”接受是一个有效的概念吗？

Question

我是敏捷scrum团队的一员，致力于软件产品发布。短跑时间为2周(~10天)。

这里有一个特殊的度量标准，叫做“ metric ”。本质上，人们的期望是，scrum团队在sprint中提交和计划的用户故事点的一半需要在sprint的中间完成。他们说，这会导致点的线性烧毁，这是一个强有力的指标，表明冲刺进行得很好。

作为一个团队，我们的中间冲刺接受通常是不好的，但我们知道，我们完成所有承诺的用户故事点结束冲刺。

我有以下问题：

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

2)期望一半的工作能在一半的时间内完成，就像把它当作一项“工厂层”的工作，在那里，手头工作的性质和复杂性是完全确定的。由于软件开发是一个“创造性”的过程，在高度灵活的方法(如敏捷)中，这种严格的度量标准是无关紧要的。你认为如何？

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

事先非常感谢。

Answer 1

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?

由于您提到的原因，对开发人员使用任何严格的度量标准通常都不是一个好主意。同样，对于喜欢的人来说，开发人员会更感兴趣的是，无论什么东西都能通过测试，而不是生产出高质量的产品。这是乔尔斯波斯基的一只臭虫熊- 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中，我一直参与完成用户故事的稳步进展是正常的，但这不能反映为在一半时间内完成一半的用户故事，并且我建议不要使用这种度量标准。

Answer 2

你有没有试过限制你正在进行的工作量。如果你让所有的团队专注于几个故事，直到这些故事完成，你就会看到你的倦怠变得更加线性。

这也可能是值得一看的故事的大小。就我个人而言，我不喜欢看到一个故事花了几天的时间才能完成。

Answer 3

这不是Scrum的练习。它可以被解释为一个度量标准，但却是一个糟糕的指标。关于你的怀疑，你是对的。

Scrum有一个完美的工具来跟踪进程--烧毁的图表。不需要添加任何任意的里程碑。

似乎你的管理层不了解冲刺的基本概念，他们应该得到一些咨询或遵循基本的培训。如果在一周内完成的事情对你的管理仍然很重要，建议把冲刺长度缩短一半。