Bug改不完，迭代总延期，咋办？ _生活百科

摘要：本文从流程上需要改进的地方进行讨论，分四个方面来分析产生这个问题的原因。

本文分享自华为云社区《Bug改不完，迭代总延期，咋办？》，作者：华为云PaaS服务小智。
前言随着互联网的兴起，版本交付越来越频繁，企业开始了敏捷转型、DevOps落地，项目组雄心勃勃，期望产品能按迭代快速交付。然而常见的现象是，到了迭代的最后一天，还有不少Bug来不及修复，迭代无法产生潜在可交付成果，延期成了必然。然后发现连续几个迭代都是这样，团队没有成就感，士气低落。迭代的无法按期交付，让团队及公司领导又觉得敏捷只是形式化，并没有解决问题，久而久之，就干脆放弃了所采用的敏捷框架，回到老路子上了。
迭代总是因为修复不完Bug而延期，该如何解决呢？本文从流程上需要改进的地方进行讨论，对于开发人员能力弱、迭代内需求量过多等人为因素我们不进行讨论。
问题分析我们主要从下面四个方面来分析产生这个问题的原因。
流程上，在迭代内搞小瀑布开发很多企业在转型敏捷后，依旧用着以前大瀑布的工作方式，即设计->开发->测试->修Bug，这就是我们常说的：在迭代内玩小瀑布。小瀑布继承了传统模式的一个弊端，就是测试工作放在了整个项目周期的最后一个环节，导致问题集中爆发，同时有的需求Bug也会影响到其他需求，而中间过程没有去检测bug，以至于导致其他需求又出现了新的Bug 。到了后期，集中测试的时候，就发现Bug的关联性错综复杂，增加了修复的时间。
更要命的是，由于使用的是迭代开发，假如是一周的迭代，到了周四下午转交给测试人员，期望用两个小时测试通过，然后稍微修补修补小bug，产品就能上生产了。是不是感觉很熟悉？期望XXX结果XXX 。按计划周四下午转交给测试，周五上生产，结果却常常是周四发现了太多的Bug，结果周四晚上团队加班修Bug，重新测，周五常常无法部署到生产，延期到下周。
需求上，需求澄清时没有明确的验收标准这个问题在刚转型敏捷的团队中，出现的更多。敏捷强调的是充分沟通需求，再将讨论一致的点都记下来，特别是验收标准要写明了。但是实际中，大家对敏捷常常有个误区，就是不需要文档，需求也只要头口沟通下就行了，结果就是既没做到充分沟通，又没有最好记录，最重要的验收标准都没讨论清楚。这样，开发人员开发出来的产品到了测试环节，由于测试人员更偏重业务方向，所以对产品的认识和使用提出了一些看法，觉得某些地方的设计不够好，提了不少需求式的Bug，等测试完毕，在产品经理验收的时候，又会出于同样的原因提出一些Bug 。这些Bug对于开发人员来说也很委屈，最开始的需求里并没有说明这几点应该做成什么样，现在提的这些Bug相当于额外加的需求，又不得不马上处理掉。
举个例子，需求澄清时，产品经理说想要个灵动的鲸鱼，和团队达成了一定的共识，双方讨论了下鲸鱼大概应该是下面的样子。