What do you need to know about XP? eXtreme Programming What do you need to know about XP? Copyright © 2015-2016 by Curt Hill

eXtreme Programming (XP) One of the earliest agile methodologies Goals to produce high quality software and increase programmer productivity XP has a set of: Activities Values Rules Principles First XP team was in 1996 http://www.extremeprogramming.org/ Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Some Generalities Emphasizes User satisfaction Team work Many small releases This is the iterative approach Feedback from the user Technical people make technical decisions and business people make business decisions Object oriented Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill The XP Approach Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Activities Coding – duh! Testing Unit tests Acceptance tests Listening To the business experts and each other Designing Overall structure of the system Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Values 1 Communication Between the business experts and every member of the XP team Simplicity Find the simplest solution – it can be made more complicated later Feedback System: unit and integration tests Customers: acceptance tests Team: to the customers on requirements Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Values 2 Courage Design for today, not tomorrow Be fearless in refactoring, not allowing a poor design to hold things back Respect For self: believe that you can produce high quality code For others: do nothing that will cause impediments for rest of team Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Principles Feedback Frequently and promptly to keep project on track Simplicity Often we are asked to consider the future XP rejects, as the future is unpredictable Change Is inevitable Accept and move on from there Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Rules There are different rules for different phases The tasks: Planning Managing Designing Coding Testing We next consider these Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Planning (1 of 2) User stories are written Similar but different to a use case Written by the user Release planning creates the release schedule Developers estimate time for each iteration Iteration is dependent on stories Make frequent small releases Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Planning (2 of 2) The project is divided into iterations Iterations are of constant size (1-3 weeks) to make measurements possible Project should divide into about 10-20 iterations Each iteration ends with a usable program Iteration planning starts each iteration The tasks for this iteration are determined by the planning meeting – not before Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill XP Project Flow Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Managing (1 of 2) Give the team a dedicated open work space Open space around computers Room for a stand up meeting Set a sustainable pace Requires good estimates and changing goals when needed A stand up meeting starts each day Standing minimizes length Brief progress reports Try to minimize other meetings Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Managing (2 of 2) The Project Velocity is measured Sum of the estimates of user stories for this iteration In the next iteration users are allowed to choose the same amount of estimates as was completed in last Move people around Spreads the knowledge around so that nobody is irreplacable Fix XP when it breaks Not if it breaks Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Development Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Designing (1 of 2) Simplicity Everything should be as simple as it can be but not simpler - Einstein Simple is easier to implement Choose a system metaphor An analogy to explain the system to the user without technical jargon Use CRC cards for design sessions See next slide Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill CRC Cards Stands for Class, Responsibilities, and Collaboration An informal OO design technique Name at top Responsibilities on left Collaborating classes on right In a meeting one person describes how the class communicates with others Others point out problems Card rearrangement or redesign follows Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Designing (2 of 2) Create spike solutions to reduce risk A program that tests the technical feasibility of a solution Like a prototype, thrown away when it proves the solution No functionality is added early Only the basics Never guess about what will be needed Refactor whenever and wherever possible See next slide Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Refactoring Definition: restructuring existing code without changing its behavior Refactoring is often called for when methods are too long or similar to other methods There are a number of refactoring techniques These we may consider later Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Coding (1 of 3) The customer is always available Recall that only business experts make business decisions Do not let user send a trainee Code must be written to agreed standards This includes formatting use of names This is determined by the team Code the unit test first The unit test is an automatable test of the class or method Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Coding (2 of 3) All production code is pair programmed Two people, one computer Keyboard can be slid between two Whoever is not typing is considering what can be typed Use collective ownership No one owns code Rather owned by all Copyright © 2015-2016 by Curt Hill

Coding and Integration Only one pair integrates code at a time The pair who developed a unit are interested in showing it right not showing whole system is right They are also the master of the version control system Integrate often Commits more often than daily Set up a dedicated integration computer All releases come off of this Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Testing (1 of 2) All code must have unit tests Automatable with a framework Also shows that refactoring did not damage All code must pass all unit tests before it  can be released The automation eases this Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Testing (2 of 2) When a bug is found tests are created Prevents this bug from reappearing Acceptance tests are run often and the score is published These are created from the user stories The user specifies the scenario of the acceptance test Acceptance tests are a form of black box testing while unit tests are white box Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Project Again Copyright © 2015-2016 by Curt Hill

Copyright © 2015-2016 by Curt Hill Finally XP is one of the earliest of the agile methods It is a team oriented, iterative approach Has much in common with Scrum We should do a CRC design exercise Finally for now Copyright © 2015-2016 by Curt Hill