Estimation of development work - ratio between alloted time for development and bug fixes [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question 开发者_如何学运维

I have now a good process for estimating development work for projects, I think how much time it would take me to do it considering the worst case scenario, and then I double that number. For each of my team members I have another ratio (higher or even lower) but the idea is the same.

My problem is the fixes phase, it is very hard to tell up front how much time to reserve for issue resolving as it depends on many parameters (complexity of the project, staff skill level, management and design quality, QA quality etc)

I am still to decide on a percentage from the project pure development estimation that I should always add for the issue fixes (Just the fixes phase untill "go live" / "production" / "next release" etc)

Is there a methodology that defines an actual golden ratio number? does anyone have one? 20%? 50%?

---

Test Driven development reduces these pains. At the cost of the time you write a test, you instantly (if you actually run your tests) detect regressions.

As you say there are many variables. For me one commonality is that look at the lines added vs the lines deleted. When every commit adds and removes about the same number of lines, those are the bug fixes.

use your SCM to track how many commits / weeks / lines this was.

NOTE: your deleters might be doing more good than your adders in some cases. ( as long as they don't introduce bugs )

---

On a traditional waterfall style project, we found a good rule of thumb was 20/20/20/40 - 20 HLD, 20 DD, 20 CCUT, 40 integration and test. I've always found that to be useful in that it works both for initial estimates and for a checkpoint when you are part way into the cycle.

From an ongoing post-delivery maintenance, I don't have as good a ratio. Most projects I know, don't even try, they just budget some number of support hours, and figure some will be bugfix, and some will be user handholding.

Addition - realized I ought to clarify my acronyms:

HLD = High Level Design DD = Detailed Design CCUT = Code, Compile, Unit Test

I'm pulling from traditional waterfall concepts here as that's where I've had access to the most metrics. So these assume that you'll (more or less) have to do HLD before DD, DD before CCUT and so forth. Practical experience shows they can blend more than a little, but if you have HLD and CCUT happening at the same time, you have some real risks afoot.

---

As you say bug fixing depends a lot on the code complexity. automated tools like ProjectCodeMeter calculate this by analyzing your source code, it usually gives me between %30 to %60 percent for debugging+testing, depending on the code.