dns配置错误修复不了_错误修复–估计还是不估计，这就是问题所在

dns配置错误修复不了

根据《代码完成》中的史蒂夫·麦康奈尔（1975-1992年的数据）所述，大多数错误无需花费很长时间即可得到修复。 可以在不到几个小时的时间内修复大约85％的错误。 可以在几个小时到几天内修复更多内容。 但是其余的则需要更长的时间，有时甚至更长的时间–正如我在较早的帖子中所谈到的 。

考虑到所有这些因素和不确定性，您如何估算错误修复？ 还是应该打扰？

花费一些时间进行错误修复

有些团队没有预先估计错误修复。 取而代之的是，他们分配了一定的时间，作为漏洞修复的缓冲，作为团队工作的常规部分，特别是如果他们在时间范围内工作。 开发人员只有在看起来需要对修补程序进行实质性更改的情况下才做出估算–在他们深入研究代码后发现修补程序并不容易，可能需要重新设计或进行更改到需要仔细检查和测试的复杂或关键代码。

为每个错误修复程序使用占位符占位符

另一种方法是使用粗略的经验法则，即每个错误修复程序的标准占位符。 例如，估计每个错误的½天开发工作。 根据Stack Overflow上的这篇文章， ½天建议来自Scrum的发明者之一Jeff Sutherland。

此占位符应适用于大多数错误。 如果开发人员花超过½天的时间来解决问题，那么他们可能需要帮助，而人们仍然需要知道。 选择一个占位符并使用一段时间。 如果看起来太小或太大，请进行更改。 重复。 您将始终有错误可以修复。 随着时间的推移，您可能会更好地对其进行修复，或者一旦您克服了显而易见的问题，它们可能会变得更难查找和修复。

或者，您可以使用Capers Jones早些时候提供的数据来确定错误类型所需的修复时间 。 平均一天或半天的效果很好，尤其是因为大多数错误是编码错误（平均3小时）或数据错误（6.5小时）。 即使是设计错误，平均也只需要一天多的时间就可以解决。

收集数据并使用

史蒂夫·麦康奈尔（Steve McConnell） 在《软件估算：揭秘艺术 》一书中说，使用数据总比猜测好。 他建议收集有关修复错误的平均时间至少要花几周或几个月的时间，并以此为基础来估计以后的错误修复。

如果您有足够的缺陷数据，则可以更明智地使用它。 如果您正在跟踪像Jira这样的错误数据库中的错误，并且程序员正在跟踪他们花费多少时间来修复每个错误以进行计费或时间计费（您也可以在Jira中进行此操作 ），则可以为该错误数据库进行挖掘类似的错误，并查看修复了多长时间 -也许还可以通过回顾其他人对您之前所做的其他错误的处理来获得一些有关如何修复正在处理的错误的想法。 您可以将不同的错误归为一组（按大小–小，中，大，x大–或类型），然后得出平均估计值，甚至可能是最佳情况，最坏情况，并且每种类型的可能性最大 。

使用基准

对于维护团队（仅负责软件修复的维护工程团队或中断/修复团队），您可以使用行业生产率基准来预测您的团队可以处理的错误数量。 Capers Jones在《 估算软件成本》中说，普通程序员（在美国，2009年）每月可以修复8-10个错误（当然，如果您是2012年在加拿大工作的普通程序员，那么您会必须将这些数字设置得更高）。 经验不足的程序员每个月可以修复6个，而经验丰富的开发人员使用好的工具每月可以修复20个。

如果您专注于修复笔测试仪或扫描报告的安全漏洞，请查看Denim Group开始收集的补救统计数据 ，以了解修复SQL注入错误或SQL漏洞可能需要多长时间。 XSS漏洞。

那么，您是否估计错误修复？

因为您必须先找出错误所在，才能估算出修复错误所需的时间，而且修复错误的大部分工作都涉及找出错误所在，因此尝试进行错误修复无济于事深入估计修复每个错误所需的时间。

使用简单的历史数据，基准或什至是粗略的猜测占位符作为经验法则，似乎都同样有效。 无论您做什么，都以最简单，最有效的方式进行操作，不要浪费时间试图使其完美无缺-并且意识到您将永远无法依靠它。

请记住10倍规则-与一般的错误相比，某些异常错误可能最多需要10倍的时间才能找到并修复。 而且根本找不到或修复了一些错误-或至少没有您今天拥有的信息。 当您错了（有时您会错）时，您可能真的错了，即使仔细估计也无济于事。 因此，请坚持简单，有效的方法，并在遇到难题时做好准备，因为这会发生。

参考： 错误修复–是估算还是不估算，这是我们JCG合作伙伴 Jim Real Bird在Building Real Software博客上提出的问题。

翻译自: https://www.javacodegeeks.com/2012/08/bug-fixing-to-estimate-or-not-to.html

dns配置错误修复不了