Delay问题分析

news2024/10/6 8:27:58

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

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

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

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

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

分析2：不是Delay迭代

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

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

软件开发估算自从上个世纪70年代以来，一直是难题，为此全人类发明了恐怕不下于100种方法，然而没有一种方法敢宣称有足够的准确度，参见软件开发工作量估算纵横谈。敏捷开发流行以来，从理想工时到故事点，包括其中的变种和组合，也是有好多种方法进行估算，参见敏捷迭代估算方式调查报告。在2023年这个时间点，首先必须承认一个事实：无论采用哪种估算方法，必然有误差。其次从最近20年发展趋势而言，故事点方法应当优于理想工时方法，最新出现的No-Estimates结合最小故事分解不排除优于故事点方法，参见将#noestimates|鸡蛋估算法付诸行动，#实问实答谈谈工作量评估和鸡蛋估算法，说说鸡蛋估算法。

对于高不确定性的情况进行估算，还有一个显著的情况是漏估计，很容易漏掉一些难以预计的细节，这就会导致估算过于乐观，进而迭代待办事项就偏长，难以在迭代内全部完成。

既然估算必然有偏差，而且往往估计不足，那么怎么办？常见的做法是把迭代待办事项分成两类，一类对应到迭代目标当中，也就是比较有把握实现，也是高优先，另外一类不在迭代目标之内，也就是没足够把握，也不是高优先。

分析4：迭代中能否第1时间识别Delay？

在英文的Commitment理解上，承诺并不是不能修改，而是满足如下2个条件之一：

因此迭代中每日短会校验是否达成迭代目标，如果识别到故事来不及，那么应当第1时间通报到干系人，寻求帮助和纠正措施，如果实在来不及，那么也避免给各方带去意外。

分析5：到了迭代末是否把部分完成故事的未完成部分拆分出新故事，把老故事缩小到完成部分？

以上做法看起来就像是糊弄，只有在完成部分确实能够上线并且被用户使用到才值得采纳。明显的问题是既然能够把完成部分提供给用户使用，那为什么它不是一个单独的故事？因此为了让可能发生的Delay减少影响范围，值得在故事识别时采用原子化规则把故事拆解到尽量小，这样万一Delay，不会拖累其它故事。

分析6：从Delay当中能够学习什么？

总有些故事的Delay不可避免的发生，一般来说在迭代评审时会考虑如何处理哪些Delay的故事，而在迭代回顾时也值得来分析下Delay，看看有哪些改进措施。这众多改进措施选项当中，笔者推荐可以把目光转向那些按时完成估算准确的好故事，用好故事组建一组法码集，给故事点为1的样例故事加多些样例，覆盖2、3、5、8，甚至覆盖到不同领域。让后面的故事估算有更多更加相近的样例可以拿来进行比较。

----------

SAFe课程信息

Leading SAFe课程，10月28日~29日，参见