Extreme Programming (XP)
Extreme Programming (XP) is a set of software development principles and methods that were originally introduced by Kent Beck and Cynthia Andres in the book "Extreme Programming: Embrace Change". The ideas in the book were based largely on Beck’s experiences and lessons learned from working, in the late 1990s, on the Chrysler Comprehensive Compensation System (C3) payroll system.
The methodology has since been extended through additional books, such as "Planning Extreme Programming" by Beck and Martin Fowler.
An early definition of XP, from the first edition of the original book, is as follows:
XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
The core concept behind extreme programming is to take industry best practices to extremes. So, if a widely accepted best practice is for code to be inspected by peers prior to integration, then the most extreme implementation of that practice is pair programming. And if it is best practice to test early, then creating automated tests before even writing the code (ie. [test-driven development]) is the most extreme approach you can take to that.
Beck envisaged all the good practices we do in software development as being light knobs on a control panel. His idea was, what would happen if you just turned up all the knobs to max? That’s what XP is. It takes best practices to extremes.
XP is based on a pyramid of values, principles, and practices.
Values
XP values are the foundation of the methodology. Values include:
-
Communication: This value drives information sharing and transparency. "What matters most in team software development is communication. When problems arise in development, most often someone already knows the solution; but that knowledge doesn’t get through to someone with the power to make the change."
-
Simplicity: XP values starting with the simplest possible solution, and adding complexity only if necessary. XP does not prepare for future possibilities that may or may not happen. It concentrates on the simplest solutions for today’s problems.
-
Feedback: In XP, feedback comes from several sources. Feedback from the system comes from automated unit tests running in continuous integration systems, returning feedback on code changes within minutes. Feedback from customers comes from frequent close contact, including acceptance tests, planning meetings, and general project steering. And feedback from the team happens when requirements change (the team gives new planning estimates).
-
Courage: In XP, courage is defined as taking effective action in the face of fear. "Courage alone is dangerous; in concert with the other values it is powerful. The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to seek real, concrete answers creates feedback."
-
Respect: XP values respect for team mates, respect for the project, respect for the customer, and respect for oneself.
Organization, teams, and projects should extend the core XP values with their own. Some possibilities include safety, security, predictability, and quality of life.
Principles
XP principles bridge the gap between values and practices.
The XP principles are:
-
Humanity: People develop software.
-
Economics: Add business value.
-
Mutual benefit: Strive for win-win always.
-
Self-similarity: If something works in one situation, try to apply it to others.
-
Improvement: "Perfect" is a verb, not an adjective. Always strive to improve processes.
-
Diversity: It takes a variety of skills and perspectives to solve problems effectively. This can lead to conflicts when there are multiple possible solutions or approaches.
-
Reflection: How and why does this work?
-
Flow: Bias towards a continuous flow of development, as opposed to developing in phases or chunks. Continuous integration.
-
Opportunity: "Learn to see problems as opportunities for change."
-
Redundancy: "The critical, difficult problems in software development should be solved several different ways." Example: defect elimination.
-
Failure: Trial and error. Try things even if they don’t work. Learn from the failures.
-
Quality: Quality is not a control variable. Always strive for high quality, and control the project by adjusting scope as needed.
-
Baby steps: Lots of little steps can be faster than a few large bounds, with more control.
-
Accepted responsibility: Responsibility for completing tasks must be taken, not given.
Practices
XP defines two types of practices: primary and corollary.
Primary practices safely give immediate benefits, while corollary practices should be attempted only after mastering the primary practices.
Primary practices
-
Sit together: Find a large room where everyone can sit together, at least for part of the day.
-
Whole team: Bring together all the skills and perspectives necessary. Foster a sense of team.
-
Informative workspace: The space should have a visible display of the project and its current status (eg. stories on sticky notes on a kanban-style wall). The space should also have resources for positive social interactions, eg. coffee and snacks.
-
Energized work: Work only as many hours as you are productive and efficient.
-
Pair programming: Two people, one computer. Keep each other on task. Brainstorm refinements. Clarify ideas. Alternate initiative when one is stuck. Hold each other accountable to learn standards. Rotate pairs after 1 to 3 hours. No more than 5 or 6 hours per day. Beware of inter-personal, hygiene, and other social issues.
-
Stories: A more natural alternative to "requirements". Functionality described by the customer and quickly estimated by the development team.
-
Weekly cycle: Plan each week at a Monday meeting. Review progress to date, including how actual progress for the previous week matched expected progress. Have the customers pick a week’s worth of stories to implement this week. Break the stories into tasks. Team members sign up for tasks and estimate them. Alternative, draw tasks randomly from a pile. Start the week by writing automated tests that will run when the stories are completed. Then spend the rest of the week completing the stories and getting the tests to pass. Deliver functionality and celebrate every Friday.
-
Quarterly cycle: Another good time frame for planning longer-term goals. During quarterly planning: identify bottlenecks, especially those controlled by outside the team; initiate repairs; plan the theme or themes for the quarter; pick a quarter’s worth of stories to address those themes; focus on the big picture, where the project fits within the organization.
-
Slack: Always include some minor tasks that can be dropped if needed to meet overall commitments. Don’t over-commit and under-deliver, but set realistic, attainable goals.
-
Ten-minute build: Automatically build the whole system and run all of the tests in ten minutes.
-
Continuous integration: Integrate and test changes after no more than a couple of hours.
-
Test-first programming: Write a failing automated test before changing any code. Avoid scope creep by keeping focused goals. Build trust by writing code that passes tests. Develop a rhythm: pick a feature, write tests that fail, write code to make the tests pass, refactor the code for quality without breaking the tests, repeat. Difficulty writing tests indicates a design problem.
-
Incremental design: Make small, safe design improvements every day. (Software is easier and cheaper to redesign than bricks and mortar, if done properly.)
|
Combining practices amplifies their effectiveness. |