估算开发工作 - 分配的开发时间与错误修复之间的比率

Question

我现在有一个很好的估算项目开发工作的过程，我想在考虑最坏情况的情况下花多少时间来做这件事，然后我把这个数字加倍。对于我的每个团队成员，我有另一个比例（更高或更低），但想法是一样的。

我的问题是修复阶段，很难预先确定解决问题的时间，因为它取决于许多参数（项目的复杂性，员工技能水平，管理和设计质量，质量保证质量等） ）

我仍然要从项目纯开发估算中确定一个百分比，我应该总是为问题修复添加（只是修复阶段，直到“上线”/“生产”/“下一个版本”等）

是否有定义实际黄金比例数的方法？有人有吗？ 20％？ 50％？

Answer 1

测试驱动开发减少了这些痛苦。以您编写测试的时间为代价，您可以立即（如果您实际运行测试）检测到回归。

正如你所说，有很多变数。对我来说，一个共同点是看看添加的行与删除的行。 当每个提交添加和删除大约相同数量的行时，这些都是错误修复。

使用您的SCM跟踪这是多少次提交/周/行。

注意：在某些情况下，您的删除者可能比您的删除者做得更好。 （只要他们不引入错误）

Answer 2

在传统的瀑布式项目中，我们发现一个好的经验法则是20/20/20/40 - 20 HLD，20 DD，20 CCUT，40集成和测试。我总是发现它很有用，因为当你进入循环时，它既适用于初始估计，也适用于检查点。

从持续的交付后维护，我没有那么好的比例。我知道的大多数项目，甚至没有尝试，他们只是预算了一些支持时间，并且有些将是错误修正，有些将是用户手持。

添加 - 意识到我应该澄清我的缩略词：

HLD =高级设计 DD =详细设计 CCUT =代码，编译，单元测试

我从传统的瀑布概念中脱颖而出，因为我可以访问大多数指标。因此，假设您（或多或少）必须在DD之前执行HLD，在CCUT之前执行DD等等。实践经验表明，他们可以融合更多，但如果您同时发生HLD和CCUT，您将面临一些真正的风险。

Answer 3

正如您所说，错误修复在很大程度上取决于代码的复杂性。像ProjectCodeMeter这样的自动化工具通过分析你的源代码来计算它，它通常在调试和测试中给我30％到60％之间，具体取决于代码。