Ooochie: A Ruby Developer’s Journal

OK my dear readers, I give you the final part of my series on Extreme Programming. Thanks for being patient (except - cough - Gist - coughcough) while I finished reading!

Parts 1 and 2 discussed the values and principles of XP. Now we are ready to talk about the practices: specific ways to apply XP to your software development. The author says the following about the practices:

"The practices in this chapter aren't the whole story of XP. They provide a foundation of respect, communication, and feedback that fosters simplicity and courage. The team members can use their increasing confidence and competence to build relationships inside and outside the team."

Without further ado, the primary practices of XP are:

Sit Together

• Develop in an open space.
• Communicate with all your senses.
• Physical proximity enhances communication.

Whole Team

• People need a sense of belonging to the team.
• Large teams lose trust, and trust is necessary for collaboration, so try to keep teams small.

Informative Workspace

• An outsider should be able to tell how the project is going within 15 seconds of being exposed to the workspace.
• Water and snacks provide comfort in the workspace and encourage positive interactions.
• Cleanliness and order of the workspace clears minds and helps people focus.
• Use big, visible charts.

Energized Work

• Work only as long as you are productive.
• "Software development is a game if insight, and insight comes to the prepared, rested, relaxed mind."
• If you're sick, rest!

Pair Programming

• Pair programming is two people working at one machine.
• "Pair programming is a dialog between two people simultaneously programming and trying to program better."
• Allows people to keep each other on task, clarify ideas, and hold each other accountable to other practices.
• Rotate pairs frequently. Switch pairs at natural breaks in development.
• Personal space must be respected!
• Pay attention to hygiene and health.
• Avoid relationships within the team.

Stories

• As soon as a story is written, try to estimate the necessary development effort.
• Early estimation gives business people and tech people the chance to interact and create value.
• Estimating early gets everyone thinking early.
• Put stories on index cards on the wall.
• "You can't make a good decision based on image alone." - Providing estimates allows customer to make an informed decision.

Weekly Cycle

• Plan work a week at a time.
• Have a weekly meeting to review progress, have the customer pick a weeks worth of stories to implement, and task out stories.
• Goal: deployable software at the end of the week.
• Work on gradually reducing planning time.

Quarterly Cycle

• Plan work a quarter at a time.
• Have a weekly meeting once per quarter to reflect on progress, plan themes, identify bottlenecks, and pick a quarter's worth of stories to implement.
• Focus on the big picture: Talking about "themes" as opposed to stories helps people see how the details of what they are doing fit into the bigger picture.

Slack

• Always include some minor tasks that can be dropped if you get behind.
• Meeting your commitments is important in building relationships.
• "Clear, honest communication relieves tension and improves credibility.

Ten-Minute Build

• Automatically build the whole system and run all tests in ten minutes.
• "A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback."
• An automated build can be a stress-reliever at crunch-time.

Continuous Integration

• Integrate changes every couple of hours.
• Pairs should integrate(build and run tests) after every pairing session.
• "Continuous integration should be complete enough that the eventual first deployment of the system is no big deal."

Test-First Programming

• Write a failing test before changing any code.
• Helps avoid writing unnecessary code.
• Tests should be easy to write. If they aren't, you may have a design problem.
• Passing tests let your teammates trust that you've written working code.
• Get into a coding rhythm: Test, code, refactor. Test, code, refactor. etc.

Incremental Design

• "Strive to make the design of the system an excellent fit for the needs of the system that day."
• Eliminates duplication.
• XP teams are confident in their ability to adapt the design, which allows them to satisfy the human need for immediate success and economic need to put off investment.
• "The most effective time to design is in the light of experience."

There you have it, a brief (and hopefully helpful) overview of the values, principles, and practices of Extreme Programming. As I mentioned in Part 1, I am glad to have found a work environment that follows XP. It creates a feeling of community and a productive working environment. For more info, go read the book yourself! Enjoy. :)