3

In "Extreme Programming Explained", Beck lists 13 "primary practices". They are:

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

Which of these have you actually implemented in your workplace? Which has been the most useful?

2

I used

  • Sit Together
  • Stories
  • Weekly Cycle
  • Informative Workspace
  • 10 Minute Build
  • Continuous Integration
  • Test-First Programming
  • Incremental Design

and it was really successful.

  • Pair programming didn't fly ( the team was a bit small to start with, sort of headed towards Pair over time)
  • Did whole team some times, customers were not always available. I sort of morphed into a faux customer with practice.
  • Slack couldn't fly with management, we did event based schedules instead.
  • Energized work was hard to do. There was a culture of longer hours.
3

I don't think there's a best practice. There are lots of good practices in that list like Test-First Programming and Continuous Integration.

My vote is for Continuous Integration. Joel Spolsky also talks about it in his Joel Test.

I think a team could have great results without sitting together or doing pair programming, but integrating the work often is very important. Every programmer will have an updated version and the sooner the team integrate the work, the easier will be to resolve mergin conflicts and detect integration error when testing.

For more info about Continuous Integration, you can see this article by Martin Fowler

2

Personally I've seen productivity gains with the following:

  • Continuous Integration (Hudson / TeamCity)
  • Incremental Design
  • Iterative Cycle (2 weeks seems to be best)
  • Pair Programming (continuous peer review)
  • Unit testing / good test coverage (not necessarily test-first)
  • No overtime / maintainable work cycle.

Of course, there are always other things in the mix that can improve things.

  • High quality, bug tracking software (which integrates closely with the CI and SCM)
  • Good SCM (svn or git, are personal recommendations) + clear SCM strategy, for feature branching, version maintenance etc.

Generally speaking these last two, should be in place regardless of your methodology, I'd say that CI should also be in place by too, there's simply no decent reason not to use it.

2

There is no best XP practices.

Generally, some of these practices can be useful on their own, but I think they really play out their benefits in combination.

You can always replace or change a practice, but keep in mind that XP has a set of practices and each of them plays a role.

Maybe you could ask a question like:

If you have to implement just one or two of the practices, from which of them would you benefit the most?

And the answer would be clearly: it depends.

If you have problems with your codebase with design/bugs/etc.. you might benefit from Test Driven Development etc...

1
  • 1
    +1 I saw somebody describing it as a wheel with each the practices depending on the previous practice. If you take out one or two of them you loose a lot of synergy. – AndersK Feb 9 '11 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.