Extreme Programming, XP Literature Annika Silvervarg • Extreme Programming Explained by Kent Beck • Extreme Programming Pocket Guide by chromatic Overview • • • • What is XP Values and principles Practices Workspace Roles What is XP? • Values – Large-scale criteria used to judge what we see, think and do – Universal • Principles – Bridge the gap between values and practices – Can be used to add practices – Domain-specific guidelines Values • • • • • Communication Feedback Simplicity Courage (Respect) • Practices – Things you actually do – Intensely situated 1 Value – Communication • • • • Honest, regular communication allows you to adjust Customer – what to do, priorities Developer – how things will be done and when Communication create a sense of team and cooperation Value – Feedback • Change creates the need for feedback • Customer – test of prototypes, implemented features • Developer – test of prototypes, test-driven programming • Strive to generate as much feedback as can be handled as quickly as possible Value – Simplicity • Code for today • Communication and Feedback should help decide exactly what is needed Value – Courage • The courage to speak truths fosters communication • The courage to discard failing solutions encourage simplicity • The courage to seek real, concrete answers creates feedback • If you made a mistake, admit it and then fix it Value – Respect • The contributions of each person on the team need to be respected • Respect your own work, strive for high quality Principles • • • • • • • Humanity Economics Mutual benefit Self-similarity Improvement Diversity Reflection • • • • • • Flow Redundancy Failure Quality Baby steps Accepted responsibility 2 Principle – Humanity • Developers are humans, with basic human needs: – – – – – Basic safety Accomplishment Belonging Growth Intimacy • Balance the needs of individuals with the needs of the team Principle – Economics • Development must have business value, meet business goals and serve business needs, for example solving the highest priority business need first maximize the value of the project • A dollar today is worth more than a dollar tomorrow, earn money sooner and spend money later – Pay-per-use – realize revenue from features as soon as they are deployed • Value as options for future (i.e. reuse) – Enhance option value of team and software without speculative flexibility Principle – Mutual benefit • • • • Every activity should benefit all concerned Most important and most difficult Benefit me now, me later and customer Win-win practices like Principle – Self-similarity • Copy a structure (a solution) that works to another context, even at different scales • For example – User stories and tests – Test-drive programming – Refactoring – Coherent code style Principle – Improvement • Perfect is a verb (förbättra) not an adjective (perfekt) • Get an activity started, do the best you can today, and refine the solution over time Principle – Diversity • Teams need a variety of skills, attitudes and perspectives • Diversity often lead to conflict, i.e. many ways to look at and solve a problem • Remember respect and communication! 3 Principle – Reflection • Do the work, think about how you do it, and why its working (not working) • Expose mistakes and learn from them • Both shared in team and individually Principle – Opportunity • Problems are opportunities for change • (Positive attitude/thinking) Principle – Failure • To try and fail provides knowledge • If you don’t know the best way try all (or many) Principle – Flow • Continuous flow of activities rather than discrete phases • Integrate and deploy often Principle – Redundancy • Critical difficult problems should be handled in several different ways (with many practices) • For example, defects when coding are prevented through pair programming, continuous integrations, real customer involvement, test first programming etc. Principle – Quality • If you do not know the best way to do something – do the best you can • If you do know the best but it would take to long – do the best you can in the time you got 4 Principle – Baby steps Principle – Accepted responsibility • Don’t do big changes in big steps • What is the least you can do that is recognizable in the right direction? • Responsibility cannot be assigned – you decide if you take responsibility or not • With responsibility comes authority Practices eXtreme… • Practices have purpose given values • Practices are situation dependent • Practices work well together – The interaction between practices amplify their effects Taking proven practices to the extreme: • If testing is good, let everybody test all the time • If code reviews are good, review all the time • If design is good, refactor all the time • If integration testing is good, integrate all the time • If simplicity is good, do the simplest thing that could possibly work • If short iterations are good, make them really, really short The 12 Practices • The Planning Game – Release planning – Iteration planning • Common vocabulary • Testing – Acceptance tests – Unit tests • On-site Customer • • • • • • • • Pair Programming Simple Design Coding Standards Refactoring Collective Ownership Continuous Integration Sustainable pace Small Releases Practices in workflow • • • • • • • • • • • • Release planning (Planning game) Iteration planning (Planning game) Choose metaphor/vocabulary (Common vocabulary) Write acceptance tests (Test-driven development) Pair up (Pair programming) Write unit test (Test-driven development) Code (Code and Design Simply, Coding Standards) Ask user for clarification (On-site customer) Clean up (Refactoring, Collective code ownership) Check in test and code (Continuous integration) Go home after 8 hours (Sustainable pace) Release (Small releases) 5 The Planning Game • Goal: schedule the most important tasks • Customer presents the desired features to the programmers • Programmers estimate their difficulty • Customer lays out a plan for the project Release planning – Step 1 • Customers write user stories – Each story represents a desired feature and all stories represent the specification of the system – About three sentences of text in the customers terminology – Provide enough detail to make a reasonably estimate of how long the story will take to implement – Stories should be assigned business value: essential, highly valuable or good idea – Developers can suggest stories but the customer has always final say – Stories can be added, changed or deleted during the project User story template • Title (one line describing the story) • Narrative: As a [role] I want/can [feature] (So that/because [benefit]) User story examples Initial: • The user can search for a book After clarification: • The user can search for a book by Title, and display the result as a list Release planning – Step 2 • Developers estimate how long the stories might take to implement – Each story will get a 1, 2 or 3 days estimate in ideal development time – Longer than 3 days means that the customer need to break the story down further and less than 1 day that it is at too detailed a level, combine some stories – Stories should be assigned technical risk: low, medium, high Release planning – Step 3 • Together developers and customers move the cards around on a large table to create a set of stories to be implemented as the first/next release – A useable, testable system that makes good business sense delivered early is desired – You may plan by time or by scope • • either how many stories can be implemented before a given date (time), or how long a set of stories will take to finish (scope) 6 Iteration planning • A practice whereby the team is given direction every couple of weeks • During Iteration Planning, the Customer presents the features desired for the next iteration • The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning) • Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration The Planning Game – Advantages • Reduction in time wasted on useless features • Greater customer appreciation of the cost of a feature • Less guesswork in planning Testing • Goal: prove that the code works as it should • Acceptance tests test the functionality of the whole system (customer) • Unit tests test the components (developers) • Once the test runs, the team keeps it running correctly thereafter. This means that the system only improves, always notching forward, never backsliding Project velocity • With six programmers and two-week iterations, a total of 60 programmer-days (6 programmers x10 days) are available • With an initial velocity set to 1/3, a good start would be to plan 20 ideal days worth of work in the iteration The Planning Game – Disadvantages • Customer availability • Is planning this often necessary? Testing • Unit Tests and Functional Tests • Test a little, code a little… – “Test-first programming” • Tests become the specification • Tests give confidence in the system • Tests give courage to change the system 7 Acceptance test • Acceptance tests are created from user stories • During an iteration the user stories selected will be translated into acceptance tests by the customer • A story can have one or many acceptance tests, each acceptance test represents some expected result from the system • Customers are responsible for verifying the correctness of the acceptance tests and decide which failed tests are of highest priority to fix in the next iteration Acceptance test examples • User story – Search for book by Title • The user can search for a book by Title, and display the result as a list • Acceptance test Given a book title and a database where books with this title exist, When the user searches Then the books with the title are displayed in a list Testing – Advantages • Unit testing promote testing completeness • Test-first gives developers a goal • Automation gives a suite of regression test Acceptance test template • Scenario 1: Title • Narrative: Given [context] (And [some more context]...) When [event] Then [outcome] (And [another outcome]...) Acceptance test examples cont • Acceptance test Given a book title and a database where books with this title are missing, When the user searches Then the message “No books that match the query” is displayed Testing – Disadvantages • Automated unit testing isn’t for everything • Reliance on unit testing isn’t a good idea • A test result is only as good as the test itself 8 Common vocabulary • Goal: communicate ideas about code clearly • A common set of terminology • Can use a metaphor (doughnut factory for message delivery) • Should be changed, simplified, clarified when needed Metaphor – Disadvantages • Often the metaphor is the system • Another opportunity for miscommunication • The system is often not well understood as a metaphor Metaphor – Advantages • Encourages a common set of terms for the system • Reduction of buzz words and jargon • A quick and easy way to explain the system Pair Programming • Goal: spread knowledge, experience and ideas • Pairs work together on (small) tasks • Two different roles: – Driver focus on details of the task, – Navigator focus on project as whole • Roles should be switched at intervalls Pair Programming Benefits • 15% less output than 2 solo programmers • Continuous code review: better design, fewer defects • Confidence to add to or change the system • Discipline to always test and refactor • Teach each other how the system works (reduced staffing risks) • Learn from partner’s knowledge and experience (enhances technical skills) Pair Programming – Advantages • Two heads are better than one • Focus • Two people are more likely to answer the following questions: – Is this whole approach going to work? – What are some test cases that may not work yet? – Is there a way to simplify this? 9 Pair Programming – Disadvantages • • • • http://www.cenqua.com/pairon/ Many tasks really don’t require two programmers A hard sell to the customers Not for everyone Simple Design – Advantages • • • • Time is not wasted adding superfluous functionality Easier to understand what is going on Refactoring and collective ownership is made possible Helps keeps programmers on track Coding Standards • Goal: communicate ideas clearly through code • Start with existing style guides and naming conventions • Conventions that evolves with the project • All code should look the same – ideally it should not be possible to determine who coded what based on the code itself Code and Design Simply • Goal: code that is easy to change • Do the Simplest Thing That Could Possibly Work – – – – Passes all the tests No duplicate code (Once and Only Once) States every intention Fewest possible classes and methods (You Aren’t Gonna Need It) Simple Design – Disadvantages • What is “simple?” • Simple isn’t always best Coding Standards – Advantages • Reduces the amount of time developers spend reformatting other peoples’ code • Reduces the need for internal commenting • Call for clear, unambiguous code 10 Coding Standards – Disadvantages • Degrading the quality of inline documentation On-Site Customer – Advantages • Can give quick and knowledgeable answers to real development questions • Makes sure that what is developed is what is needed • Functionality is prioritized correctly Refactoring • Goal: optimal code design • Changing how the system does something but not what is done • Improves the quality of the system in some way • Do it regularly On-Site Customer • Goal: handle business concerns accurately and directly • Customer set project’s goal and schedule • Gives quick and continuous feedback to the development team • If impossible to have a customer on-site, a proxy may be used instead On-Site Customer – Disadvantages • Difficult to get an On-Site Customer • The On-Site customer that is given may not be fully knowledgeable about what the company • May not have authority to make many decisions • Loss of work to the customer’s company Refactoring • Design becomes everybody’s daily business • Continuously improve quality of the code • Unit Tests and Pair Programming give courage Result: • Fast development speed • Code becomes easy to change 11 Refactoring – Advantages • Prompts developers to proactively improve the product as a whole • Increases developer knowledge of the system Collective Ownership • Goal: spread responsibility to whole team • The idea that all developers own all of the code • Any developer can change any code if needed to complete a task • Enables refactoring Collective Ownership Disadvantages • Loss of accountability • Limitation to how much of a large system that an individual can practically “own” Refactoring – Disadvantages • Not everyone is capable of refactoring • Refactoring may not always be appropriate • Would upfront design eliminate refactoring? Collective Ownership – Advantages • Helps mitigate the loss of a team member leaving • Promotes developers to take responsibility for the system as a whole rather then parts of the system Continuous Integration • Goal: reduce impact of adding new features • Merge tasks and tests to whole as soon as they are completed • Code is not worked on without being integrated for more than a day 12 Continuous Integration Advantages • Reduces to lengthy process • Enables the Small Releases practice Sustainable pace • • • • Goal: go home tired, but not exhausted The work week should be limited to 40 hours Time is fixed, adjust the scope if necessary Regular overtime is a symptom of a problem and not a long term solution 40-Hour Week - Disadvantages • The underlying principle is flawed • 40-Hours is a magic number • Some may like to work more than 40-Hours Continuous Integration – Disadvantages • The one day limit is not always practical • Reduces the importance of a well-thought-out architecture 40-Hour Week – Advantage • Most developers lose effectiveness past 40-Hours • Value is placed on the developers well-being • Management is forced to find real solutions Small Releases • Goal: return customer’s investment often • Small in terms of functionality • Less functionality means releases happen more frequently • Frequent opportunities for evaluation and feed-back • Reduce chance of overall project slippage 13 Small Releases – Disadvantages • Not easy for all projects • Not needed for all projects • Versioning issues • • • • Done This week This release To be estimated Future • Big visible charts • Supports: planning game • Requires: simple design, comprehensive testing, continual integration, planning game Workspace Workspace Workspace Workspace Open space for the whole developer team Small private spaces nearby or limited work hours Provide overview of projects status and progress Stories on a wall, sorted spatially in for example: – – – – – Practice – Release Regularly • Portable workspace – – – – User stories Task cards Acceptance tests Charts • Virtual workspace – Use wiki, google docs, homepage … Decide which aspects of informative workspace that can be handled and how to compensate for others 14 Roles • • • • • • • Customer/User Developer Interaction designer Tracker Coach Tester And some more Customer Bill of Rights As the customer, you have the right to: • An overall plan, to know what can be accomplished, when, and at what cost • Get the most possible value out of every programming week • See progress in a running system, proven to work by passing repeatable tests that you specify • Change your mind, to substitute functionality, and to change priorities without paying exorbitant costs • Be informed of schedule changes, in time to choose how to reduce scope to restore the original date, even cancel at any time and be left with a useful working system reflecting investment to date Developer Bill of Rights As the Developer, you have the right to: • Know what is needed, with clear declarations of priority; • Produce quality work at all times; • Ask for and receive help from peers, superiors, and customers; • Make and update your own estimates; • Accept your responsibilities instead of having them assigned to you. Customer • • • • Writes User Stories and specifies Acceptance Tests Sets priorities, explains stories May or may not be an end-user Has authority to decide questions about the stories Developer • Estimates stories • Defines Tasks from stories, and estimates • Implements Stories and Unit Tests Interaction designer • Choose overall metaphors for the system • Help users write stories, using their tools to understand the users requirements • Evaluate usage of the deployed system (to find more stories) + • Lofi prototypes • Usability See Nielsen & Nodder report 15 Tracker • Monitors Programmers’ progress, takes action if things seem to be going off track • Keeps track of project velocity, number of passing tests, overtime • Actions include setting up a meeting with Customer, asking Coach or another Programmer to help Coach • Watches everything, makes sure the project stays on course, that practices are followed • Helps with anything • Has experience and can guide/teach Manager • Schedules meetings (e.g. Iteration Plan, Release Plan), makes sure the meeting process is followed, records results of meeting for future reporting, and passes to the Tracker • Possibly responsible to the Gold Owner. • Goes to meetings, brings back useful information • Pays for pizza Tester • Help customers write automated acceptance tests • Write more detailed test during development • Graphs results, and makes sure people know when test results decline Doomsayer • Ensures that everybody knows the risks involved • Ensures that bad news isn't hidden, glossed over, or blown out of proportion Gold owner • The person funding the project, which may or may not be the same as the Customer 16 Who benefits from XP? Programmers Customers • get clear requirements & priorities • can do a good job • can make technical decisions • don’t work overtime • get most business value first • get accurate feedback • can make informed business decisions • can change their mind Why XP works • Light-weight: discipline without bureaucracy • Under stress, people do what is easiest – All XP practices have short-term benefits as well as longterm benefits • Development as a Conversation • The code is the documentation • XP is fun XP – Advantages • • • • • Built-In Quality Overall Simplicity Programmer Power Customer Power Synergy Between Practices XP – Disadvantages • • • • • Informal, little, or no documentation Scalability Contract Issues Misconception on the cost of change Tailoring 17