Extreme Programming, Agile Software Development or Light Software Methodologies have been gaining in popularity. Why XP.
They are particularly suited to New Zealand Developers who have the bungy-jumping attitude, kiwi ingenuity, good team co-operation and who can successfully combine team play with individual flair, support the ball-handler and cover the field.
Two year development projects pre-planned in detail in advance are no longer a fit to modern business models whose business tactics and business models may well flex every quarter. See Business Models.
Extreme Programming leads to faster delivery of useful code and a substantial reduction in project risk. To learn more see a summary of Extreme Programming and Power Point Presentations: Fad, Fall-back or Fail-Safe Fast Forward [62kB] and XP addresses 10 reasons for Project Failure [52kB].
Ian Mitchell, a member of The iE3 Group, is available to accept your comments, to discuss XP with you or provide mentoring services.
If you want to think about using XP then see: Meditation in preparation for encountering Extreme Programming [Compliments of Kent Beck]
Menu: This site is split into the 15 topics of XP and some general topics. On each page we will add comments from the New Zealand Experience. Please pass your comments for publication (or not) by using the “Comment” link at the bottom of each specific page.
- Values – The values which must be held by XP proponents
- Management – Some Words For User Management
- Contracts Using XP Methods – Contracts which include the task of defining the deliverables
- The Planning Game – How to record requirements and sequence them to permit early delivery
- Short Releases – How to deliver short releases
- Metaphor – How to communicate the application model
- Simple Design – How to fight complexity
- Testing – Should you test every line of code and how?
- Refactoring – Building optimal architecture
- Pair Programming – Working together
- Collective Ownership – Anyone can change any code – does that work?
- Continuous Integration – Always hold a deliverable code-set even with unreleased features
- 40-hour Week – Programmers deliver better code if they are not abused
- On-Site Customer – The customer is the real determinant of quality on-time delivery
- Coding Standards – How to get agreement on standards