概述
最近公司使用敏捷中的双周迭代，也即是每两个星期发布一次应用。双周迭代是控制团队交付节奏的，但是如果玩的不好，会导致大量的线上bug。先讲一下我们之前遇到的一个双周迭代问题。
产品需求提出后，我们研发这边开始分析需求，输出user story，并估算故事点。这个阶段的时间是非常短的，一般就一天，为啥呢？因为是双周发布上线一次，因此测试人员会根据上线时间进行倒推，要求开发在哪一天必须提测，不然上线就有风险。因此就形成了一个恶性循环，开发分析任务时间短、开发时间短，自测时间短，与前端联调的时间短，测试人员的测试时间也短，但是为了那个人为设定的deadline，只能加班加点的搞。到了最后上线的时候，经常出现了各种线上故障。
对这样的病态双周迭代流程，我是强烈抗议的，我们做软件，质量是第一位的，开发质量不行了，就会影响后续的整个流程，整条链路都会非常的累和忙。
但是这个是老板定的流程哦，我们应该如何处理呢？答案是对上思辨，并不是老板的定的东西就是对的，可能之前他在其他公司，用过这个方法，成功了。但是这种只是阶段性成功，在当前公司的实际场景下，确未必是适用的。
由于公司有个聚合层单体应用，在上面开发的程序员有几十号人，稍有不慎，线上就频繁出现问题，因此，当前的首要任务是降低线上故障数量，保证系统稳定性，这个是最迫切需要解决的，而双周迭代对此毫无帮助，且会由于开发时间短，造成更多的故障。
后面我们换了一种方式，给开发留足估算任务的时间，尽量的了解任务细节后，输出故事点，然后才开始排期，并且把单元测试、自测、前后端联调，code review都作为一个任务，这样子，才能尽量保证提测的东西质量好，从而也提高的测试人员的测试效率。
执行了几次后，每次上线，故障都基本没有。
双周迭代的另外一种运行方式
如果你一定要保持双周一发布的节奏，那么你可以尝试这样来玩，第一个双周迭代，就是给开发人员用的，也即是，有两周的开发时间，在这两周内提测任务，然后测试人员在下个双周迭代测试上个双周迭代的任务，这样，测试人员也有两个星期的测试时间。
这样的话，就不会造成整条链路都非常忙，测试人员使劲来催的事情了。