Extreme Programming Alexander Kanavin Lappeenranta University of Technology.

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