XP: Planning, coding and testing. Practice Planning game. Release Planning. User stories. Annika Silvervarg

Transcription

1 XP: Planning, coding and testing Annika Silvervarg Practice Planning game Goal: schedule the most important tasks Which features to implement in what order Supports: simple design, acceptance testing, regular releases Requires: active customer, mutual respect 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 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 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 Step 1 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 Project velocity Iteration planning Step 2 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 30 hours x Num of devs = total time for iteration 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 Iteration planning Step 3 Planning poker 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 one at a time 3

4 Planning poker Iteration planning Step 4 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 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 The first 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 Start with the most important/highest risk task first Write down how your estimates were Planning game workflow A picture says more than a thousand words?! Development Coding 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) 4

5 Practice Pair Programming Pair programming 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 Supports: collective code ownership, comprehensive testing, simple design, refactoring, good development practices, teamwork Requires: facilities designed for pairs, developers willing to try pair programming, managers willing to try pair programming, coding standards Practice Test-driven Development Testing 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 Supports: refactoring, regular releases, collective code ownership Requires: positive peer pressure, good communication between developers and customers 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 test Acceptance test template 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 Scenario 1: Title Narrative: Given [context] (And [some more context]...) When [event] Then [outcome] (And [another outcome]...) 5

6 Acceptance test examples Acceptance test examples cont 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 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 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 Practice Code and Design Simply 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 Goal: code that is easy to change Do the Simplest Thing That Could Possibly Work You Aren t Gonna Need It Once and Only Once Supports: collective code ownership, refactoring, testing Requires: good communication between developers and customers, confidence, ability to recognize simplicity Do the Simplest Thing That Could Possibly Work Balance functionality with simplicity Process: Solve the current problem Implement it simply Code should pass all tests and nothing more Clean up Discovering the simplest solution can be hard, avoid what if? You Aren t Gonna Need It 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 Practice Coding Standards Practice On-site customer Goal: communicate ideas clearly through code Conventions that evolves with the project Start with existing style guides and naming conventions Supports: refactoring, pair programming, collective code ownership Requires: developer teamwork, occasional review, pair programming Goal: handle business concerns accurately and directly Customer set project s goal and schedule If impossible to have on-site a proxy may be used Supports: planning game, acceptance testing, regular releases Requires: initial investment, common vocabulary Try once or twice! 7

8 Practice Refactor Mercilessly Once and Only Once Goal: optimal code design Improve the design without changing the behaviour Do it regularly Supports: simple design, disciplined coding Requires: discipline, comprehensive tests, collective code ownership, 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 Practice Collective Code Ownership Goal: spread responsibility to whole team Any developer can change any code if needed to complete a task Supports: refactoring, pair programming Requires: coding standards, comprehensive testing, frequent integration, shared vocabulary Practice Integrate Continually Goal: reduce impact of adding new features Merge tasks and tests to whole as soon as they are completed Supports: refactoring, releasing regularly Requires: collective source repository, comprehensive testing, quick test suite, planning game, work at a sustainable pace SVN is probably a good idea! Practice Sustainable Pace The XP project Goal: go home tired, but not exhausted Time is fixed, adjust the scope if necessary Facilitated by: planning game, onsite customer, integrate continually, regular releases 8

9 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 Practice Release Regularly Goal: return customer s investment often Frequent opportunities for evaluation and feed-back Supports: planning game Requires: simple design, comprehensive testing, continual integration, planning game 9