这些我们可以称为需求变更，也不能说是需求变更，因为在需求澄清的时候，双方没有明确验收标准，在开发一个产品时，产品经理所想的和开发人员想的是不一样的，最后验收时就会提出各种可A可B的选择题，产品经理选的是A，他认为最开始讨论的时候达成的共识就是A，而你开发出来的是B，所以最后时刻提出看似新需求的Bug 。
质量上，保证的工作全部交给了测试【Bug改不完，迭代总延期，咋办？】传统的质量保证工作，就是在最后一个环节——测试里做到的 。开发人员将做好的产品转交给测试人员，期望在这个环节里多多的测出Bug，然后自己很“勤奋”很“努力”的去修复 。最终结果就是，大家都加班干活，项目依旧没法按时完成 。开发疲于奔命的写（创）代（造）码（Bug）和修Bug，测试拿到开发好的代码后不厌其烦的寻找Bug，这期间并没有从源头上去提高质量 。这就陷入了误区-质量是由测试来保证的 。测试，只是检测手段，质量本身没有做好提高措施的话，光靠检测，只会事倍功半 。
测试上，没有能力做到持续回归测试新功能测试完毕后，要进行回归测试，这时候发现出现很多已有功能的Bug 。已有功能的Bug又是新功能代码间接引入的，查找问题原因，修复Bug，再针对这一次修复进行回归，流程很长，花费时间比修复新功能的Bug要多 。由于回归测试常常是放在了测试环节里面的最后一步来做，时间盒已经消耗殆尽，造成迭代延期 。
传统项目里，回归测试常常做好几轮 。以一个三个月开发周期为例，第四个月开始测试工作，到了月底可能测试+修复的差不多了，进行第一轮回归测试，然后继续修复新发现的Bug 。一周后进行第二轮回归测试，再修复新Bug，再3天后进行第三轮回归测试，再修复，这样的流程 。
我们都知道做软件开发过程中，会带来很多已有功能的Bug，但是依旧选择将这么重要的回归测试放在了项目的最最最后的那几天，导致集中出现大量的已有功能的Bug 。通常这都是由于，做一次回归测试需要的时间太久导致的，团队没有能力做到每次更改代码，都快速的做一遍全量回归测试 。
解决措施针对上面提出的导致因为修复不完Bug而延期的四个方面问题，给出以下建议 。
流程上，避免小瀑布陷阱一定要避免诸如前半周需求，后半周设计，第一周开发第二周测试这样的小瀑布开发模式 。
无论迭代里有多少个需求，一个迭代时长是几周，每开发完一个需求，立刻开始测试工作 。
理想状态如下：
? 第一个需求开发完毕，测试人员开始测试，开发开始为第二个需求进行编码，期间同时修复第一个需求的Bug 。
? 等第二个需求开发完毕，第一个需求的测试及bug修复应该也结束了，然后第三个需求的开发和第二个需求的测试工作应该开始了 。
如果团队使用Scrum框架的话，那么在每天的站立会议上，团队在看板上移动需求卡片时，测试人员关注那些已经被开发人员移动到了已解决的卡片，按照实际能力将相应数量的移动到测试中，如下图所示 。
文章插图
图3 合理的任务看板
上图中，进行中和测试中的卡片数量都看上去没那么多，比较合理 。如果出现类似下面的情况，开发活动开始了，完成了好多需求，但是测试活动远远落后，就要注意了，你可能掉进了小瀑布陷阱 。
经验总结扩展阅读
- 魔改xxl-job，彻底告别手动配置任务！
- 花呗如何设置还款方式（花呗还款日期改到20号好不好)
- 结婚改口茶说什么 需含有感激之意
- 银行贷款申请了等额本息可以更改吗
- 火箭浣熊是怎么被改造的
- 饥荒怎么修改人物的回精神速度
- 微信来消息声音怎么改
- 虚心接受改变的句子
- 案例分享-https证书链不完整导致请求失败
- 邮箱大师怎么修改密码