There's a buzz about starting a new project. A clean slate, the chance to do implement all the new ideas you have - and most importantly for me - the chance to do it THE RIGHT WAY - to put into practice all the things you've learned from your last work.
Software construction is sometimes compared to construction of other 'real-world' projects - whether it be building a house or even installing a new kitchen or bathroom. There is a tendency for people to think "well, a plumber can look at a job and know that it'll take him 2 days - why can't software engineers do the same?".
The problem here is that no two projects are ever the same, and even then the tools that we use change all the time. Imagine the same plumber asked to estimate a job, but this time the laws of physics have changed and water now flows up instead of down, and he's got to use his tools in his left hand instead of his right this time.
Getting the Requirements
So the way I see it, and the way Agile sees it, is to first of all deliver the requirements in the form of FEATURES, which are mini-stories of what the user is trying to achieve. It's then a case of getting a gut-feel for these features and putting down a relative sizing for each. If the story is too big, it's further broken down and so on. But we're still no closer to giving an estimate in terms of hours yet.
My own opinion is this is fine, but the project managers have to be very forgiving of any figures we supply here. Mainly it's because the stories are still far too lacking in any detail whatsoever (that is half the point!) - but that really doesn't help when you're being asked for an estimate.
The approach I have taken with this project is UI-First. If it's good enough for 37signals then it's going to work for me.
But how to liaise with the customer, especially one who, and no disrespect is intended here, can't visualise a software system outside of Excel, Word and a couple of company-specific applications?
I tried Paper Prototyping. But I could tell that the customer was struggling with this, and it was definitely running the risk of missed/erroneous requirements. You know, this old chestnut:
Prototyping
So I switched instead to actually building a workable, clickable, hands-on prototype of the application. The customer was instantly able to see what their end product would look like, and came back with several new or modified requirements that they were previously unable to visualise. It also had the added bonus of allowing me to familiarise myself with the UI controls that I would be using, which saves time when I come to fully implement this software.
Okay, so Joel doesn't like it. Or at least he didn't (that article was a while ago now). But I would argue the case that I'd never have someone work on a whole week prototyping ONE feature.
But the way I see it, you don't have to prototype EVERYTHING. It's not a replacement for sitting down and conversing with your end-users. Put placeholder screenshots in place of complex dialogs, hard-code sample data values. It has to be robust enough not to fall over often, but user input should be limited anyway, so there aren't that many cases this should happen. Having said that, my particular prototype for this app is probably quite brittle, but that's only because it is being demonstrated in a very controlled manner.
Now, from start to finish, that took me 8 hours. ONE day. Admittedly, it's only a handful of screens, but that included the time to design the UI and basic data model. I'm 100% positive that I've saved time in the long run - all it takes is for ONE feature to be misunderstood and you've got a disgruntled user. It doesn't matter that they haven't given you all the right information - IT'S THE DESIGNER THAT HASN'T ASKED THE RIGHT QUESTIONS.
And In addition, I can now more accurately guage my estimates. I'll be posting a breakdown of these features soon, using the Agile/Function Points technique that I've outlined in an earlier post.