[AM] Let's call a spade a spade

Discussion:

debhart

2004-03-26 04:02:19 UTC

... When a client or employer
doesn't want to work that way, I look for a quick exit. > I have been able

to feed my family so far.

JB: thanks for sharing this honest viewpoint. It's taken out of context
here, because I'm more interested in the sentiment than the discussion it
comes from, I hope that's ok. Here's my take on the same subject:

We need to remember this in the Agile community, because Agile is about
Values: Where an organisation or client *mandates* non-agile practices one
needs to accept being non-agile in that area, or get out and do something
more satisfying. The third option must be resisted: incorporating non-agile
or anti-agile practices *and* calling it Agile. This is confusing and not
satisfying: it weakens the effectiveness of Agile's inspect-and-adapt cycle.
One's Agile efforts will be handicapped - as the team limps along, wondering
why "it hurts when I do /this/", wondering why Agile is not working, we give
Agile a bad name and make our teams unhappy.

Let's be honest and own up to the practices we are using - by choice or
economic necessity. Compromises are sometimes necessary, we have all seen
this and know it exists. But let's not try to twist Agile to incorporate or
compensate for these compromises. So, if it's not Agile, don't try to sugar
coat it and call it Agile. Call it a hybrid. Call it "on our way".

Or get out - as JB mentions. This is an honest approach, and seems to be
satisfying to JB and others I know. That's important. Well, for many of us,
job satisfaction is important.

Personally, I'm happy to be *more agile* every month... it's an organic
growth thing, but then I have a long fuse. Over time, we try to replace the
next thing that hurts the work the most with an Agile practice... if it's
where the team hurts most, there is more motivation to accept the change.
Who cares if we're not 100% Agile today? Next week? As long as it's
sufficiently satisfying in terms of what you value. It is for me. For now.

We'll see next month. There's always the door. :-)
deb

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Paul Oldfield

2004-03-26 12:37:14 UTC

Permalink

Post by debhart
Let's be honest and own up to the practices we are
using - by choice or economic necessity. Compromises
are sometimes necessary, we have all seen this and
know it exists. But let's not try to twist Agile to incorporate
or compensate for these compromises. So, if it's not
Agile, don't try to sugar coat it and call it Agile. Call it a
hybrid. Call it "on our way".

I try to work to a guideline of being as agile as possible,
and as robust as necessary, when tailoring process.
Any process that follows this guideline (and 3 others)
I call an 'appropriate' process.

I would be happy refusing to call a process 'agile' if it
were more robust than necessary. I'm in two minds as
to whether a process that is only as robust as necessary
should be denied the label 'agile' for that reason alone.
Maybe I need a few examples to consider.

Paul Oldfield
www.aptprocess.com

Advertisments belong BELOW this line

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

debhart

2004-03-27 13:56:29 UTC

Permalink

Post by Paul Oldfield
(responding to Deb)

I'm trying to work out where (or how?) to draw the line myself...
some examples:

1a. Throwing *tested* software from a Scrum Sprint "over the wall" to a
separate mandated QA process - Agile enough.
1b. Not testing inside a Sprint because QA will do it later - Not Agile
(not Scrum, definitely)

2a. Producing heavy documentation at the *end* of a Sprint because it's
demanded by someone outside the process - Agile enough (something to
improve over time, hopefully)
2b. Doing mini-waterfall with heavy documentation inside Sprints,
because it is mandated by someone outside the process - major compromise
but probably still "somewhat Agile" due to
Scrum's iterative nature.

There are a couple of issues here, regarding the "b" cases:
- participants would need to decide if they can live with the inherent
compromises. Some would prefer to leave, others would prefer to make the
investment to try to change it.
- either way, publicly touting these scenarios as "Agile" muddies the
waters and works against the Agile Manifesto and its Agile Principles.
Actions speak louder than words - we need to be careful what our
projects are concretely saying about the Manifesto.
- a key issue might be: is there room for this to change? If not, the
"inspect and adapt" aspect of Agile will be frustrating - in each
iteration, if the team identifies a roadblock to effectiveness, and each
time are told "forget it, it stays", then morale might become a problem.
Or inspect-and-adapt will be dropped because it yields nothing. Another
reaction could be the development of "blockers", adding cost (and
hassle) to the work.

To my mind, there should be no shame in calling something "partially
Agile". To me, it indicates integrity and underlines the importance of
the values of the Manifesto. Granted, there are grey areas...

Maybe the tags "Agile enough" or "as Agile as possible" can be useful to
us, because they require context to be meaningful:
Agile enough for now - we're still developing our processes
Agile enough given the constraints put on us by our VP
As Agile as possible, until our team is cross-trained
As Agile as possible, within the sphere of influence of our leader.
Agile enough, until we evangelise the following key people...

These statements necessitate conscious identification of blockages to
Agility, setting the stage for potential change and improvement.
Alternately, they could be identifying firm blockages that will make
further Agility impossible. Either way, they facilitate decision making
among participants: stay and work for change? or go and be Agile
somewhere else?

These statements also could ward off disillusionment among newbies to
Agile within and outside the team: when constraints are identified as
*blockages* to Agility, they are less likely to be called *failures* of
Agile, by naysayers. You know the kind of stories that surface, that
start with "We're forbidden to call anything "Agile" at XYZ Corp., due
to the failure of an Agile project last year..." And we all ask: were
they truly Agile? What were they doing?

While thinking about this, I've developed a "Scrum Scoreboard" of sorts
that could be extended to cover other Agile practices too. I'm just
floating an idea at this point - feedback would be welcome on the
ScrumRegistry wiki: http://wiki.scrums.org/index.cgi?ScrumScoreboard

Have a good weekend!
deb

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-27 16:58:09 UTC

Permalink

Post by debhart
I'm trying to work out where (or how?) to draw the line myself...

We are about to go on a journey through time and space...

The time is now 1984. The space is an alternate universe
in which the Agile Manifesto was written in 1979. These
messages are all dated 1984 and are being written in the
context of 1984 software technology.

There is this new thing people are talking about. Something
about designing software using objects. Others are talking
about hiding information. Sounds dumb to me -- as a
software maintainer I need more info, not less. People
are supposed to interact, not hide things from each other!
And this thing about designing subroutines to represent
objects sounds very unnatural; everyone knows a subroutine
represents a good 'ol function. Thinking so unnaturally
violates the simplicity principle. And of course, our
customers will never understand it, even if us developers
somehow manage to figure it out. That makes customer
collaberation a lot harder.

So what do we have? Info hiding instead of open interaction,
unnaturally complex code structure, confusing design that
makes cummunication with the customer harder -- this whole
object thing violates a whole slew of our values. I think
us agilers should be against this new object craze as it
clearly is not agile.

What do you think?

...Control of time and space is now being returned to you.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Ashley McNeile

2004-03-27 23:28:04 UTC

Permalink

Post by debhart
I'm trying to work out where (or how?) to draw the line myself...

We are about to go on a journey through time and space...

The time is now 1984. The space is an alternate universe
in which the Agile Manifesto was written in 1979. These
messages are all dated 1984 and are being written in the
context of 1984 software technology.

There is this new thing people are talking about. Something
about designing software using objects. Others are talking
about hiding information. Sounds dumb to me -- as a
software maintainer I need more info, not less. People
are supposed to interact, not hide things from each other!
And this thing about designing subroutines to represent
objects sounds very unnatural; everyone knows a subroutine
represents a good 'ol function. Thinking so unnaturally
violates the simplicity principle. And of course, our
customers will never understand it, even if us developers
somehow manage to figure it out. That makes customer
collaberation a lot harder.

So what do we have? Info hiding instead of open interaction,
unnaturally complex code structure, confusing design that
makes cummunication with the customer harder -- this whole
object thing violates a whole slew of our values. I think
us agilers should be against this new object craze as it
clearly is not agile.

What do you think?

...Control of time and space is now being returned to you.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWg0Nif/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 17:06:01 UTC

Permalink

Post by debhart
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAb7APIWa/ Ivo Interactive
===========================================================
It was about 1984, or perhaps 1985, that a colleague of mine, fed up with
endless metaphysical modelling sessions, was advocating an approach he
called SPACI. This stood for "Stop Pissing About and Code It".
Was this the actual birth of XP?

I think XP came much later, but you'd have to ask
Ward and Cunningham to be sure. Certainly, your
colleague was not the first to get fed up with
approaches that are up-front "spec-heavy".

Unfortunately, swinging the pendulum fully the
other way and coding without any spec work at all
is also not the answer. The fact that AM exists
means that agile minds agree some spec work,
either before or perhaps interleaved with, coding
is necessary.

The key is achieving an appropriate balance. Where
this balance point lies can vary with project as
it depends on both technical and management factors.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Robert C. Martin

2004-03-29 05:40:34 UTC

Permalink

Post by debhart
-----Original Message-----
Unfortunately, swinging the pendulum fully the
other way and coding without any spec work at all
is also not the answer.

I'd like to point out that the above is not a description of XP. XP is not
about coding without spec work. Indeed, XP demands the most formal kind of
spec possible: customer acceptance tests that execute.

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Robert C. Martin

2004-03-29 05:32:48 UTC

Permalink

Post by debhart
-----Original Message-----
It was about 1984, or perhaps 1985, that a colleague of mine, fed up with
endless metaphysical modelling sessions, was advocating an approach he
called SPACI. This stood for "Stop Pissing About and Code It".
Was this the actual birth of XP?

No, since XP does not adopt that attitude. XP adopts an attitude of care
and craftsmanship.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
***@objectmentor.com
800-338-6716

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Peter Lynch

2004-03-28 06:47:36 UTC

Permalink

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtka/ Ivo Interactive
===========================================================

I agree about OO implementation, it has ended up as the aim rather than the
tool.

But has not OO suffered the same as Agile is suffering - the intent is lost
in a cacophony of words. Words from people who know no more than the words
themselves - with no internal model which allows differentiation between
software choices, usually managers who left their technical areas too early
in the pursuit of success and prestige.

After OO was implemented in C and other mainstreams from models like Eiffel
and Smalltalk, the masses believed that OO was fully defined and implemented
by that model. But before those implementations manifested, the CONCEPT of
OO was being discussed and pursued by small groups, usually in software
bureaux, where conventional development was not an option. The now accepted
definition of OO is one of the many ways the concept could have (and has)
manifested.
I always have had trouble with the OO implementations. I found them less
effective than the techniques I was currently using, and still use. One day,
in the late 80's, I asked a fresh graduate whether he could summarize what
he understood of OO. His answer was "What, not how". I really like that
answer.
Is that not also at the essence of Agile? Manage the technical in such a
way that there is a beneficial interaction between user and developer? What
am I doing, not how will I implement this.

----- Original Message -----
From: "Rick Lutowski" <***@jreality.com>
To: <***@topica.com>
Sent: Sunday, March 28, 2004 2:58 AM
Subject: Re: [AM] Let's call a spade a spade

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAb7u5T4a/ Ivo Interactive
===========================================================

Post by debhart
I'm trying to work out where (or how?) to draw the line myself...

We are about to go on a journey through time and space...

The time is now 1984. The space is an alternate universe
in which the Agile Manifesto was written in 1979. These
messages are all dated 1984 and are being written in the
context of 1984 software technology.

There is this new thing people are talking about. Something
about designing software using objects. Others are talking
about hiding information. Sounds dumb to me -- as a
software maintainer I need more info, not less. People
are supposed to interact, not hide things from each other!
And this thing about designing subroutines to represent
objects sounds very unnatural; everyone knows a subroutine
represents a good 'ol function. Thinking so unnaturally
violates the simplicity principle. And of course, our
customers will never understand it, even if us developers
somehow manage to figure it out. That makes customer
collaberation a lot harder.

So what do we have? Info hiding instead of open interaction,
unnaturally complex code structure, confusing design that
makes cummunication with the customer harder -- this whole
object thing violates a whole slew of our values. I think
us agilers should be against this new object craze as it
clearly is not agile.

What do you think?

..Control of time and space is now being returned to you.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7u5T4f/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 16:45:59 UTC

Permalink

Post by Peter Lynch
I agree about OO implementation, it has ended up as the aim rather than the
tool.

I think it depends on how well one understands OO. Those who
understand it well can, and usually do, use it as a tool. Those
who do not understand it well are sufficiently challenged by
the intricacies of OO that OO itself becomes a goal, diverting
focus from the software problem it is intended to help solve.

Post by Peter Lynch
But has not OO suffered the same as Agile is suffering - the intent is lost
in a cacophony of words. Words from people who know no more than the words

This gets to the next obvious question -- _how_many_ developers are
sufficiently challenged by OO to be adversely affected by it? These
are likely the same ones who get "lost in a cacophony of words."
(Nicely articulated, BTW) A web page that gives one insight into
this "how many" question is http://www.acm.org/sigsoft/SEN/parnas.html

This page is a 1999 interview with David Parnas, the "father of
information-hiding." (Info-hiding one of the two most important
underlying concepts of OO, the other being the idea of modeling
real-world objects.) In this interview, Parnas says

"I don't think that the most promising ideas are on the horizon.
They are already here and have been here for years but are not
being used properly....The biggest payoff will not come from new
research but from putting old ideas into practice and teaching
people how to apply them properly."

It is pretty clear that info-hiding is one of the ideas he is
referring to. He appears to think that a LOT of people are
not using it properly, which implies a widespread lack of
understanding of basic OO concepts.

Thus, one of the founding fathers of OO appears to agree with
your assessment.

Post by Peter Lynch
themselves - with no internal model which allows differentiation between
software choices, usually managers who left their technical areas too early
in the pursuit of success and prestige.

I think the idea of an "internal model" to differentiate software
choices is a VERY important observation. In fact, it is so
important that I have actually developed such a model. It is an
explicit model (that is, capable of being written down), is
customer-centric, and also software quality-centric. It would be
off topic for this thread to explain it here. Maybe in another
posting if there is sufficient interest in the group.

Anyway, excellent observation -- but easier said than done!

Post by Peter Lynch
After OO was implemented in C and other mainstreams from models like Eiffel
and Smalltalk, the masses believed that OO was fully defined and implemented
by that model. But before those implementations manifested, the CONCEPT of
OO was being discussed and pursued by small groups, usually in software
bureaux, where conventional development was not an option. The now accepted
definition of OO is one of the many ways the concept could have (and has)
manifested.

Your implication is that OO as we know it is not the only way to
implement these concepts. Again, one need not look any farther
than Parnas to prove you are right. When Parnas and his team
invented the term "information-hiding", they envisioned it being
applied to three major types of information to facilitate ease of
change of this information:

1. Software interfaces to hardware
2. Design decisions
3. Required behavior

Current OO focuses only on item 2 in the form of data and data structures.

Item 1 is being practiced by operating system developers in the form
of device drivers, but is divorced from mainstream OO. In fact the
OS developers do not consider themselves to be using OO. How
many OS's are written using "OO"? I only know of one -- Steve Job's
NeXT. Maybe there are a few others, but the OS industry as a whole
is still wedded to function design, even though their use of device
drivers to encapsulate hardware interfaces makes them 'just as OO'
as OO (i.e., both encapsulate only one major kind of information
for ease of change.)

Hardly anyone in the industry today even remembers that Parnas said
*requirements* could be encapsulated for ease of change.

So you are clearly right -- over 20 years ago Parnas and his team
drew a roadmap for OO that is far from being met by OO as we know
it today. There is clearly a lot of room for improvement.

<aside>
A NASA Space Station team I was on over 10 years ago developed
a form of OO that addressed all three, but most notably item 3,
requirements. We felt this 'requirements encapsulation' methodology
represented a major advance conceptually over current OO. (You
sure managed to hit my 'hot buttons' with this posting, Peter! :-)
</aside>

Post by Peter Lynch
I always have had trouble with the OO implementations. I found them less
effective than the techniques I was currently using, and still use. One day,

Peter, I'd be interesting in hearing about these better techniques
you are currently using. If you think they are off topic for the
group, please email me personally. Thanks.

Post by Peter Lynch
in the late 80's, I asked a fresh graduate whether he could summarize what
he understood of OO. His answer was "What, not how". I really like that
answer.

Of course, "What, not how" is the traditional answer to the question
"What are requirements?" (a little bit of Jeopardy)

In the context of OO, "What, not how" refers to interfaces. When we
were formulating the requirements encapsulation methodology for NASA,
we discovered the two meanings were actually coincident.

Post by Peter Lynch
Is that not also at the essence of Agile? Manage the technical in such a
way that there is a beneficial interaction between user and developer? What
am I doing, not how will I implement this.

I could not agree more. The requirements encapsulation
methodology does exactly this -- recording requirements
in a manner that permits their encapsulation for ease of
change leads naturally to an improvement in "beneficial
interaction between user and developer."

This, among other things, led me to believe the methodology
was highly consistent with agile principles, However, many
agilists who have looked at the web site or read various
papers about the methodology disagree. I strongly suspect
this is due to a misunderstanding of the methodology. Some
methodologies are difficult to fully comprehend solely from
literature. As in the case of agile and AM, understanding is
best achieved by doing.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-29 05:09:25 UTC

Permalink

Post by Rick Lutowski
Hardly anyone in the industry today even remembers that Parnas said
*requirements* could be encapsulated for ease of change.

[...]

Post by Rick Lutowski
I could not agree more. The requirements encapsulation
methodology does exactly this -- recording requirements
in a manner that permits their encapsulation for ease of
change leads naturally to an improvement in "beneficial
interaction between user and developer."

Could you say more about "how" the requirements are
_effectively_ encapsulated? I've read the material at your
jreality.com website - and have seen the material about treating
requirements as black boxes, and creating software objects
corresponding to the requirements such that there is a 1-1
mapping (and hence "traceability" is automatically attained
from that point onward).

So I see how that attempts to encapsulate a requirement. By the
same token, I can write a class/object and a set of methods,
and I can think I'm doing O-O, but I'm sure we've all seen
examples of code that did this that wants very object-oriented
at all and wasn't very well encapsulated. Just because I use a
class and methods doesn't mean I am automatically successfully
employing encapsulation and abstraction and information hiding,
or that I am attaining high-cohesion and low-coupling, and
am appropriately separating concerns and dependencies at the
appropriate boundaries and scope.

So what do we do that can guarantee that each software
requirement "object" we create will be at the right
granularity, and will 'abstract' the right things and
hide/expose the right things, and that the dependencies
with and upon other things will result in the "good"
properties of high-cohesion and low-coupling and
localization of change-impact and resiliency/maintainability?
Is there more to it than simply making software "objects"
for requirements in the "functional baseline" and for
interfaces and sub-items in the "allocated baseline"
that will ensure these properties?
w
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 18:55:52 UTC

Permalink

Post by Brad Appleton
Could you say more about "how" the requirements are
_effectively_ encapsulated? I've read the material at your
jreality.com website - and have seen the material about treating
requirements as black boxes, and creating software objects
corresponding to the requirements such that there is a 1-1
mapping (and hence "traceability" is automatically attained
from that point onward).

I'd love to answer your question about how to _effectively_
encapsulate requirements. The answer is one short sentence
of about 13 words. Unfortunately, that sentence would be
incomprehensible, sort of like quoting a physics equation
without explaining any of the terms. Even if the terms
were given, they would only be understandable to someone
trained in that branch of physics.

The req encap answer is covered in day 4 of a 5 day course.
This means that understanding the sentence (the "terms of the
equation") requires about 4 day's worth of prerequisite
concepts, techniques, and similar knowledge.

This should not be construed to mean that requirements
encapsulation is difficult. Actually, it's quite easy,
*IF* the requirements are captured properly. How to do
that, and associated concepts and terminology, are the
4 days worth of prerequisite knowledge needed to understand
the answer. (Note: about half of the 4 days is hands-on
lab practice to reinforce learning by doing. So only
about 2 days of book learning. But I have found book
learning by itself without hands-on practice to be
inadequate. Requirements capture and encapsulation is
a skill set, and skills are learned by doing, not just
reading.)

Post by Brad Appleton
So I see how that attempts to encapsulate a requirement. By the
same token, I can write a class/object and a set of methods,
and I can think I'm doing O-O, but I'm sure we've all seen
examples of code that did this that wants very object-oriented
at all and wasn't very well encapsulated. Just because I use a
class and methods doesn't mean I am automatically successfully
employing encapsulation and abstraction and information hiding,
or that I am attaining high-cohesion and low-coupling, and
am appropriately separating concerns and dependencies at the
appropriate boundaries and scope.

Absolutely correct. OO is not just classes, methods, and
objects. For example, make your field data public and you've
just blown OO right out of the water, and all the classes,
methods, and objects might just as well be old-style Fortran.

Conversely, I have used Fortran to implement informnation-hiding
in a passable manner. (When a university Fortran professor
somehow found out about it, he insisted it be published. This
was in '95.)

Point is, programming artifacts, while they might make OO easier,
are not themselves OO. OO is a set of concepts, the most basic
of which can be utilized in ANY language, even assembler.

The requirements encapsulation methodology applies these
basic concepts to requirements. In doing so, it becomes
necessary to formulate requirements quite differently than
the way "the powers that be" are advocating today. Hence
the need for 4 days of additional training to understand
how to better formulate requirements so they are
encapsulatable. After that, actually doing it is easy.

Post by Brad Appleton
So what do we do that can guarantee that each software
requirement "object" we create will be at the right
granularity, and will 'abstract' the right things and
hide/expose the right things, and that the dependencies
with and upon other things will result in the "good"
properties of high-cohesion and low-coupling and
localization of change-impact and resiliency/maintainability?
Is there more to it than simply making software "objects"
for requirements in the "functional baseline" and for
interfaces and sub-items in the "allocated baseline"
that will ensure these properties?

You are hitting on exactly the right things -- high-cohesion,
low coupling, localization of change-impact. Again, it takes
a five day course to explain it all properly wrt requirements.
(This assumes you already have some familiarity with basic OO
and Java, or similar, programming.) A web site is not the
proper venue, as I have found through prior hard experience, so
the details of how to do it, or even how to properly capture
requirements (the more interesting part) are not on the site
at all. The site just covers a few fundamentals, and the fact
that it can be done.

BTW, in case you're just dying to hear the short answer to
the requirements encapsulation question, (or maybe think I'm
just being elusive because it's all vapor), here it is:

"Create one functionality module for each unique stimulus
set of the functionality tree."

Do that correctly and you will have effectively encapsulated
your customer's software requirements.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Jason Gorman

2004-03-29 07:10:54 UTC

Permalink

Post by Rick Lutowski
"Create one functionality module for each unique stimulus
set of the functionality tree."

Or you could encapsulate your requirements as executable (and
self-explanatory) system tests :-)

Jason Gorman
http://www.objectmonkey.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-29 18:24:13 UTC

Permalink

Post by Jason Gorman

Post by Rick Lutowski
"Create one functionality module for each unique stimulus
set of the functionality tree."

Or you could encapsulate your requirements as executable (and
self-explanatory) system tests :-)

Suppose I did that? Suppose for each "requirement" I create
an object that implements a "Requirements Object" interface,
and that instance of the requirement object is responsible
outputting description/explanation of that requirement and
running and executing its tests and presenting the results.

How might that code "evolve" over time in structure assuming
I continually apply "incremental structural modularization"
(e.g., refactoring) as new requirements and information come
in to maintain high cohesion and low coupling and good
encapsulation/localization of these objects?

I have worked in an internal IT shop where "requirements"
were formally captured in the form of use cases, and since
the number of projects being worked on was huge and "good"
IT portfolio management and governance was highly valued,
use-cases where captured in a global database rather than
a project-specific one, and keywords were used to aid
searching, and when a new request came in against a particular
project one could first to some amount of querying to see if
any existing project in the department already had documented
(and maybe even implemented) a similar requirement based on
functional category, bottom-line business functions supported,
actor/role (user-type) category, technologies used/requested,
interacting "agents" (e.g., manual, software, or hardware
systems/events/stimuli) and a few others.

And this usecase-"base" eventually took on a hierarchical
structure, with different kinds of relationships between
use-cases (extends, generalizes, subpart-whole, exception)
and both the relationships and content of and between use-cases
would be "refactored" to support better encapsulation/independence
of the use-cases in usecase-base and localize impact of changes.

So we had what you might call a "use-case" tree which sounds
a lot like a "functionality tree" (actually, it was more like
a forest) and different sets of relationships, actors, related
events, and input-types. And we would "refactor" regularly so
we could more easily identify when a new requirement matched
(and how closely it matched) that of an existing project and
help decide which project (old or new) was the most suitable
one to try and work it, and to allocate funds/materials to in
order to best serve that business function being supported.

How is this the same or different from what Rick describes
as a functionality-tree and a stimulus-set and a functionality
"module"?
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-29 18:07:59 UTC

Permalink

Post by Rick Lutowski

Okay - so, from what little text there is above, and from
your references to Parnas, the following papers immediately
come to mind:
"Specifying Software Requirements for Complex Systems:
New Techniques and their Applications" by Kathryn Heninger
(paper was a result of the SRC project the author worked
with Parnas on)
[BTW - there are some interesting parallels between what is
described in this paper and the goals of FitNesse.org]

"On the Design and Development of Program Families"

"Designing Software for Ease of Extension and Contraction"

"A Procedure for Designing Abstract Interfaces for Device Interface Modules"

"The Modular Structure of Complex Systems"

"Software Aging"
[interestingly enough, "retroactive incremental modularization"
seems to be what is called "refactoring" today with its
buzzword-buddy "emergent design"]

As of 2001, all these papers (and others by Parnas) are available
in the book "Software Fundamentals: Collected papers by David L.
Parnas" and some are even available online at the Software Quality
research Lab at McMaster University that Parnas heads up (tho
he is currently on LOA) at http://www.sqrl.ul.ie/publications.html
(also the paper "Requirements Documentation: A Systematic Approach")

So assume I have knowledge and understanding of these papers,
assume I even have an undergraduate-level understanding of
physics (lets assume two semesters each of kinematics, E&M,
thermodynamics, and maybe high-energy physics and quantum
mechanics) and basic mathematical knowledge of higher-order
multivariate calculus, combinatorics, abstract algebra,
linear algebra, discrete math, probability, and topology,

Rather than "information hiding" in a way that says "I can't
tell you because you don't know enough and don't have the proper
foundation Al background and you have to pay me to take my
training to acquire it", assume instead I'm a well-read software-type
with solid grounding in the above things and knowledge of or at
least access to the body of software engineering publications,
and solid grasp and understanding of object-orientation and
abstraction and encapsulation and separation of concerns,
and separation of interface from implementation, and of
policy from mechanism, etc..

So if you didn't have to talk down to me based on a presumed
lack of knowledge of the above things, what would be a more
peer-to-peer type of descriptive explanation you would use to
talk to someone who knows those things, tho not necessarily your
specific methodology, and how would you describe it to them in
say 100-200 lines of text, and the references you would provide
that are publicly available either online or in available books.

I hereby throw down a challenge to you to do this without hiding
evidence and details behind "you wouldn't understand" and/or
"you have to pay to take my training first" and make an open
and honest attempt to illuminate it here on this list in open
discussion with many other experts with genuine depth and
breadth of understanding in all the above things.
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 21:21:15 UTC

Permalink

Post by Brad Appleton
I hereby throw down a challenge to you to do this without hiding
evidence and details behind "you wouldn't understand" and/or
"you have to pay to take my training first" and make an open
and honest attempt to illuminate it here on this list in open
discussion with many other experts with genuine depth and
breadth of understanding in all the above things.

It certainly was not my intent to talk down to anyone or insult
anyone's intelligence or training, but to paint the picture as
accurately as possible based on my prior experience. Prior
experience to date has shown that written explanations are
necessary but insufficient to understand Freedom. A certain
amount of face-to-face and hands-on seem to be required.

However, since you threw down the gauntlet, I will do the same
and challenge the denizens of this list to learn Freedom based
on written explanations in this forum without exposure to the
face-to-face course. If you all can do this, you will be the
first.

I have always attributed the past failures to the fact that
Freedom involves not just new techniques like functionality
trees, behavior tables, and the like, but an entirely new
mindset wrt requirements. It is probably fair to say it is
a requirements paradigm shift. Paradigm shifts are typically
more challenging to wrap one's mind around than most other
types of material.

However, I am also willing to concede the failures may strictly
lie with me. Perhaps I have simply not found the correct
way to present this material. If that is the case, I may
be the one who learns the most in this exercise by finding
better ways of explaining the material. I do hope this
turns out to be the case.

There is one other thing I will ask of the members of this list.
Assuming we successfully reach our goal of explaining Freedom
so that you all understand it, I will then ask all of you to
give your assessment of how Freedom might best be used in an
agile context or, if it cannot be, then why. I would also
expect an assessment of Freedom wrt AM values and principles
to result from such a discussion.

That is my counter-challenge. Is everyone game? If not,
please speak your mind now.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-29 23:33:44 UTC

Permalink

Post by Rick Lutowski
However, since you threw down the gauntlet, I will do the same
and challenge the denizens of this list to learn Freedom based
on written explanations in this forum without exposure to the
face-to-face course. If you all can do this, you will be the
first.

I'll certainly give it my best shot, as I've been struggling with
the notion of "encapsulating" and "refactoring" of requirements
for a year or so (tho in my case, I think the result was not
just for localizing code-impact, but also for minimizing impact
to other-requirements and/or identifying the most appropriate
business level/scope at which to leverage the change.

Post by Rick Lutowski
There is one other thing I will ask of the members of this list.
Assuming we successfully reach our goal of explaining Freedom
so that you all understand it, I will then ask all of you to
give your assessment of how Freedom might best be used in an
agile context or, if it cannot be, then why. I would also
expect an assessment of Freedom wrt AM values and principles
to result from such a discussion.
That is my counter-challenge. Is everyone game? If not,
please speak your mind now.

I'm game (modulo time-constraints imposed by my needing to
keep my "day job" :-)
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Robert C. Martin

2004-03-29 05:35:55 UTC

Permalink

Post by debhart
-----Original Message-----
(Info-hiding one of the two most important
underlying concepts of OO, the other being the idea of modeling
real-world objects.)

I think this view of OO is badly skewed and leads to the inappropriate
usages and endless arguments.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
***@objectmentor.com
800-338-6716

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Peter Lynch

2004-03-29 06:04:46 UTC

Permalink

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtka/ Ivo Interactive
===========================================================

Rick,
Thankyou for your thoughts. I am still reading them, but I will have to
continue reading later.
I just wanted to ask, before posting a reply to the forum - what part of
NASA did you work in. I worked for AWA Defence Industries where I wrote a
configuration management system in 1988/9. The contact with the NASA/DOD way
of designing and building a missile profoundly affected my view of software
development. And I was already out on a limb.

Regarding your and my individual, personal ideas on the software process,
they most likely should be aired, and AM threads are an appropriate place to
air them. It is a very intellectually open place form what I can see.

Thanks again for the kind words, and I hope to hear from you.

Peter

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 19:18:38 UTC

Permalink

Post by Peter Lynch
Rick,
Thankyou for your thoughts. I am still reading them, but I will have to
continue reading later.
I just wanted to ask, before posting a reply to the forum - what part of
NASA did you work in. I worked for AWA Defence Industries where I wrote a
configuration management system in 1988/9. The contact with the NASA/DOD way
of designing and building a missile profoundly affected my view of software
development. And I was already out on a limb.
Regarding your and my individual, personal ideas on the software process,
they most likely should be aired, and AM threads are an appropriate place to
air them. It is a very intellectually open place form what I can see.
Thanks again for the kind words, and I hope to hear from you.

Peter,

Not sure if you intended this to go to the group or not,
Your reply button must work like mine ;-) No harm done
either way.

I was at JSC (Lockheed, then Grumman) from 88-95 when
the budget cut ax hit us. Wiped out our whole Cray
support team -- replaced with a Windows sys ad to save
money!! (now you know why shuttles crash)
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Robert C. Martin

2004-03-29 05:26:48 UTC

Permalink

Post by debhart
-----Original Message-----
We are about to go on a journey through time and space...

[clever little story snipped]

Post by debhart
What do you think?

I think you've discovered why the standard definition of OO development is
so skewed.

What if we presented the following to the 1984 agilers:

1. OO technology allows us to better manage the coupling between modules by
formalizing the old technique of using jump tables in data structures.

2. Using OO language, we can avoid the clumsy and dangerous use of pointers
to functions in order to break critical dependencies. The ease and safety
of the decoupling techniques mean that we can apply them throughout our code
instead of just in critical areas.

3. The wholesale use of these decoupling techniques throughout every module
in our systems will allow us to more easily modify our code, and will
greatly enhance our ability to refactor.

4. The decoupling tools will also make it much easier to test modules
independently of each other allowing us to write much more granular unit
tests.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
***@objectmentor.com
800-338-6716

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Robert C. Martin

2004-03-29 05:18:24 UTC

Permalink

Post by debhart
-----Original Message-----
I'm trying to work out where (or how?) to draw the line myself...

I think the minimum set of agile practices might be:

1. Short cycles (30 days or shorter)
2. Daily customer/business involvement.
3. Test Driven Development
4. Planning based on business value and scope management.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
***@objectmentor.com
800-338-6716

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Jason Gorman

2004-03-29 07:19:17 UTC

Permalink

Post by Robert C. Martin
1. Short cycles (30 days or shorter)
2. Daily customer/business involvement.
3. Test Driven Development
4. Planning based on business value and scope management.

Rick Lutowski

2004-03-29 19:45:58 UTC

Permalink

Post by Robert C. Martin

Post by debhart
I'm trying to work out where (or how?) to draw the line myself...

1. Short cycles (30 days or shorter)

Probably reasonable in most cases, but must consider the
customer's release management needs as well. Not all
customers may need or want max 30 day cycles. Release cycle
time should be set in consultation with the customer, not a
priori by a methodology.

Post by Robert C. Martin
2. Daily customer/business involvement.

Sure, if the customer is willing and able.
Might be tough with offshoring and DoD work for example.
Again, customer's needs and willingness govern.

Post by Robert C. Martin
3. Test Driven Development

Agree with the goal (a test for each function) but
NOT the mechanism (test-DRIVEN development).
There are better mechanisms.

Post by Robert C. Martin
4. Planning based on business value and scope management.

Probably. But there's that darn customer again,
maybe with different ideas.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-29 17:06:57 UTC

Permalink

Post by Rick Lutowski

Post by Robert C. Martin

Post by debhart
I'm trying to work out where (or how?) to draw the line myself...

1. Short cycles (30 days or shorter)

I don't think Robert necessarily meant release cycles when he
used "cycles" above. I think he meant iterations (of which there
may be many within a release). The customer negotiates when
they will take/accept a release. And there might be several
iterations within a release. And ideally, even tho the customer
may not take delivery at the end of each iteration, they still
negotiate the contents and priorities of work to be done at
the start of an iteration (30 days or less) and will evaluate
and give feedback on the result of each iteration (even tho they
may not have it delivered/installed to them), and are available to
quickly resolve questions/issues/priorities during the iteration
itself.

Again this hinges upon one of the other items about having
close customer collaboration at the beginning and and of
each iteration as well as timely accessibility and decision
resolution/turnaround time during the iteration. As you stated,
this ideal is not always attainable.
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

p***@aol.com

2004-03-27 15:22:59 UTC

Permalink

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtka/ Lorillard
===========================================================

In a message dated 3/27/2004 5:57:07 AM Pacific Standard Time,
***@hartmann.net writes:
To my mind, there should be no shame in calling something "partially
Agile". To me, it indicates integrity and underlines the importance of
the values of the Manifesto.
I like to think that there is value in applying Agile practices, or even just
an Agile "mindset" in projects being conducted in accordance with virtually
any methodology. In fact, if history is any guide, agility of the sort we
practice is likely to be spread through incremental use and acceptance, as the
"unbelievers" become either Desperate or Daring enough to try it, even in an
abbreviated form. Also, as long as there are those who decry the agile approach
because of its purported scalability issue, adoption of it will be slow. Perhaps
the ultimate victory of the agile approach will be the incorporation of its
principles in many other methodologies. IMHE, I've found that applying the
spirit of the Agile Manifesto, if not the letter, yields substantial improvements
to any development methodology.

I have often described my clients as either desperate or daring. In virtually
every case, the application of tradition development methods was not an
option; there was simply not enough time or other resources to use them. Success in
these projects, against what seemed like significant odds, impressed their
sponsors and other participants enough to consider applying the agile approach
in subsequent projects. I don't recall any of them doing so, however, "to the
letter". Nonetheless, IMHO, they're "on their way". In the playground of my
mind, I see those whose attitudes and practices remain rooted in traditional
software development methodologies being overrun from behind by the increasing
number of "Closet Agileers" who, for whatever reason, have elected to apply the
principles of the Agile Manifesto to the extent possible in the projects in
which they participate. If "building better software, faster" is the objective, I
can think of nothing better than legions of developers, practitioners of some
form of agile methodology or philosophy or other, throwing bricks at each
other across the "methodological divides" proclaiming the superiority of their
own particular brand of "agile" as the pinnacle of achievement. If we can't
predict the future when building software, how can we presume to be any better at
it regarding the future of Agile? For my money, the future of Agile is
assured, simply "by virtue of its virtues". Agility as we know it was born as a
solution to a chronic and intolerable problem: bad software due to bad process. If
there are problems with the current view of Agile (like the aforementioned
scalability issue), it is likely that some agile practitioner(s) will eventually
apply the agile philosophy to the problem and come up with an agile solution.

IMHO, standing in he way of widespread adoption of agile principles is pure
folly. Resistance to it is largely the result of the widespred and ingrained
conservatism of the vast majority of developers and the audiences they serve. It
is entirely conceiveable, from my perspective, that had our predecessors (I'm
talking pre-Agile, here) paid more attention to the growing number of
failing, out of control, chaotic development projects, and "stuck to their knitting"
rather than embraced their imagined "Gods of the Enterprise" status, the
current presidential race would be devoid of one of its "hot topics", software
outsourcing. Does anyone really think that this practice was the result of
anyone's notion that the software would be better by being produced off-shore? Think
of it this way: if there is a major likelihood that the software being
developed just might not do what it's intended to do when the time or money runs out
(according to some estimates, a virtual certainty), then why not spend as
little as possible on it's development? If the medical profession (another hotbed
of professional conservatism) had the same record of achievement as software
developers, our health would largely be in the hands of shamans.

FMM, software developers and their beneficieries are standing on the
theshhold of a new reality in the way software is designed and built, a reality in
which I believe "Agileers" will play a major role in its evolution. If I live to
be a hundred, it will probably be due to my insatiable curiosity rgarding how
all this turns out.

Agile forever.

Regards,

Pete

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

p***@aol.com

2004-03-27 18:01:52 UTC

Permalink

Steven Gordon

2004-03-29 13:44:09 UTC

Permalink

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtka/ Ivo Interactive
===========================================================

Rick,

Is it possible to identify a "unique stimulus set", let alone "the functionality tree", without knowing all of your customer's software requirements? What happens when a new requirement or requirement change comes along later that effectively straddles 2 or more stimulus sets that were previously unique? I have found that approaches that depend on knowing all the requirements at the beginning of a project are delusional in most domains, and are generally resistant to change.

What happens when a "unique stimulus set of the functionality tree" leads to a "functionality module" that is so large that further decomposition and encapsulation is highly desirable?

Steven Gordon
http://sf.asu.edu/

-----Original Message-----
From: Rick Lutowski [mailto:***@jreality.com]
Sent: Mon 3/29/2004 11:55 AM
To: ***@topica.com
Cc:
Subject: Re: [AM] Requirements Encapsulation

"Create one functionality module for each unique stimulus
set of the functionality tree."

Do that correctly and you will have effectively encapsulated
your customer's software requirements.

--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-29 18:42:59 UTC

Permalink

Post by Steven Gordon
Is it possible to identify a "unique stimulus set", let alone "the functionality tree",
without knowing all of your customer's software requirements?

The basic idea of information-hiding is to identify things that have
a high probability of change, and encapsulate those things to make
the implementing code easier to change later. If requirements (or
data structures, or hardware) never changed, then there would be no
need to encapsulate them.

So what is the probability of change for requirements?

I have a paper that indicates 60-80% of all changes during the
maintenance phase of the software life cycle are requirements changes.
If this is true, then requirements are THE most volatile of all
software information. Requirements therefore should have the highest
priority for encapsulation, and should result in the highest financial
payback to the customer of any application of the information-hiding
approach.

So the answer to your question is an unqualified 'yes.' Freedom
fully expects the functionality tree will be incomplete or
otherwise need to change in the future. This in no way hampers
its development, or the development of the software. Quite the
opposite. Freedom specifies techniques for writing code which
should make future changes to the code easier when the functionality
tree changes.

Note that encapsulation doesn't make it easier to change
the requirements spec, but rather the code that implements it.
Encapsulation is a code-centric concept. But it relies on proper
specification as a prerequisite. This why we have OO design --
it wasn't possible to encapsulate design decisions like data
structures using the old functional design approaches. Design
specification had to change.

Likewise, requirements encapsulation requires new approaches to
requirements specification. It is quite ironic that these new
requirements spec approaches are NOT equivalent to OOA. OOA is just
as inappropriate for requirements encapsulation as functional
requirements! That may sounds oxymoronic, but it's true. Freedom's
approach to requirements specification has nothing to do with
either OOA (object requirements) or Use Cases (functional
requirements). If anything, it is closer to Use Cases (depending
on how one defines "Use Cases"; I have encountered at least two
different views of what they are.) In reality, tho, it is not like
either. A requirements spec that permits encapsulation is neither
functional nor OO, it is external interface-centric.

Post by Steven Gordon
What happens when a new requirement or requirement change comes along later that
effectively straddles 2 or more stimulus sets that were previously unique?

A requirement will never straddle two stimulus sets. Changes that
affect multiple stimulus sets are considered multiple requirements
changes, not a single requirements change. Requirements have
sufficiently high granularity under Freedom to make this a non-issue.

It is also worth pointing out that requirements are NOT
recorded using natural language prose (i.e., sentences) in
Freedom. Parnas once wrote

"PROSE IS THE SIGN OF AN ERROR" (his caps)

in a requirements spec. Freedom follows this guidance and
totally avoids prose for requirements capture. This also
helps avoid "straddling" and similar sticky issues that
can easily result from using prose.

Post by Steven Gordon
I have found that approaches that depend on knowing all the requirements at the beginning of a > project are delusional in most domains, and are generally resistant to change.

As mentioned above, Freedom in no way demands or expects all
requirements to be defined up front. The whole approach is
predicated on the assumption that requirements WILL change
throughout the entire life of the software, including during
development. This includes all ways that they might change:
add, modify, delete. Freedom handles all these requirements
change possibilities equally cleanly.

Post by Steven Gordon
What happens when a "unique stimulus set of the functionality tree" leads to a "functionality module" that is so large that further decomposition and encapsulation is highly desirable?

The granularity of requirements is sufficiently fine that overly
large requirements encapsulation classes never result when the
functionality tree and its constituent stimulus sets are specified
properly. Various well-established rules of thumb come into play
in this regard. One of the better known and most important is the
Rule of 7+-2. Thus, the problem you postulate is not a problem
in practice. If it did become a problem due to poor functionality
tree specification, the users would probably be the first to drag
your tail to the carpet about it. So the users act as another
sanity check against this happening.

Good questions. They show an appreciation of important issues,
and a healthy constructive skepticism for Freedom's ability to
address them. It's a pleasure answering such questions. I
hope you found the answers informative. Thanks very much, Steven.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Peter Lynch

2004-03-30 02:03:24 UTC

Permalink

Post by Steven Gordon
Is it possible to identify a "unique stimulus set", let alone "the functionality tree",
without knowing all of your customer's software requirements?

Post by Steven Gordon
What happens when a new requirement or requirement change comes along later that
effectively straddles 2 or more stimulus sets that were previously unique?

Post by Steven Gordon
I have found that approaches that depend on knowing all the requirements

at the beginning of a > project are delusional in most domains, and are
generally resistant to change.

As mentioned above, Freedom in no way demands or expects all
requirements to be defined up front. The whole approach is
predicated on the assumption that requirements WILL change
throughout the entire life of the software, including during
development. This includes all ways that they might change:
add, modify, delete. Freedom handles all these requirements
change possibilities equally cleanly.

Post by Steven Gordon
What happens when a "unique stimulus set of the functionality tree" leads

to a "functionality module" that is so large that further decomposition and
encapsulation is highly desirable?

The granularity of requirements is sufficiently fine that overly
large requirements encapsulation classes never result when the
functionality tree and its constituent stimulus sets are specified
properly. Various well-established rules of thumb come into play
in this regard. One of the better known and most important is the
Rule of 7+-2. Thus, the problem you postulate is not a problem
in practice. If it did become a problem due to poor functionality
tree specification, the users would probably be the first to drag
your tail to the carpet about it. So the users act as another
sanity check against this happening.

Good questions. They show an appreciation of important issues,
and a healthy constructive skepticism for Freedom's ability to
address them. It's a pleasure answering such questions. I
hope you found the answers informative. Thanks very much, Steven.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7u5T4f/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-30 01:54:56 UTC

Permalink

Post by Peter Lynch
"The basic idea of information-hiding is to identify things that have
a high probability of change, and encapsulate those things to make
the implementing code easier to change later. If requirements (or
data structures, or hardware) never changed, then there would be no
need to encapsulate them."
I reckon this is at the essence of agile. Encapsulation has many
advantages, but I have found that the view which produces the easiest to
maintain systems is semantic clarity.
If the code "says" what it is doing, it is easier to understand. And easier
to maintain.

Agree that clarity is also important, which is why I started
documenting my Fortran code with loads of descriptive
comments back in the '80s. Never regretted it. Meaningful
variable names, method names and the like are also important.
Good maintainability is the result of many factors, not just
one technique like info-hiding or OO.

I would add that clear requirements and design specs are also
invaluable to a maintainer. Of course, there is always the
problem of keeping these docs or specs up to date with the code.
Probably the best way to do this is a toolset that can auto-
generate these specs and docs from the code, or the code from
the specs. So far, we aren't quite there yet. I think this
is the "multiple view" idea of AM (but somebody correct me if
I'm wrong because I'm still learning about AM).
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

McGovern, Patrick J

2004-03-29 21:52:16 UTC

Permalink

Post by debhart
-----Original Message-----
Sent: Monday, March 29, 2004 4:21 PM
Subject: Re: [AM] Requirements Encapsulation
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAb4F8dda/ Crazy Aaron Enterprises
===========================================================

It certainly was not my intent to talk down to anyone or insult
anyone's intelligence or training, but to paint the picture as
accurately as possible based on my prior experience. Prior
experience to date has shown that written explanations are
necessary but insufficient to understand Freedom. A certain
amount of face-to-face and hands-on seem to be required.
However, since you threw down the gauntlet, I will do the same
and challenge the denizens of this list to learn Freedom based
on written explanations in this forum without exposure to the
face-to-face course. If you all can do this, you will be the
first.
I have always attributed the past failures to the fact that
Freedom involves not just new techniques like functionality
trees, behavior tables, and the like, but an entirely new
mindset wrt requirements. It is probably fair to say it is
a requirements paradigm shift. Paradigm shifts are typically
more challenging to wrap one's mind around than most other
types of material.
However, I am also willing to concede the failures may strictly
lie with me. Perhaps I have simply not found the correct
way to present this material. If that is the case, I may
be the one who learns the most in this exercise by finding
better ways of explaining the material. I do hope this
turns out to be the case.
There is one other thing I will ask of the members of this list.
Assuming we successfully reach our goal of explaining Freedom
so that you all understand it, I will then ask all of you to
give your assessment of how Freedom might best be used in an
agile context or, if it cannot be, then why. I would also
expect an assessment of Freedom wrt AM values and principles
to result from such a discussion.
That is my counter-challenge. Is everyone game? If not,
please speak your mind now.
--
Rick Lutowski
Principal, JReality
http://www.jreality.com
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAb4F8ddf/ Ivo Interactive
===========================================================
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

Rick Lutowski

2004-03-30 02:51:35 UTC

Permalink

Post by McGovern, Patrick J
I'll certainly pick up your gauntlet. I'm sure I'm not alone in this
I'll certainly give it my best shot, as I've been struggling with

Well, that's two 'for' and zero 'against.' Will assume the
silent majority is 'for' (or at least neutral) and proceed.

Let's start where we left off -- with the one sentence
description of req encap:

"Create one functionality module for each unique stimulus
set of the functionality tree."

This begs explanation of the following:

* stimulus sets
* functionality trees
* unique (a reference to requirements reuse)
* functionality modules

The sentence could just as accurately be written:

"Create one functionality module for each unique behavior table."

So we need to cover:

* behavior tables

And underlying everything is the question "What are requirements?"
which is answered by:

* concept models
* definition of requirements

That should be a minimum starter set. Will add more if
questions and other feedback indicate a need.

The logical progression is:

* concept models
* definition of requirements
* stimulus sets
* functionality trees
* unique (requirements reuse)
* behavior tables
* functionality modules

We will cover one topic at a time, and will move on to the
next after all questions and comments about the current topic
are addressed. That way hopefully we won't loose anyone.
Just to be tidy, will start the first topic, concept models,
in a separate email.

If anyone has any suggestions for improving for this process,
quite possible given we have other instructors on the list,
please let me know.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Brad Appleton

2004-03-30 06:57:30 UTC

Permalink

Post by Rick Lutowski
Well, that's two 'for' and zero 'against.' Will assume the
silent majority is 'for' (or at least neutral) and proceed.

Many thanks Rick! Glad to see the conversation flowing. Might I suggest perhaps at most 2-3 "lecture material" type postings in a given week and the remainder of postings that week might perhaps be replies to questions and comments? (and obviously pick-up or ease-up the pace based upon feedback from the resulting 'traffic" :-)
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-03-30 17:17:46 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

Post by Brad Appleton
Many thanks Rick! Glad to see the conversation flowing. Might I suggest perhaps at most 2-3 "lecture material" type postings in a given week and the remainder of postings that week might perhaps be replies to questions and comments? (and obviously pick-up or ease-up the pace based upon feedback from the resulting 'traffic" :-)

I will try to avoid posting more frequently than the
group can absorb. However, I will be depending on
comments and questions to guide this determination,
so please make yourself heard!

Am also thinking about throwing in some simple
exercises to reinforce the concepts by some hands-on,
for those who want to get the idea better and have
the time. Any thoughts on that?

Due partly to the change to yahoo, but mostly to the
fact that I have a competing commitment tonight, the
first Freedom topic posting will not be until
tomorrow (Wed).

Will be out all tonight. Catch you all tomorrow.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Peter Lynch

2004-03-30 12:21:18 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtka/ Lorillard
===========================================================

Rick

I am pleased that you took that attitude to the objections..

Although I can understand Brad's objection. The topic appears long and
intricate, and probably warrants a Wiki or something.

There is a big hole in the industry, and it is due to our long-term lack of
introspection. I think anything that successfully reassesses the development
process in a different light is worth investigating in detail. But where
would it stop?

Call it apple-polishing if you like. But that would be an indication of
'premature management syndrome'. You know - the ones who went straight to
management.

I am very interested in this 'requirements driven' design. Is it the same
as 'needs driven'? That certainly requires some very agile development to
achieve. Is the interpretataion you have of requirements driven founded in
configuration management. (If not, why not?). Is configuration management
used here the accounting system for design?

Peter

----- Original Message -----

From: "Rick Lutowski" <***@jreality.com>
To: <***@topica.com>
Sent: Tuesday, March 30, 2004 12:51 PM
Subject: Re: [AM] Requirements Encapsulation

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAb7u5T4a/ Ivo Interactive
===========================================================

Post by McGovern, Patrick J
I'll certainly pick up your gauntlet. I'm sure I'm not alone in this
I'll certainly give it my best shot, as I've been struggling with

Well, that's two 'for' and zero 'against.' Will assume the
silent majority is 'for' (or at least neutral) and proceed.

Let's start where we left off -- with the one sentence
description of req encap:

"Create one functionality module for each unique stimulus
set of the functionality tree."

This begs explanation of the following:

* stimulus sets
* functionality trees
* unique (a reference to requirements reuse)
* functionality modules

The sentence could just as accurately be written:

"Create one functionality module for each unique behavior table."

So we need to cover:

* behavior tables

And underlying everything is the question "What are requirements?"
which is answered by:

* concept models
* definition of requirements

That should be a minimum starter set. Will add more if
questions and other feedback indicate a need.

The logical progression is:

* concept models
* definition of requirements
* stimulus sets
* functionality trees
* unique (requirements reuse)
* behavior tables
* functionality modules

We will cover one topic at a time, and will move on to the
next after all questions and comments about the current topic
are addressed. That way hopefully we won't loose anyone.
Just to be tidy, will start the first topic, concept models,
in a separate email.

If anyone has any suggestions for improving for this process,
quite possible given we have other instructors on the list,
please let me know.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7u5T4f/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Richard Fisher

2004-04-04 22:35:41 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Sign up to get FREE information from leading colleges!
Compare degrees, admissions, financial aid and more.
Study your career education options at
Collegeinformation.info.
http://click.topica.com/caab6aibUrKDAbWnbtka/ College Info
===========================================================

Rick,

I am always interested in requirements techniques. Especially anything that
helps to define what a "requirement" is and how to capture them in a way
that: Is understandable to business folks and their management, AND readily
usable by developer folks to produce high quality software.

As an instructor I like the approach we are taking - backward chaining. We
started with the end product... your statement. Now we will work backwards
learning the concepts that make that statement meaningful. Since we will be
working in a linear fashion, I might suggest Mile Markers along the way to
refresh where we are with respect to the original statement. Something that
put the current topic into that context (sort of like the hierarchical
heading list at the top of a detailed web page).

Looking forward to an interesting thread.

Rick Fisher
Instructor/Consultant - Modeling, Methods, Proj Mgmt, Facilitation

----- Original Message -----
From: "Rick Lutowski" <***@jreality.com>
To: <***@topica.com>
Sent: Monday, March 29, 2004 10:51 PM
Subject: Re: [AM] Requirements Encapsulation

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbVF19Za/ Ivo Interactive
===========================================================

Post by McGovern, Patrick J
I'll certainly pick up your gauntlet. I'm sure I'm not alone in this
I'll certainly give it my best shot, as I've been struggling with

Well, that's two 'for' and zero 'against.' Will assume the
silent majority is 'for' (or at least neutral) and proceed.

Let's start where we left off -- with the one sentence
description of req encap:

"Create one functionality module for each unique stimulus
set of the functionality tree."

This begs explanation of the following:

* stimulus sets
* functionality trees
* unique (a reference to requirements reuse)
* functionality modules

The sentence could just as accurately be written:

"Create one functionality module for each unique behavior table."

So we need to cover:

* behavior tables

And underlying everything is the question "What are requirements?"
which is answered by:

* concept models
* definition of requirements

That should be a minimum starter set. Will add more if
questions and other feedback indicate a need.

The logical progression is:

* concept models
* definition of requirements
* stimulus sets
* functionality trees
* unique (requirements reuse)
* behavior tables
* functionality modules

We will cover one topic at a time, and will move on to the
next after all questions and comments about the current topic
are addressed. That way hopefully we won't loose anyone.
Just to be tidy, will start the first topic, concept models,
in a separate email.

If anyone has any suggestions for improving for this process,
quite possible given we have other instructors on the list,
please let me know.

--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbVF19Zf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
Your opinion counts! Were conducting a survey for a
computer service/repair company. When you complete our
survey, you will also be entered into a drawing for one of
ten $100 prizes. Just click
http://click.topica.com/caab6PibUrKDAbWnbtkf/ Val Rad
===========================================================
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Rick Lutowski

2004-04-05 01:45:41 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.

===========================================================
Let University of Phoenix make 2004 your year. Evening,
weekend or FlexNet� classes � over 130 locations. Look
into our programs and get the degree that gets you going!
http://click.topica.com/caab6aBbUrKDAbWnbtka/ UOP
===========================================================

Post by Richard Fisher
I am always interested in requirements techniques. Especially anything that
helps to define what a "requirement" is and how to capture them in a way
that: Is understandable to business folks and their management, AND readily
usable by developer folks to produce high quality software.

Richard,

I think your above message and Post #2 crossed in the email stream.

Post #2 begins to answer how Freedom's approach to requirements
strives to do exactly the things you mention above. As outlined
in Post #1, it will take about half dozen posts to cover the key
aspects of the approach.

Post by Richard Fisher
As an instructor I like the approach we are taking - backward chaining. We
started with the end product... your statement. Now we will work backwards
learning the concepts that make that statement meaningful. Since we will be
working in a linear fashion, I might suggest Mile Markers along the way to
refresh where we are with respect to the original statement. Something that
put the current topic into that context (sort of like the hierarchical
heading list at the top of a detailed web page).

Backward chaining appears to be predicated on being given requirements
stated in natural language prose, as it appears from the above to be an
approach to semantic analysis of natural language. At least that's
how I'm reading it. The structural organization you describe sort of
reminds me of sentence diagramming, although it clearly goes beyond that.

As long as requirements continue to be written in prose, I would think
that approaches such as backward chaining may have much merit as a way
of reducing ambiguity and increasing understanding of the requirements.
However, as you may have read by now, Freedom changes the ball field
by pulling the carpet out from under prose (as strongly advocated by
Parnas).

If I am in error about backward chaining and it is not specific to
prose requirements, then please elaborate more on the approach as
I obviously missed something important.

Post by Richard Fisher
Looking forward to an interesting thread.

Appreciate your interest, and look forward to your additional comments.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Your opinion counts! We�re conducting a survey for a
computer service/repair company. When you complete our
survey, you will also be entered into a drawing for one of
ten $100 prizes. Just click
http://click.topica.com/caab6PVbUrKDAbWnbtkf/ Val Rad
===========================================================
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Scott Ambler

2004-04-05 11:03:31 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Your opinion counts! We�re conducting a survey for a
computer service/repair company. When you complete our
survey, you will also be entered into a drawing for one of
ten $100 prizes. Just click
http://click.topica.com/caab6PVbUrKDAbWnbtka/ Val Rad
===========================================================

Thanks.

Instead of responding to this list, instead respond to
***@yahoogroups.com.

- Scott
====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

===========================================================
Bounces like rubber! Shatters like ceramic! Discover Crazy
Aaron's Thinking Putty in grown up handfuls. It's the
creativity unleashing, mood enhancing desk toy!
http://click.topica.com/caab593bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Joel Karafin

2004-03-30 05:00:05 UTC

Permalink

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtka/ Ivo Interactive
===========================================================

Rick,

I'm in, too. Special request: Don't skimp on the definitions. My math
background has made me used to a definitions/axioms/theorem ordering. And I
find that with good semantic grounding, I can usually climb Mount Esoterica.
You might start with "Freedom." No one has mentioned whether it's a
concept, a practice, a book, or a product.

-JCK

-----Original Message-----
From: McGovern, Patrick J [mailto:***@unisys.com]
Sent: Monday, March 29, 2004 1:52 PM
To: ***@topica.com
Subject: RE: [AM] Requirements Encapsulation

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7yabea/ Lorillard
===========================================================

Rick,

I'll certainly pick up your gauntlet. I'm sure I'm not alone in this group
in my experience that during my career I've been required to pickup some
pretty esoteric subjects simply from reading. There is often a training
budget but it is always limited and if the money isn't the limit then the
time away from productive work is the limitation. So fire away. I'll try to
wrap my mind around it.

-pjm-

"did i understand your question, man?" - Bob Dylan

Post by debhart
-----Original Message-----
Sent: Monday, March 29, 2004 4:21 PM
Subject: Re: [AM] Requirements Encapsulation
===========================================================
**** Bounces like rubber! Shatters like ceramic! **** Discover Crazy
Aaron's Thinking Putty in grown up handfuls. It's the creativity
unleashing, mood enhancing desk toy!
http://click.topica.com/caab5n2bUrKDAb4F8dda/ Crazy Aaron Enterprises
===========================================================

Post by Brad Appleton
I hereby throw down a challenge to you to do this without hiding
evidence and details behind "you wouldn't understand" and/or "you
have to pay to take my training first" and make an open and honest
attempt to illuminate it here on this list in open discussion with
many other experts with genuine depth and breadth of understanding
in all the above things.

It certainly was not my intent to talk down to anyone or insult
anyone's intelligence or training, but to paint the picture as
accurately as possible based on my prior experience. Prior experience
to date has shown that written explanations are necessary but
insufficient to understand Freedom. A certain amount of face-to-face
and hands-on seem to be required.
However, since you threw down the gauntlet, I will do the same and
challenge the denizens of this list to learn Freedom based on written
explanations in this forum without exposure to the face-to-face
course. If you all can do this, you will be the first.
I have always attributed the past failures to the fact that Freedom
involves not just new techniques like functionality trees, behavior
tables, and the like, but an entirely new mindset wrt requirements.
It is probably fair to say it is a requirements paradigm shift.
Paradigm shifts are typically more challenging to wrap one's mind
around than most other types of material.
However, I am also willing to concede the failures may strictly lie
with me. Perhaps I have simply not found the correct way to present
this material. If that is the case, I may be the one who learns the
most in this exercise by finding better ways of explaining the
material. I do hope this turns out to be the case.
There is one other thing I will ask of the members of this list.
Assuming we successfully reach our goal of explaining Freedom so that
you all understand it, I will then ask all of you to give your
assessment of how Freedom might best be used in an agile context or,
if it cannot be, then why. I would also expect an assessment of
Freedom wrt AM values and principles to result from such a discussion.
That is my counter-challenge. Is everyone game? If not, please speak
your mind now.
--
Rick Lutowski
Principal, JReality
http://www.jreality.com
===========================================================
Are you looking for savings on products you use everyday? Visit
Quality Health today and see the coupons, free samples and special
offers our members enjoy each and everyday.
http://click.topica.com/caab3ozbUrKDAb4F8ddf/ Ivo Interactive
===========================================================
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

Tina Erwee

2004-03-30 09:29:08 UTC

Permalink

Post by debhart
-----Original Message-----
Sent: 30 March 2004 04:52
Subject: Re: [AM] Requirements Encapsulation
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAb7hSOoa/ Ivo Interactive
===========================================================

Post by McGovern, Patrick J
I'll certainly pick up your gauntlet. I'm sure I'm not alone in this
I'll certainly give it my best shot, as I've been struggling with

Well, that's two 'for' and zero 'against.' Will assume the
silent majority is 'for' (or at least neutral) and proceed.
Let's start where we left off -- with the one sentence
"Create one functionality module for each unique stimulus
set of the functionality tree."
* stimulus sets
* functionality trees
* unique (a reference to requirements reuse)
* functionality modules
"Create one functionality module for each unique behavior table."
* behavior tables
And underlying everything is the question "What are requirements?"
* concept models
* definition of requirements
That should be a minimum starter set. Will add more if
questions and other feedback indicate a need.
* concept models
* definition of requirements
* stimulus sets
* functionality trees
* unique (requirements reuse)
* behavior tables
* functionality modules
We will cover one topic at a time, and will move on to the
next after all questions and comments about the current topic
are addressed. That way hopefully we won't loose anyone.
Just to be tidy, will start the first topic, concept models,
in a separate email.
If anyone has any suggestions for improving for this process,
quite possible given we have other instructors on the list,
please let me know.
--
Rick Lutowski
Principal, JReality
http://www.jreality.com
===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7hSOof/ Lorillard
===========================================================
For more information about AM, visit the Agile Modeling Home
Page at www.agilemodeling.com

Philippe Back (High Octane)

2004-03-30 09:53:00 UTC

Permalink

Post by McGovern, Patrick J
I'll certainly pick up your gauntlet. I'm sure I'm not alone in this
I'll certainly give it my best shot, as I've been struggling with

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbVZCKif/ Crazy Aaron Enterprises
===========================================================

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

i***@prnewswire.co.uk

2004-03-30 12:13:00 UTC

Permalink

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

Return Receipt

Your RE: [AM] Requirements Encapsulation
document
:

was Idris Ahmad/IT/LN/UK/PRNewswire
received
by:

at: 30/03/2004 13:17:18

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

p***@aol.com

2004-03-30 13:34:35 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtka/ Ivo Interactive
===========================================================

Rick:

Sounds interesting. Let 'er rip!

Regards,

Pete

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

a***@ig.com.br

2004-03-30 15:18:28 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

Return Receipt

Your RE: [AM] Requirements Encapsulation
document
:

was Arisio Costa/Arisio Costa
received
by:

at: 30/03/2004 12:18:28

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtkf/ Ivo Interactive
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------

Sukanta Baliarsingh

2004-04-05 15:17:45 UTC

Permalink

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
INSTANT CAR INSURANCE QUOTE! Save time, save money, and
get the best deal. Get quote, buy, and print insurance
cards online!
http://click.topica.com/caab599bUrKDAbWnbtka/ Insurance4usa.com
===========================================================

Hi,

I am looking for some good study material on FDD (Feature Driven
Development). Kindly let me know if you know any web site.

Thanks in advance,
Sukanta

-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: Monday, April 05, 2004 6:04 AM
To: ***@topica.com
Subject: [AM-Old List] Please Stop Posting to this list

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Your opinion counts! We're conducting a survey for a
computer service/repair company. When you complete our
survey, you will also be entered into a drawing for one of
ten $100 prizes. Just click
http://click.topica.com/caab6PVbUrKDAb7ujOHa/ Val Rad
===========================================================

Thanks.

Instead of responding to this list, instead respond to
***@yahoogroups.com.

- Scott
====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

===========================================================
Bounces like rubber! Shatters like ceramic! Discover Crazy
Aaron's Thinking Putty in grown up handfuls. It's the
creativity unleashing, mood enhancing desk toy!
http://click.topica.com/caab593bUrKDAb7ujOHf/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.

===========================================================
Your opinion counts! Were conducting a survey for a
computer service/repair company. When you complete our
survey, you will also be entered into a drawing for one of
ten $100 prizes. Just click
http://click.topica.com/caab6PibUrKDAbWnbtkf/ Val Rad
===========================================================
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------