|
|
|
|
|
by nlawalker
5551 days ago
|
|
Oh man oh man, this right here. I like to think of myself as someone who has a lot of common sense, but reading McConnell's "Software Estimation" made me feel like an idiot. He lays out the most important stuff right at the start of the book: an estimate is not a commitment is not a plan to meet a target. Reading this, I realized that where I work, the term "estimate" is often used to mean any one of those three things at different times, but most often is used to mean "commitment." Not knowing any better, I fell right in line. McConnell's basic strategy for delivering an estimate (give a minimum, a maximum, and an "expected time") is great for so many reasons, but the reason I like it the best is for its communication value - by giving three numbers, none of them being an "I can have it done by..." number, you reinforce the idea that you are delivering an estimate and that the point of delivering that estimate is to help the project manager control the project. If it turns out that the PM is lazy and they really do just want a commitment ("sure, sure, whatever, when will it be done?!"), you can adjust your communication strategy accordingly. |
|