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

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

本文分享自华为云社区《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，这期间并没有从源头上去提高质量。这就陷入了误区-质量是由测试来保证的。测试，只是检测手段，质量本身没有做好提高措施的话，光靠检测，只会事倍功半。