Extreme Programming

1. Extreme Programming • Team Members • Aaron Zedonis • Cesar Garduno • Jian Song • Jose Cortes • Ko-Wei Pan Date: May 29, 2001 Class: Programming Methods Instructor: Dan Klawitter

2. Rules and Practices of Extreme Programming Planning User stories;Release planning; small releases; Business Analysis;Project Velocity; Iterations; Iteration planning; Move people around; Stand-up meeting day; Fix XP when it breaks. Designing Simplicity; System metaphor.    Use CRC cards for design sessions.Spike solutions to reduce risk.    No functionality added early.Refactor. Coding Customer is always available; Standards.    Code the unit test first; Pair programmed; Integrates often; Collective code ownership. Optimization till last; No overtime. Testing All code must have and pass unit tests before it     can be released; When a bug is found tests are created; Acceptance tests are run often and the score is published. Copyright 1999 J. Donovan Wells all rights reserved

3. Extreme programming (Jose) User Stories (Cesar) Business Analysis in XP (Pan) CRC Cards (Aaron) Extreme programming implementation example (Jian) Overview

4. Extreme Programming Overview

5. One iteration of Extreme Programming

6. Development overview

7. Programmers activities and work Style

8. User Stories

9. What are User Stories? • A user story is a short description of what the business or customer wants the software to do, written by the customer in the customer terminology without techno-syntax. • They are in the format of about three sentences typically written on 4x6 cards.

10. Purpose • User Stories are used to create time estimates for the release planning meeting. • They are also used instead of a large requirements document. • User Stories also drive the creation of the acceptance tests.

11. Example "Tell me the story and write down the name of the story and a paragraph or two." I'll put on my "Development" hat tomorrow and estimate this. Tomorrow or 'mañana'? License Enforcement When run for the first time, JeraWorks puts up a license dialog, and will not proceed until the user enters either: • a valid non-time-limited (paid) license certificate or • a valid time-limited (demo) license that has not yet expired. • A valid license is stored so the user doesn't have to re-enter it on subsequent runs. • License info is displayed on the splash screen. • When a demo license expires, the license dialog re-appears the next time JeraWorks is run.

12. User Stories & the Planning Game • The basic goal is to create a release plan • The basic pieces are the User Stories (cards) • The players are the customers and developers • The Rules: • Developers estimate how long the stories might take to implement • Business then decides which stories are going to be implemented for each release and the dates for those releases.

13. User Stories & the Planning Game (cont.) • Once the release plan is set, the selected stories are then translated into individual programming tasks that will be implemented during the iteration to complete the stories. • Each story will get a 1, 2 or 3 week estimate in "ideal development time". • A typical XP project of six to 12 months calls for between 50 and 100 user stories.

15. Requirements SpecificationsVS User Stories • level of detail • User stories are short and to the point • User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. • focus on user needs • You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts.

16. Business Analysis in Extreme Programming

17. Business Analysis in Extreme Programming XP "circle of life": • the customer decides which features have value, • programmers estimate the cost of providing the features, • the customer chooses the best combination of features based on value and cost, • programmers build the features, learning how to estimate costs in the process, • the customer learns how to define value and how to make effective choices.

18. Business Analysis in Extreme Programming • Both customers and programmers learn and prosper during the “cycle of life”. • Business analysts are added when there is a wide range of customers or the customers have difficulties in making decisions. • Advantages of adding analysts: • Both customers and programmers learn and understand more about their own work • Both customers and programmers learn and understand more about each other’s work • Improves mutual communication, accuracy and consistency of the product

19. Business Analysis in Extreme Programming • The problems with translation: • The translation interferes with learning, in both directions • Customers will not respect the programmers' work, or the estimates • Customers will lose control and decrease satisfaction • Solutions: • Business analysts should work as aides to the customer, not as an interface between customer and programmer • Have regular meetings between analysts and customers • The analysts should help the customers to write their stories instead of translating for them

20. Business Analysis in Extreme Programming • Help the customers decide the priorities instead of deciding for them • Have all the customers understanding what they should know and make them feel as much control over the project as possible • Help customers define the acceptance tests

21. CRC Cards

22. CRC Cards • Class, Responsibilities, and Collaboration Cards • A simple way to specify a design • First introduced by Kent Beck and Ward Cunningham at OOPSLA ’89 • Not specifically part of Extreme Programming • …but works well with the XP paradigm

23. What is a CRC Card? • On the top of the card is the Class • The list on the left are the Responsibilities • The list on the right are the Collaborating classes • A simple specification/design of a class, and what it does

24. How are they used? • Create cards for the obvious classes • Talk through a user story, describing how the classes interact with each other • Move cards (exploring different designs) • Add/Delete cards as needed

25. Documenting Your Design • You don’t need to keep the cards, nor do you need to produce any extra design documents. • Well written and well tested code is the documentation of the design. • Why waste time writing and updating the documentation? Or why live with out-of-date documentation?

26. But what’s wrong with UML? • Well… nothing • Why invest the time drawing pictures of a design, when in XP your design will change via constant refactoring? • CRC Cards can be a front-end for a heavier process if your project requires that (or if you just really like making the documents.)

27. XP Implementation Example

28. XP Programming example:This is a very primitive example of using XP programming methodology to revive a project. • Project Structure • Project: Customized an existing Labor Collection System. • Primary User: Human resource • Project Team: Programer1, Programer2, Senior Programmer, DBA, Project Manager. • Project Manager owns: Project plan, project source code, project user requirements. • Prog1 owns Part P1; Prog2 owns Part P2; Senior Part P3; DBA Database objects; • User contact in team: project manager.

29. Original project structure diagram. • Any communication among users and programmers goes through program manager. • Code ownership: monopoly.

30. Problems encountered: • In the absence of any member of team, work slows down or stops. • Impossible to maintain other programmer’s work; • System testing and feedback takes long time; • Programmers and users are in the dark about requirement interpretation and implementation; • Each part of system is owned by a team member;

31. When one person is gone, it’s difficult to back up the person’s work. When more than one person left, the project is to die unless some critic changes are made to project structure. • Three months into project, three people left in two months. Project looked like.

32. Implement XP with limited available human resources to revive the project: • First work in pair and take over the ownership of code left by the senior programmer using one computer in each other’s cubic. • Started to work on each others code in pair. Promote a code standard. Promote a collective ownership of project. • Perform unit test, integration test, and user test frequently on each implementation. Users are consistently available to each programmer on feedback about changes, requirements implementations. • User stories are used to describe requirements, and test the implementation. • All above had made development, modification, unit testing and integration testing much easier and faster.

33. New project diagram after following XP programming method. • Direct communication among users and programmers. No middle man; • Direct access to any resources of project. No middle barrier; • Collective ownership of project. • Project status: • In production with parallel testing three months after the change of project structure and programming method.

34. Summary We have reviewed as we said: • Extreme programming (Jose) • User Stories (Cesar) • Business Analysis in XP (Pan) • CRC Cards (Aaron) • Extreme programming implementation example (Jian)

35. References • http://www.extremeprogramming.org/ • Wiki Wiki. The Portland Pattern repository http://c2.com/cgi/wiki?UserStory • http://xprogramming.com/