零缺陷系统的圣杯

　　尽管零缺陷听上去很动听，但真有这种可能吗？还是说这是一个无法实现的目标？很多组织采用“零缺陷的方法”。这是否真的有意义？

　　Jim Bird认为，100%完美的成本是异常高昂的。一旦团队去除了90%的缺陷，到达了最佳水平，进一步去除缺陷所得的回报，相对于不成正比的成本而言，会明显降低。Jim引用了Ken Beck和Martin Fowler在《规划极限编程》中提到的观点：

但是，对于大多数软件，我们实际上并不期望它是零缺陷的。任何缺陷，一旦发现，要消除它就要花费时间和精力。这些时间和精力本可以投入到更有价值的新功能上。因此你必须决定做什么。

　　Michael Dubakov有类似的观点，他认为相比零缺陷思想能带来的好处，它产生的问题可能会更多。Michael说，不良的后果包括：

• 没有足够的勇气去重构复杂、混乱、到处是缺陷的重要代码。
• 无法做出重要的决策，而会做出风险相对较小的错误决定。
• 尽其所能不愿承担责任，这会导致滑稽愚蠢的行为。

　　Michael认为在现实中，在生产系统中有缺陷是很正常的。这并不意味着团队应该自满，不去修正缺陷。但是，这并不代表所谓的“最后缺陷”是一个海市蜃楼。

　　Jim认为对于需要修正的缺陷，应该加以选择。通过确认缺陷的严重程度和发生频率，团队首先应该确定缺陷对于业务运作的重要性。下一步，则是在修正缺陷前，考虑诸如“修正成本”和“对于系统其他部分的风险”这样的技术因素。

零缺陷的观点天真地假设：修正缺陷总是好的、正确的。但修正缺陷并不总是一件正确的事情，因为对于任何修正，都会有引入新问题的风险。

　　Joel Spolsky认为，零缺陷并不是字面上代表的意义。它是说在任何时候，在编写新的代码之前，最高的优先级是消除缺陷。

　　那么减少缺陷的最佳途径是什么？

　　Mark Windholtz认为测试驱动开发是至关重要的：

测试先行的编码是实现零缺陷目标的基础。测试先行的编码方法，要求在编写生产代码之前，先编写自动化的单元测试，而编写测试代码的时间周期是5～15分钟。

　　同样地，为了减少缺陷数目，Michael Dubakov建议结合使用TDD、持续集成、自动化回归测试、根本原因分析和高水平的开发技能。

　　Rolf Gotz提到了开发零缺陷系统的十大原则。其中几条包括：

• 客户与软件开发人员互敬互爱。
• 需求的范围要小，要简单，逐步增加。
• 优先关注高价值的需求。
• 验收标准是最重要的。
• 问题本身是第一位的（然后才是需求）。
• 优先考虑性能需求。

　　因此，尽管系统应该只有极少数缺陷，但零缺陷是一个永无止境的追求目标。关键在于要了解何时应该停手。就像Jim建议的：

要了解何时停止修正缺陷，何时到达了收益逐渐降低的关口，何时应该把精力集中到更重要的工作上，并不是一件简单的事情。知道哪些缺陷要修正，而哪些不要，或者哪些缺陷是目前不能或者不应该修正的，都不是简单的事情。而且有时候你可能是错误的。

　　查看英文原文：The Holy Grail of Zero Defect Systems