Greetings all.
Sorry about not giving a proper introduction to the XP Method of
development.
Essentially XP addresses the problem you probably all know about - that is
that your customer never gives you complete or correct requirements, meaning
your specification is never totally correct - and you always end up changing
things, extending things, or at worse, rewriting things.
The answer is to let it go - accept that the user will change their mind,
and move to a development model which accomodates users changing needs.
Many of the ideas begind XP actually have been around since much earlier.
If you have read Code Complete and Microsoft Secrets you will already know
about many of the things XP is about.
The essential core of XP is evolution. Rather than depending on perfect
requirements and design (and we all know those are fantasies) we take a more
pragmatic approach - that we can only really plan in detail a few weeks
ahead, and that we can only plan a 'direction' for the longer term. Rather
than in depth planning we evolve solutions with the aid of our users as a
form of 'natural selection' in a quick release cycle.
XP is only one method using evolutionary techniques, and some people are
getting hung up on the details - such as pair programming. I don't believe
pair programming is the core success. The core is the way code is cycled
quickly through iterations, and extensive use of unit tests. As a result
the end product fits the users needs in a way that developments with up
front design can't hope to achieve.
XP is not fragile. It is not a case where just because you don't follow one
of the "golden rules" the method will fail. In fact the method itself is
adaptive - you change the details to fit your organisation. The core
principle (in my opinion) is the evolutionary principle - that you need to
have a close ongoing communication with users, and a tight release cycle.
In support of this view I note the success of the Open Source method. In
Open Source generally test units are not common. Pair programming is also
very rare in OS. However the core of quick release cycles to the user has
the same effect - of evolution by mini iterations rather than monolithic
large versions releases.
One of the difficulties however is application of XP to visual apps like
Delphi typically produces. While test frameworks for Java are quite well
developed, unit test systems for Delphi are more challanging. If anyone has
ideas for solutions to creating test units for visual apps - I would like to
hear them...
Regards,
Peter Harrison
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
