有什么缺陷？ 我喜欢这个定义。
缺陷是威胁产品价值的任何事物。
在开始之前，我们要同意：
- 我们不想破坏威胁我们产品价值的缺陷
- 我们希望在任何时候都为客户提供尽可能多的价值。
如果您不同意1和2，请不要浪费时间并立即停止阅读。
测试人员通常与发现缺陷有关。 一些测试人员可以很好地保护发现的缺陷，而某些开发人员可以对所编写的缺陷采取防御措施。 客户不喜欢缺陷，开发人员不喜欢缺陷，产品经理不喜欢缺陷，说实话，除了一些测试人员，没有人喜欢缺陷。
为什么会这样呢？ 原因是许多测试人员的重点是检测缺陷，而这正是许多组织为之付出的报酬。 如果您是一名测试人员并且喜欢您的缺陷，那么您可能会觉得这篇文章令人不安，如果您决定继续进行，则后果自负。
缺陷是浪费
让我们从一开始就很清楚：缺陷是浪费。 设计缺陷产品时浪费时间，在编码缺陷程序时浪费时间，在检测它们时浪费时间，在安装它们时浪费时间，在重新检查它们时浪费时间。 即使写了这句话也花了很长时间，现在想想您需要花费多少时间来产生，检测，修复和重新检查缺陷。
我们的行业已经开发出一种缺陷应对机制，我们将其称为缺陷管理。 它基于检测=>修复=>重新测试的工作流程。 多年来，拥有缺陷管理工具以及记录和跟踪缺陷已成为最佳实践。 缺陷管理方法通常麻烦，缓慢，成本高昂，并且容易使人烦恼，无论您是将缺陷拒之门外的测试人员，是被标记为缺陷的按设计功能的开发人员，还是需要花费精力的产品经理时间优先排序，图表绘制和趋势浪费。
缺陷的另一个危险特征是可以很容易地计算出缺陷，并且您总是会发现一个尖尖的毛发经理，决定要对他的产品的健康状况和团队效率进行计数，方法是计数并绘制彩色的废品图表。
但是，如果我们同意缺陷是浪费，那么为什么我们要记录和跟踪浪费，创建浪费图似乎更加荒谬，尝试防止它们难道难道吗？
哦，只要我们能先写对的东西并减少我们产生的缺陷的数量，就可以了！ 我说我们可以，耐心并继续阅读。
软件开发团队发现了许多创造性地解决缺陷的方法，请参见下面的示例。
示例1： 奖励浪费
奖励错误原因
几年前，我曾与5个Scrum团队一起从事一项关键业务项目。 首先让我澄清一下，我们的Scrum实施充其量是差劲的，我们没有释放所有的sprint，我们对done的定义值得怀疑。
接近一个重要的版本，我们发现自己处于一种需要在生产之前修复很多缺陷的情况。 我们有2周的时间，而我们的团队总共要解决100个缺陷。 我们的CTO非常支持消除缺陷的倡议，他渴望提供零缺陷。 他制定了一项计划，其中包括全天候免费提供食物，并为那些需要将100％的注意力集中在缺陷解决上的开发人员提供一些宠爱。 然后，他决定向团队颁发奖金，以修复最大数量的缺陷。
我记得对这种奖励可能带来的未来后果感到恐惧。 我与CTO谈过，并告诉他，对于那些缺陷最少的团队而不是缺陷最多的团队，我本来希望获得更多奖励。 我们的首席技术官是个聪明人，理解我反对的价值主张，他改变了态度，并与团队讨论了如何首先不引入缺陷比将缺陷编码后更有效。 发布后不久，我们就开始采用一种侧重于预防缺陷而不是专注于检测的方法。 我们再也没有在2周内修复100个bug的问题。
典型的缺陷优先级会议
示例2： 缺陷指标
在我以前的瀑布式生活中，我记得管理层在引入与缺陷直接相关的性能指标时。 测试人员应根据计算出的缺陷检测指数（测试期间检测到的缺陷数/检测到的缺陷总数（包括生产））* 100进行判断。 指数低于90意味着测试团队中没有人会获得奖金。 开发人员在
（测试过程中检测到的缺陷数/检测到的缺陷总数（包括生产））* 100。 指数低于90意味着测试团队中没有人会获得奖金。 开发人员在
指数低于90意味着测试团队中没有人会获得奖金。 测试人员分别对开发人员的代码中发现的缺陷数量进行判断，而业务分析师则根据测试人员在其需求中发现的缺陷数量进行单独判断。
欢迎来到战场！
错误优先级会议是一场争斗，开发经理认为任何错误都是遗漏的要求，产品经理认为每个错误都是编码错误或测试人员的误解，而测试负责人（me）只是因为允许他的测试人员参加而大喊大叫并受到批评。超出要求，并在脚本化验证例程之外利用其智能功能。
参加该会议是一场噩梦，人们完全忘记了我们的客户，只是想正确地制定他们的指标。 我们浪费时间争论和捍卫我们的奖金的时间真是惊人。 我们的客户通常不满意，因为我们不专注于价值传递，而是专注于处理缺陷，这是我们的一大输家！
我们的客户非常不高兴。
示例3： 不符合要求的缺陷
让挑剔的季节开始
在与示例2相同的环境中，测试人员为了保持较高的缺陷检测指数而使用它来提出大量实际上不符合要求的微小或不重要的“缺陷”。 有趣的是，这种不符合通常可以得到改善。
测试人员不在乎它们是否是需求，代码缺陷甚至改进，对他们来说它们就是金钱，所以他们打开了它们。 由于不符合要求，因此将改进作为缺陷提出。 在大多数情况下，这些被认为是低严重性，因此低优先级的缺陷使测试人员满意，因此必须归档，审查，确定优先级并用于趋势，度量标准和其他无用的计算中。
这项活动很容易占用测试人员时间的30％。 这样的缺陷不仅会花费测试人员的时间，而且还会影响开发人员，产品经理，业务分析师，并最终使缺陷管理工具变得混乱。
浪费成倍地增加了浪费。
一个多彩的转储
示例4： 缺陷图表，趋势和其他完全废话
每周我必须准备缺陷图表以进行管理。 这些是从我们可怕的缺陷管理工具中提取的，并以色彩鲜艳，无用的图表形式呈现。 我的经理对产生无用信息的前景感到非常兴奋，以至于她发起了一个宠物项目，制作的图表比我介绍的图表还要丰富多彩。 她用2个开发人员进行了6周的创作，以创造出让高级管理人员赞叹的东西。
在定义大公司的要求的过程中，她引入了一些新的甚至更无用的图表，并将其合并到一个汇总的仪表板中。 她称其为产品质量健康仪表板，我秘密将其称为“垃圾场” 。
没有人对仪表板有任何疑问，没有人出于任何原因使用数字，没有人关心可以配置它，但是我的老板为它感到非常自豪。 一位传奇人物说她因此而大幅度提高。 如果您使用垃圾，那么您将开始测量垃圾，最终您将进行数据分析并显示存储在代码中的垃圾的合并视图。
1. 注重缺陷预防
许多开发团队专注于快速交付功能，很少考虑预防缺陷。 从理论上讲，测试人员（有时花费的时间比开发人员便宜）会发现缺陷，这些缺陷将在以后修复。 这种方法代表了虚假的经济； 返工会破坏开发人员的活动并损害所交付的价值流。 开发团队可以使用许多方法来减少所需的返工量。
您想防止缺陷吗？ 您可以尝试以下任意组合：
- 使用BDD / ATDD / Specification by Example或其他测试优先方法，交付团队可以通过对话来测试产品所有者的假设，并且更有可能在第一时间产生正确的功能。
- 具有快速反馈循环的能力还可以及早消除缺陷，自动化的单元和集成测试可以帮助开发人员快速识别潜在问题，并在将其嵌入功能之前将其消除。
- 业务团队和交付团队之间的紧密协作可以帮助团队使其符合其实际业务目标，并减少不必要的功能。 这意味着更少的代码，因此更少的缺陷。 因为，您最好的代码是您不必编写的代码。
- 降低复杂度在预防缺陷方面非常有力，如果我们能够在许多简单的问题中分解出一个复杂的问题，我们很可能会减少引入的缺陷数量。 简单的问题具有简单的解决方案，简单的解决方案比复杂的解决方案具有更少的缺陷。
- 良好的编码标准，例如将方法的长度限制为较少的行数，限制循环复杂度，应用良好的命名约定以帮助提高可读性，这些都会对产生的缺陷数量产生积极影响
- 代码审查和结对编程大大有助于减少缺陷
- 长期进行重构还可以减少缺陷
故事的寓意：如果您不编写缺陷，则无需修复它们。
2. 立即修复缺陷并刻录缺陷管理工具
如果几年前像我一样，您已经厌倦了归档，分类，讨论，报告，订购缺陷，我有一个非常快速的解决方案。 发现缺陷后立即修复。
对于开发人员来说，一旦发现发现的缺陷而无需将其记录下来，则立即修复他在正在编写的代码中发现的缺陷是正常的，但是一旦发现缺陷是由其他人（例如测试人员）发现的，则显然我们需要开始严格的日志记录过程。 为什么？ 真的不知道 人们有时会说：“如果不进行根本原因分析，您将不知道自己在做什么，因此您需要提出缺陷”，但实际上，没人会在发现缺陷时阻止您进行根本原因分析。您真正想要的是，我的建议是，凡发现错误的人都将交给负责代码的开发人员并进行对话。 对话的结果（在某些情况下还可能涉及产品所有者）应该是
我的建议是，凡发现错误的人都将交给负责代码的开发人员并进行交谈。 对话的结果（在某些情况下可能还涉及产品所有者）应该让我们立即进行修复，或者让我们永远忘记它 。 现在修复它，通常意味着开发人员会重新了解需要修复的特定代码，当然要比不记得自己编写该代码的4周内更新。
现在进行修复，通常意味着开发人员会重新了解需要修复的特定代码，肯定比4周内更新，那时他甚至都不记得自己曾经编写过该代码。 现在修复它意味着问题已经解决，我们不必再担心它了，我们的客户将很感激。
永远忘记它意味着它不是一个值得修复的问题，它可能不会威胁到项目的价值，并且如果我们不修复它，客户将不在乎。 永远忘掉它也意味着我们不会在缺陷管理工具中携带臭死鱼。 将来，我们将不必再浪费时间重新讨论同样的死鱼，而我们的客户很高兴，我们不是在浪费时间，而是在开发新功能。 如果您决定修复它，我还建议您为此编写一个自动测试，这样可以确保如果问题再次发生，您将立即知道。
当建议烧毁缺陷管理工具并及时修复时，我遇到了极大的怀疑。 似乎只有极少数人认为这是可能的。 事实上，在过去的6年中，我所有的团队都能够做到这一点，而且没人能说：“我想念Jira和漂亮的错误图表”。
显然，这种方法更适合于位于同一地点的开发团队，我还没有在地理位置分散的团队中尝试过，我建议您尝试一下，让我知道它的进展。
流行病： 90％–唯一没有归档和管理我所遇到的缺陷的地方就是我工作和改变流程的地方。 在过去的几年中，我听说过另外两个地方，他们在这里做类似的事情，仅此而已。 全世界似乎在浪费金钱，分类，报告，趋势浪费方面有很多时间。
损坏： 100％–使用缺陷进行人员评估是我在漫长的职业生涯中经历过的最糟糕的做法之一，损害可能是巨大的。 客户变得无关紧要，人们开始专注于游戏系统以从中受益。 记录和管理缺陷也是非常浪费的，它需要时间，精力，并且尤其可能危害测试人员和开发人员之间的关系。 趋势和从缺陷密度中扣除发布日期是愚蠢的，当很少注意缺陷预防时，缺陷将是如此罕见，以致趋势将不复存在。
抵抗： 90％–我不得不离开一家公司，因为我不敢相信缺陷管理的福音，而且像一个异端一样，我几乎被火烧了。 在第二家公司中，我尝试删除缺陷管理工具，但经过两年的尝试，我颇有抵抗力，并获得了成功。 第三个是人们乐于尝试的那个，当他们看到我们清除的废物数量很快就变成了一条新规则。 我已经与人们就此主题进行了无数讨论，总体立场是缺陷管理必须通过一种工具并遵循严格的过程来完成。
因为“这就是我们在这里做事的方式！”
推荐读物
精益软件开发–敏捷工具包 （Mary和Tom Poppendieck）
https://mysoftwarequality.wordpress.com/2015/05/06/little-tim-and-the-messy-house/
这是我2015年首次写的文章的审阅和改进版本（ 此处为旧版本）
翻译自: https://www.javacodegeeks.com/2016/10/ultimate-guide-reducing-amount-defects-waste-product.html