Delay问题分析

【在刚刚过去的SAFe Scrum Master课程上有学员提出了Delay问题，进行了重点分析，颇有意义，因此整理得到本文】

大致背景情况：To B软件开发，已经启用了敏捷开发，迭代周期2周。

问题：经常出现Delay，如何优化？

分析1：并不严重，值得提升

首先这不是严重的问题，研发工作当中，这算是常见现象，毕竟包括软件开发在内的研发类工作是有高度不确定性。其次在敏捷迭代启用之后，恰恰是能够尽快得暴露Delay，当前常用的迭代周期是2周，对比20年前长达3个月的里程碑阶段，显然能更早地暴露Delay，进而更早的采取调整措施。但我们总是追求精益求精，虽然并不严重，但总是希望有所提升。

分析2：不是Delay迭代

笔者首次听到这问题时，没完全理解，追问Delay是否把迭代Delay了？得到答复不是延长迭代，而是把没有完成的故事Delay到后面。我一听之后还是蛮欣慰的，早期敏捷实践里面临时延长迭代的事情没有发生。因为Delay而临时延长迭代是敏捷实践的大忌，固定周期的敏捷迭代也是积累数据积累经验进而学习提升的迭代，一旦随意改变迭代周期，会导致这些积累的效果就明显下降。

分析3：是不是估算过于乐观？

软件开发估算自从上个世纪70年代以来，一直是难题，为此全人类发明了恐怕不下于100种方法，然而没有一种方法敢宣称有足够的准确度，参见