Extreme Programming for Web Projects
| I l @ ve RuBoard |
| How much a project will cost depends on four main factors, all of them interrelated:
Time
The best way to lose a customer is to promise to build her site in half the time and not tell her that it will be brittle, it will be impossible to maintain, and it will slow to a crawl under a heavy load. She may love you when you deliver, but within six months will tell you that you will never work for her again. Worse, she will expect you to maintain her site during that six months, and your team will hate you because you made them bail water and plug holes in a sinking ship for half a year. Price
If the customer needs a Web site in three months instead of five, the cost must increase or the quality or scope must decrease. The only way to get a job done faster is to increase the size of the team or work longer hours, and both solutions have their limits. Only so many people can work on a project at one time, and people can only work extra hours in short bursts or they burn out and become less effective. You can reduce quality but only so far, and be assured that you are going to pay for the reduced quality sooner than you think. The only safe bet is to reduce scope and do less. Scope
In the past scope shrank if it wasn't defined in enough detail at the beginning of the project. If it wasn't written in the original contract, in a way that all parties understood , it meant that there was some mythical leeway. Unfortunately, this far too common practice of building the least possible amount of functionality led to some very unhappy customers, simply because they didn't get to decide. If the customer asked for a newsletter, the developers would ask themselves what features made up a newsletter and which ones could be dropped while still technically delivering what was requested . The only time dropping features is good is when the customer is the one deciding which ones. Quality
In traditional Web development methodologies, quality was poor because it was the easiest factor to ignore. Customers need to be educated about the work you do so that they can fully understand the implications of ignoring quality. Some customers have great difficulty understanding what quality means. You need to take the time to explain that skipping steps introduces bugs into the design and that rushing turns code into spaghetti. Of all the things you can do to a developer, making her responsible for bad code and poor design when the customer will not allow sufficient time is the worst. |
| I l @ ve RuBoard |