XP: Planning, coding and testing. Planning. Release planning. Release Planning. User stories. Release planning Step 1.

Transcription

1 XP: Planning, coding and testing Annika Silvervarg Planning XP planning addresses two key questions in software development: predicting what will be accomplished by the due date determining what to do next The emphasis is on steering the project rather than on exact prediction of what will be needed and how long it will take There are two key planning steps in XP, addressing these two questions: Release planning Iteration planning Release planning Release Planning Customer presents the desired features to the programmers Programmers estimate their difficulty Customer lays out a plan for the project Initial release plans are necessarily imprecise. However, even the first release plan is accurate enough for decision making and XP teams revise the release plan regularly Release planning Step 1 User stories 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 1

2 Writing user stories User story template The customer get a stack of cards (Scribble on one card, then tear it up!) Customer writes a story Developers ask questions for clarification (not implementation) Tear up cards and write new ones when needed Title (one line describing the story) Narrative: As a [role] I want/can [feature] (So that/because [benefit]) For backbone development, try to relate it to customer need and break it down in stories User story examples 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 Estimating user stories Release planning Step 3 Intuitive time estimates how long it would take if you programmed all days without interruptions, compare the different stories for difficulty Spike solution experiment to get an idea of how a problem can be solved Estimate by comparison compare a story with the previously implemented stories 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) 2

3 Iteration planning 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 Iteration planning Step 1 Project velocity Project velocity is based on previous iteration Number of completed stories/tasks/ideal hours divided by actual hours Customer choose stories from release plan Failed acceptance tests to be fixed are also selected 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 We recomend initial velocity at 0.5 and the time unit is hours, this gives: 0.5 x 15 hours x 2 weeks x 4 devs = 60 hours of for each iteration (45 hour for 3 developers) Iteration planning Step 2 Iteration planning Step 3 The user stories and failed tests are broken down into the programming tasks that will support them by the developers Tasks are written down on index cards like user stories While user stories are in the customer's language, tasks are in the developer's language Duplicate tasks can be removed Each story has a corresponding task card for writing an acceptance test together with the customer Developers sign up to do the tasks and then estimate how long their own tasks will take to complete* Each task should be estimated as 1, 2, or 3 ideal programming hours in duration Tasks which are shorter than 1 hour can be grouped together and tasks which are longer than 3 hours should be broken down farther * or estimates are made by the team and tasks divided at the end of the session, or put in a stack where developers choose tasks one at a time 3

4 Planning poker Planning poker A task is presented and briefly discussed (max 2 min) Each participant chooses from his own deck the numbered card that represents his estimate All estimates are kept private until each participant has chosen a card All estimates are revealed If estimates differ, the high and low estimators explain their estimates The process is repeated until estimates are similar Iteration planning Step 4 The first iteration Total up the time estimates in ideal programming hours of the tasks, this must not exceed the project velocity from the previous iteration If the iteration has too much then the customer must choose user stories to be put off until a later iteration (snow ploughing) If estimates are shown to be wrong during development work, ask the customer to adjust the scope of the iteration Choose several small tasks to lay a basic architecture Do as much of the end-to-end application as possible Helps gather data for future iterations Choose velocity 0 and ask the customer to choose new stories during the process, or choose an arbitrary velocity, e.g. 0.5 Start with the most important/highest risk task first Write down how your estimates were Planning game workflow Development A picture says more than a thousand words?! 4

5 Work flow Practice Pair Programming Choose task (Planning game) 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 (Refactor Mercilessly, Collective code ownership) Check in test and code (Continuous integration, Collective code ownership) Go home after 8 hours (Sustainable pace) Goal: spread knowledge, experience and ideas Pairs work together on (small) tasks Driver focus on details of the task, Navigator focus on project as whole Pair programming Practice Test-driven Development Goal: prove that the code works as it should Acceptance test, write a test together with the customer for each requirement Unit tests, write a test that fails, write code, check that the test is passed, refactor, automate test Testing Acceptance test Defects are expensive, but eliminating defects are also expensive The sooner a defect is found the cheaper to fix it 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 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 5

6 Acceptance test template Acceptance test examples Scenario 1: Title Narrative: Given [context] (And [some more context]...) When [event] Then [outcome] (And [another outcome]...) User story Criteria for acceptance test Acceptance test examples cont Acceptance test example cont User story Payment The customer can pay by credit card Acceptance test Payment everything ok Given a VISA card with correct card id number, expiration date and purchase amount under card limit, When the user pays Then payment goes through and user receives confirmation on purchase Acceptance test Over card limit Given a VISA card with correct card id number, expiration date and purchase amount over card limit When the user pays Then payment fails and user receives error message Automating acceptance tests Unit tests Define input and expected output Write functional test as programs Have a scripting language simulate GUI commands Have an input recorder and ask the customer use it to define a test Automate tests incrementally as needed Can be tricky for highly interactive GUI systems First you should create or download a unit test framework to be able to create automated unit tests suites ( Second you should test all classes in the system (Trivial getter and setter methods are usually omitted) And last you should try to create your tests first, before the code Unit tests are released into the code repository along with the code they test 6

7 Bug tests Workspace When a bug is found tests are created to guard against it coming back A bug in production requires an acceptance test be written to guard against it Given a failed acceptance test, developers can create unit tests to show the defect from a more source code specific point of view When the unit tests run at 100% then the failing acceptance test can be run again to validate the bug is fixed Workspace Workspace Code and Design Simply You Aren t Gonna Need It Goal: code that is easy to change Do the Simplest Thing That Could Possibly Work Solve the current problem Implement it simply Fewest possible classes and methods (You Aren t Gonna Need It) Code should pass all tests and nothing more Clean up No duplicate code (Once and Only Once) Do today s work today and tomorrow's work tomorrow, do not guess ahead Do not add flexibility if not needed, makes the code more complex The customer/user identifies what needed 7

8 Once and Only Once Coding Standards Eliminate repetition, simplify code by removing complexity Refactor! Process Write code to solve problem When you write similar code refactor to remove duplication Next time you write similar code generalise to cover all cases you will encounter 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 On-Site Customer Refactoring 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 on-site a proxy may be used 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 Collective Ownership Continuous Integration 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 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 8

9 Sustainable pace The XP project 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 Acceptance test Other types of testing 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 User interface testing ensure all components behave as expected Usability testing ensure the application and functions can be easily used Performance testing test performance during various workloads Release 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 9