Extreme Programming

1. XP Extreme Programming

2. Goals for Presentation • Explain the basics of software development methodologies • Explain basic XP elements • Show the structure of an XP project • Give a few simple examples

3. DESIRED Customer Satsification Our Hopes DELIVERED

4. DESIRED Customer Satsification Our Reality DELIVERED

5. Common Breakdowns Problem: We just had this great idea. Forget what we told you last time. . . Problem: Six months of meetings and we have nothing to show for it… Problem: When we went to install this, we found out this will need to be done in Perl. Is that a problem? Problem: This isn’t what I wanted….

6. Software Methodologies Formally Address… • Requirement Analysis – Specifying what it needs to do • System Design – Specifying how it will do it • Implementation Techniques - Specifying when it will do it • Deployment strategies – Specifying where it will do it … Providing techniques to accomplish each.

7. DESIRED Making this connection is requirement analysis. It is where most projects fail. It is the hardest job for most programmers. Methods for this are critical!

8. THE Question For software developers How little can we do and still build great software? From XP Agile Universe

9. Extreme Programming • Evolutionary – Assumes customers will change their minds. • Light-weight – Minimizes excessive documentation • Fast – Produces tested software in 1 to 2 week cycles • Rapid Assessment - Customers are activity involved in all phases. Hence, the term Agile

10. From the web site http://www.extremeprogramming.org/ It is an excellent resource and I strongly recommend reviewing it.

11. XP Element – User Story • They are a one to three sentence description of how the customer envisions using the system. • They are written by the customer. • They are written on 3” x 5” card. • The programmer assigns a time estimate to it in terms of ideal programmer weeks. • They are written in the language of the customer and not in programmer techno-jargon. Note that no lengthy requirement document is produced.

12. XP Element – User Story Some pages trigger the login mechanism and some don’t. The list of pages that do/don’t is dynamic. And the mechanism is triggered once per session. One day Taken from Extreme Programming in Practice By Newkirk and Martin Example

13. XP Element – Acceptance Test • The customer must supply an acceptance test for each user story. • It is detailed scenario that will determine whether the user story is operational. • The customer is responsible for verifying accuracy. • All acceptance tests are run whenever the system is changed in any way. Hence they should be automated.

14. XP Element – Acceptance Test Automated testing is facilitated through unit test software. Many packages to do this are on sourceforge. A nice summary is found at http://c2.com/cgi/wiki?TestingFramework Example

15. XP Element – Spike • A small, simple program written to resolve uncertainty. • Normally done to improve an time estimated associated with a user story. • Expect to throw the effort away. • Try not to spend much time doing it

16. User Story Summary Customer Programmer Writes Story Provides Estimate Spike Specifies Acceptance Test Verifies Acceptance Test

17. XP Element - Velocity • The velocity of a set of user stories is the sum of the estimates, which is given in terms of ideal programmer weeks. • The velocity of an individual is the number of ideal days per real days. (For example, velocity = ½ means it takes two real days to do an ideal day.)

18. Project Structure • Each Project is subdivided into a series of Releases. Typically a release is of 1 to 3 months. • Each release is sub-divided into Iterations. Each iteration is 1 to 3 weeks. • Velocityis held constant.

19. XP Element – Release & Iteration Customer Programmer Determines User Story Priorities Determines Release Duration Limits number of user stories Determines velocity Selects user stories Within the constraint

20. XP Element – Release & Iteration Iteration duration: 1 real week Release duration: 3 iterations or 3 real weeks Individual velocity: 1/3 ideal days per real day Pair velocity: 2/3 ideal/real 15 real x 2/3 ideal/real = 10 ideal days allowed for the release roughly 3 ideal days for each iteration Always work in pairs No overtime Allowed! Example

21. XP Element - Task • The user stories selected for an iteration are broken down into programming tasks. • These tasks are written on index cards like user stories. • Tasks are written by programmers in the language of programmers. • Programmers are allowed to select their own tasks. • A time estimate in ideal days is assigned to each task by the programmer who selected it.

22. XP Element – Task Registration Servlet Task Pull data from HTML input. If e-mail present in database go to “forgot password” screen. Else Generate password. Insert user into database. E-mail password to e-mail then go to login screen. Jim 4 hours Taken from Extreme Programming in Practice By Newkirk and Martin Example

23. XP Element –Iteration & Task There are two time estimates for an iteration: user story view & task view Customer Programmer Determines User Story For iteration Determines Programming Tasks Estimates iteration velocity Estimates time on task Moves user stories to Next iteration, if needed

24. Writing the Code • Unit tests are written first. • All programming is done in pairs. Two people work on a shared computer. • Only one pair integrates at a time. • No overtime!

25. Testing the code • All code must have unit tests based on the acceptance tests. • All code must pass unit tests before it can be released. • Errors lead to new unit tests. • Acceptance test scores are published.

26. From the web site http://www.extremeprogramming.org/ It is an excellent resource and I strongly recommend reviewing it.