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 F. & Kent Beck’s
“Planning Extreme Programming” and I am currently reading Dave T.’
“Agile Web D. 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 Wed, Nov 30, 2005 at 11:31:18AM -0500, Paul B. 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 plonesolutions.com - plonesolutions Resources and Information.
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
).
- Matt