XP and Extreme Hour Literature Annika Silvervarg • Extreme Programming Explained by Kent Beck • Extreme Programming Pocket Guide by chromatic What is XP Values • • • • • eXtreme… 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 Communication Feedback Simplicity Courage (Respect) 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 Small Releases Sustainable pace 1 The Planning Game • Customer presents the desired features to the programmers – Each story represents a desired feature – business value: essential, highly valuable or good idea • Programmers estimate their difficulty User story template • Title (one line describing the story) • Narrative: As a [role] I want/can [feature] (So that/because [benefit]) – 1, 2 or 3 days estimate in ideal development time – technical risk: low, medium, high • Customer lays out a plan for the project 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 Iteration planning • The Customer presents the features desired for the next iteration • The programmers break them down into tasks, and estimate their cost • Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration Project velocity Common vocabulary • 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 (= 160 ideal hours) worth of work in the iteration • 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 2 Testing Acceptance test • 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 • 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 Unit Testing On-Site Customer • 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 • 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 – Product owner in Scrum 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 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) 3 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 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 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 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 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 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 4 • • • • 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: – – – – – Done This week This release To be estimated Future • Portable workspace – – – – • Virtual workspace – Trello, wiki, google docs, excel, homepage … Decide which aspects of informative workspace that can be handled and how to compensate for others • Big visible charts Roles • • • • • • • Customer/User Developer Interaction designer Tracker Coach Tester And some more User stories Task cards Acceptance tests Charts Extreme hour • 60 min to do a project in an XP way, i.e. developing a product using XP practices: – – – – – – – – – The Planning Game On-Site Customer Short Releases Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 5 Teams • Teams of about 7-8 people • 2 customers and they should sit where they can talk • 1-2 monitors that present the result and process at end of class • 4 developers on each team Resources • A place for each team to work, though this may just be a corner of the class room • 30 cards to each team • A watch that tracks seconds (even better, but not necessary, is a stopwatch) Task • The idea here is to "build" a coffee maker/mouse trap to the specification of the customers, where build here means that the developers will draw a picture of the desired machine incrementally • Customers specify functionality, and developers build them by sketching • The task will be carried out in three iterations • While the teams are working the instructor may be called upon to answer questions about the process. Practices • The Planning Game – Write user stories (customer) – Estimate time (developers) – Choose scope for iteration (customer) • On-Site Customer – Can write new stories during an iteration to be added to next iteration – Answer clarification questions during development • Simple Design – Draw only the required feature, not the complete picture Practices • Pair Programming – 2 pairs of developers, where one is driver (has pen) and one is navigator (switch after each task) • Continuous Integration – Integrate after each task Practices • Testing – Customers do acceptance test of features after each iteration (be critical) • Short Releases – Release after 2 iterations • Collective Ownership – Everyone can change existing features if necessary to complete current task • Refactoring • Customers can get new ideas midway and change thei minds! – Redo the complete design when needed 6 Exercise outline • Release planning (10 minutes) – Customers decide what they want and write user stories – one feature per card – Developers get the user stories as soon as they are written • When they get a card, they estimate its time in ideal minutes (1,2 or 3) and give it back to Customers • If a user story is unclear they ask the customer for clarification • If a user story is too big they ask the customer that the user story is split Exercise outline • Iteration planning (5 minutes) – Developers announce the velocity for the next peroid, for example out of 10 min, 8 min can be used for development, velocity = 0.8 – Customers choose the most desirable features up to a time limit determined and announced by developers. For example 2 pairs x velocity x 10 min = 16 min • Iteration developing (10 minutes) – Developers draw features corresponding to user stories • Consult with customers as needed • Draw separate features! • Continous integration! Exercise outline • Testing (5 minutes) • Discuss your experience of the exercise (15 min) – Acceptance tests – Usability tests? • Iteration planning (5 minutes) – – – – Exercise outline Customer can write new user stories Developers estimate new cards if any Developers state a new velocity Customers choose user stories • Developing (10 minutes) As above • Take a 15 min break – How were XP values followed: communication, feed-back, simplicity, courage? – How were XP practices followed: On-site customer, Planning game, Release regularly, Sustainable pace, Design Simply, Refactor, Common Vocabulary, Pair programming, Collective ownership, Continuous integration? – Have the exercise shown any advantage and disadvantaged of XP? – What knowledge and experiences can you bring from the exercise to the real project? • Draw the result on the whiteboard • Monitor presents your discussion Time • • • • 14.30-15.15 Exercise 15.15-15.30 Break 15.30-15.45 Reflections 15.45- Presentation 7