Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili

Agile Methods Scrum eXtreme Programming (XP) Kanban Others: DSDM, FDD, ASD

Extreme programming (XP) A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements A software development discipline that organizes people to produce higher quality software more productively. (Extreme Programming Explained, 1999) Initiated by Kent Beck, Ward Cunningham, and Ron Jeffries during their work on the Chrysler Comprehensive Compensation (C3) System in 1996

XP Activities Coding Listening – Communication between the customer and programmer Designing Testing – Unit tests: if all tests run successfully, then the coding is complete – Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements

XP Values Communication: – collaboration of users & programmers, frequent verbal communication, and feedback. Simplicity: (in design and coding) – start with simplest solution, add extra functionality later Feedback: (system, team, customer) Respect: Courage: – design and code for today and not for tomorrow – Refactor code – throw obsolete code away

XP Roles

Coach A person responsible for the process as a whole, guiding the team, and understanding the process and learning from other XP teams. Tracker A person responsible for making good estimates and checking how they match up to the real results. Programmer A person with good communication skills, who maintains simplicity in work &code. Customer A person(s) from the customer organization, who is integral part of the XP team. Tester A person who helps the customer write functional tests, runs them regularly, and posts results for everybody's knowledge. Consultant A person who may be needed to assist the XP team by providing technical knowledge or help with the process. Big Boss A project sponsor, responsible for checking the team's progress regularly and communicating with the team to listen their issues.

XP Practices 1.The planning game 2.On-site customer 3.Small releases 4.System metaphor (Imagine) 5.Pair programming 6.Collective code ownership 7.Coding standard 8.40-hour week 9.Refactoring 10.Simple design 11.Continuous integration 12.Testing Business Practice Teamwork Practice Programming Practice

1- The Planning Game Planning for the upcoming iteration Uses stories provided by the customer Technical persons determine schedules, estimates, costs, etc A result of collaboration between the customer and the developers Advantages – Reduction in time wasted on useless features – Less guesswork in planning

2- On-Site Customer Development is largely about learning the customer’s requirements Communication with the real customer is vital Tasks of the on-site customer: – Communicates customer wishes, clarify feature requests to developers, etc. – Specifies functional tests (user stories)‏ – Participates in planning of iteration and releases

2- On-Site Customer Disadvantages – Difficult to get an On-Site Customer – The On-Site customer that is given may not be fully knowledgeable about what the company – May not have authority to make many decisions

3- Small Releases Small in terms of functionality Less functionality means releases happen more frequently Advantages – Frequent feedback – Tracking – Reduce chance of overall project slippage

4- Metaphor The oral architecture of the system Use common set of terminology between customers, programmers, and managers to tell how the system works & to guess the functionality of a particular class/method Disadvantages – Often the metaphor is the system – Another opportunity for miscommunication – The system is often not well understood as a metaphor

5- Pair programming All code is written in pairs One person types, the other comments and thinks about the big picture, then swap Frequent pair switch – At least once per day, in two different pairs Takes place of code reviews, tactical meetings, training, progress reports

5- Pair programming Pair programming provides many benefits: – All design decisions involve at least two brains. – At least two people are familiar with every part of the system. – There is less chance of both people neglecting tests. – Changing pairs spreads knowledge throughout the team. – Code is always being reviewed by at least one person.

6- Collective code ownership The idea that all developers own all of the code Enables refactoring Disadvantages – Loss of accountability – Limitation to how much of a large system that an individual can practically “own” – Conflict in opinion

7- Coding standard All code should look the same Advantages – Reduces the amount of time developers spend reformatting other peoples’ code

8- 40-hour week The work week should be limited to 40 hours Regular overtime is a symptom of a problem and not a long term solution

9- Refactoring Improves the quality of the system in some way Disadvantages – Not everyone is capable of refactoring

10- Simple Design Do as little as needed, nothing more Then refactor Advantages – Time is not wasted adding extra functionality – Easier to understand what is going on – Helps keeps programmers on track Disadvantages – Simple isn’t always best

11-Continuous integration Automate the build, tests, and deployment Rebuild the whole project and test it frequently, at least after every iteration of unit development Everyone can see what’s happening, so integration problems can be detected and fixed continuously

12- Testing Unit testing Test-first design All automated Disadvantages – Automated unit testing isn’t for everything – A test result is only as good as the test itself

XP Criticisms Lack of structure and necessary documentation Only works with senior-level developers Requires meetings at frequent intervals at enormous expense to customers Incorporates insufficient software design Often used as a means to bleed money from customers through lack of defining a deliverable Requires too much cultural change to adopt Scalability