May 13, 2010: The Rules of Agile Estimation
Top Story
JRuby 1.5 is out. Highlights include improved Rails 3 support, better support for Windows, better FFI support, better startup time (yay!) and a lot of other tweaks and fixes.
Book Update
Still Cucumbering, hope to finish today.
The book is still on sale, of course. And I’d still love to see more comments in the forum.
I’ll be talking at Chicago Ruby on June 1, exact topic TBD (let me know if you have a preference), but I’m leaning toward talking about how to avoid test problems and write good, robust tests.
And Then…
As an unrepentant old Newton fan, I loved this compare and contrast of a recent iPad ad with an old Newton ad. The Newton, flaws and all, was way ahead of the market back them.
If you are going to RailsConf, first of all have fun and wish I could be there. Second, if you are wondering about the difference between the two Rails 3 tutorials, wonder no more.
Kent Beck is publishing some old pieces again, including one about how the original XP book made the mistake of equating “the team” with “the developers”.
Fred and George Weasley are marketing experts.
And Finally
The Rules of Agile Estimation:
-
Estimates are always wrong
-
If you think spending more time on estimates is a good idea, see rule 1.
-
On average, an experienced developer is not going to improve on his or her gut reaction by thinking it over.
-
Team estimates are important, one person may see something that everybody else missed. Just keep it quick.
-
People are much better at estimating size relative to each other than absolute time a task takes.
-
Separate the problem into smaller chunks, the more estimates you make the better the chance that the law of averages will help you.
-
Decomposition into roughly equal sized tasks is pretty much the whole ballgame.