Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer Science Department King Fahd University of Petroleum and Minerals March (6,13), 2004

Extreme Programming: Practices and Strategies 2 Agenda What is XP? XP Practices Management Strategy Facilities Strategy Planning Strategy Design Strategy Development Strategy Testing Strategy When to use XP?

Extreme Programming: Practices and Strategies 3 What is XP? “XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software”. -Kent Beck

Extreme Programming: Practices and Strategies 4 XP is Different Early, concrete, and continuous feedback from short-cycles. Incremental planning approach. Flexibility of scheduling the implementation based on changing business needs. Reliance on tests written by the programmers. Reliance on the collaboration of programmers.

Extreme Programming: Practices and Strategies 5 Software Processes Analysis Design Code Test WaterfallIterativeXP Kent Beck 1999

Extreme Programming: Practices and Strategies 6 XP Practices Planning game. Small releases. Simple design. Testing. Refactoring. Coding standards. Pair programming. Collective ownership. On-site customer. 40-hour week. Open workspace. Continuous integration.

Extreme Programming: Practices and Strategies 7 Management Strategy Be available as a development partner. See long term refactoring goals. Help programmers with individual technical skills like testing and refactoring. Explain the process to upper level managers. Keep track with software metrics.

Extreme Programming: Practices and Strategies 8 Management Strategy- Meeting Daily Stand-up Meeting Entire team Problems. Solutions. Stand in a circle Avoid long discussions. No side conversations.

Extreme Programming: Practices and Strategies 9 Summary of Management Strategy Coach: help, plan and manage. Track software metrics. Daily stand-up meeting.

Extreme Programming: Practices and Strategies 10 Facilities Strategy Kent Beck, Extreme Programming Explained 2000 Open space. Tables in the middle of the space. Cubbies around the outside of the space. A room with a nice view -if possible. The DaimlerChrysler C3 work area

Extreme Programming: Practices and Strategies 11 Planning Strategy- Guidelines Only plan -in details- for the next release. Accepted responsibility. The person responsible for implementation gets to estimate.

Extreme Programming: Practices and Strategies 12 Planning: User Stories User stories are written by the customers – features the system needs to do Stories that are most valuable to the customer are developed first. Much simpler format than traditional requirements specifications: 3 sentences written by customers. Non-technical terminology.

Extreme Programming: Practices and Strategies 13 Planning -Story Card Kent Beck, Extreme Programming Explained 2000

Extreme Programming: Practices and Strategies 14 Planning: Iterations Developers give each user story an estimate of 1, 2, or 3 weeks. Stories are then organized in order of importance to the customer. The development schedule is divided into iterations of 1 to 3 weeks in length based on the user stories.

Extreme Programming: Practices and Strategies 15 Planning: Releases Releases are iterative versions of the system released by the development team to the customers. Released at the end of iteration. An integrated working system. Includes the latest successfully implemented, integrated, and tested story from that iteration.

Extreme Programming: Practices and Strategies 16 Story Breakdown Iterations assigned for the development of each story Customer System Priority Organization of user stories Release 1Release 2Release 3 Story 1Story 2Story 3 Division of system into user stories Iteration 1 Iteration 2 Iteration 3 Story 2Story 3Story 1

Extreme Programming: Practices and Strategies 17 Iteration Breakdown Each iteration is broken down into programming tasks for developing the user story of that iteration. Each task is 1-3 days in duration. Each programming pair choose a task (or more). The programming pair then design test cases and implement them.

Extreme Programming: Practices and Strategies 18 Iteration Breakdown Test Case 3 Integrate into the system Passed Test Case 2Test Case 1 Task 3Task 2Task 1 One iteration Development of one user story

Extreme Programming: Practices and Strategies 19 Summary of XP Planning User Stories Priorities IterationsReleases Tasks Test Cases

Extreme Programming: Practices and Strategies 20 Design Strategy -Rules Always do the simplest thing that could possibly work. Use CRC cards for design One card per object.

Extreme Programming: Practices and Strategies 21 Design Strategy -Rules Never add functionality early. “Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time” “Concentrate on what is scheduled for today only” ExtremeProgramming.org Refactor: replace anything complex with something simpler. Remove redundancy. Eliminate unused functionality. Enhance efficiency.

Extreme Programming: Practices and Strategies 22 Summary of Design Rules The goal is simple code on time so: Keep things simple and clean. Refactor. Stick to the planned schedule.

Extreme Programming: Practices and Strategies 23 Development Strategy -Guidelines Collective code ownership Encourages all programmers to contribute to all segments of the project. Coding standards Consistency saves time and money. Makes it easier for the entire team to code and refactor.

Extreme Programming: Practices and Strategies 24 Development Strategy -Guidelines Write the test case before the code. Continuous integration. 40 hour week Projects requiring overtime will be late anyway. Avoid overtime. Pair programming.

Extreme Programming: Practices and Strategies 25 Pair Programming Two brains are better than one. Pairs consider more possible solutions to a problem. Design alternatives increase.

Extreme Programming: Practices and Strategies 26 Pair Programming Individuals (mean) Teams (mean) Readability Functionality Score Confidence Enjoy Time John Nosek, “The Case for Collaborative Programming,” Communications of the ACM, March 1998, Vol. 41, No. 3 pp

Extreme Programming: Practices and Strategies 27 Summary of Development Strategy Write the test case before the code. Collective code ownership. Coding standards. Continuous integration. Pair programming. 40 hour week.

Extreme Programming: Practices and Strategies 28 Testing Strategy –Unit Testing Unit testing (test cases) Programmers write their own unit tests Create tests BEFORE the code. Programmers implement one unit test at a time. After 100% of unit tests are passed, that unit can be integrated. During integration, all previous tests are run to verify the overall system still runs.

Extreme Programming: Practices and Strategies 29 Testing Strategy -Integration Code integration One pair at a time. Prevents problems introduced when integrating modules. Maintain a latest version. Allows for parallel coding. Integrate often.

Extreme Programming: Practices and Strategies 30 Testing Strategy -Acceptance Test Acceptance tests User stories are the basis for acceptance testing. Black box testing.

Extreme Programming: Practices and Strategies 31 Summary of Testing Pair Programming Continuous Integration 100% Unit Tests Passed Acceptance Tests Passed Create Unit Test Failed Passed End of Task Run all unit tests ExtremeProgramming.org

Extreme Programming: Practices and Strategies 32 Customers Customer availability On site customer. Duties Write stories. Define the priorities of the stories. Define the scope or timing of releases.

Extreme Programming: Practices and Strategies 33 XP Favorable Conditions Dynamically changing requirements and functionality. Small groups of programmers Short-term projects. Input by customers and managers. Testability.

Extreme Programming: Practices and Strategies 34 Companies That Use XP Thought works. Acxiom. Chrysler. Knowledge management software. Andrena objects. EuropeLoan bank. Evant solutions. Workshare technology.

Extreme Programming: Practices and Strategies 35 References “Extreme Programming Explained: Embrace Change,” by Kent Beck “Planning Extreme Programming,” by Kent Beck, Martin Fowler “Extreme Programming Installed,” by Ron Jeffries, Ann Anderson, Chet Hendrickson, Kent Beck, Ronald E. Jeffries “Extreme Programming in Practice,” by James W. Newkirk, Robert C. Martin “Extreme Programming Examined,” by Giancarlo Succi, Michele Marchesi

Extreme Programming: Practices and Strategies 36 Websites

Extreme Programming: Practices and Strategies 37 Questions?