零缺陷/缺陷策略保持敏捷

在我们的项目中，我们采用零缺陷（也称为零缺陷）方法。基本思想是，错误的优先级始终高于功能。如果您正在处理一个故事，并且有错误，则必须解决该问题才能使该故事被接受。如果在sprint期间发现了较旧的故事中的错误，我们需要将其放在待办事项列表上并加以解决-最高优先级。

我说解决的原因是我们并不总是修复该错误。有时我们只是宣布它“不会修复”，因为它并不那么重要。总而言之，这听起来很棒。我们正在运送高品质的产品，并且不会以积压大量错误的形式出现“驼峰”。

但是我不确定这种方法是否正确。我确实同意，我们总是需要尽快修复严重的错误，并且需要丢弃无用的错误。但是重要但不如新功能重要的错误又如何呢？我倾向于认为应将它们以适当的优先级提交待办事项清单。

为了使它更清晰，我将举一个示例-在我的项目中，我们使用用flex编写的UI。我们有一个向导屏幕，它以每种屏幕分辨率打开的大小相同。事实证明，当我们扩展向导窗口时，其中一个页面看起来并不好（虽然向导现在可以显示所有内容并且不需要滚动条，但是垂直滚动条并不会消失）。我认为这个错误很难看。我确定它一定要修复。但是我们的时间表很紧，我们有很多功能，我们担心这些功能不会成功并进入发行版。我觉得我们可以忍受这样的错误。它确实需要修复，但是优先级低于其他功能（因此，如果我们无法完成它，至少我们没有遗漏更重要的功能）。但，

我很想听听有关如何管理我不想标记为“无法修复”但也不是最重要的错误的意见。

在编写新代码之前修复bug实际上是Joel测试的十二点之一。乔尔还解释了为什么这是必须具备的：

通常，修复错误之前等待的时间越长，修复所需的时间和金钱就越多。

您可以选择：

• 您要么实施要求很高的功能，要么延迟修复错误，这将不可避免地增加修复它的成本，

• 或者您现在就修复该错误，因为客户会失望地发现您交付他们如此急需的功能太慢了。

如果错误不是很重要，而功能很重要，则管理层将倾向于先实施该功能，然后再修复该错误。从业务角度来看，这是一个完全正确的选择，因为管理层清楚地了解了后果，即，比现在更晚修复错误将更加困难。

坚持“在修复所有错误之前没有新功能”可能不是最佳的业务选择。您已经提到了它的局限性，因此无需解释。

话虽这么说，在修复较小的错误之前先实施非常重要的功能的风险存在风险：在哪里设置限制？1 000个客户要求的功能是否比100个客户遇到的错误更重要？在修复给定的错误之前，如何评估给定的功能是否应该完成？

如果没有严格的规则，并且如果管理层对开发过程不太了解，那么您可能会在几年内发现自己积压了很多错误，这些错误被认为不够重要，因此只能在发现另一个新功能之前就进行修复。

除了深入了解您情况的特定低级详细信息之外，您还应确保正确理解了基本的基本知识。

在这方面，我认为非常重要的一点是要指出，您提到的策略“错误始终优先于功能”，尤其是该单词始终偏离《敏捷宣言》中所述的至少四个原则中的两个：

个人与流程和工具之间的互动

响应计划变更

我不坚持，你应该改变政策，因为我坚信一个人应该是敏捷关于敏捷原则非常适用。

但是，您至少应该知道何时偏离，并了解是否以及如何证明偏离是合理的。简而言之，您最好确保您所说的“敏捷”实际上不会滑入毫无意义的假货中，因此雄辩地涵盖在“ 半武装敏捷宣言”中：

个人和流程和工具之间的互动
，我们拥有强制性流程和工具来控制这些人（我们更喜欢“资源”一词）的互动方式

工作的软件胜过面面俱到的文档
，只要该软件是全面记录

当然，在严格的合同范围内，客户需要通过合同谈判进行协作
，并且要受到严格的变更控制

应对变化在遵循计划
提供了一个详细的计划是在地方的变化做出反应，而恰恰是遵循

出于竞争的目的，零缺陷策略似乎不仅仅偏离敏捷原则。

在我参与的非敏捷项目中，通常被认为是不正确的。花时间在程序员身上的错误是不明智的，因为这些错误的重要性不足以延迟高优先级功能的发布。

因此，管理人员通常会花费一些精力（也许说投资得多些）来决定哪些错误可以等待下一个版本。

• ^{您是否偶然在关键任务软件上工作？我问，因为在这种情况下，零错误政策非常有意义，并且值得妥协于敏捷/非敏捷/任何原则。尽管我很难想象在这种情况下的敏捷过程。}

您知道，除非您使用关键任务软件，否则我建议您更仔细地评估您的管理技能和思考能力。

我的意思是，从您的描述来看，它看上去根本无法正确地确定错误和功能的优先级。如果是这样，如果他们不能处理这样一个相对例行的任务，他们还无能为力？提供有竞争力的薪水？职业发展机会？工作环境？

正如您正确地指出的那样，零错误策略可能会忽略或避免非关键性问题，因为现在不是解决这些问题的最佳时机。

当发现新问题时，您可以做的是做出三个决定：

1. 这是一个真正的错误，应尽快修复：放在积压的顶部
2. 这是一个真正的错误，但对应用程序的功能并不重要：将其转变为常规故事，并让产品所有者确定其优先级。
3. 这不是错误，或者是重复的错误，也不值得解决：出于适当的理由拒绝。

这样，次要的问题就不会被完全遗忘，但是它们也不会将所有新的亮点功能强加给下一个冲刺。“变成一个故事”只是为了让管理层可以继续声称您遵循的是零错误政策，产品负责人应该能够在问题的重要性与待办事项功能的重要性之间取得平衡。

请注意，通过此过程，您提到的滚动条之类的问题在项目结束时仍可能无法解决，但这是因为没有人认为它足够重要（包括客户），而不是因为没有发现问题的时间。

我喜欢您的方案，但是，正如您已经确定的那样，它只需要进行一些细微的调整即可使其起作用-正如您所观察到的，现实通常是一个新功能胜过一个错误修复.....

我的建议是强制错误优先级增加每个sprint。假设您的错误级别为5（等级1高，等级5 =低）。它开始时为5、4冲刺，其级别为1。但是，优先级计算所需的思维定式是“当前优先级-冲刺数”，而不是“在每个冲刺结束时增加未解决错误的优先级”-这样可以防止将优先级“重置”为低，以进一步推迟优先级。

1级错误必须在下一个Sprint中解决。

简单易解释，易于实现。

现在，针对请求的程度可能有所不同。一段时间后，必须处理该请求-完成或放弃该请求，以防止积压无价值的功能...

当您尝试对软件开发中的任何内容过于刻板或过于固执时，就会遇到麻烦，因为我们所有人都希望将事情割裂干dry。在添加新功能之前，应该先修复错误，但是在做出此决定以及问题的范围时，我仍然会考虑每个错误的重要性。一切都有例外。

有些应用程序太大，它们的部分根本不相关。我看不到为什么必须暂停应付帐款模块的每个新功能，因为员工福利GUI中存在几个令人讨厌的错误。如果某些向导步骤的GUI烦恼位于公司网站的购买部分中，请对其进行修复，但是如果所添加的功能是由于附加的安全性，业务需求以及特别是法规变更而导致的，则许多错误可能必须修复。

除了完成任何一项的时间和资源上的巨大差异外，最好获得一些用户/客户输入。如果他们可以忍受该错误（如果这意味着获得新功能），请添加该功能。目标应该是避免让错误堆积，所以要有一个停止的间隙。在某些时候，许多小问题成为主要问题。

在运行测试时编写测试以显示错误是修复错误的良好开始。但是，当尝试修复优先级最低的错误时，我们应该三思而后行。我不是要跳过修复它。但是我们可以使用非关键资源来修复这些错误。假设，在我的团队中，我们用错误列表中优先级最低的错误来训练新资源。通过这种方式，我们有机会培训新资源，并给他们一种信心，使他们确信他们已经对进入应用程序进行了修复。这无疑会使他们自愿参加下一个优先任务。

希望这可以帮助 ：）