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
Top Related