Introduction to Extreme Programming

Transcription

1 Introduction to Extreme Programming References: William Wake, Capital One Steve Metsker, Capital One Kent Beck Robert Martin, Object Mentor Ron Jeffries,et.al. 12/3/2003 Slide Content by Wake/Metsker 1 Extreme Programming is... An Agile software development method used for small to mediumsized development projects Philosophy about how to develop code rather than rules for design Emphasizes: ongoing user involvement pay-as-you-go design incremental, test-first programming 12/3/2003 Slide Content by Wake/Metsker 2 Why is it Extreme? Because it takes good practices to extreme levels ( turning the knobs up to 10! ): If code reviews are good, we ll review code all the time (pair programming). If testing is good, everybody will test all the time (unit testing), even the customers (Acceptance Testing). If design is good, we ll make it part of everybody s daily business (Refactoring). If simplicity is good, we ll always leave the system with the simplest design that supports its current functionality. (The simplest thing that could possibly work. --Bob Martin 12/3/2003 Slide Content by Wake/Metsker 3 1

2 Turning the Knobs to 10 (Cont). If architecture is important, everybody will work defining and refining the architecture all the time (Metaphor). If integration testing is important, then we ll integrate and test several times a day (continuous integration). If feedback is good, we ll get feedback quickly -- seconds and minutes and hours, not weeks and months and years (the Planning Game). --Bob Martin 12/3/2003 Slide Content by Wake/Metsker 4 XP Requirements There are certain things you must do. You must write tests before code. You must program in pairs. You must integrate frequently. You must be rested. You must communicate with the customer daily. You must follow the customer s priorities. You must leave the software clean and simple by the end of the day. You must adapt the process and practices to your environment. 12/3/2003 Slide Content by Wake/Metsker 5 XP Principles Rapid feedback Assume simplicity Incremental change Embrace Change Quality Work Small releases Establish metaphor Tests On-site customer 40-hour week Open workspace 12/3/2003 Slide Content by Wake/Metsker 6 2

3 XP Practices - Development Planning game Pair programming Simple design Refactoring Collective ownership Continuous integration Coding standards 12/3/2003 Slide Content by Wake/Metsker 7 XP Process The Planning Game Release Planning Iteration Planning The Programming Game 12/3/2003 Slide Content by Wake/Metsker 8 Release Planning Large scale planning for the overall project Story is one thing that the customer wants the system to do Tasks: Create stories Prioritize stories 12/3/2003 Slide Content by Wake/Metsker 9 3

4 Iteration Planning Developers determine what stories can be done within schedule Developer Tasks: Read customer stories Brainstorm tasks Estimate task completion time Negotiate with customer to accept tasks 12/3/2003 Slide Content by Wake/Metsker 10 Programming Game Incremental, test-first programming Tasks: listen build unit test Test everything that could possibly break code design (refactor) Track time for task completion 12/3/2003 Slide Content by Wake/Metsker 11 Tests Functional Tests Unit Tests 12/3/2003 Slide Content by Wake/Metsker 12 4

5 Functional Tests Specified by the user(i.e. customer) Implemented by users, developers, and/or test team Automated Run at least daily Part of the specification 12/3/2003 Slide Content by Wake/Metsker 13 Unit Tests Written by developers Written before and after coding Support design, coding, refactoring, and quality. 12/3/2003 Slide Content by Wake/Metsker 14 Code Approach Write a small test Run ==> compiler error Write enough code to compile Run ==> test fails Write enough code to pass the test Run ==> test succeeds Repeat from top 12/3/2003 Slide Content by Wake/Metsker 15 5

6 Game Play Write code test-first Use JUnit for tests Track time for task completion 12/3/2003 Slide Content by Wake/Metsker 16 Design - part of coding Pay as you go Spike when necessary You aren t gonna need it Simplest thing that could possibly work Once And Only Once rule 12/3/2003 Slide Content by Wake/Metsker 17 Refactoring Game Refactor code until it Works (passes tests) Communicates what it needs to Has no duplication Has as few methods and classes as possible Eliminate code smells Classes too large Methods too long struct classes Useless comments Almost (but not quite) duplicated code 12/3/2003 Slide Content by Wake/Metsker 18 6

7 Refactoring Example Extract Method (Wake) : String s=reader.readline(); //assemble dashed string int p1 = s.indexof( # ); int p2 = s.lastindexof( # ); result = s.substring(0,p1) s.substring(p2, s.length()); : : String s=reader.readline(); result=assembledashedstring(s); : public static String assembledashedstring(string s) { int p1 = s.indexof( # ); } int p2 = s.lastindexof( # ); String dashed = s.substring(0,p1) s.substring(p2, s.length() ); return dashed; 12/3/2003 Slide Content by Wake/Metsker 19 Refactoring Example (Wake) Replace Magic # w/ Symbolic Constant: return 32.5 * miles_traveled; Separate Query from Modifier: Stack: Object gettopandpop(); static final double MILEAGE_RATE = 32.5; return MILEAGE_RATE * miles_traveled; Object gettop(); void pop(); 12/3/2003 Slide Content by Wake/Metsker 20 Other Development Approaches UML: XP uses it on the whiteboard, if at all CRC: XP uses them for discovering objects in the system Rational Unified Process: XP has many fewer roles & documents; XP emphasizes team over artifacts --Bob Martin 12/3/2003 Slide Content by Wake/Metsker 21 7

8 User Story User Story defined: Unit of functionality in an XP project Written in the language of business Focus development team on solving key business problems, not specification conversion Promise for conversation User Story example: Terry the Traveler finds the lowest fare Terry the Traveler books a flight 12/3/2003 Slide Content by Wake/Metsker 22 User Story Gathering Session User Stories are recorded in a Master List User Stories are assigned risk-level User Stories are estimated Team assumption is made Plan is created based on 3-5 week iterations 12/3/2003 Slide Content by Wake/Metsker 23 Writing Stories The process of writing stories is iterative and requires lot of feedback. Customers will propose a story to the programmers. The programmers will ask themselves if the story can be tested and estimated, and if it is of appropriate size. 12/3/2003 Slide Content by Wake/Metsker 24 8

9 Writing Stories (contd.) The customer will have to specify acceptance tests whose execution will determine whether the user stories have been successfully implemented. Thus all the user stories must be testable Splitting of user stories possible. 12/3/2003 Slide Content by Wake/Metsker 25 User Story Form Date: Type: New Fix Enhance Func Test: Story #: Priority User: Tech: Prior Reference: Risk: Tech Estimate: Task Description: Notes Task Tracking: Date Done To Do Comments 12/3/2003 Slide Content by Wake/Metsker 26 Estimating Stories 3 keys to effective estimation: Keep it simple Use what happened in the past Learn from experience Estimation is a team effort Estimates are not commitments If we don t know enough about solving some problem to be able to estimate it, write some sample code to help us learn to estimate (Spike Estimation). 12/3/2003 Slide Content by Wake/Metsker 27 9

10 Project Velocity This is a measure of how fast work is getting done on the project. Count up the number of stories or tasks completed during the last iteration. Then total up the estimates, each task received. This is the velocity. We may need to re -negotiate the release plan if our velocity changes dramatically for more than one iteration. 12/3/2003 Slide Content by Wake/Metsker 28 Iterative Planning and Development Divide the development schedule into about a dozen iterations of 1 to 3 weeks in length. Create an iteration plan at the start of each iteration. User stories are chosen from the release plan in priority order to be implemented. These stories are translated into tasks, broken down so each task is 1 to 3 days in length. Developers sign up for the tasks and then estimate how long their own tasks will take to complete. 12/3/2003 Slide Content by Wake/Metsker 29 Iterative Planning and Development (cont.) Total up the time estimate in ideal programming days of the tasks, this must not exceed the project velocity from the previous iteration. If the iteration has too much, then some stories must be postponed until the next iteration. The release plan and the iteration plan are not the same thing. The former focuses on deliverables to the customer while the latter concentrates on implementation. The iteration plan is for the near-term and is more detailed. 12/3/2003 Slide Content by Wake/Metsker 30 10

11 XP Timeline Customer Write stories Pick stories Developers Estimate stories Implement stories 12/3/2003 Slide Content by Wake/Metsker 31 11