Transcript 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