1. Extreme programming (XP) Advanced Software Engineering 603 492 Dr Nuha El-Khalili

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

3. 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

4. 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

5. 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

6. XP Roles

7. 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.

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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.

16. 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

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

18. 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

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

20. 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

21. 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

22. 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

23. 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