Urgent!!! UPGRADE METHODOLOGY

[Phlip]

The process tends to be different with agile projects, where the
customer pays by iteration, with the option to pull that pug after the
iteration is complete. The level of required documentation is
considerably less because the risk to the client is much lower, the most
they will loose is a week or two of the suppliers time.

I've run a couple of successful projects this way, one in particular was
very successful, delivering the client exactly what they wanted, which
turned out to be considerably more than they would have specified up
front. They got extra business value, I got several more months work.
At no time were the requirements anything more than 4x6 cards.

It's funny how the dominos fall. If you assume that software must grow
harder to change as it matures, then you must assume that it must be planned
up-front, designed up-front, and required up-front. This passes the buck
back to the client - they must perform the superhuman task of predicting
which set of _detailed_ requirements they will need.

Then this system devolves into a game of brinkmanship, where at delivery
time the client checks what the code actually does, and then attempts to
re-specify for the things that are now missing. If these things are in the
contract but not delivered, the client orders the programmers to work for
free, and the programmers take the hit. If these things are not in the
contract, the client takes the hit. So the client has an incentive to
over-specify the up-front contract, and the programmers have the incentive
to try to guess what's really important.

Adaptive planning and just-in-time requirements balance all that out.

 

[James Kanze]

Quite. Take a look at the SEI site, for example.

http://www.sei.cmu.edu/productlines/frame_report/testing.htm

----8<-----------------------------------------

TDD is one practice of the agile development community. Its goal is "clean
code that works" [Beck 2002a]. In this practice, developers define
requirements for the piece they are assigned to construct by maintaining
close communication with the developers who are constructing related units
and writing test cases that serve as the specification for the unit. The
developer then writes and revises code until the unit passes all the tests.
The rhythm of TDD is very short cycles of these steps:

Define a new test.
Execute all tests.
Write code to fix tests that fail.
Execute all tests.

TDD has the advantage that the test code is always in synch with the product
code, because the test code defines the product code. The disadvantage of
TDD is that there is not a good method for determining whether the set of
test cases is complete, since the completeness of a test set is usually
determined by comparing it to the specification.

TDD is applicable to product line organizations provided it is applied to
units that are first defined in the context of the product line
architecture. TDD does not provide tools and techniques for balancing the
diverse quality attributes usually present in a product line. TDD can be
successful if applied to units that a small group of developers, often a
two-person or pair programming team, can produce in a timely manner. The
range of variability for the unit should also be sufficiently narrow to
allow for timely completion. The success of TDD depends on the availability
of tools, such as JUnit, to assist with development and automate testing.

----8<-----------------------------------------

Exactly. Very, very limited in its range of applicability.

ftp://ftp.sei.cmu.edu/pub/documents/articles/pdf/xp-from-a-cmm-perspe...

XP satisfaction of key process areas, given the appropriate environment

Level Satisfaction Key process area

2 ++ Requirements management
2 ++ Software project planning
2 ++ Software project tracking and oversight
2 - Software subcontract management
2 + Software quality assurance
2 + Software configuration management
3 + Organization process focus
3 + Organization process definition
3 - Training program
3 - Integrated software management
3 ++ Software product engineering
3 ++ Intergroup coordination
3 ++ Peer reviews
4 - Quantitative process management
4 - Software quality management
5 + Defect prevention
5 - Technology change management
5 - Process change management

+ Partially addressed in XP
++ Largely addressed in XP (perhaps by inference)
- Not addressed in XP

You'll note some very important issues that it doesn't address.
Like overall quality. I'd also disagree about it's addressing
software project planning or software project tracking and
oversight---planning definitly involves specifications: how much
time/money to do what, and tracking and oversight pre-suppose a
plan: how can you know if you're on schedule if you don't have a
schedule.

----8<-----------------------------------------

Note that this survey only compares XP's documentation and
verbiage to CMMi's verbiage. It is not a study of real
projects in action. So under "Training program", the -
represents the author, Dr. Mark Paulk, declines to speculate
that pair programming could be used as an ideal training
program.

Pair programming is a very effective *training* tool; it has
been more or less one of standard training tools for some 20 or
30 years now (although it didn't have such a catchy name in the
past).

Next, all Agile projects, in practice, automate their entire
build chain. Maybe the CMMi has higher goals for its
"Integrated software management" KPA.

All projects I've worked on for the past twenty or thirty years
have automated the build chain. That's only a small part of the
problem. The issues of tracking progress and measuring quality
are less often addressed.

And note that "Defect prevention" gets only one +. The actual
response from folks who switched to XP (and did all its
practices, not just the convenient ones) is their code grows
very robust and difficult to break over time.

Do you have anything but annecdotal evidence? What tools do you
use to measure?

On a well managed project, I would estimate that one error per
100,000 lines of code would be about the minimum acceptable
level of quality. Up until that point, at least, reducing the
number of errors reduces cost. (I've heard of projects with
less than one error per million lines of code. These are the
ones, of course, where the developers don't even have access to
a compiler. It can be done. It is done for very critical
systems, where human life is at stake. But I don't think it's
really cost effective otherwise.)

Agile development provides aspects of design and teamwork
which the SEI is not yet capable of interpreting.

So called "agile development" in fact takes us back to what was
current practive 20 or 30 years ago. SEI is roughly a
generation beyond that.

So, in conclusion, I don't think it's the Agile community who
is being immature here.

Just a serious step backwards.

 

[Ian Collins]

Just a serious step backwards.

Those with the courage to have taken the step would disagree.

 

[Ian Collins]

You'll note some very important issues that it doesn't address.
Like overall quality. I'd also disagree about it's addressing
software project planning or software project tracking and
oversight---planning definitly involves specifications: how much
time/money to do what, and tracking and oversight pre-suppose a
plan: how can you know if you're on schedule if you don't have a
schedule.

You have a pile of completed stories with a measured velocity and a pile
of estimated stories. These give you real data on progress and time
remaining, rather than speculation.

From this data, the customer (or management) knows exactly where the
development is and has real data to use to manipulate the priorities of
stories to meet specific deadlines. The data is extremely useful in the
feature/cost juggling act.

I have found that project managers tend to start out hostile to this
approach, but come to love it once they realise they have solid
reporting and estimations to work with.

Pair programming is a very effective *training* tool; it has
been more or less one of standard training tools for some 20 or
30 years now (although it didn't have such a catchy name in the
past).

It is also a very effective development tool, but you really have to try
it for real to understand this.

 

[Phlip]

Those with the courage to have taken the step would disagree.

I'm dropping out; this is all just slants and innuendos. Not even a word
that James was obviously surprised to learn SEI is seriously investigating
XP, and was not sharing his drooling invective for them.

In conclusion, I quote Pierre Pachet, Professor of Physiology at Toulouse,
1872:

"Louis Pasteur's theory of germs is ridiculous fiction."

No actual discourse, no alternate theory of disease exctept evil spirits,
and no washing hands before we operate on our patients.

 

[James Kanze]

James Kanze wrote:

Those with the courage to have taken the step would disagree.

It corresponds roughly to what was standard practice 20 or 30
years ago. Fancy names have been added, but the fundamentals
haven't changed. Some companies have moved beyond.

 

[James Kanze]

James Kanze wrote:

You have a pile of completed stories with a measured velocity
and a pile of estimated stories. These give you real data on
progress and time remaining, rather than speculation.

After a certain time. The problem is that the customer wants to
know the price and delivery date before starting the project.

From this data, the customer (or management) knows exactly where the
development is and has real data to use to manipulate the priorities of
stories to meet specific deadlines. The data is extremely useful in the
feature/cost juggling act.

I have found that project managers tend to start out hostile to this
approach, but come to love it once they realise they have solid
reporting and estimations to work with.

I'm not sure about project managers, but the customer or final
user generally doesn't want to be that involved. He has a
specific need or want. He asks how much it will cost, and when
can we deliver. We make our estimates; he decides whether it
will fit into his budget or not, signs the order, and then moves
on---specifying or designing software is the main occupation of
his organization.

It does happen that he changes his mind about some things during
development. The probability of this depends, obviously, on the
length of the project. When that happens, he recontacts us, and
we negotiate the changes. (If the project is running well, and
we have a good, modular design, we can often make small changes
for nothing.)

It also happens that during development, we discover that some
features which seem useful would be trivial to add, or that a
slight modification might make the software easier to use, and
less expensive to develop. In that case, we contact the
customer, and make a proposition.

We don't involve him on a day to day basis, or even weekly.

It is also a very effective development tool, but you really
have to try it for real to understand this.

My experience with it is that it isn't cost effective. It does
improve quality and development speed somewhat, but it costs
more than it brings.

 

[James Kanze]

I'm dropping out; this is all just slants and innuendos.

All I've seen is established facts. Adopting the process which
was standard 20 or 30 years ago is a step backward, even if you
wrap it in a fancy new name.

Not even a word
that James was obviously surprised to learn SEI is seriously investigating
XP, and was not sharing his drooling invective for them.

I wasn't at all surprised, since I'd read articles about it from
them five or more years ago. The SEI, in fact, investigates
pretty much everything that is proposed.

Their style is, of course, different from mine. Even when we
say basically the same thing.

 

[Ian Collins]

It corresponds roughly to what was standard practice 20 or 30
years ago. Fancy names have been added, but the fundamentals
haven't changed. Some companies have moved beyond.

30 year ago when I started writing software, we submitted our jobs on
cards and waited days for the results. When I started professional
development 5 years later, our build still took hours.

I don't see much similarity between how I work now and how I worked then.

I must admit, TDD with cards would be interesting, submit the test cards
Monday, get the fail back Wednesday, submit the code cards to pass the
test Thursday, get the pass back Monday. One test a week. Things would
have improved with our PDP11, we could probably manage to or three a day
on that.

 

[Phlip]

I must admit, TDD with cards would be interesting, submit the test cards
Monday, get the fail back Wednesday, submit the code cards to pass the
test Thursday, get the pass back Monday. One test a week. Things would
have improved with our PDP11, we could probably manage to or three a day
on that.

IIRC, that's how the Gemini software program worked.