Xtreme Programming

Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally retired.

5 Phases of software engineering Analysis Design Implementation Testing Deployment

Waterfall model When the process was first developed in the early 1970’s it was postulated that one phase would run to completion, its output would spill over to the next phase, and the next phase would begin. This model was called the Waterfall model

Problems with the Waterfall Figure out what Figure out how Then do it Verify was done right Hand product to customer Perfect requirement definition?

The Spiral Model Proposed by Barry Boehm in Breaks the development process down into multiple phases. Early phases focus on construction of prototypes

Problems with the Spiral By building in repeated trials and feedback, a development process that follows the spiral model has a greater chance of delivering a satisfactory system. BUT there is a danger that if engineers believe that they don’t have to do a good job because they can always do another iteration, then there will be many iterations and the process will take a long time to complete

More problems! Not enough time to test due to pressure to get new software or new versions out fast Breakdown in communication between programmers and management Blamed by managers if things go wrong Business problem changes half way through project

What is needed Continuous feedback Incremental planning Test driven development Collective ownership Simplicity Support for difficult decisions

New Philosophy

Set of Practices Realistic Planning – Customers are to make business decisions, programmers are to make technical decisions – Update the plan when it conflicts with reality How does this help?

Set of Practices Small Releases – Release a useful system quickly – Then release updates on a very short cycle. How does it help? – Reduces risk of schedule slip and project cancellation – a small release that actually works establishes credibility – Gets the customer involved

Set of Practices Metaphor – All programmers should have a simple shared story that explains the system under development – “This program works like a hive of bees, going out for pollen and bringing it back to the hive.”: description of an agent based information system How does this help? – Use of a common system of names ensures that everyone understands how the system works and where to find the functionality they are looking for

Set of Practices Simplicity – Design everything to be as simple as possible instead of preparing for future complexity How does this help? – Avoids “featuritis” and maintains focus on the real problems

Set of Practices Test Driven Development – The system is continuously tested in short cycles of adding a test and making it work – When the code is released to the repository, all the tests MUST run 100% of the time

Set of Practices How does this help? – Programmers get immediate feedback – Leads to almost 100% test coverage – If the defect rate of an implemented system is too high, the system might be discarded or replaced

Set of Practices Customer Tests – The customer defines one or more automated acceptance tests to show that the feature is working. – Once the test runs, the team keeps it running correctly thereafter. How does this help? – The system only improves, always notching forward

Set of Practices Refactoring – Programmers are to restructure the system continuously to improve the code and eliminate duplication – And increase the cohesion of the code while lowering the coupling (hallmarks of well designed code) How does this help? – Good, simple design helps maintain development speed

Set of Practices Pair programming – Two heads are better than one – Put programmers together in pairs, and require each pair write code on a single computer

Set of Practices How does it help? – Programmers do not feel isolated or unsupported – Provides better code and tests – Serves to communicate knowledge throughout the team – As pairs switch, everyone gets the benefit of everyone’s specialised knowledge – Programmers learn, their skills improve, they become more valuable to the team and to the company.

Set of Practices Collective Code Ownership – All programmers have permission to change all code as it becomes necessary How does this help? – All code gets the benefit of many people’s attention, which increases code quality and reduces defects – Avoids an individual putting a feature in the wrong place, code duplication and low or bad cohesion

Set of Practices Continuous integration – Whenever a task is completed, build the entire system and test it. – This could mean multiple builds per day! How does this help? – Ever made several changes to code in different places, then built the system and …it does not work? And not known why?

Set of Practices Continuous Integration How does this help? – The team gets practiced at integration by doing it frequently, rather than delegating it to people not familiar with the whole system – Detects bugs that are not detected by testing – Avoids time lost due to code freezes

Set of Practices 40 hour week – Don’t cover up unrealistic schedules with bursts of heroic effort. How does this help? – Enables work at a sustainable pace

Set of Practices On-site customer – An actual customer of the system is to be accessible to team members at all times. How does it help? – Reduces chance of the business being misunderstood – The specification can be continuously refined to meet expectations

Set of Practices Coding standards – Programmers are to follow standards that emphasize self-documenting code – All the code in the system looks as if it was written by a single – very competent – individual. – The specifics of the standard are not important How does it help? – Supports collective ownership

Synergy Beck claims that the value of the Extreme Programming approach lies in the synergy of these practices – the sum is bigger than the parts. Refactoring is strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken. Thus customer tests and programmer tests are a critical enabling factor. The XP practices support each other.

XP Practices