摘要：本文从流程上需要改进的地方进行讨论，分四个方面来分析产生这个问题的原因。
本文分享自华为云社区《Bug改不完，迭代总延期，咋办？》，作者： 华为云PaaS服务小智。
前言随着互联网的兴起，版本交付越来越频繁，企业开始了敏捷转型、DevOps落地，项目组雄心勃勃，期望产品能按迭代快速交付。然而常见的现象是，到了迭代的最后一天，还有不少Bug来不及修复，迭代无法产生潜在可交付成果，延期成了必然。然后发现连续几个迭代都是这样，团队没有成就感，士气低落。迭代的无法按期交付，让团队及公司领导又觉得敏捷只是形式化，并没有解决问题，久而久之，就干脆放弃了所采用的敏捷框架，回到老路子上了。
迭代总是因为修复不完Bug而延期，该如何解决呢？本文从流程上需要改进的地方进行讨论，对于开发人员能力弱、迭代内需求量过多等人为因素我们不进行讨论。
问题分析我们主要从下面四个方面来分析产生这个问题的原因。
流程上，在迭代内搞小瀑布开发很多企业在转型敏捷后，依旧用着以前大瀑布的工作方式，即设计->开发->测试->修Bug，这就是我们常说的：在迭代内玩小瀑布。小瀑布继承了传统模式的一个弊端，就是测试工作放在了整个项目周期的最后一个环节，导致问题集中爆发，同时有的需求Bug也会影响到其他需求，而中间过程没有去检测bug，以至于导致其他需求又出现了新的Bug。到了后期，集中测试的时候，就发现Bug的关联性错综复杂，增加了修复的时间。
更要命的是，由于使用的是迭代开发，假如是一周的迭代，到了周四下午转交给测试人员，期望用两个小时测试通过，然后稍微修补修补小bug，产品就能上生产了。是不是感觉很熟悉？期望XXX结果XXX。按计划周四下午转交给测试，周五上生产，结果却常常是周四发现了太多的Bug，结果周四晚上团队加班修Bug，重新测，周五常常无法部署到生产，延期到下周。
需求上，需求澄清时没有明确的验收标准这个问题在刚转型敏捷的团队中，出现的更多。敏捷强调的是充分沟通需求，再将讨论一致的点都记下来，特别是验收标准要写明了。但是实际中，大家对敏捷常常有个误区，就是不需要文档，需求也只要头口沟通下就行了，结果就是既没做到充分沟通，又没有最好记录，最重要的验收标准都没讨论清楚。这样，开发人员开发出来的产品到了测试环节，由于测试人员更偏重业务方向，所以对产品的认识和使用提出了一些看法，觉得某些地方的设计不够好，提了不少需求式的Bug，等测试完毕，在产品经理验收的时候，又会出于同样的原因提出一些Bug。这些Bug对于开发人员来说也很委屈，最开始的需求里并没有说明这几点应该做成什么样，现在提的这些Bug相当于额外加的需求，又不得不马上处理掉。
举个例子，需求澄清时，产品经理说想要个灵动的鲸鱼，和团队达成了一定的共识，双方讨论了下鲸鱼大概应该是下面的样子。
图1 需求版：灵动的鲸鱼
然而最后开发出来的结果却是下面这样。
图2 交付版：灵动的鲸鱼
出现这个结果的原因就是，在需求澄清时，没有清晰的验收标准，客户也不是很清楚自己的需求具象化之后什么样，团队和产品负责人以为达成了一致意见，实际上都是脑子中想象的一致，他们对图片的理解是不同的。真正验收的时候，产品负责人必然会要求再次改动。
这些我们可以称为需求变更，也不能说是需求变更，因为在需求澄清的时候，双方没有明确验收标准，在开发一个产品时，产品经理所想的和开发人员想的是不一样的，最后验收时就会提出各种可A可B的选择题，产品经理选的是A，他认为最开始讨论的时候达成的共识就是A，而你开发出来的是B，所以最后时刻提出看似新需求的Bug。
质量上，保证的工作全部交给了测试传统的质量保证工作，就是在最后一个环节——测试里做到的。开发人员将做好的产品转交给测试人员，期望在这个环节里多多的测出Bug，然后自己很“勤奋”很“努力”的去修复。最终结果就是，大家都加班干活，项目依旧没法按时完成。开发疲于奔命的写（创）代（造）码（Bug）和修Bug，测试拿到开发好的代码后不厌其烦的寻找Bug，这期间并没有从源头上去提高质量。这就陷入了误区-质量是由测试来保证的。测试，只是检测手段，质量本身没有做好提高措施的话，光靠检测，只会事倍功半。
测试上，没有能力做到持续回归测试新功能测试完毕后，要进行回归测试，这时候发现出现很多已有功能的Bug。已有功能的Bug又是新功能代码间接引入的，查找问题原因，修复Bug，再针对这一次修复进行回归，流程很长，花费时间比修复新功能的Bug要多。由于回归测试常常是放在了测试环节里面的最后一步来做，时间盒已经消耗殆尽，造成迭代延期。
传统项目里，回归测试常常做好几轮。以一个三个月开发周期为例，第四个月开始测试工作，到了月底可能测试 修复的差不多了，进行第一轮回归测试，然后继续修复新发现的Bug。一周后进行第二轮回归测试，再修复新Bug，再3天后进行第三轮回归测试，再修复，这样的流程。
我们都知道做软件开发过程中，会带来很多已有功能的Bug，但是依旧选择将这么重要的回归测试放在了项目的最最最后的那几天，导致集中出现大量的已有功能的Bug。通常这都是由于，做一次回归测试需要的时间太久导致的，团队没有能力做到每次更改代码，都快速的做一遍全量回归测试。
解决措施针对上面提出的导致因为修复不完Bug而延期的四个方面问题，给出以下建议。
流程上，避免小瀑布陷阱一定要避免诸如前半周需求，后半周设计，第一周开发第二周测试这样的小瀑布开发模式。
无论迭代里有多少个需求，一个迭代时长是几周，每开发完一个需求，立刻开始测试工作。
理想状态如下：
• 第一个需求开发完毕，测试人员开始测试，开发开始为第二个需求进行编码，期间同时修复第一个需求的Bug。
• 等第二个需求开发完毕，第一个需求的测试及bug修复应该也结束了，然后第三个需求的开发和第二个需求的测试工作应该开始了。
如果团队使用Scrum框架的话，那么在每天的站立会议上，团队在看板上移动需求卡片时，测试人员关注那些已经被开发人员移动到了已解决的卡片，按照实际能力将相应数量的移动到测试中，如下图所示。
图3 合理的任务看板
上图中，进行中和测试中的卡片数量都看上去没那么多，比较合理。如果出现类似下面的情况，开发活动开始了，完成了好多需求，但是测试活动远远落后，就要注意了，你可能掉进了小瀑布陷阱。
