标签：需求倒排迭代开发人员 Bug 验收测试改不完

前言

随着互联网的兴起，版本交付越来越频繁，企业开始了敏捷转型、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 合理的任务看板

上图中，进行中和测试中的卡片数量都看上去没那么多，比较合理。如果出现类似下面的情况，开发活动开始了，完成了好多需求，但是测试活动远远落后，就要注意了，你可能掉进了小瀑布陷阱。

图4 不合理的任务看板

按照【图3：合理的任务看板】的卡片流转情况，这样可以尽早的发现需求的缺陷，降低了缺陷在系统中存留的时间，就是降低了它带来的风险。

需求上，澄清需求的时候明确验收标准

在需求澄清的时候，团队和产品负责人要对验收标准达成一致意见，并且记录下来，以辅助开发团队编码时有法可依。下图为示意图，在DevCloud记录用户故事的工作项里，同时记录验收标准，减少最后验收时出现需求式的Bug。

图5 DevCloud用户故事中的验收标准

质量上，通过预防来产生质量

质量管理大师克劳士比的质量管理基本原则里提到，预防产生质量，检验不能产生质量。所以，如果我们能在开发的时候就采取预防措施，做到第一次做正确，这才产生了质量，这也是零缺陷管理的核心。

图6 克劳士比零缺陷管理三要素

根据我们的实践和总结，推荐如下动作：

1. 沟通需求的时候，团队一起了解需求，在用户故事卡片里帮助添加检查点，以便于在编码的时候就会提前考虑这些检查点，进而编写代码的同时就保证了质量。

2. 在讨论需求和设计的时候，团队（一般由架构师或者技术能力强的测试人员来主导）就针对当前的设计和使用的技术提出需要注意的问题和建议，可以让开发人员在编码的时候就规避了潜在质量问题。

通过以上活动，从产品内在提高了质量，可以从本身上大大减少Bug数量。

测试上，加强自动化测试做到持续回归

从迭代里的第一次提交代码开始，任何一次提交代码，都做一次回归测试，这样可以保证第一时间发现对已有功能的影响，尽早修复，而不是在最后一次回归测试的时候发现问题。这个回归测试速度要快，也就是不花费太多时间，同时覆盖的面越广越好。

考虑到开发人员不爱做测试的共性，所以回归测试要做成便于开发人员维护，学习、维护成本低，效果好（如上所述的运行速度快、覆盖面广）的特点，比如说接口自动化测试。如下图所示，以软件开发平台 DevCloud 的接口测试为例，配置必要的信息，即为一个场景下的接口测试用例。

图7 DevCloud的接口测试配置

将所有接口都写好测试用例，然后配置到在流水线里。每次提交新的代码，都让它自动触发流水线，运行自动化测试用例，失败的话，就发邮件通知到该开发人员。

图8 DevCloud的流水线

这样，就可以高效的做了回归测试，最终使得在编码期间，有任何Bug出现，都可以第一时间发现，不会都堆积到项目的最后时刻爆发。

总结

迭代总是因为修复不完Bug而延期，解决方法并不是团队继续加班去工作，而是要找到根本原因，对症下药，通过诸如避免小瀑布陷阱、通过预防来产生质量、增加接口自动化测试、需求澄清时明确验收标准等措施来改善工作流程，才能避免陷入恶性循环，彻底解决这个问题。

Bug改不完，迭代总延期，项目又是倒排期怎么破局？

前言