eXtreme Programming By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)

What is XP?

XP is… A set of rules\principles\practices used to rapidly develop high-quality software Tools not Rules -Ron Jeffries One of the more prominent lightweight software-engineering methodologies Main Goal: Customer Satisfaction Highest quality in Lowest time frame.

XP emphasizes: Communication Communication Simplicity Simplicity Feedback Feedback Courage Courage …Using 12 main principles, including: Comprehensive unit tests Short release cycles Adding only what’s needed for the current task Collective code ownership Pair programming

Where did XP come from? “Father of XP”: Kent Beck Wrote “Extreme Programming Explained: Embracing Change” Wrote “Extreme Programming Explained: Embracing Change” Had years of experience in OOP such as Small Talk (at time of xP creation) Had years of experience in OOP such as Small Talk (at time of xP creation) Ward Cunningham Ron Jeffries…

It all started… Kent Beck developed XP back in 1996 while working at Daimler Chrysler Its use in developing the payroll system for D.C. is considered one of the great XP success stories.

Pros/Cons of XP Pros: Handles changing requirements well Handles changing requirements well Maximizes quality while minimizing time Maximizes quality while minimizing timeCons Only works well with small groups (around a dozen) Only works well with small groups (around a dozen) Many people dislike Pair Programming and think of it as overkill and a waste of resources Many people dislike Pair Programming and think of it as overkill and a waste of resources

A more in depth look -> And now my associates will give you all a more in depth look at XP so you can decide for yourself how useful or worthless XP is…

Extreme Roles Extreme Roles Customer  writes & explains user stories  sets priorities, specifies tests  may or may not be an end-user Programmer  estimates stories  defines tasks from stories  implements stories and unit tests Tracker  monitors progress  keeps track of schedule Coach  guides & mentors the team  watches the progress

Extreme Roles (contd.) Tester  runs functional tests  makes sure people know when test results decline. Doomsayer  ensures that everybody knows the risks involved  ensures that bad news isn't hidden, glossed over, or blown out of proportion Manager  schedules meetings, passes results to tracker  responsible to the Gold Owner. Gold Owner  the person funding the project  may or may not be the same as the Customer

Extreme Practices  The Planning Process  Simple Design  System Metaphor  Frequent, Small Releases  On-site Customer  40 hr weeks  Pair Programming  Refactoring  Test Driven Development  Collective Code Ownership  Continuous Integration  Coding Standard The 12 Golden Rules

XP Practice Cycle XP Practice Cycle

The Planning Process  defines desired features briefly  describes each feature's business value and priority  helps estimate project cost Simple Design  the best design is the easiest one that works  a correct design must have:  no duplicate code  fewest possible classes and methods  meets the business value and expected functionality  System Metaphor  provide a broad view of the project’s goal  describes how the system should work, its functionality  defines the overall theme to which developers and clients can relate XP Practices

Frequent, Small Releases  develop and deliver the application in a series of frequently updated versions.  provides frequent feedback On-site Customer  integral part of the development effort.  must be available at all times to set priorities, deliver and establish requirements, and answer questions. and establish requirements, and answer questions. Sustainable Pace / 40 hr weeks  avoid overtime  re-examine schedule  rested programmers = fewer mistakes

Pair Programming  all code is written in pairs  programmer and observer  code is simpler  less defects found  continuous code review  software quality increases  increases learning  every programmer knows all aspects

Refactoring Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure The aim of refactoring is to :  constantly revise  make the design simpler  make the code more understandable  improve the tolerance of code to change  remove duplication,  improve communication & add flexibility Change it even if it is not broken!

XP Practices (contd.) Collective Code Ownership  code belongs to the team  encourages team to work closer  everybody tries to produce a high-quality system Test Driven Development  plays central role in XP  each block is tested thoroughly  2 kinds - acceptance and unit test Continuous Integration  immediate integration  new system must pass all tests Coding Standard  common naming & formatting schemes  makes pair progamming and collective code ownership easier  rapid code sharing & reduces the learning curve

XP Project - Phases

Stages of an XP Project Initiation Use stories Spike solutions Release Planning Release Iteration 1 Iteration 1DevelopmentDeployment Acceptance Testing Iteration 2 Iteration 2DevelopmentDeployment Acceptance Testing.. Iteration n Iteration n

User Stories Short Description of the behavior of the system Customer’s point of view Customer terminology – no technical terms One for each major feature of the system Create low-risk time estimates for the project Similar to Requirements Documents but not the same Different from Use Cases – written by user, not programmer Average implementation time ( 2-3 weeks) 80 +/- 20 stories – sufficient to create a release plan. Printed on cards, similar to CRC cards.

Spike Solution Simple programs Explore solutions for tough technical / design problems Address only the problem under consideration Ignore other concerns If not good – throw away

Release Planning Create release plan for the whole project ( 1-6 months ) Programmer provides estimates of 1,2 or 3 points for each story Customer decides which stories should be included in the release Customer decides the priorities of the stories Stories chosen for the release are arranged in 1-3 week iteration High risk/high priority stories – earlier iteration Release and iteration dates are fixed.

Iteration Iteration planning meeting-beginning of each iteration Each iteration – 1-3 weeks For each iteration, user stories and failed tests are chosen Programmers break stories into tasks Programmers sign up for tasks and estimate time needed Programmers have a limitation on the task they can sign up for Can only sign up for as many points as were completed in the last iteration If the iteration is too long, Customer chooses stories to be put off for later iterations – called ‘Snow Plowing’ If iteration is too short, extra stories are added.

Acceptance Tests Same as Functional Tests – determines if the system is acceptable ‘Test First’ Principle – Tests are written first and then code is written to pass the test No code goes into production without an associated test Tests determine what code to write Customers specify the conditions to be tested These conditions are taken from user stories For each user story, there can be 1 or more tests Test scores are published to the customers and programmers Failed tests become part of the next iteration