Getting Started with XP
In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 8, in this chapter we will talk about getting started with XP in your project.
Where to start?
You are already developing software and have already started. XP is a way to both improve your development process and your experience of it. You start with XP where you are right now and adapt by adding practices that meet your goals and express your values. As you add practices, you will realize you can do things you previously didn’t imagine. By the time you have applied XP completely you are energized, confident, part of an active community, and working at a seemingly incredible pace with less stress than ever before.
When to start?
There’s no specific point to start with XP. Any of the primary practices are safe, offering immediate improvement if you have the problem they are designed to address. Start by changing one thing at a time, it’s hard to jump in and do all the practices, embrace all the values, and apply all the principles.
The process will not be necessarily slow if the team is eager to improve. Also, take your time because if you progress really fast there a risk you slip bakc to old practices and values.
What to change first?
Look at what you are doing and what you want to achieve. Choose the first practice on that path. One option is to use XP-style planning. Write stories about improving your software development process. Estimate how long each will take. Figure out your budget for process improvement. Pick a story to work on first. Adapt as you discover what is easy or valuable and what is difficult.
Change begins with awareness. Awareness of the need for change comes from feelings, instincts, facts, or feedback from outsiders. Feelings, while valuable, need to be cross-checked with facts or trusted opinions. Once you are aware of the need for change, you can begin to change. The primary practices are possible places to begin improving your development practices.
Find your current position with respect to each of the practices. Pick a practice whose purpose matches your own priorities for change. Move one step closer to the endpoint illustrating the practice. See if the humanity and effectiveness of your development improves.
Pair programming
If I feel that a big integration is coming and I’m feeling nervous, you may need to collaborate with someone to feel more secure and have instant feedback so that things can flow accordingly. In these cases, we start with Pair Programming.
Pair programming is the practice that addresses technical collaboration. At full intensity, it suggests that all long-lived code be written by two people having a conversation as they program. You can collaborate one step more intensely by picking a piece of code about which you are nervous and asking someone else to pair with you for an hour or two as you work out its interface to another part of the system. It would be wise to choose the person responsible for the other part of the system as your partner, if he is willing.
However, you need to keep improving by yourself. Change always starts at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself.
Mapping the Practices
There is a simple exercise in which you list the things you feel the team can improve and actually take action. Many times programmers start to complain about things they don’t like or that being done in a bad way, but it only gets that far, to only complain about it but no action is taken. This exercise will help you see what are the things you should work as a team. And also, with this exercise you can decide how to implement XP based on the things you need to work as a team.
