零缺陷系统的圣杯

  • Vikas Hazrati
  • 石永超

2011 年 3 月 1 日

话题:敏捷语言 & 开发架构文化 & 方法

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

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

敏捷语言 & 开发架构文化 & 方法