Presentation is loading. Please wait.

Presentation is loading. Please wait.

What do you need to know about XP?

Similar presentations


Presentation on theme: "What do you need to know about XP?"— Presentation transcript:

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

2 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 Copyright © by Curt Hill

3 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 © by Curt Hill

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

5 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 © by Curt Hill

6 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 © by Curt Hill

7 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 © by Curt Hill

8 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 © by Curt Hill

9 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 © by Curt Hill

10 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 © by Curt Hill

11 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 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 © by Curt Hill

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

13 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 © by Curt Hill

14 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 © by Curt Hill

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

16 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 © by Curt Hill

17 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 © by Curt Hill

18 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 © by Curt Hill

19 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 © by Curt Hill

20 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 © by Curt Hill

21 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 © by Curt Hill

22 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 © by Curt Hill

23 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 © by Curt Hill

24 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 © by Curt Hill

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

26 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 © by Curt Hill


Download ppt "What do you need to know about XP?"

Similar presentations


Ads by Google