15.1.4 敏捷开发中是否有必要解决所有bug？

[GreyZeng]

在十五章中，提到了ZBB策略，即在这一版本构建把所有已知的bug全部解决，而本书在此之前也提到过“优秀的软件团队会发布有已知缺陷的软件”。
​
实际项目中我们也不能保证消除所有的bug，有些bug消除起来较难，需要改动的代码较多，而bug影响又小，在花费的时间和收获的效果不成正比的情况下，有些公司会对这些bug视若无睹，或者等到版本大更的时候考虑修复。追求修复所有bug反而有可能拖慢项目进度。在bug也不影响新功能的开发的情况下，ZBB可以选择留bug以保证项目进度吗?

原文地址

[GreyZeng]

在我们的实际操作过程中，并没有遇到我所描述的难以消除且影响不大的bug，但是我们确实遇到了需要花很长时间才能解决的问题。在我们的敏捷开发中，由于要保证交付时间，我们选择先避开这个问题，用另一种方法解决问题。而ZBB策略中，我也没有改变自己的想法，虽然ZBB需要清零bug，但是团队在质量外也需要兼顾速度，偶尔遇到几个难以修复又影响不大的bug可以先不修复。

原文地址

[GreyZeng]

在我们的软件开发流程中，对于“优先级较低的Bug”也是经过充分与完全的测试发现的bug，对其出现条件有清晰准确的定义，因此我们可以保证，对于此类优先级较低且尚未修复的bug是次要且不紧急的，并不会引发出其他测试未覆盖到的严重错误。

在我们的软件发布前，团队充分测试了发布版本的软件，确保没有发布出包含已知Bug的产品，并且对于发布版本中存在的部分限制也明确地标注在发布声明中，因此用户反馈的bug都是未知的，团队在修复用户反馈时具有较好的效率。
————————————————
版权声明：本文为CSDN博主「Mmmusel」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Mmmusel/article/details/131254231