谁在说什么，但我在说错误。
去年，我向您介绍了百吉饼面包店（Bagel's） ，这是我们公司举办的旨在清理积压的bug的活动。 该事件很好并且有用，但是可以一次性解决错误问题。 我们已经举办了六届Bagodelen，但是参与者的数量正在逐渐减少，并且很明显，此活动的需要开始消失了。 主要原因是零漏洞政策的出现。 俄语方面没有很多资料可以阅读和找到适合自己的便捷解决方案。 在本文中，我将讨论我们对该主题的处理方式，并愉快地阅读您在评论中的经验。
这是什么
零错误策略（ZBP）是基于规则的错误处理策略：
“当出现新错误时，您必须立即决定在不久的将来对其进行修复，或者将其关闭为“无法修复”。”
在这种情况下，请不要极端：不要犯任何错误或连续编辑所有内容。 为您准备好要提供给用户的功能的质量标准，并在纠正所有重要错误后考虑完成的任务，这一点很重要。
保单利益
- 每个人都知道有多少个未解决的错误，并且这个数目非常有限。
- 在错误跟踪系统中查找任务所需的时间更少。
- 没有冗长的会议来对错误积压进行排序和重新排序。
- 当您没有积压的积压压力时，从心理上来说这可能会变得更容易。
- 经过更正后，不必回顾“一百年前”的情况，而再次陷入环境中。
听起来不错，但可能会有副作用。
- 产品质量下降。
- 测试团队水平下降。 （如果仍然无法解决，为什么要浪费时间寻找棘手且复杂的错误？）。
- 对于新团队成员，有用的信息源（以未完成的积压形式）已丢失。
总是有一个恐惧因素。
“因此，我们将消除错误，如果有时间修复错误的未来，该怎么办？”
您不太可能会有额外的时间。 这就像在阳台上存放旧垃圾：您不会失去使用其中一种东西的希望，但很可能永远不会发生。
在这里，我们关闭了错误，用户可以在产品中看到它。
沮丧的用户将写信给支持，后者会通知您。 有必要检查此错误的优先级，然后重新决定是否要纠正它。
实作
最难的部分是上手。 为此，您需要找到时间，资源和愿望（需要加下划线），以铲除所有积压的古代错误，并做出更正或更正的决定。
然后，清除错误后，集中力量并纠正“幸存者”。
并开始按照新规则生活。
开始将错误分为两类：
- 测试新功能时发现的错误；
- 在prod上发现的错误/具有回归。
如果在测试新功能时发现错误，则必须立即做出决定：
- 在功能的开发/测试完成之前修复错误；
- 重新分类错误（也许这实际上是改进）；
- 如果您不打算对其进行编辑，那么也许根本就没有bug。
在该过程的侵入阶段，最好使用“ Wo n't Fix”（解决该问题的原因）解决方案来启动和关闭此类错误。 基于这些数据，您将能够分析缺陷并正确制定团队中的质量标准。
并且如果产品/回归上存在错误，那么您需要决定要做什么。
- 修复错误并在截止日期之前根据错误的优先级进行修复。 修复时间从“现在”到两个冲刺。 如果该错误没有在两次冲刺中得到修复，则应将其关闭。
- 将任务类型从“错误”更改为“改进”。
- 使用“无法修复”解决方案关闭该错误，并说明关闭原因。
为了确定错误的优先级，我们使用一个矩阵，该矩阵结合了特定命令中错误的严重性和出现的频率。
其他细节
如果您不另外更改开发和测试中的流程和方法，则使用此方法的收益可能微不足道。
开发新功能时，什么将减少错误数量？
- 使用广泛的技术和组织实践（例如，实施质量门，影响分析，敏捷测试）。
- 通过重构旧代码来消除产生错误的位置。
- 快速纠正错误，这将减少将来的影响。
- 编写自动测试以更快地发现问题区域并
防止重复错误。
指标
为了不对我们的感受得出结论，我们遵循ZBP度量标准（我非常喜欢Tableau并使用它来构建报告）。 这使您可以跟踪动态进度并突出显示新出现的问题。
结果
我们与ZBP合作的结果是什么？
我们生活在现实世界中，以其最纯粹的形式不可能使用政治。
有人遇到了旧问题，并且在有限的时间内无法修复某些错误。 这些年来积累了很多积压，接近他真是令人恐惧，他们不急着开始这一过程。
但总的来说，许多团队设法解析其积压工作，并对未解决的错误数量设置一定的标准。 团队开始更好地评估错误，并就需要更正做出更快的决策。
结论
- 更改您的错误处理方法需要大量的精力。
- 为了使流程正常运行，它必须成为公司工程文化的一部分。
- 团队必须在纠错和冲刺开发之间取得平衡。
所有好的和更少的错误！