RE: Managing Extreme Programming

I like what Glen says here. I've also worked on big (avionics, ATC, etc)
systems, where the requirements are almost completely known from day
one. However, this does not make XP irrelevant. At the "coding end of
things" the XP practices are a beautiful thing. It's just that the
System Analyst playing the role of Customer is feeding the requirements
to the developers in bite-sized chunks called stories. The hardest part
of a project like this is not the development, but the decomposition of
the requirements into stories in a rational way to feed the "XP machine"
efficiently. 

 

At OOPSLA I talked to Kent about this, and my statement was that XP had
solved the problem of producing quality code given a flow of (possibly
changing) requirements. I asked if that was the extent of the intended
scope of XP, and we both agreed that it was.

 

Anyway, at Net Objectives we use (and teach) a technique called the
"Ever Unfolding Story" to move from use cases to more detailed
requirements that would be suitable for feeding an XP team. This is
certainly not the only use for the technique - it also has its uses
within a BDUF - but it's the one we recommend. Our focus is on making
producing software with less pain, and agility is a cornerstone of our
thinking. The Ever Unfolding Story enables agility, as does TDD and a
whole list of techniques that you are familiar with.

 

So, just agreeing with Glen.

 

Dan  ;-)

Dan Rawsthorne, PhD, Sr. Consultant
www.netobjectives.com
[email protected]
office: 425-641-0814

Net Objectives' vision is effective software development without
suffering. Our mission is to assist software development teams in
accomplishing this through a combination of training and mentoring. 

-----Original Message-----
From: Alleman, Glen B. [mailto:[email protected]] 
Sent: Tuesday, January 14, 2003 7:42 AM
To: [email protected]
Subject: RE: [xpAdoption] Managing Extreme Programming

 

George,

 

One troubling concept in all this discussion is the assumption that ALL
software development project are based on emergent requirements of the
type addressable by pure-XP. This is simply not the case. However many
of the XP practices as useful no matter what the "chaos" level of the
project. Many of our projects and most of hose in aerospace and telecom,
have externally specified requirements, since these systems are embedded
in larger systems. Yes the requirements are the interfaces can and do
change, but they are not "discovery" requirements in the manner
suggested by many XP authors - where the user has no a clue as to what
she wants and XP provides adaptive development process.

 

The requirements we receive here are say 80% to 90% defined when we get
them, adapting to changes in a rapid manner is useful, but PP, 100%UT,
CM and all the downstream XP practices are more useful in the end
because quality and on time deliver are "assured" - in the traditional
methods of the past they were not.

 

The time and expense of changes the requirements is NOT what prevents
the customer from changing them. What prevents them from changing them
is the system is embedded in a larger scheme and there is no economic
advantage to change them. The class of problem we are providing
solutions to is a "systems engineering" problem not a point solution
problem.

 

Glen B. Alleman

 

 

-----Original Message-----
From: Dinwiddie, George [mailto:[email protected]] 
Sent: Tuesday, January 14, 2003 6:55 AM
To: [email protected]
Subject: RE: [xpAdoption] Managing Extreme Programming

 

It seems to me that this is a natural consequence of a customer who is
distinctly non-agile in producing requirements.  I don't doubt that the
real world changes just as fast for them as for everyone else, but they
have a considerably longer decision proces.  The time and expense of
changing requirements causes your customer to avoid it if at all
possible.

-----Original Message-----
From: Alleman, Glen B. [mailto:[email protected]]  

[>] The added value of EV in the XP world is to add to the "velocity"
metric the accrued value. That is use the BCWS as the target value
rather than yesterday's weather. Adding or deleting stories in EV means
scope changes so we are careful not to allow this except in special
circumstances. Our world here is not discovery design so this is rare.  

 


To unsubscribe from this group, send an email to:
[email protected]



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service.