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?

Improve this question

4 Answers 4

Reset to default
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.
Improve this answer
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

Improve this answer
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.

Improve this answer
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...

Improve this answer
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
    Commented Feb 9, 2011 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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