eXtreme Programming

1. eXtreme Programming A lightweight development process for small to medium-sized projects (an Agile Process) by Shahid N. Shah

2. Waterfall* Extreme Programming Crystal Family (Alistair Cockburn) Open Source Adaptive Software Development (Jim Highsmith) SCRUM Feature Driven Development (FDD, Jeff De Luca and Peter Coad) Dynamic System Development Method (DSDM, $$) Rational Unified Process ($$)* Sampling of Available Methodolgies * Non-agile

3. XP Philosophy • Always ask yourself: “what is the simplest thing that could possibly work?” -- Kent Beck, XP Creator • Never do any more coding, more testing, more process, or more documentation than is absolutely necessary to delight the customer. • Main values: Communication, Feedback, Simplicity, and Courage • Formalize and do what has been known by “smart guys” for years • Not a “license to hack”!

4. XP Key Practices • Adaptive, not predictive • The Planning Game -- Quick, up-date as needed, 80/20 rule, push out what doesn’t need to be immediately decided • Small releases -- Get simple system into production quickly, add features in small releases • Simple design -- Design as simple as possible • Refactoring -- Continuously restructure to simplify, remove duplication • 40 hour week • On-site customer -- collective ownership • Travel light -- No more documentation than needed to support deployment of application

5. To set objectives for the project and have them followed. To know how long the software project will take and how much it will cost. To decide which features are in and which are out of the software. To know the project’s status. To make reasonable changes to requirements throughout the course of the project and to know the costs of making these changes. To be apprised regularly of risks that could affect cost, schedule or quality. To have ready access to project deliverables throughout the project. Customer’s bill of rights

6. To know the project objectives and to be able to clarify priorities. To know in detail what product I’m supposed to build. To have ready access to the customer, manager, marketer, or other person responsible for the functionality. To work each phase of the project in a technically responsible way. To approve effort and schedule estimates for any work that I will be asked to perform. To have my project’s status reported accurately to customers and upper management. To work in a productive environment free from frequent interruptions. Developer’s Bill of Rights

7. Benefits of XP • Software stays soft • Handles changing requirements with relative ease • Quickly produces something useful, keeps making useful enhancements -- delivery is provided when customer is ready • Average developers can produce great software

8. Prerequisites • Flexible Project Management • Goal is to delight customers and not to maintain process (though they are not mutually exclusive) • Groups that can talk to each other • Close contact with users

9. Obvious things to do • Staged Delivery • continuous stream of value • feedback • adapt to change • Business people make business decisions and technical people make technical decisions • Regression testing, unit tests • Review designs and code

10. Extreme Programming • Analysis • Test • Code • Design • Project Management

11. Extreme Analysis • Describe system as a set of user stories (storyboards) • Users write stories explaining one use of the system (explain by example) • Like use cases, but informal (no special tools are needed) • Realize that all artifacts created during design will rarely be updated after implementation

12. Extreme Testing • Write tests before code • unit tests before each class • end-to-end tests before any classes • Convert each user story into a set of tests • All unit tests must run 100% all the time • Don’t worry if you can’t test everything • GUI • real-time I/O • complete coverage • Don’t worry if testing is expensive

13. Extreme Coding • Eliminate code in favor of configuration • Write code for test cases one at a time • Write the simplest thing that could possibly work • Goal: make the tests work ASAP • write new classes • use/change old classes • copy code • add if statements • Enforce coding standards

14. Pair Programming • All code is written in pairs • Pairs talk continually • Pair switches driver frequently • People switch pairs several times a day • Continuous code review

15. Refactoring:Extreme Design • Make sure each thing is done in one place - eliminate all duplicate code • Make sure each class/function does one thing • All code must be readable • All tests run

16. Extreme Design • Project starts with a few days of design on white-boards/CRC cards • Major problems lead to group design sessions (servers, objects, etc) • Documentation is after the fact, and no more than necessary • Start simple, refactor to keep simple

17. Extreme Scheduling • Customer write stories • Developers estimate cost • Customer decides which to do next • Group a few weeks worth of stories into an iteration • Developers implement stories one at a time until iteration is finished

18. What is Extreme? • Extreme, but not unusual • user stories, schedule negotiation, staged delivery, testing, simplicity • Extreme and unusual • pair programming • continuous refactoring

19. Conclusion • Produce consistently better applications with fewer people (or less qualified people), in less time, with higher quality and significantly lower overall cost.