Delay问题分析

【在刚刚过去的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个条件之一:

Delay问题分析_第1张图片

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

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

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

分析6:从Delay当中能够学习什么?

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

----------

SAFe课程信息

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

    • Leading SAFe领导规模化敏捷框架课程简介

    • Leading SAFe 规模化敏捷领导者认证SA

SAFe POPM课程,11月11日~12日,参见

    • 最新鲜SAFe6 POPM(Product Owner Product Manager)课程来了

    • 简记一场SAFe6 POPM培训

如果课程感兴趣,请扫码联络。

Delay问题分析_第2张图片

电话:400-888-5228

你可能感兴趣的:(敏捷,1024程序员节)