Quote:
|
Originally Posted by Phil^
Thats what i guess the agile method was developed to guard against
In the agile method, generally speaking you do development in iterations. You start off with a few small tasks to do in each and go through the plan,implement,test,deploy,evaluate,(document?) cycle for each one of those iterations.
|
We skip the documentation part. We are currently producing a demo for the big Philips demo fair and getting the software going is more important than writing user documentation.
In general Agile methods say that documentation is bad because it is subject to change. So unless it is documentation we can create with very little effort (class/method listings) we don't do it. Also, code comments are also evil because it is classed as "documentation". Think of the kind of code comment from which you generate Doxygen documentation.
Quote:
The theory is that the customer ends up getting precisely what they want, and its more forgiving of change then the traditional 'waterfall' approach however since you are only doing planning for specific tasks at any one time, there is no overall master plan when it comes to things like individual components on different iterations and how they are all supposed to interact together nicely. Its achieved through refactoring of old work and generally seems ( to me ) like a cludge/hack effort to make it work together.
It is also quite difficult to do agile development in monolithic teams, its best suited for smaller groups
Enterprise level development tends to favour the waterfall approach purely because of the masses of planning done beforehand ( and i guess because there are times you can have an unresponsive customer which does not help the agile approach much )
|
In a previous project we were asked to give an estimation for the duration of the project and we based our planning on the major requirements the customer gave us. It was like "a milestone like that will take us one month", and "this feature will take a week or so".
In the end it took us less time, and we made something completely different than what the customer asked for on day 1. He got a C# usercontrol because it suited his needs better while in the very beginning he was thinking about a complete application.
Not planning might be something the XP purists might do, but in a business environment you won't get away with that.
What Agile in my opinion is far superior in is always delivering something usefull to the customer even if the project is stopped prematurely. For example, if you have a budget of $100,000 for a project, and you spend 70% of that for planning and designing you spent $70,000 without even delivering one line of code. You better get everything coded in the other 30% of the time or you might not be able to deliver a product with enough or the right features to be accepted by the customer. So in the end, if you implemented 60% of the features, it might not be the features that the customer thinks are most important.
Whereas if you had started coding features right away you would ideally have 70% of the features ready. Or if the project isn't going well you might have 40% of the features ready. But because you have been prioritizing all the time, those are the 40% most important features to the customer. And we all know that the other 60% of the features customers want are bollocks anyway.
This can make a difference between delivering something even remotely usefull, and something useless. Think along the lines of an email client that is 60% done. We're out of budget and have no money to implement the actual mailing part. But it CAN do rich text editting, insert tables, parse HTML, burn CD's.... But it can't send mail. 60% done, 0% business value.