1. eXtreme Programming Quick Introduction Daniel Arraes Pereira Eduardo Lourenço Apolinário Ricardo de Oliveira Cavalcanti

2. Overview Classical Software Engineering Variables Values Practices

3. Classical SE 3 phases, management able to set deadlines Customers provide all requirements Analysts translate requirement into a specification Coders implement the specification Reviews ensure the specification is met Testing is performed by a third party Maintenance means modifying as little as possible (old code is good code) Change is hard (and expensive)

4. Cost of Change time Cost of Change Standard SE XP

5. What is XP? a disciplined approach to software development code centric: no reckless coding, test-first successful because it emphasizes customer involvement and promotes team work not a solution looking for a problem One of several agile software development processes

6. Agile Manifesto (2001) Individuals and interactions over processes and tools  Communication Working software over comprehensive documentation  Travel light Customer collaboration over contract negotiation  On-Site Customer Responding to change over following a plan  Feedback

7. Essence of XP Four variables in software development :  Cost, Time, Quality, Scope Four Values  Communication, Simplicity, Feedback, and Courage 12 Practices (or fewer)  Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, move people around, collective ownership, 40-hour week, on- site customer, coding standard, metaphor

8. The Four Variables Increase cost and you can do a bit more but Pouring money into a project won't solve the problem Too much time can hurt, also with too little time, quality suffers Quality is a terrible control variable Scope is the primary control

9. Values of XP Simplicity  Choose the simplest thing that will work Communication  within the team, between developers and customer… Feedback  Acceptance Testing, small releases Courage  To refactor, to throw the code away and start again

10. XP Practices On-Site Customer  Defines business needs  Answers questions and resolves issues  Prioritizes features Planning Game  involves story cards, which are short descriptions of a feature.  Estimation  Business Decisions x Technical Decisions

11. XP Practices Small Releases  Deliver valuable features first  Always the last week Simple Design  Design for today not the future Metaphor  How does the whole system work?  What is the overall idea of the system?

12. XP Practices Testing  If testing is good, everybody will test all the time  Unit tests and Acceptance tests Refactoring  Restructure code without changing the functionality  Goal: Keep design simple

13. XP Practices Pair Programming  Person 1: Implements the method  Person 2: Thinks strategically about potential improvements, test cases, issues Move People Around  No single expert on any part of the system  Continuous code reviews, fewer defects  Cheaper in the long run, and more fun

14. XP Practices Collective Ownership  All code can be changed by anybody on the team  Everyone has responsibility for the system Continuous Integration  Find problems early  Can see if a change breaks the system more quickly -- while you remember the details

15. XP Practices 40-Hour Week  Developing full speed only works with fresh people  Working overtime can help the first week, and hurt the next week Coding Standards  Makes it easier to understand other people’s code

16. XP roles Gold Owner Goal Donor Manager Acceptance Tester Programmer Tracker Coach