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

5. Common Breakdowns Problem: This isn’t what I wanted…. 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: We just had this great idea. Forget what we told you last time...

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. 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. From XP Agile UniverseXP Agile Universe THE Question For software developers

9. 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.http://www.extremeprogramming.org/

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

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.sourceforge A nice summary is found at http://c2.com/cgi/wiki?TestingFramework

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 Specifies Acceptance Test Verifies Acceptance Test Provides EstimateSpike

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. Velocity is held constant.

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

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 Alway s work in pairs No overtime Allowed !

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

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

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.http://www.extremeprogramming.org/