EXtreme Programming explained: embrace change by Kent Beck, Addison Wesley, September 1999.

Transcription

1 XP XP extreme programming (slides partially from Andrew Black, Ras Bodik, and Dan Klawitter s letures) EXtreme Programming explained: embrace change by Kent Beck, Addison Wesley, September What is XP? a light-weight methodology for small to medium sized teams developing software in the face of vague and rapidly changing requirements Why XP? traditional software development methodologies are too rigid and over-constraining, they do not work for small projects, Is XP a religion? 1 2 XP Why XP? XP in context Kent Beck has a Smalltalk background He is part of the Design Pattern community He has worked with Fowler on Refactoring XP and traditional Methodologies XP runs counter to almost all software engineering practice, XP is not a solution for all problems (mostly for small teams), XP is programmer friendly The Risks of Software Development Schedule slips the delivery date is always six months in the future Project canceled after many slips, project canned System goes sour after a couple of years of operation and some changes, bugs start to appear Defect rate so buggy that it is not used Business misunderstood software does not answer all the right questions Business changes the system answers the wrong (out of date) questions False feature rich lots of unused features Staff turnover where have all the good programmers gone? 3 4 1

2 Why XP? Why XP? XP to the rescue Schedule slips short release cycles to limit the scope of slips within release XP uses 1 to 4 wks customer-requested feature iterations within an iteration, 1-3 day tasks implement most important features first, to minimize the impact of slips Project canceled Customer involvement to choose the smallest possible release, to minimize potential bottlenecks and maximize software value. System goes sour create and maintain a comprehensive suite of tests run tests after every change Defect rate unit test (programmer defined) functional tests (user defined) XP to the rescue Business misunderstood customer is an integral part of the team specification continuously refined Business changes shorter release cycles imply less change during development unimplemented features can be replaced at no cost False feature rich only highest priority tasks are addressed Staff turnover religion 5 6 The XP premise The cost of change plays a key role in most software engineering methodologies The XP premise What if the cost of change did not rise exponentially? Cost of change Cost of change REQUIREMENTS ANALYSIS DESIGN IMPLEMENTATION TESTING PRODUCTION TIME 7 8 2

3 The XP premise The Basics How does the premise affect software development? XP relies on 12 principles that are used as guides during the development process. Instead of making big decisions early and little ones late, XP makes each decision quickly, backs them with tests, and is also prepared to modify designs. XP separates software development into 4 activities, these are roles a software engineer can play XP advocates 12 practices that describe how to approach the development process 9 10 The 12 XP principles The 12 XP principles 1. Rapid feedback 2. Assume simplicity 3. Incremental change 4. Embracing change 5. Quality work 6. Small initial investment 7. Concrete experiments 8. Open, honest communication 9. Accepted responsibility 10. Local adaptation 11. Travel light 12. Honest measurements 1. Rapid feedback generate feedback, interpret it and put experience in the system as frequently as possible business learns the benefits and shortcoming of the systems programmers lean how to best test, design, implement seconds/minutes instead of weeks/months 2. Assume simplicity do not design for reuse plan for today and trust your ability to add complexity in the future

4 The 12 XP principles The 12 XP principles 3. Incremental change designs change a little at a time plans change a little at a time teams change a little at a time 4. Embracing change best strategies preserve most options while solving the pressing problems 5. Quality of work quality is not a free variable: the only possible values are excellent and insanely excellent 6. Small initial investment tight budgets force programmers and customers to focus on essentials avoid comfort 7. Concrete experiments every abstract decision should be test the result of a design session should be a series of experiements The 12 XP principles The 4 XP activities 8. Open, honest communication deliver the bad news early 9. Accepted responsibility responsibilities should not be given, they should be accepted 10. Local adaptation there are no fixed rules 11. Travel light keep things small, maintain only the essential 11. Honest measurements strive for accurate measurement of productivity CODING TESTING LISTENING DESIGNING

5 Life Cycle The 12 XP practices Like iterative, but putting to extreme Short cycle (2 weeks): 1. Meet with client to elicit requirements User stories + acceptance tests 2. Planning game Break stories into tasks, estimate cost Client prioritizes stories to do first 3. Implementation Wit Write programmer tests t first Simplest possible design to pass the tests Occasionally refactor the code 4. Evaluate progress and reiterate from step The Planning Game quickly determine scope of next release 2. Small releases put a simple system in production quickly then release new version on a short cycle 3. Metaphor guide development with a simple shared story 4. Simple design system should be as simple as possible, complexity should be removed if at all possible 5. Testing continually write unit tests, customers write functional tests 6. Refactoring restructure the system without changing behavior 7. Pair programming g all code written with 2 programmer at 1 machine 8. Collective ownership anyone can change code anywhere anytime 9. Continuous integration integrate and build many times a day hour week work no more than 40h/wk as a rule 11.On-site customer include a real, live user on the team full time 12.Coding standards code in accord. to rules emphasizing communication 18 Planning Game Example User stories = lightweight use cases 2-3 sentences on a file card (4X6) that the customer cares about can be reasonably tested can be estimated & prioritized Users write stories Stories-> tasks Developers estimate them Users split, merge, & prioritize Plan overall release (loosely) and the next iteration Don t plan too far ahead Create account I can create named accounts List accounts I can get a list of all accounts Question: How is the list ordered? I can get an alphabetical list of all accounts Query account balance I can query account balance Delete account I can delete a named account Question: Even if the balance is not zero? I can delete a named account if the balance is not zero

6 Example Tasks 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. Each story is broken into tasks To split the work and to improve cost estimates Story: customer-centered description Task: developer-centered description Example: Story: I can create named accounts Tasks: ask the user the name of the account check to see if the account already exists create an empty account Break down only as much as needed to estimate cost Tasks Small Releases Validate the breakdown of stories into tasks with the customer If a story has too many tasks: break it down Team assigns cost to tasks We care about relative cost of task/stories Use abstract units (as opposed to hours, days) Experience will tell us how much a unit is Developers can assign units by bidding: I can do this task in 2 units Make every release as small as possible Release makes sense as a whole Make simple designs, sufficient for the current release Small releases provide: rapid feedback sense of accomplishment reduced risk customer confidence adjustments to changing requirements

7 Metaphor Simple Design Guide the project with a single Metaphor e.g., the UI is a desktop Must represent the architecture makes it easier to discuss The customer must be comfortable with it The right design for software: Runs all the tests. Has no duplicated d logic (DRY principle) i States every intention important to the programmers. Has the fewest possible classes and methods Don t worry about having to change a design later CRC Cards What is a CRC Card? Class, Responsibilities, and Collaboration Cards A simple way to specify a design First introduced d by Kent Beck and Ward Cunningham at OOPSLA 89 Not specifically part of Extreme Programming but works well with the XP paradigm 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 27 7

8 How are they used? Documenting Your Design 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 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? Testing Test Driven Development XP tests everything that might possibly break, all the time The tests are the specification: An executable specification Two kinds of tests: Functional Tests Specified by the user; implemented by users, developers, and/or test team; automated; run at least daily; part of the specification Unit Tests Written by developers Written before and after coding Always run at 100% Support design, coding, refactoring, and quality. Write unit tests before implementing tasks Unit test: concentrate on one module Start by breaking acceptance tests into units Example of a test addaccount( checking ); if(balance( checking )!= 0) throw ; try { addaccount( checking ); } catch(duplicateaccount e) { };

9 Why Write Tests First Refactoring Testing-first clarifies the task at hand Forces you to think in concrete terms Helps identify and focus on corner cases Testing forces simplicity Your only goal (now) is to pass the test Fight premature optimization Tests act as useful documentation Exposes (completely) the programmer s intent Ensures that you think about testability first How will you know when you are done? In what order do you need to test components? What infrastructure you need to test? Refactor = to improve the structure of code without affecting its external behavior Done in small steps Supported by unit tests, simple design, and pair programming Seek once and only once Refactoring in pairs gives you more courage and confidence Pair Programming Collective Code Ownership Role of one partner uses the mouse and the keyboard thinks about the best way implementing the method Role of the other is the approach going to work think about test cases can it be done simpler Pairing is dynamic Pairing provides discipline Pairing spreads knowledge about the system Anybody can add to any portion of the code subject to current requirements subject to simple design Unit tests protect the system functionality Whoever find a problem, solves it Everybody is responsible for the whole system

10 Continuous Integration 40 Hour Week Integration of tested code every few hours (max. a day) All unit tests need to run successfully If a test fails the pair has to repair it If you can t repair it, throw away the code and start again If you can t do your work in 40 hours, then you have too much work 40-Hour weeks keeps you fresh to tackle problems It prevents making silly, hard to find mistakes late at night Frequent planning prevents you from having too much work Overtime is a symptom m of a serious problem On-Site Customer Writes functional tests Makes priority and scope decisions for the programmers Answers questions Does his or her own work If you cann t get a on-site customer Maybe the project is not important enough

11 Coding Standards Extreme Programming in Summary Complicated constructions are not allowed let s keep things simple Code looks uniform easier to read No need to reformat the code no curly brackets wars 41 What is Different About XP When to Use XP No specialized analysts, architects programmers, testers, and integrators every XP programmer participates i t in all of these critical activities every day. No complete up-front analysis and design start with a quick analysis of the system team continues to make analysis and design decisions throughout development. Use for: A dynamic project done in small teams (2-10 people) Projects with requirements prone to change Have a customer available Do not use when: Requirements are truly fixed Cost of late changes is very high Your customer is not available (e.g., space probe)

12 In Conclusion XP Programming example (by Dan s team) A lightweight development process that emphasizes active and ongoing customer involvement pay-as-you-go design test-before-you-implement This is a very primitive example of using XP programming methodology to revive a project. Project Structure Project: Customize 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 Original project structure diagram. Any communication among users and programmers goes through program manager. Code ownership: monopoly. P1, P2, P3 R and Data Prog1 P1 Program manager Pro 2 DBA P2 User Senior Pro. P3 R 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; Data 48 12

13 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. P1, P2, P3 R and Data Prog1 P1 Pro 2 P2 User P3 R 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. Started to work on each others code in pair. Promote a code standard. Promote a collective ownership of project. Perform unit testing, integration testing, 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. Data 50 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. P1, P2, P3 R and Data Prog1 Pro 2 User Pro Lead 13