XP (Extreme Programming) Practices Part 2

In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 7, in this chapter we will talk about XP Practices.

In XP there are several practices that go in line with Extreme Programming, these practices help teams to get the best of them and to produce code in a new way that brings with it a lot of advantages. The XP practices are the following and we will talk a little bit of each one, for this part 2we will talk about the last 7:

• Sit Together
• Whole Team
• Informative Workspace
• Energized Work
• Pair Programming
• Stories
• Weekly Cycle
• Quarterly Cycle
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design

Weekly Cycle

• 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.

Xp encourages us to make planning once a week, this planning is where we define the tasks that will be completed in five days. The tasks will be estimated and assigned to each programmer. Also, in this meeting we should check the past week’s progress and ensure that all tasks were completed. If some tasks are still pending then we should better our estimates. A common practice that many teams are doing is having this weekly meeting on Tuesday or Wednesday instead of Monday, the reason for this is that many people don’t like Mondays and also they don’t like planning so with this you reduce a bit of stress on this meeting.

Quarterly Cycle

• Identify bottlenecks, especially those controlled 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.

These meetings are designed to eliminate bottlenecks or identify problems mid-sprint. During a week a lot of things can happen and the quarterly meetings help to intercept any problems that occur during the week, I see them as mini-sprints to solve a certain task or problem.

Slack

You should always include some minor tasks that can be dropped if you get behind. It is very important that you fulfill your promises and deliver on time. Many companies are used to overcommit and underdeliver, but their plan is to ask for too much in order for the team to deliver as much as they can and still the result will be good for them but this is not a good practice. You should estimate and promise a reasonable amount of tasks and deliver them, no more no less, well if you deliver more it’s okay.

Ten-Minute Build

This is a really good practice in which you compile, run and test your whole project in ten minutes. This helps teams to feel more secure about their system. Every new change or feature can be tested easily with the whole system and you won’t be afraid to test a big new release with tons of new features because week by week you will be doing this practice and never miss a bug on the way and do baby steps with no fear.

You should develop this process in ten minutes because if it takes longer you will not like to do it that often. So, it is key to make it in ten minutes, if you are taking longer find a way to automate the process.

Continuous Integration

Integrate and test changes after no more than a couple of hours. This saying is key to XP. Continuous Integration will help you to deliver fast and with not many trouble in the future, when integrating new code, it is always unpredictable what will happen or what will break. The correct thing to do is as soon as you have some working tasks and tested, start integrating to the project. The longer you take to integrate new code, the more unpredictable things might get. This also helps for daily builds and to focus on delivering what you were asked, if you follow this practice your first system deploy will not be a big deal or a huge change of functionality.

Test-First Programming

Write a failing automated test before changing any code. Test-first programming addresses many problems at once:

• Scope creep — It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
• Coupling and cohesion — If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
• Trust — It’s hard to trust the author of code that doesn’t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
• Rhythm — It’s easy to get lost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm — test, code, refactor, test, code, refactor.

A refinement for test-first programming is continuous testing which consists of running tests on every program change. Continuous testing reduces the time to fix errors by reducing the time to discover them. The tests have to run quickly, however.

The advantage of these tests is that they run pretty fast and you can include thousands of them in the ten-minute build.

Incremental Design

Since we where in school, teachers always taught that we should over design in the design phase because we would not have time to do it later and this way we can prepare for future changes because we will over design. In XP, this is not always the case. In today’s programming world, requirements change often, the client changes its mind pretty often and sometimes a new requirement appears out of nowhere because of the petition of the head master director of the company. When you only design at the beginning of the project, applying these new requirements can be a pain in the back. A practice that XP uses to solve this is incremental design.

You will design the bases and basic requirements at the beginning of the project but as you advance or as changes appear you will continue to design based on them. With this the system is more prepared for new changes because it didn’t assume something in the long run that a change that appeared today will make it hard to modify. XP teams work hard to create conditions under which the cost of changing the software doesn’t rise catastrophically. The automated tests, the continual practice of improving the design, and the explicit social process all contribute to keep the cost of changes low.

So, with all the practices of XP we can apply this one in particular and be calm that our other practices will sustain the practice of designing on the go.