Not sure if this is the right place for this kind of discussion, but I don't know of a better place. I've read Martin Fowler & Kent Beck's "Planning Extreme Programming" and I am currently reading Dave Thomas' "Agile Web Development with Rails". Both books discuss Agile methodologies and XP. From what I can tell, Agile and XP seem to be almost the same thing (I'm sure a lot of people will reply explaining how they are different). One of the basic premises of both that you should develop code in small design-develop-test iterations, rather that the typical development model (waterfall I think it is called?) where you do all the design, then development, then testing in separate phases of the project. In theory, I think the Agile/XP methodology sounds more efficient and productive. I have one question, how do you come up with a project schedule and budget in an Agile/XP project? In the real world, when a client is deciding to invest money in a project, the bottom line question they want an answer to is how long will it take and how much will it cost. Sometimes the question is can you get "it" done by X date and how much will it cost. In either case, without developing a full specification for the project, how can you give the client a quote? For example, if ABC company comes to you and says I want an e-commerce site, they are not going to agree to pay you to develop the site unless you can put together a proposal that has a project plan and a budget. How does this fit into Agile/XP development? Are there any articles/books that cover this subject?
on 2005-11-30 17:35
on 2005-12-01 00:20
On Wed, Nov 30, 2005 at 11:31:18AM -0500, Paul Barry wrote: > methodologies and XP. From what I can tell, Agile and XP seem to be > almost the same thing (I'm sure a lot of people will reply explaining > how they are different). "Agile" is a term used to describe a general philosophy of software engineering, where you stay flexible and able to adapt to change. XP is an software engineering methodology which fits the criteria of Agility quite well. > there any articles/books that cover this subject? I found http://www.plonesolutions.com/about/OptionalScopeC... an interesting read. It doesn't answer all your questions, and a lot of people find the ideas behind it to be a little fruity, but it's something to kick-start your thoughts, at any rate. I avoid fixed-price contracts for anything except trivial solutions, myself, because of the huge risk involved, and also the fact that the customer rarely gets what they want in the end. It's part of the sales job, to convince the customer that they don't really want a fixed cost/date/scope contract, because the quality is liable to go completely to shit. Remember that in software development, you are almost never re-implementing a solved problem. Problem solving is naturally an unreliable activity -- up-front, you cannot reliably state how long it will take, because you don't know the true scope of the problem until you know the problem entirely. It can be hard to convince clients of this sometimes, but you're far better off making this idea stick (or walking away) than accepting a bodgy contract. If someone says "I'll go somewhere else", wish them the very best, and welcome them back with open arms when their "fixed" price option falls apart (with your optional scope contract and a hefty rate increase <grin>). - Matt