我现在有一个很好的流程来估算项目的开发工作，我认为考虑到最坏的情况，我需要多少时间来完成它，然后我将这个数字加倍。对于我的每个团队成员，我都有另一个比率（更高甚至更低），但想法是一样的。
我的问题是修复阶段，因为它取决于许多参数（项目的复杂性、员工技能水平、管理和设计质量、QA 质量等），所以很难预先确定为问题解决预留多少时间)
我仍然要从项目纯开发估算中确定一个百分比，我应该始终为问题修复添加该百分比（只是修复阶段，直到“上线”/“生产”/“下一个版本”等）
是否有定义实际黄金比例数字的方法？有人有吗？ 20%？ 50%？
【问题讨论】：
标签： project-management estimation
测试驱动开发减少了这些痛苦。以您编写测试的时间为代价，您可以立即（如果您实际运行测试）检测到回归。
正如你所说，有很多变数。对我来说，一个共同点是查看添加的行与删除的行。 当每次提交添加和删除大约相同数量的行时，这些就是错误修复。
使用您的 SCM 来跟踪这是多少次提交/周/行。
注意：在某些情况下，您的删除器可能比您的加法器做得更好。 （只要他们不引入错误）
【讨论】：
在传统的瀑布式项目中，我们发现一个好的经验法则是 20/20/20/40 - 20 HLD、20 DD、20 CCUT、40 集成和测试。我一直发现它很有用，因为它既适用于初始估计，也适用于您进入周期的一部分时的检查点。
从持续的交付后维护来看，我没有那么好的比率。我知道的大多数项目，甚至都不尝试，他们只是预算了一些支持时间，并认为有些会是错误修复，有些会是用户手持。
添加 - 意识到我应该澄清我的首字母缩略词：
HLD = 高级设计 DD = 详细设计 CCUT = 代码、编译、单元测试
我在这里从传统的瀑布概念中汲取灵感，因为这是我可以访问最多指标的地方。所以这些假设你（或多或少）必须在 DD 之前做 HLD，在 CCUT 之前做 DD 等等。实践经验表明，它们可以融合不止一点，但如果您同时发生 HLD 和 CCUT，您将面临一些真正的风险。
【讨论】：
正如您所说，错误修复很大程度上取决于代码的复杂性。像 ProjectCodeMeter 这样的自动化工具通过分析你的源代码来计算这个，它通常会给我 %30 到 %60% 的调试和测试，具体取决于代码。
【讨论】：