Extreme Programming - Sorting features in business priority is a design technique

Author

Sorting features in business priority is a design technique

Phlip

2004-03-19, 1:17 pm

eXtremos:

Under eXtreme Programming, the Onsite Customer sorts features in order by
business value.

Superficially, this practice sounds mostly harmless. At least you can get
the end-users to start using the project before you can finish it, right?

Code supporting the earliest features lives the longest, and gets re-used
into other features the most. So new tests cross-verify the oldest code,
putting incredible pressure on it to behave.

But converting a requirement into a feature activates it in a way that all
subsequent features are beholden to. This "pecking order" of features
conditions the subsequent ones to support and re-inforce the early ones.

All roads lead to Rome. So all features in a program lead to the features
that best promote the target business.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Scott Kinney

2004-03-19, 1:17 pm

Your post reminded me of something that nags at me when I read
XP stuff about requirements/stories....

In (gasp) traditional project management, requirement prioritization
takes place along with analysis to determine whether:
1. the requirements are internally consistent (ie don't contradict
each other, or work at cross purposes)
2. the requirements are complete, nothing missing, nothing extra

I've never seen these two questions addressed in XP. (I could
have missed it, I'm sure.) Does XP do this work in another way
or at another time?

Scott

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:ojF6c.37239$7B5.313@newssvr16.news.prodigy.com...
> eXtremos:
>
> Under eXtreme Programming, the Onsite Customer sorts features in order by
> business value.
>
> Superficially, this practice sounds mostly harmless. At least you can get
> the end-users to start using the project before you can finish it, right?
>
> Code supporting the earliest features lives the longest, and gets re-used
> into other features the most. So new tests cross-verify the oldest code,
> putting incredible pressure on it to behave.
>
> But converting a requirement into a feature activates it in a way that all
> subsequent features are beholden to. This "pecking order" of features
> conditions the subsequent ones to support and re-inforce the early ones.
>
> All roads lead to Rome. So all features in a program lead to the features
> that best promote the target business.
>
> --
> Phlip
> http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces
>
>
>

Phlip

2004-03-26, 11:50 pm

Scott Kinney wrote:

> Your post reminded me of something that nags at me when I read
> XP stuff about requirements/stories....
>
> In (gasp) traditional project management, requirement prioritization
> takes place along with analysis to determine whether:
> 1. the requirements are internally consistent (ie don't contradict
> each other, or work at cross purposes)
> 2. the requirements are complete, nothing missing, nothing extra
>
>
> I've never seen these two questions addressed in XP. (I could
> have missed it, I'm sure.) Does XP do this work in another way
> or at another time?

XP addresses those issues by implementing the features.

If the feature with highest business value is inconsistent, then the effort
to find that out as early as possible, to limit damage, is synchronous with
the activity to deliver the highest business value feature as early as
possible.

If something is missing or incomplete, the attempt to write the feature will
detect that. The Onsite Customer role is charged with reviewing features in
real-time, as they grow. That's not as hard as it sounds; it makes
impatience into a tool.

Much of Agility is about compounding the return from simple activities.
Implementing the feature validates the requirements for the feature.

All remaining features, being less important, remain on the drawing board,
more fuzzy. Bringing them into focus reveals their risks. But the code, and
tests, to support the highest business value are now used to help resolve
the next iteration's features.

I suspect you should read Lean Development, but I ain't read it yet. When it
came out, the differences between its simple clarity and my current job site
were heartbreaking.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Laurent Bossavit

2004-03-26, 11:50 pm

Scott:

One problem with project management as "traditionally" understood is the
unwarranted assumptions that get dragged into requirements work.
Consistency and completeness are among these assumptions.

> 1. the requirements are internally consistent (ie don't contradict
> each other, or work at cross purposes)

No set of requirements can be internally consistent. There is always
some tension between requirements - that's a defining characteristic of
design problems. For instance, there always is an implicit requirement
that the project should cost as little as possible, conflicting with
requirements for reliability, performance, ease of use, etc.

> 2. the requirements are complete, nothing missing, nothing extra

For the reason above, any project involves selecting among conflicting
requirements. Further, requirements are never stable over time. There's
no way that a given formulation of the requirements can be "complete"
with respect to what will actually need to be implemented.

Then there's the argument of risk management. Realizing the benefits of
the project depends on uncertain future events, some of which will be
risks - incidents that /reduce/ the benefits if they occur. Some of the
project "requirements" will be in the form of contingency plans - they
may never be implemented if the risk does not materialize. (See
DeMarco's /Waltzing with Bears/.)

Laurent
http://bossavit.com/thoughts/

Ronald E Jeffries

2004-03-26, 11:50 pm

On Fri, 19 Mar 2004 12:03:26 -0500, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>Your post reminded me of something that nags at me when I read
>XP stuff about requirements/stories....
>
>In (gasp) traditional project management, requirement prioritization
>takes place along with analysis to determine whether:
>1. the requirements are internally consistent (ie don't contradict
>each other, or work at cross purposes)
>2. the requirements are complete, nothing missing, nothing extra
>
>
>I've never seen these two questions addressed in XP. (I could
>have missed it, I'm sure.) Does XP do this work in another way
>or at another time?

Well, regarding 2, we are suggesting that for most projects, it just
isn't so:

2a. Things change, so that the features list is never complete. This
is why most programs spend ages in maintenance, adding new features.
So when the people with the need have enough of the need figured out
to make an implementation worth the cost, it's time to go ahead.

2b. In thinking of "requirements", we generally go way beyond
"required". Most feature-generating techniques do this explicitly, by
trying to brainstorm or otherwise generate a list of everything we
might do. So many desired features are in fact "extra".

2c. In scoping a project, we generally have far less money and time
than we would like to have. Thus features are given priorities in any
rational scheme, and the lower-priority features are dropped.

Now regarding 1, a number of observations:

1a. XP includes the Planning Game, in which the team, together with
its Customer, examines, considers, estimates, and prioritizes all the
then-known features. In the course of this simple practice, the team
considers all the features at once, and how they might be implemented.
Since everyone on the team is present, all the people who might
possibly notice contradictions have the opportunity to do so.

1b. Features are generally done in the order of highest value and
lowest cost. The primary benefit of this is to deliver the "most
profitable" product at the earliest possible date. A side effect,
however, is to place all the most important features in juxtaposition
early on, so that any conficts will again be shown up.

1c. Features are specified concretely by automated tests. This
practice weeds out inconsistencies and lack of clarity quite
effectively, since it gets down to all the details.

1d. People don't seem to generate very many truly contradictory
requirements anyway. When through forgetting or other mistakes, the
are discovered, the answer is usually quite immediate: "Oh, I meant
this, not that."

Now all this is just vague assurances, but it's based on watching a
lot of XP projects over the years. You might have something more
explicit in mind in terms of missing or conflicting requirements.
Would you like to give some examples and talk about how XP projects
would behave in those circumstances?

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott Kinney

2004-03-26, 11:50 pm

It sounds a lot like 'ready-fire-aim'.

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:UdQ6c.27080$oX6.24265@newssvr31.news.prodigy.com...
> Scott Kinney wrote:
>
>
> XP addresses those issues by implementing the features.
>
> If the feature with highest business value is inconsistent, then the
effort
> to find that out as early as possible, to limit damage, is synchronous
with
> the activity to deliver the highest business value feature as early as
> possible.
>
> If something is missing or incomplete, the attempt to write the feature
will
> detect that. The Onsite Customer role is charged with reviewing features
in
> real-time, as they grow. That's not as hard as it sounds; it makes
> impatience into a tool.
>
> Much of Agility is about compounding the return from simple activities.
> Implementing the feature validates the requirements for the feature.
>
> All remaining features, being less important, remain on the drawing board,
> more fuzzy. Bringing them into focus reveals their risks. But the code,
and
> tests, to support the highest business value are now used to help resolve
> the next iteration's features.
>
> I suspect you should read Lean Development, but I ain't read it yet. When
it
> came out, the differences between its simple clarity and my current job
site
> were heartbreaking.
>
> --
> Phlip
> http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces
>
>

John Roth

2004-03-26, 11:50 pm

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:m66dncPIqJp9usbd4p2dnA@comcast.com...
> Your post reminded me of something that nags at me when I read
> XP stuff about requirements/stories....
>
> In (gasp) traditional project management, requirement prioritization
> takes place along with analysis to determine whether:
> 1. the requirements are internally consistent (ie don't contradict
> each other, or work at cross purposes)
> 2. the requirements are complete, nothing missing, nothing extra
>
>
> I've never seen these two questions addressed in XP. (I could
> have missed it, I'm sure.) Does XP do this work in another way
> or at another time?

It doesn't need to. This is one of those places where a practice
makes sense in the context of one design paradigm (big bang
delivery at the end of the process) but doesn't make sense in
a different paradigm (incremental development and delivery.)
Incompatible and incomplete requirement sets will be found as
the project progresses. The only possible problem is that the
incompatible or missing requirements might cause the project
to go down a wrong path that will take a lot of effort to correct.

XP (and Lean Software Development, which I consider a must
read for any XP practitioner) do contain practices that reduce
the liklihood of that happening.

John Roth
>
> Scott
>
> "Phlip" <phlip_cpp@yahoo.com> wrote in message
> news:ojF6c.37239$7B5.313@newssvr16.news.prodigy.com...
by[color=darkred]
get[color=darkred]
right?[color=darkred]
re-used[color=darkred]
all[color=darkred]
features[color=darkred]
>
>

Scott Kinney

2004-03-26, 11:50 pm

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:rh6o50lijrmrjg4s86o77ugvjmlkepjnr1@
4ax.com...
>
> Well, regarding 2, we are suggesting that for most projects, it just
> isn't so:
>
> 2a. Things change, so that the features list is never complete. This
> is why most programs spend ages in maintenance, adding new features.
> So when the people with the need have enough of the need figured out
> to make an implementation worth the cost, it's time to go ahead.
>

Then it's not a project. It's some kind of maintenance program.
A project has a definite result. And change management; the documentation,
estimation and disposition of changes and/or additions to the requirements
are part of the project management discipline.

> 2b. In thinking of "requirements", we generally go way beyond
> "required". Most feature-generating techniques do this explicitly, by
> trying to brainstorm or otherwise generate a list of everything we
> might do. So many desired features are in fact "extra".
>
I think this is a semantic difference. The activities you describe
as 'feature generating', I describe as 'requirements gathering'.

> Now regarding 1, a number of observations:
>
> 1a. XP includes the Planning Game, in which the team, together with
> its Customer, examines, considers, estimates, and prioritizes all the
> then-known features. In the course of this simple practice, the team
> considers all the features at once, and how they might be implemented.
> Since everyone on the team is present, all the people who might
> possibly notice contradictions have the opportunity to do so.
>
> 1b. Features are generally done in the order of highest value and
> lowest cost. The primary benefit of this is to deliver the "most
> profitable" product at the earliest possible date. A side effect,
> however, is to place all the most important features in juxtaposition
> early on, so that any conficts will again be shown up.
>
> 1c. Features are specified concretely by automated tests. This
> practice weeds out inconsistencies and lack of clarity quite
> effectively, since it gets down to all the details.
>
Any well-written requirement contains its own 'evidence procedure'.
I call it the 'as shown by' clause.

> 1d. People don't seem to generate very many truly contradictory
> requirements anyway. When through forgetting or other mistakes, the
> are discovered, the answer is usually quite immediate: "Oh, I meant
> this, not that."
>
> Now all this is just vague assurances, but it's based on watching a
> lot of XP projects over the years. You might have something more
> explicit in mind in terms of missing or conflicting requirements.
> Would you like to give some examples and talk about how XP projects
> would behave in those circumstances?
>

First, I'll add a piece about consistency that was missing from my
initial comment. There's the big question "Do these requirements get us
to the business goal?" The requirements gathered may not, on their
face, bear much relation to the project's business goal.

One example of conflicting requirements would be that a marketing
requirement for unrestricted access to some data would conflict with
a corporate standard (or even a Federal law) for data security or
confidentiality.
Another might be that the training group's requirement for a 1-time training
in the
new features conflicts with the phased production deployment (although this
is more
properly a conflict between a requirement and a development approach.)

Scott Kinney

2004-03-26, 11:50 pm

"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1ac61a575aaf119f98972c@news.noos.fr...
> Scott:
>
> One problem with project management as "traditionally" understood is the
> unwarranted assumptions that get dragged into requirements work.
> Consistency and completeness are among these assumptions.
>
>
> No set of requirements can be internally consistent. There is always
> some tension between requirements - that's a defining characteristic of
> design problems. For instance, there always is an implicit requirement
> that the project should cost as little as possible, conflicting with
> requirements for reliability, performance, ease of use, etc.

This is true, but sort of trivial. The design process moderates these and
results in a design that the customer still has to validate in terms of
whether
it meets the business objective.

The responsible thing to do with conflicting requirements is to work out
the obvious and easy ones when they're in the requirement stage when it's
cheap
to fix. Those conflicts that 'define' the design problem should be all
that's left, and
identified as such.

>
> For the reason above, any project involves selecting among conflicting
> requirements. Further, requirements are never stable over time. There's
> no way that a given formulation of the requirements can be "complete"
> with respect to what will actually need to be implemented.

Well, that's what a change management process is for. The requested change
is either worth the increase in effort, cost or schedule creep, or it's not.
>
> Then there's the argument of risk management. Realizing the benefits of
> the project depends on uncertain future events, some of which will be
> risks - incidents that /reduce/ the benefits if they occur. Some of the
> project "requirements" will be in the form of contingency plans - they
> may never be implemented if the risk does not materialize. (See
> DeMarco's /Waltzing with Bears/.)

Risk management plans do not form requirements. If a contingency plan
is invoked because the condition was detected, then there will be changes
to the requirements. But risk plans themselves do not add or delete
requirements.

I don't understand your statement "Realizing the benefits of the project
depends on uncertain future events....."

Laurent Bossavit

2004-03-26, 11:50 pm

Scott:

[From your response to Ron]

> Then it's not a project. It's some kind of maintenance program.

Well, most so-called software projects partake of both to some extent.
One of project management's dirty secrets is how rarely what we manage
is actually a project... (Out of curiosity, how do you define a
project?)

> The responsible thing to do with conflicting requirements is to work out
> the obvious and easy ones when they're in the requirement stage when it's
> cheap to fix. Those conflicts that 'define' the design problem should be all
> that's left, and identified as such.

By and large I agree. We might differ on how much effort is to be
expended before we can be confident that the conflicts we have spotted
were the obvious and easy ones.

> Well, that's what a change management process is for. The requested change
> is either worth the increase in effort, cost or schedule creep, or it's not.

OK. That's what the on-site customer is there for in XP. The change
management process consists of her calling the shots on that...
responsibly.

> Risk management plans do not form requirements.

I'll take that as definitional. No problem. :)

> I don't understand your statement "Realizing the benefits of the project
> depends on uncertain future events....."

Projects deal with statements about the future, with reference to some
desirable outcomes. "If we put ourselves in such and such a situation,
then such and such an outcome will result." Project work is concerned
with creating these situations. But these predictions may turn out to be
incorrect - we might be unable to create the situations we envision, or
the desired outcomes might not follow from them.

We could speak of "complete" requirements only if we were totally
certain about our capability of creating specific situations /and/ of
predicting the resulting outcomes. That's not the case, so whatever we
do involves some measure of making it up as we go along.

Laurent
http://bossavit.com/thoughts/

Robert C. Martin

2004-03-26, 11:50 pm

On Sat, 20 Mar 2004 15:17:08 -0500, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>It sounds a lot like 'ready-fire-aim'.

You mean like a smart weapon.

Larry Niven once wrote that when you shoot with a laser, you fire and
then aim.

In any case, I think it's save to say that a software project is not
an artillery shell. It does not follow an uncontrolled ballistic
trajectory once you shoot it. The target does not depend solely on
the impulse and initial trajectory. Indeed, a software project must
be *managed*. And that management *is* aiming after firing.

Scott Kinney

2004-03-26, 11:50 pm

"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1ac6e3b271facb9798972d@news.noos.fr...
>
> Well, most so-called software projects partake of both to some extent.
> One of project management's dirty secrets is how rarely what we manage
> is actually a project... (Out of curiosity, how do you define a
> project?)
>
Pretty old school about that -
A project is a temporary endeavor to create a unique product or service.

change[color=darkred]
not.[color=darkred]
>
> OK. That's what the on-site customer is there for in XP. The change
> management process consists of her calling the shots on that...
> responsibly.
>

Isn't the 'dirty little secret' of XP that the on-site customer isn't
really the customer, it's someone on the project team representing
their interests? (and that's just a return jab for the snarky comment
about how few projects are really projects.)

>
> I'll take that as definitional. No problem. :)
>
>
> Projects deal with statements about the future, with reference to some
> desirable outcomes. "If we put ourselves in such and such a situation,
> then such and such an outcome will result." Project work is concerned
> with creating these situations. But these predictions may turn out to be
> incorrect - we might be unable to create the situations we envision, or
> the desired outcomes might not follow from them.

Er, no, I don't think so.

>
> Laurent
> http://bossavit.com/thoughts/

Scott Kinney

2004-03-26, 11:50 pm

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:gelp50d4k2sn5d6s5it1fepj47vvfsc347@
4ax.com...
> On Sat, 20 Mar 2004 15:17:08 -0500, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> You mean like a smart weapon.

Actually, no, more like an artillery round. And since the loop in
XP is explicitly "There I coded it, how close did I get to what you
wanted? Not there yet, here, I'll code some more...." That would
be a more accurate analogy.

> In any case, I think it's save to say that a software project is not
> an artillery shell. It does not follow an uncontrolled ballistic
> trajectory once you shoot it. The target does not depend solely on
> the impulse and initial trajectory. Indeed, a software project must
> be *managed*. And that management *is* aiming after firing.
>
No, that's navigation.

Steve Jorgensen

2004-03-26, 11:50 pm

Laurent Bossavit

2004-03-26, 11:50 pm

X-Newsreader: MicroPlanet Gravity v2.50
Lines: 55
Organization: Noos
NNTP-Posting-Date: 21 Mar 2004 00:44:36 GMT
NNTP-Posting-Host: 81.64.253.95
X-Trace: 1079829876 news.noos.fr 13399 81.64.253.95
X-Complaints-To: abuse@noos.fr
Path: kermit!newsfeed-east.nntpserver.com!nntpserver.com!news-out.visi.com!petbe.visi.com!news.octanews.net!proxad.net!proxad.net!noos.fr!not-for-mail
Xref: kermit comp.software.extreme-programming:27815

Scott:

> A project is a temporary endeavor to create a unique product or service.

Thanks. I appreciate the conciseness of that.

I'm

about what you mean by "unique". Is it "single", or
"different from all others", or some other meaning ?

Would your definition apply to a "SAP rollout project" ? Would the
"temporary" part of it apply to "the GNU Project", which seems more of
an ongoing thing ? How about the "Web Standards Project", which defines
itself as a "grassroots coalition fighting for [Web] standards" - and
doesn't sound like a single product or service ?

> Isn't the 'dirty little secret' of XP that the on-site customer isn't
> really the customer, it's someone on the project team representing
> their interests? (and that's just a return jab for the snarky comment
> about how few projects are really projects.)

Thanks for wanting to give as good as you get. It wasn't snarky, though;
that's my considered opinion.

The term "project" means something different to every person I ask for a
definition. For every definition I've been given, there are things many
people are quite happy to call "project" that don't fit the definition.
My comment is a conclusion from these observations.

The term "customer" is also a much overloaded one. Let me rephrase: the
change management process in XP consists of one designated person
calling the shots of what is added to or subtracted from the
requirements. That person is called "on-site customer". This is normally
a person designated by the party funding the project, who has extensive
domain expertise.

>
> Er, no, I don't think so.

Would you care to expand on that ? I'm not sure which part of the above
you are disagreeing with - perhaps I didn't provide you with a clear
enough target.

Are you suggesting that a) we are always capable of fulfilling the
"requirements" of our projects - of bringing about the situations from
which we expect to benefit; or that b) we always get the results we
expect from fulfilling those "requirements" ?

Laurent
http://bossavit.com/thoughts/

Donald Roby

2004-03-26, 11:50 pm

On Sat, 20 Mar 2004 19:01:25 -0500, Scott Kinney wrote:

>
> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:gelp50d4k2sn5d6s5it1fepj47vvfsc347@
4ax.com...
>
> Actually, no, more like an artillery round. And since the loop in
> XP is explicitly "There I coded it, how close did I get to what you
> wanted? Not there yet, here, I'll code some more...." That would
> be a more accurate analogy.
>

Tracer bullets. Better analogy and better approach.

Scott Kinney

2004-03-26, 11:50 pm

"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1ac7048d755fdc4e98972f@news.noos.fr...
> Scott:
>
>
> Thanks. I appreciate the conciseness of that.
>
> I'm

about what you mean by "unique". Is it "single", or
> "different from all others", or some other meaning ?
>
> Would your definition apply to a "SAP rollout project" ? Would the
> "temporary" part of it apply to "the GNU Project", which seems more of
> an ongoing thing ? How about the "Web Standards Project", which defines
> itself as a "grassroots coalition fighting for [Web] standards" - and
> doesn't sound like a single product or service ?
>
"Unique", according to the definition I quoted is 'the product or service
is different in some distinguishing way from all similar products or
services.

"Temporary" means having a definite beginning and a definite ending.

SAP Rollout would be a project.
Neither the GNU project nor the Web Standards Project would
qualify under the definition (unless they have a time-frame I'm unaware of.)

However, I'm willing to consider that the Alan Parsons Project (being of
finite duration) would qualify.

Robert C. Martin

2004-03-26, 11:50 pm

On Sat, 20 Mar 2004 19:01:25 -0500, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:gelp50d4k2sn5d6s5it1fepj47vvfsc347@
4ax.com...
>
>Actually, no, more like an artillery round. And since the loop in
>XP is explicitly "There I coded it, how close did I get to what you
>wanted? Not there yet, here, I'll code some more...." That would
>be a more accurate analogy.

That's quite incorrect. In XP we have the stakeholders collaborate
with QA to create acceptance tests of excruciating detail. Every
iteration the stakeholders select the requirements to work on, and
then produce the executable acceptance tests for them. The
requirements are not considered complete until these acceptance tests
execute and pass.

There may be some things that the stakeholders aren't sure about.
Especially about cosmetic issues. Certainly then they'll work closely
with the programmers to see what is feasible and what isn't. The
programmers may show them some ideas by writing some demonstration
code. But overall, the programmers *know* what they are producing.
Indeed, they know in hideous detail, because they have the acceptance
tests in front of them.

There is another form of iteration, however, that occurs *between*
iterations. Customers cannot know up front exactly what they want.
Nobody is that prescient. So as they see the project grow from
iteration to iteration they will very likely find things about it that
they don't like -- even though they specified those things. They are
allowed, and even encouraged to change those requirements and schedule
those changes in ways that make financial sense to them.

>No, that's navigation.

Whatever. It's controlling your path so that you manage to hit a good
target. In the case of a software project it's often not even the
target you initially thought you were supposed to hit.
>

Jason Nocks

2004-03-26, 11:50 pm

Scott Kinney wrote:

> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:gelp50d4k2sn5d6s5it1fepj47vvfsc347@
4ax.com...
>
>
> Actually, no, more like an artillery round. And since the loop in
> XP is explicitly "There I coded it, how close did I get to what you
> wanted? Not there yet, here, I'll code some more...." That would
> be a more accurate analogy.

If this is explicit, then where did this quote come from?

The explicit coding "loop" in XP is TDD, and goes something like this:
* Write automated test (so you know when you are done)
* Write code (there's no guess as to how close you got, you know you are
all the way there when the test passes)
* Eliminate duplication (find and remove any unnecessary code)

The tests in TDD are Unit Tests, but even before writing the Unit Test,
a failing Acceptance Test was written by or agreed to by the customer,
and is waiting for me to get it to pass. As soon as it passes, I know
I'm done and have implemented "what you wanted". I should stop working
on that feature and move on to the next.

When I observe developers not practicing XP, I see developers staring at
their code, even after they think they are done. Then, they "code some
more", because they think of something else they could add that *might*
be needed down the road. Writing tests first in XP specifically prevents
this behavior.

When the test passes, you confidently stop writing code. You then start
looking for code you can delete! We want the code to be as clean as
possible.

What I am guessing that you were probably thinking of as "how close did
I get to what you wanted" is what *might* happen after *delivering* the
tested, working features to the customer.

The customer gets the working, tested features that he or she requested.
These features conform to tests that were either written by, or approved
by the customer. After actually using the delivered software, the
customer realizes that a *new* requirement is important or that a
requirement needs to change (what the customer *thought* he or she
wanted is not quite what they really wanted).

This is the type of change that would result in something like a Change
Order that would increase the overall budget in a different process (if
it was even uncovered at all while there was any chance of getting a
developer to work on it).

This new feature/requirement becomes a new User Story and goes through
the same process. This feature is generally equivalent to what is
uncovered in other projects only in the maintenance phase, when there is
no more development budget left and many of the developers have moved on
to other projects/companies. The issue here is that the customer/user
will only realize that certain features/requirements need to be added or
changed after having a chance to start *using* the *delivered* software.

Does this clear up what you were thinking of, and explain it better?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Ronald E Jeffries

2004-03-26, 11:50 pm

On Sat, 20 Mar 2004 15:37:27 -0500, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:rh6o50lijrmrjg4s86o77ugvjmlkepjnr1@
4ax.com...
>
>Then it's not a project. It's some kind of maintenance program.
>A project has a definite result. And change management; the documentation,
>estimation and disposition of changes and/or additions to the requirements
>are part of the project management discipline.

OK. It was said early on, by Kent Beck, that the point of XP is to get
a program into maintenance as early as possible. The notion is that
the actual steady state part of a program's existence is the more
common state, and the project, if we want to call it that, to create
it the first time is the most risky.

I'm not sure just what distinction you're trying to draw with the
notion of a project having "a definite result". I'm sure we'd agree
that almost no real project has a definite result that is the same as
the result predicted at the beginning, since most wise project people
learn as they go, adjust as they go.

And is the software development inside a larger project, with all the
requirements disposition you are speaking of, still not a project? If
it's not a (sub) project, what is it to be called?
>
>I think this is a semantic difference. The activities you describe
>as 'feature generating', I describe as 'requirements gathering'.

Yes.
>
>Any well-written requirement contains its own 'evidence procedure'.
>I call it the 'as shown by' clause.

OK. Is your point that some other processes also specify a shown-by?
I'm OK with that. I've not seen one that focuses so strongly on
automated tests as does XP, but in any case, XP isn't trying to be
different, it's trying to be what it is: a collection of good
practices.
>
>
>First, I'll add a piece about consistency that was missing from my
>initial comment. There's the big question "Do these requirements get us
>to the business goal?" The requirements gathered may not, on their
>face, bear much relation to the project's business goal.

True. This notion is, at least today, entirely outside the XP
perimeter. XP is about how, given requirements, to steer a project to
a successful delivery. It's not, at least today, about how to know
what requirements to want.
>
>One example of conflicting requirements would be that a marketing
>requirement for unrestricted access to some data would conflict with
>a corporate standard (or even a Federal law) for data security or
>confidentiality.

OK. And therefore what? Are you looking for some kind of
pre-implementation sorting process? One could do that if one had fear
about that sort of thing. I've worked on agile projects that were
subject to a lot of interacting rules, however, and it goes just fine,
as long as the people on the team know all those rules. And, as far as
I can imagine, there is no process that will work if the people don't
know the rules.

Anyway, I understand the kidn of conflict you're talking about .. but
not what question you're asking.

>Another might be that the training group's requirement for a 1-time training
>in the
>new features conflicts with the phased production deployment (although this
>is more
>properly a conflict between a requirement and a development approach.)

Yes. Again ... and therefore what?

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Phlip

2004-03-26, 11:50 pm

Robert C. Martin wrote:

> Larry Niven once wrote that when you shoot with a laser, you fire and
> then aim.
>
> In any case, I think it's save to say that a software project is not
> an artillery shell. It does not follow an uncontrolled ballistic
> trajectory once you shoot it. The target does not depend solely on
> the impulse and initial trajectory. Indeed, a software project must
> be *managed*. And that management *is* aiming after firing.

Hmm. I just now finished writing an analogy elsewhere on the 'net, then
selected this post on the same theme next:

Given the project "fly astronauts to the moon", the first requirement is to
strap astronauts to the tip of an intercontinental ballistic missile, shoot
them into space, and make sure they come back. The first requirement is
/not/ to make sure the onboard tea dispenser produces an adequate Earl Grey
tea.

This is because the rocket forms the framework for the tea dispenser, not
vice-versa.

So, if "get a long way towards the Moon" is implemented first, then all
subsequent features must implement in a way that supports that primal one,
both spiritually and physically. If the first space program feature is a big
rocket, then when we add the tea dispenser, it is now more likely to go to
the Moon.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Sponsored Links