Actualmente estoy leyendo otro libro de Ingeniería del Software; en esta ocasión trata sobre Estimaciones en los proyectos software, y se titula Software Estimation; Demystifying the Black Art, del famoso autor Steve McConnell, autor de una multitud de libros de ingeniería; entre otros es autor de Rapid Development – Taming Wild Software Schedules y Code Complete.
Lo que a continuación transcribo, sin traducir (posiblemente lo haga en los próximos días), viene literalmente en su libro, y presenta ciertos escenarios que a más de uno le resultarán familiares en la vida de un ingeniero informático. A mí, personalmente, me recuerda mucho a las historietas publicadas en el fantástico blog Sinergia sin control.
EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT LEAD: OK, let me crunch some numbers, and get back to you.
PROJECT LEAD: We’ve estimated the project will take 5 months.
EXECUTIVE: Five months!? Didn’t you hear me? I said we needed to have this software ready in 3 months for a trade show!
MANAGER: I know we had a goal of finishing this release in 12 weeks, but my estimates indicate that it will take 16 weeks. Let’s walk through the estimate using this software estimation tool. Here are the assumptions I made. First, I had to calibrate the estimation model. For the “programmer capability” factor, I assumed our programmers are 35th percentile—
EXECUTIVE: What?! No one on our staff is below average! You need to have more confidence in your staff! What kind of manager are you? Well, maybe we’ve got a few people who aren’t quite as good as the rest, but the overall team can’t be that bad. Let’s assume they’re at least average, right? Can you enter that into the software?
MANAGER: Well, OK. Now, the next factor is the capability of the requirements engineers. We’ve never focused on recruiting good requirements engineers or developing those skills in our engineers, so I assumed they were 15th percentile—
EXECUTIVE: Hold on! 15th percentile? These people are very talented, even if they haven’t had formal training in requirements engineering. They’ve got to be at least average. Can we change that factor to average?
MANAGER: I can’t justify making them average. We really don’t even have any staff we can call requirements specialists.
EXECUTIVE: Fine. Let’s compromise and change the factor to 35th percentile then.
MANAGER: OK (sigh).
EXECUTIVE: We need Giga-Blat 4.0 in 6 months.
TECHNICAL LEAD: We’ve estimated the project carefully. Unfortunately, our estimates show that we can’t deliver it in less than 8 months.
EXECUTIVE: That’s not good enough. We really need it in 6 months.
TECHNICAL LEAD: Do we really need all the functionality that’s currently required? If we could cut enough functionality, we could deliver it in 6 months.
EXECUTIVE: We can’t cut functionality. We’ve already cut features to the bone on this release. We need all the features, and we need them within 6 months.
TECHNICAL LEAD: What’s the major factor that’s driving the 6-month schedule? Maybe we can find a creative solution.
EXECUTIVE: The annual trade show for our industry is in 6 months. If we miss the trade show, we’ve missed our chance to demo the software to many of our key accounts. That will effectively push back our sales cycle by a whole year.
TECHNICAL LEAD: I really can’t commit to delivering the final software in time for the trade show. But I can commit to having a beta version ready for the trade show, and I can provide a tester who knows where all the problems are and who can run the software during the show so that it doesn’t break. How does that sound?
EXECUTIVE: If you can promise the software won’t crash, that will work fine.
TECHNICAL LEAD: No problem.
TECHNICAL LEAD: Our estimate for this project is that it will take 5 to 7 months. We’re still pretty early in the Cone of Uncertainty, so we can tighten that up as we go.
EXECUTIVE: Five to 7 months is too wide a range. How about if we just use an estimate of 5 months?
TECHNICAL LEAD: We’ve found it really useful to distinguish between estimates and commitments. I can’t change the estimate, because that’s a result of a lot of computations. But I could possibly have my team commit to a delivery schedule of 5 months if we all agree that we want to take on that level of risks.
EXECUTIVE: That seems like semantics to me. What’s the difference?
TECHNICAL LEAD: Our range of 5 to 7 months includes one standard deviation of variation on each side of our 50/50 estimate of 6 months. That means we have about an 84% chance that we’ll deliver within 7 months. Our estimates suggest that we have only 16% chance of actually meeting a 5-month commitment.
EXECUTIVE: We need more than 50% confidence in the date we commit to, but 84% is more conservative than we need. What would the 75% confident date be?
TECHNICAL LEAD: According to the probabilities we estimated, that would be about 6.5 months.
EXECUTIVE: Let’s commit to that then.
TECHNICAL LEAD: That sounds good.
Software Estimation; Demystifying the Black Art
Microsoft Press 2006