Extreme Programming

Extreme Programming Alexander Kanavin Lappeenranta University of Technology

Some background • Lightweight vs heavyweight methodologies • Software Engineering Institute Capability Maturity Model (SEI CMM) • Extreme Programming

Basic ideas • Was put together as a response to the increasing difficulty of practicing heavyweight methodologies, especially in medium and small projects • Has very few rules and practices

Rules • Fall into four categories • Planning • Design • Coding • Testing

Rules for planning • User stories are written • Release planning creates the schedule • Make frequent small releases • The project velocity is measured • The project is divided into iterations • Iteration planning starts each iteration

Rules for planning 2 • Move people around • A stand-up meeting starts each day • Fix XP when it breaks

Planning - user stories • Like use cases • Written by the customers as things that the system needs to do for them • Used for time estimation and release planning • Avoid specifics (GUI layouts and such

Release planning meeting • Creation of a release plan document • Planning of individual iterations • Estimation of user stories in terms of ideal programming weeks

Release plan • Specifies exactly which user stories are going to be implemented for each system release and dates for the releases • Stories are translated into acceptance tests

Make frequent small releases • For valuable feedback • Important features are introduced early - more time to fix them

Project velocity • How many user stories were finished during the iteration • Allows estimation for future iterations

Iterative development • Don’t schedule tasks in advance • Don’t look ahead and add anything that’s not scheduled for this iteration

Iteration planning meeting • Customer chooses user stories from the release plan, that are most valuable to him • These are translated into the programming tasks (1 to 3 ideal programming days) • Project velocity is used to estimate if the iteration is overbooked or not.

Move people around • Avoiding knowledge loss and coding bottlenecks • Everyone knows enough about every part of the system

Daily stand up meeting • Everyone stands up in a circle • Prevents it from dragging on for too long • Communications of problems, solutions and promotion of team focus

Design rules • Simplicity • Choose a system metaphor • Use CRC cards for design sessions • Create spike solutions to reduce risk • No functionality is added early • Refactor whenever possible

Simplicity • Needs no explanation • Keeping a design simple is hard work, however

Choose a system metaphor • Allows consistent naming of classes and methods • Being able to guess how something is named is important (time saver)

CRC cards • Class, Responsibilities and Collaboration • Used to represent objects • Class written on top • Responsibilities on the left • Collaborating classes to the right of each responsibility

Spike solution • A very simple program to explore potential solutions • Throw-away program

Never add functionality early • Avoid the tempation • Concentrate on what is scheduled for today only

Refactoring • Rewriting a piece of program so that it does the same thing, but does it better • Removing redundancy, elimination of unused code, getting rid of obsolete designs • Helps keep the design simple and keeping code clean and concise

Coding rules • The customer is always available • Code must be written to agreed standards • Code the unit test first • All code is pair programmed • Only one pair integrates code at a time • Integrate often

Coding rules 2 • Use collective code ownership • Leave optimization till last • No overtime work

Customer is always available • To write user stories • To select user stories • Developers need to talk with the customer to get enough detail to complete a programming task • Functional testing

Coding standards • Self-explanatory

Code the unit test first • It’s easier to create code after creating tests • Tests define the requirements

Pair programming • Sitting side by side in front of the monitor • One person types and thinks tactically • The other one thinks strategically

Sequential integration • Solves problems of parallel integration • Using a physical token or a dedicated computer

Integrate often • Every few hours, not more than a day • Helps detect compatibility problems early, promotes communication

Collective code ownership • Everyone contributes ideas to all parts of the project (or fixes bugs or refactors) • No one becomes a bottleneck • The architecture is distributed among the team

Optimize last • Don’t try to guess what the bottleneck is going to be • Make it work right, then make it work fast

No overtime • If it requires overtime, it will be late no matter what • Use a release planning meeting to change the timing

Testing • All code must have unit tests • All code must pass unit tests before it can be released • When a bug is found tests are created • Acceptance tests are run often and the results are published

Unit tests • Enables collective code ownership • Enables refactoring • Enables frequent integration

Unit testing framework • A development tool, not a testing tool • Helps formalize requirements, clarify architecture, debug, optimize and test • Example: Junit - a unit testing framework for Java,

When a bug is found • Create an acceptance test and unit tests to guard against it coming back

Acceptance tests • Created from user stories • Black box system tests • Customer verifies the correctness of the tests

Weaknesses of XP • Outstanding abilities of the team • Having customer on site • Doesn’t work in a large environment, with no contracting customer, few experts or simultaneous hardware development

Going further • http://www.extremeprogramming.org • Books: Amazon, Books.ru

Extreme Programming