维修时间的行业平均值

一位经理最近宣布，他们花了太多时间来修复错误。我想他认为我们应该一直编写完美的代码（当然仍然要达到那些不可能的截止日期！），这让我想知道行业平均花费在错误修复v编写新代码上的时间是多少。

那么，有没有人有时间衡量针对新代码开发的错误修复的指标？还是对整个行业的错误修复时间进行任何实证分析？是花了50％的错误修复了太多东西，还是正确的？20％或33％呢？

我很高兴接受个人经验中的轶事证据，因为这将构成一些统计数据的一部分，可以与我们的表现进行比较。

一位经理最近宣布，他们花了太多时间来修复错误。

以上听起来很无知。建议阅读以下案例：Robert L. Glass 撰写的软件工程的事实和谬论，尤其是“事实43。维护是解决方案，而不是问题”。

维基百科文章提到80％的精力花在软件维护上。

我的经理让Dilbert的PHB看起来很天才:)

上面给出的Hm我还将花一些精力来分析您所做的所有请求是否确实是bug。

以我的经验，将增强功能或新功能的请求作为错误提交的情况经常发生。优秀的经理会让程序员与他们的程序员一起找出那些不好的经理，好吧，只是不断抱怨太多的时间来修正错误。

要问的第一个问题是您的“错误修复”是否实际上是在修复编码错误或其他错误。只要您具有良好的代码基础，实际代码错误的修复在大多数情况下应该相对较小。如果您使用的是较差的代码库，则不可避免的是要进行广泛的错误修复。

但是，在将程序投入生产的过程中，您会发现未记录的需求，意外的用户活动，数据异常，硬件不兼容，安装问题以及其他并非严格的代码错误的问题。经理和用户通常将这些生产支持/维护问题视为错误，因为它们通常需要更改代码。

我也遇到过经理，他们会将应该被称为次要增强请求的内容归为bug。通常，这些信息会输入到错误跟踪或问题报告系统中，这会使您的“错误”统计信息高于实际情况。

这取决于您那里有多少代码，那里有多长时间等等。

修复软件错误所花的时间应该提前到发布的前6到12个月，但是随着时间的临近，维护所花费的时间与最初开发所花费的时间将超过100％-这就是事实工作。

虽然我没有任何硬统计（“代码完整”有，但我无法确切告诉您哪个页面/部分），但根据我的经验，大约有40％的开发（有时高达60％）用于维护。显然，您发布的代码越多，维护时间就越长。错误并不总是可以起作用的，并且它们是程序性缺陷，很大程度上是不确定性的结果。

如果您使用的是良好的票务跟踪器（例如Atlasian的Jira），并且已经花了时间正确输入所有不同的类别，用户故事，紧急程度，并且在队友的同意下，那么您实际上在计算这些指标（等等）非常容易。

在先前的项目中，我们使用Jira来管理我们的错误/任务/待办事项列表，最后，它实际上向我们展示了导致延迟和问题的最大原因是无效的管理实践。

奇怪的是，当这些信息发布时，我们突然告诉我们，我们将不再使用Jira，而将引入一种新产品来替代它。

同时，所有通过Jira传递数据的请求都必须发送给管理团队，并且我们取消了直接访问权限。

没注意到的是，作为统计数据计算的一部分，开发团队将Jira将数据戳到Web钩子上，并且此Web钩子用于将数据传递到某些内部服务器上的端点，我们在其中创建了代码这些报告自动生成。

我们开始监视Web钩子，发现即使告诉我们不再使用Jira，它仍然可以存活很长一段时间（准确地说是6个月以上），并且高层管理人员的批发滥用是只是使用不当而横行。

当然，它不必像Jira那样复杂。

如果您想要低收益的解决方案，则可以使用google-docs电子表格和GDocs通知API来跟踪任务/票证/错误/功能请求等。

GDocs本身现在可以发布网络挂钩和各种各样的东西。

结合使用Git和/或Github以及一些挂钩，这些挂钩会在代码提交到您的存储库时触发，并且您拥有一个相当有效的家庭酿造系统，该系统可以记录大量数据。

但是，通常，在产品自然寿命的100％中，未开发的开发人员和维护人员之间的分配比例通常为20/80，ALM（应用程序生命周期管理）周期中的大部分成本都由维护和支持成本承担。

没有花费太多时间来修复错误的事情，因为根本不可能编写没有错误的代码。

良好的测试和持续的集成策略将减少缺陷，但是您永远不会完全消除它。

否则相信（IMHO）的任何人都没有足够的知识做出准确的判断，或者对编写软件实际上有多困难视而不见（更为常见的情况）。

如果您的经理愿意（其中一些人）支持，那么您可能希望建议他为您提供一天的服务，以便他可以准确地看到您的工作以及如何做。

Iv's在一些积极鼓励此类工作的公司中工作，上级员工掩盖了下级员工，反之亦然，对于双方而言，这都是非常非常好的学习经验。