“老兵新传” 开篇丨 “三个洞察+三个连通” 金融企业数字化转型实践与思考
2021年8月12日
规模化敏捷Large Scale Scrum – Certified LeSS Basic 中文CLB认证课程-大规模敏捷扩展
2021年8月14日

​敏捷已经不是个新鲜词了,现在很多团队都实现了某种形式的敏捷。Scrum是其中最为流行的一种方式。但随着时间的推移,不少组织的敏捷都出现了一定程度的退化,具体表现为:

  • 固定时间迭代被版本迭代代替
  • 敏捷活动(站会、回顾等)流于形式或者被取消
  • 团队疲于奔命,996也不罕见
  • 团队速率未知,每次迭代都被产品尽可能往里面塞入更多东西
  • 燃尽图曲线不理想,经常很长时间没有进展,在最后突然完成。

我最近就看到这样一个团队。团队Leader跟我说他们曾经很努力,“坚持”敏捷了3年,可能是公司最后一个退化的团队。他用到了“坚持”这个词,说明在这个过程中,团队遇到了很多不合拍的情况,最后不得不“退化”为按版本迭代,按发布版本要求,分成若干小瀑布。不可避免的是交付周期延长,迭代末期加班,上线前鸡飞狗跳。

究竟为什么会这样呢?他们的演变过程是这样的:在一开始,他们是按照时间盒进行迭代。当某个版本要发布的时候,安排对这个版本进行测试。这个时候很多原来没有发现的问题就会涌现出来,团队不得不分出一部分精力去解决上线问题。随着时间的推移,这个为了上线的工作占的比重越来越大,逐渐就超过了开发新特性所需要的时间。于是不可避免地,原来的迭代要让位与版本上线。最终退化为按版本进行迭代。

为什么会造成这种退化?为什么上线版本的时候,要花费大量地经历修改问题?因为团队迭代中的“完成”标准不是上线标准,迭代中的完成,并不是“可工作的软件”。为什么迭代中不能达到可工作的标准?因为团队没有能力在足够短的时间内,对要上线的版本进行回归测试?为什么没有能力进行回归测试?因为都是人工测试,测试人员没那么多,必须进行批量测试,否则安排不过来。为什么都是人工测试?因为团队不掌握自动化测试技能,少数的编写接口测试的人员也无法满足开发的需要。这个就最终归结到一个问题:实施敏捷失败的最根本原因都可以归结到不会TDD上来。

一句话:

没有TDD的敏捷,几乎必然退化为中华田园敏捷。

评论关闭了。

拨打免费咨询电话 021-63809913