Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices eXtreme programming Practices Eliza Stefanova Sofia University

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Contents Roles in XP Responsibilities Practices

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Roles in XP Customer –Defines requirements and priorities –Representative can drive the process Coach –Watches the process, take care that everything runs –Typical from development team Developer –Estimate time and implement tests and code –Defines acceptance criteria together with customer Tracker –Measure the progress – watches the time: 2-3 times in week ask the team which on task works, how much time needs

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Strict line between Business & Technical Responsibility Customer - business decisions –Scope –Priorities –Release planning Developers – technical decisions –Effort –Risks –Iteration planning

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices On-site customer One of the few requirements of XP - to have the customer available on-site, not only to help the development team, but to be a part of it as well All phases of an XP project rely on communication with the customer, preferably face to face, thus the best is to assign a customer to the development team

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices On-site customer Write user stories Determine priorities Answers questions during the iteration Specifies functional acceptance tests Is typically neither the investor nor the end user

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Extreme Development Collect user stories and make architectural design Release planning: Prioritization and Estimation First Iteration Planning First Iteration Performing Second Iteration planning Second Iteration Performing … Release

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Planning Game Planning Process Players: –Customer –Developers team Pieces: –User Stories (CRC cards) Name of the ClassCollaborators Responsibilities

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices How to play the game Release Planning – one to two days Customer specify its requirements writing User stories Developers estimate each User story according to difficulty (effort and risk) Developers divide/merge stories (3-9 days) Customer order User stories according to business value Developers determine velocity –velocity (finished tasks/stories per iteration) Customer select the stories for the release

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices How to play the game Iteration Planning – half to whole day Customer select stories (could come with new stories) Developers ask questions regarding scope Developers discuss the risks Developers split into tasks (4-12 hours) Developers take responsibility for tasks Developers estimate difficulty

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices What we need to play the game System Metaphor Everyone in team understanding what the system should be, how its components fit together To do that the team should have shared terminology and glossary

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Small releases (one to three months) A release is a software version of the final product, completely usable and tested that implements a business value desired by the customer Has to be as small as possible, but implementing a business value Frequently developed and given to the Customer

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Short iterations (one to three weeks) The iterations objective –To put into production some new stories, tested and finished correctly An iteration kick-off meeting for the iterations planning In the beginning of each day of iteration stand-up meeting –Whole team status report –Each person 2-3 minutes –Name the problems, not solve them

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Pair Programming Pairs of developers write all production code Two programmers - actively working on the same task on the same computer at the same time

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Pair Programming Roles Two active and interchangeable roles: a driver and a navigator The driver writes code The navigator: –asks questions –raises objections –suggests alternatives –makes code review constantly If navigator sees that driver gets stuck it is better to change the roles

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices How to form pairs If one person resists pairing or simply refuses to do it, don’t put up with it. The coach should talk to him to explain the reason behind the rules. If he still refuses to comply it is better not to force him take part in the XP team. Everyone in the pair should respect his partner. Every person in the pair should be kind and to try to help his partner be the best he can be.

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices When to form pairs Pair is defined per task during the iteration planning. The advantage is that during the task development at least two persons know about that task progress. Pairs should change often – switch up as often as practically possible (e.g. when beginning a new task) – like this knowledge is spread throughout the team (the whole team is familiar with every part of the system).

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices When not to pair When you are exploring something new – give both developers of the pair room to move in their own direction When you have multiple ideas about what might be causing a bug

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices 40-hours week Long period of intensive work kill performance - tired people make more mistakes that slow them down Overtime is not the answer of the project schedule delay problem – often is symptom of other problem (e.g. inability to estimate well, private problems, etc) that has to be identified and resolved

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Test-Driven Development Two kinds of Tests –Unit tests Wrote be Developers –Acceptance tests Specified by Customer

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Tests executable Specification Requirements are clearly and unmistakable specified with a test –Can verified them as often as we like Requirements are analyzed systematically and timely –Early detection of analysis problems

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Effective Testing Motivate each change of program behavior with an automated test Based on automated, repeatable test As frequent and as simple as compiling A test suite should run in <10 minutes The goal is catch important problems (possible holes) The benefit must be higher than the cost

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Test/Code Micro Cycle Brainstorm for possible test cases Implementation of the tests Code writing and compiling (to see if the test fail) Code changing as much as necessary in order to pass the test Bring the code in the simplest form

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Test requirements Quality standards like for code: –Self-documenting –No duplicated code –As simple as possible Test code is refactoring as often as regular code

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Simple design Simple design save time, effort, complexity Functionality to only be developed if it is required –Develop only the things that are really required now –No assumptions Tests are satisfied in the simplest way Unused flexibility to be eliminated

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Criteria for Simple Design Pass all its tests Present its intention Has no duplicated logic Has as few classes and methods as possible

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices How to develop the simplest code that could be work Satisfy the current test cases – design the simplest code that would pass all necessary tests As soon as tests run, do the refactoring to make code simpler

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Collective Ownership Allows every developer to change anything at anytime in the code, enabling the possibility to change the code immediately when identifying an improvement potential Each developer take responsibility for the whole system, understanding what will be the effects to the overall system when making changes

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Coding Standards intend to introduce a common coding style makes it easy for everybody to read and understand any code created by any colleague in the team without them it is harder to apply other XP practices (refactoring, collective ownership, simple design, as well as switching pairs)

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Refactoring A modification of the internal structure of a program without changing its observable behavior –To improve the design –To simplify the code –Improve understandability Evidence for a needed refactoring – code and test smells

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Smells Code smells Duplicated code Long methods Available comments Switch-chains, nested if-then-else Code does not express its idea Data classes without real behavior Test smells Duplicated code Indirect tests Hidden failed assertion Unnecessary test environment Optimistic assumptions about test environment

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Refactoring Actions Refactoring code smells Rename Class/Method/Variable Extract Class/Inline Class Move Method Extract Method/Inline Method Replace Conditional with Polymorphism Introduce Explaining Variable Refactoring test smells Self-explaining assertions Adjust test case classes around test environment Introduce semaphore for critical test resources Explicit allocation and release of resources Never change the functional and test code at the same time

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Refactoring process and principles Happens continuously –in little steps –shared responsibilities Do it more often Goal – always bring your code into simplest form

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Integration Incorporate changes into the shared code base Synchronization of the different developments effort Resolution of conflicts

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices Continuous Integration Changes of code are integrate as often as necessary and possible Conflicts are easier to resolve because the more often integration Each integration result is a running system

Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming - principles & practices How does continuous integration works? Integration machine & integration token Integration after accomplishing a task All unit tests have to pass 100% after integration As much automation as possible