Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Programmer

XP is unusual as methodologies go, in that it prescribes activities at the day-by-day (and even at the minute-by-minute) level. We can think of XP's programming activities as shown in FIGURE 9.1.

The triangle in the middle of FIGURE 9.1 captures the idea of test-first programming, a key feature of XP:

  • Test, then code, then refactor

This is the opposite of traditional programming, which does

  • Design, then code, then test

FIGURE 9.1 XP Programming Activities

In traditional programming, the cycle might take weeks to months; in XP, the cycle happens on the order of minutes to hours.

Let's look at the activities one at a time.

Stand Up Meeting at 9 AM

  • Meet for 10 minutes at the beginning of the day.

  • Identify problems and who will solve them, but don't try to solve them in the meeting.

  • Fix the starting time; this helps remind the team to work a 40-hour week.

Pair Up and Do a Quick Design

  • All production code is produced by a pair.

  • The typist thinks tactically, the partner thinks strategically.

  • Switch roles periodically.

Test

  • Write only small bits of unit-test code at a time.

  • Verify that the test fails before coding. (It's sure interesting if it doesn't fail.)

  • "Test everything that could possibly break."

  • Ask the customer if you're not sure what the answer should be.

Code

  • Implement just enough to make the tests pass. ("Do the Simplest Thing That Could Possibly Work.")

  • Follow the team's coding standard.

Refactor

  • Seek out "code smells" (places that don't feel right); apply a refactoring; verify that the unit tests still pass.

  • The code should:

    • Run all unit tests

    • Communicate what it needs to communicate

    • Have no duplicate logic

    • Have as few classes and methods as possible

  • Take small steps, and unit-test after each.

  • See Refactoring (Fowler et al., 1999).

Q&A

  • The customer is available on-site to provide immediate answers.

  • Many questions require decisions (not facts), and the customer should be prepared to make them.

  • The customer should write an acceptance test or (more rarely) a story to capture the answer.

Integrate or Toss

  • Move the code to the integration machine, build the system, and run all tests.

  • Fix things to bring the unit tests back to 100 percent.

  • Some teams require that acceptance tests be in no worse condition. (No test that was passing before you got there should be failing now.)

  • If you can't easily integrate, throw it away and try again tomorrow.

Return to "Pair Up"

  • If you have time left in the day, you can pair up (or at least switch roles) and start over on another task (perhaps the partner's).

Go Home at 5 PM

  • Going home on time reinforces the practice of having a 40-hour week.

  • Notice that nothing is hanging over your head: everything you've done for the day is integrated or tossed.

Summary

These activities remind you of important aspects of XP:

  • Always have a partner.

  • Get answers before you code.

  • Program test-first.

  • Throw it away when you need to.

  • Go home "clean."

  • + Share This
  • 🔖 Save To Your Account