Nag*_*U M 1 agile scrum agile-processes
我是一个致力于软件产品发布的敏捷Scrum团队的一员.冲刺持续时间为2周(约10天).
这里使用了一种特殊的度量标准,称为" 中间冲刺接受 ".从本质上讲,期望是sprint团队在sprint中承诺和计划的用户故事点数的一半需要在sprint的中间完成.他们说,这会导致点线性燃烧,这是冲刺进展良好的一个强有力的指标.
作为一个团队,我们的中期冲刺接受通常很糟糕,但我们知道在冲刺结束时完成所有承诺的用户故事点.
我有以下问题:
1)中等冲刺接受是否是有效的敏捷/ SCRUM练习？是否在其他地方使用？
2)期望在一半时间内完成的工作的一半类似于将其视为"工厂底层"工作,其中手头工作的性质和复杂性是完全确定的.由于软件开发是一个"创造性"过程,因此像Agile这样高度灵活的方法中的这种严格的度量标准是无关紧要的.你怎么看？
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虫熊之一 - 这里,这里和这里
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结束时完成他们承诺要做的所有事情.燃烧图表应该是可见的,以指导实现这一目标的进展,当然在冲刺的后半部分将指示冲刺是否可能成功.在成功的冲刺中,我参与了在完成用户故事方面取得稳步进展是正常的,但这不能反映在一半的时间内完成一半的用户故事,我会反对这种指标.