敏捷退化

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

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

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

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

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

一句话：

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