Re: Agile developement ... more than just extreme programming ???

From: Shayne Wissler (thalesNOSPAM000_at_yahoo.com)
Date: 11/14/03 

Date: Fri, 14 Nov 2003 16:27:49 GMT

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:w06tb.29358$r76.25324@newssvr31.news.prodigy.com...
> > > - accept feature requests in any order
>
> Shayne Wissler wrote:
>
> > Any project can "accept" feature requests in any order. And every
project
> > will have different cost outcomes depending on the order. This doesn't
> > distinguish anything.
>
> Try "accept feature requests in any order without affecting the cost
> outcome".

So your assertion is that an agile project can implement requirements in any
order, with no change in what it costs to implement all of them? That would
certainly be a distinguishing characteristic. Of course, it would also be a
lie.

> > > - release any integration
> >
> > Again, any project can release any integration, but whether or not it is
> > usable in any sense other than something to futz around with is an
> entirely
> > different matter. And no project can, for every situation, create a
> > "release" that's actually useful to a business in only two weeks.
>
> Try "release any integration with the same extremely low odds that Quality
> Control will find any bug in it as any other integration, including the
> formal 'release' ones."

How about "similar odds" rather than "same odds"?

> (Recall we integrate after every tiny change; that's the "release" I'm
> talking about.)
>
> The end result: If a customer wants a patch, they get it now, not later.

This is a fine characteristic, but it would not by itself differentiate
"agile" from "iterative".

> Can you think of a way to enable these two project capabilities while
going
> faster?

What two? Faster than what?

> > > - minimize the time between committing a request
> > > and making end-users more productive with it.
> >
> > If I interpret the term "minimize" literally, then no project actually
> > achieves this. And all proper projects strive to minimize the time from
> > getting requirements to fulfilling them.
>
> This is just the same as the hardware manufacturing goal "minimize average
> inventory shelf time". The time between a purchase order and delivery
should
> be short!
>
> Achieving the other two goals enables this goal.

My point is that the goal is in common with all other methodologies. The
purpose of any methodology is to do things more efficiently. To be objective
you should not have the goal as one of the distinguishing characteristics,
it's like the word "agile" itself.

Shayne Wissler

Relevant Pages

  • Re: How do you make decisions that optimize software quality?
    ... >> ...mandate that you must deliver software at the absolute lowest ... >> possible total cost of development and deployment... ... Clearly it should be the goal of a built system ... If they are chosen after goals ...
    (comp.object)
  • Re: How do you make decisions that optimize software quality?
    ... >> ...mandate that you must deliver software at the absolute lowest ... >> possible total cost of development and deployment... ... Clearly it should be the goal of a built system ... If they are chosen after goals ...
    (comp.lang.java.softwaretools)
  • Re: Data driven people arguments
    ... you want to achieve is to minimize the cost of some future change. ... colleague is concerned with the cost of redeploying and the cost ... possiblity of redeploying with a 5 minutes downtime (because it gives ... You'll probably find that you have lots of common goals, ...
    (comp.object)
  • Re: Days not weeks
    ... A programs success is determined by whether it meets its goals. ... is not a goal then cost is not a success criteria. ...
    (rec.sport.golf)
  • Re: Days not weeks
    ... A programs success is determined by whether it meets its goals. ... is not a goal then cost is not a success criteria. ...
    (rec.sport.golf)