第2节 敏捷转型

项目例会开始了，今天有点奇怪，部门的boss也到场了，大家议论纷纷，觉得一定有不同寻常的事情发生。

果然，boss首先说话了：“同学们，今天给大家宣布一件重大事情！鉴于目前行业现状和公司业务上的要求，我们考虑践行敏捷转型！”

“哇塞，敏捷？这个词好熟悉！”下面开始议论纷纷。

boss接着说“没错！虽然敏捷已经在行业里面风靡了好几年了，但是对于我们这样的公司，因为业务性质的关系，我们一直比较谨慎。但经过这几年的观察，我们不得不面临转型的挑战，我们的产品需要快速迭代发布版本！”

“领导英明！”众人纷纷支持。

“别拍马屁了！鉴于此，我们技术部做出了一个决定，邀请了业界知名的敏捷教练，同我们一起实施这场变革！”boss制止了喧闹。

“哇，牛！期待看看是谁！”

“下面让我来介绍一下……”

腾小宇听得入迷了，在他看来，自己刚踏上工作岗位，就碰上了这样的事情，实在是梦寐以求。一直以来，他是学霸，计算机编程高手，恨不得有三头六臂，把自己所有的精力都投入到工作中。

在接下来的几个月里，敏捷像一阵风一样侵袭公司的每个角落，包括总经理办公室、会议室、文件打印室和洗手间。不管是研发领导们，还是开发工程师们，仿佛在一夜之间都彻底恨透了CMMI，甚至连配置管理和SQA工程师们也跟着起哄，互相奔走相告践行敏捷转型：

“以后不怕产品加需求和变更需求了，尽管放马过来吧！”

“终于可以不用加班熬夜写系统设计文档了，让流程见鬼去吧；终于可以想怎么写代码就怎么写代码了，不用为了修一个bug，改一行代码就看测试人员的脸色。”

“嗯，SVN服务器的目录和空间可以省一省了。”

……

仔细观察这些人的眉宇之间，好像隐隐有了一种马上都要“出任CEO，迎娶白富美，走上人生巅峰”的豪情壮志。

然而，在这万众欢呼庆祝敏捷转型的到来之际，却有那么一群人看起来不太对劲，会议室里，几个测试员正紧缩眉头，集体苦苦思索着。敏捷转型意味着去流程化，可以想象这对测试人员来说是多大的挑战，需求说变就变，代码想改就改，测试效率如何提高，测试质量又如何保证呢？腾小宇作为一枚新人，当然还体会不到其中的困惑，只是意识到敏捷转型已经是一件势在必行的事情。

敏捷转型的号角已经吹响，各个项目都开始进行敏捷转型落地，开始改革各种流程。产品需求说改就改，测试人员只好见招拆招，你改需求我就要求延长测试时间，作为测试人员质量是最重要的，但敏捷强调快是王道，看起来这似乎是矛盾的。

现实中测试面临的挑战

在传统体系中，我们希望很多事情都是完美的，在测试人员眼中的软件研发应该是这样的：

a）需求是清晰的。

b）流程是固化的。

c）开发是有序的。

d）系统是可测的。

e）测试时间是充足的。

f）用户是讲道理的。

可是，理想是丰满的，现实是骨感的！我们看到的是这样的：需求频繁改，开发者的交付问题多，测试者总是被催促，用户骂声一片，产品经理拼命想点子。

是这个世界太疯狂了吗？不是的。互联网的变化越来越快，用户越来越在乎体验，客户越来越挑剔；交付压力也越来越大；这一切的一切都使敏捷显得势在必行。

既然我们对需求频繁变化不再陌生，并且开始慢慢认为这是合理的；开发人员延迟开发计划、压缩测试时间，已经成为常态。测试经常会是最后的一道工序，加班加点似乎已经成了一种习惯。

那么问题来了，在这种情况下：

□ 我们还能随心所欲地设计大量测试用例吗？

□ 还有大段的系统测试时间和集成测试时间吗？

□ 还能要求充足地回归测试吗？

□ 还能期望开发人员提供各种测试建议吗？

□ 现实如此，测试还能不能愉快地进行下去了？