Extreme Programming

1
Extreme Programming

• Alexander Kanavin
• Lappeenranta University of Technology

2
Some background

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

3
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

4
Rules

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

5
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

6
Rules for planning 2

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

7
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

8
Release planning meeting

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

9
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

10
Make frequent small releases

• For valuable feedback
• Important features are introduced early - more
  time to fix them

11
Project velocity

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

12
Iterative development

• Dont schedule tasks in advance
• Dont look ahead and add anything thats not
  scheduled for this iteration

13
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.

14
Move people around

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

15
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

16
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

17
Simplicity

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

18
Choose a system metaphor

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

19
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

20
Spike solution

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

21
Never add functionality early

• Avoid the tempation
• Concentrate on what is scheduled for today only

22
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

23
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

24
Coding rules 2

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

25
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

26
Coding standards

• Self-explanatory

27
Code the unit test first

• Its easier to create code after creating tests
• Tests define the requirements

28
Pair programming

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

29
Sequential integration

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

30
Integrate often

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

31
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

32
Optimize last

• Dont try to guess what the bottleneck is going
  to be
• Make it work right, then make it work fast

33
No overtime

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

34
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

35
Unit tests

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

36
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,

37
When a bug is found

• Create an acceptance test and unit tests to guard
  against it coming back

38
Acceptance tests

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

39
Weaknesses of XP

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

40
Going further

• http//www.extremeprogramming.org
• Books Amazon, Books.ru