Kent said:
None of which are related to the issues of coming
into a project which lacks an architecture document,
and spurns documentation as a waste of time, and
solves problems "in the small" and "as they come up"
rather than before they occur.
Agile methodologies (XP, Scrum etc) all value documentation. None spurns
them as 'a waste of time'
Indeed the Agile Manifesto actual says:
"Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on
the right, we value the items on the left more."
What XP says, like the other agile methodologies, is that some documents
have been found to be of less value than others and so tend not be be
created or are created later in the project life cycle.
XP does NOT say you cant have them, it simply says, 'Here is the cost of
them' If that cost is ok for the team and the various types of
Customers then they are created and maintained. If they are not deemed
worthwhile or too expensive then they wont be.
Lots of XP teams will create a broad architecture and various other
documents. They tend to create them nearer the end of the projects,
usually just before the project is moved into a maintenance phase. For
the same reasons other methodologies create them - Communication.
They tend not to create them at the beginning, because they simply
aren't needed by the team. This does NOT mean the team starts out
creating a system without any idea of what architecture to use.
All XP teams spend an amount of time at the beginning working through
the various architectural approaches they might take, before deciding
upon one. Once decided, they will certainly, only implement enough of
it for the features they are working upon at that time.
We call this time 'Iteration Zero'.
In practice, its very rare for the fundamentals of the architecture to
change during the project, even when we only implement those parts that
we need today. Some parts may change, but the overall architecture
doesn't, but then this happens even in other methodologies.
XP compared to CMM level 4 is sort of like the
difference between peephole optimization and global
optimization in a compiler. Both "work", but one is
a whole lot more powerful in controlling the shape
of the final product, because it has a broader
perspective from the start.
That's broken. Reviewers _should_ be other peers,
not some superprogrammer. Code review is a great way
to develop code reading and writing skills in all
participants, the experience shouldn't be tailored
to use only the most competent and leave out the
newbies as reviewers, who could most use the
education and the familiarization with the rest of the
code.
This, on the other hand, should have taken about
five minutes: "write the test, then the code it
tests" isn't a difficult meme if they have to be
delivered in that order.
The 3 Steps of TDD '1) Write one failing test, 2) Make the test pass,
3) Refactor' shouldn't be too hard to grasp. However, it typically is.
Just about every developer I've coached TDD to, always creates the class
and its skeleton before the filling in the testcase. They have done it
that way for soooo long they find it hard to do otherwise. Even simple
things like intellisense gets them. With the first test, there is no
class so the intellisense doesn't work - it totally screws them.
I personally have no idea why - but it does for most.
Aside from the mechanics though, the biggest challenge is making the
mental shift required to get the most out of TDD.
It can easily take a month, two or more before people have the 'a-ha'
moment when they are TDDing. The simple things like approriate testcase
names for example. I interviewed a developer last month who had been
TDDing for 6 months - great I thought - someone who should be
experienced enough to join the team without much coaching.
However his test cases were called
class TestRomanNumeralGenerator extends testcase {
testSimple1() {...}
testSimple2() {...}
testSimple3() {...}
testMultiple() {...}
testException() {...}
}
These are useless as testcase names as they do NOT reveal anything about
what the design is.
During the interview we went through them and he changed them to be more
Behavior and/or Specification revealing....
class TestRomanNumeralGenerator extends testcase {
testRomanNumeralRepresentationsForIntegersOneToNine() {...}
testRomanNumeralRepresentationsForIntegersBetween10And99(){..}
testRomanNumeralRepresentationsForIntegersBetween100And3999(){...}
testExceptionThrownAsZeroIsNotValidRomanNumber() {...}
}
These aren't brilliant, but they are a hell of a lot clearer than the
initial set.
TDD is design process which uses Unit tests to capture and document the
behavior/specification - there's even a project ongoing now where people
are creating new frameworks that use the words 'Behaviour' or
'Specification' instead of 'Test' or 'unit test' as they feel it
correctly shows what is meant by TDD.
No, thank you.
I lasted about three months in my last job,
precisely because my employers couldn't be bothered
to decide in advance what they wanted me to do
before it was begun. In that period, they changed
the projects' specs roughly daily, often with "start
over from scratch" effects, and I could only deliver
prototypes, never something that fully satisfied
their current thinking, in that entire time period.
That they also took some college student's
"framework" project from a grad school class, one
that ignored most modern thinking on how complex,
frequently redefined interfaces should be done (in
robust XML streams, not in fragile parameter by
parameter passing), as their be all and end all
project architecture, and refused all pleas for
changes to it, didn't help a bit.
XP projects certainly do NOT run like this.
Yes this sounds like a nightmare - were they trying to do XP here or was
it more of the case that they simply didn't know what they wanted? or both?
Either way, regardless of the methodology used, this project would be
doomed.
Compare this to my happy, productive experience in a
CMM level 3 shop, where projects occasionally
slipped schedule a bit, but arrived fully compliant
with specs and embedded in a well-thought out
architecture that worked end to end. Of course, we
were dealing in a project whose budget was dollars
in thousands of millions, not thousands (Motorola's
IRIDIUM), and in code bases of hundreds of millions
of lines, not tens of thousands of lines, so no one
was going to "own all the code", thus XP was never
even a consideration.
For projects of that size, vanilla XP wouldn't be a good choice.
There are some supplemental practices that could be used to facilitate
this size (see industrialXP for those) or my preference, use a different
Agile methodology - Scrum for instance. Scrum can scale to this size
out of the box, because you can have scrums of scrums (Teams of Teams
working upon their own part of the feature list).
FWIW
xanthian, not a fan of "agile programming".
Andrew
FWIW, not a fan of poo-pooing things I haven't used.