Is CM part of XP?

Does XP include CM?

Sort of.
XP practices include ones such as "continuous integration", "frequent releases" and "iterations", which implicitly require configuration management.
On the other hand, using a configuration management system in a software project is pretty much a given these days.

But I did not see the role of "configuration
manager" or "build manager" in XP. Who is going
to build, control the release, ensure the correctness of the code? Every developer?

Originally posted by Mary King:
Who is going to build, control the release, ensure the correctness of the code? Every developer?

Yes and no. The collective code ownership and continuous integration imply that the build is "controlled" by the developers themselves - with small increments on the codebase. However, I don't know which role should control releases according to XP.
On the other hand, the "frequent releases" practice suggests that your "daily build" is in fact your "release" (and doesn't need planning/controlling per se - everything that is working goes in).

Collective ownership can be translated as
"every developer can change any part of the code", but does not mean CM. Collective ownership
might work for a small and simple project.
I have seen "building a load" is used as
punishment to the developer whose code
breaks the build. But 80% of the real
problems are not from the compilation
errors (they are good errors because you
can fix them right away), but from
the wrong versions of lib, files, ...
I know there are CM tools can help, but
anything can go wrong if everyone can do anything
through it.
I do not think real commercial projects can
use XP w/o modification.

What I meant with collective code ownership, continuous integration and implied CM was more like
"in order for these to work, configuration management must be employed". In other words, even though XP practices don't explicitly mention CM, implicitly they require it. On the other hand, CM has been a self-evident best practice since Woodstock...

Hi,
I think XP worked if your organization model itself after JobShop environment, even in the Customer Services organization like my involvement. The management calls XP as glorified hacker process. The only way it can strive through mix and match with other processes.
Thanks,
MCao

Originally posted by Mary King:
Collective ownership can be translated as
"every developer can change any part of the code", but does not mean CM.

It *does* mean that CM is the responsibility of the whole team, though.

Collective ownership might work for a small and simple project.

Yes - and it might also work on big and complex projects.

I have seen "building a load" is used as
punishment to the developer whose code
breaks the build.

That's bad - punishment doesn't make things better; only feedback, reflection and learning do.

But 80% of the real
problems are not from the compilation
errors (they are good errors because you
can fix them right away), but from
the wrong versions of lib, files, ...

Then the team somehow needs to handle those problems...

I know there are CM tools can help, but
anything can go wrong if everyone can do anything
through it.

Wich isn't much of a problem if you
- have means to catch those problems early, and
- have mature coworkers who know whom to ask for assistance

I do not think real commercial projects can
use XP w/o modification.

It isn't *meant* to be used w/o modification. It is meant as a good starting point.

Originally posted by Mary King:
But I did not see the role of "configuration
manager" or "build manager" in XP.

That's because XP doesn't try to assign roles to people. Instead it trusts the team to figure out what it needs to do and roles to emerge when needed - and tries to give the team enough feedback to do so.

Who is going to build

Most teams automate this process, to be able to do this several times a day. We are using Ant for this - every developer can make minor modifications (like adding a thirdparty jar), for more complex tasks there has evolved an "expert" you can pair with if you need to.

control the release

"control" in which way?

ensure the correctness of the code?

The developers are ensuring the correctness of their code by pair programming and extensive unit testing (and anything else they find necessary).
Customers ensure correctness of the code by providing automated acceptance tests, being available for questions and by taking a look at the working system early and frequently (and perhaps even using it) - and anything else they find necessary.
Did that help?

Originally posted by Matt Cao:

The management calls XP as glorified hacker process.
MCao

I like this name.

quote:
It *does* mean that CM is the responsibility of the whole team, though.
------------------------------
That means no one is responsible...

Originally posted by Mary King:

I like this name.

OK. Do you also think it's right?

Originally posted by Mary King:
quote:
It *does* mean that CM is the responsibility of the whole team, though.
------------------------------
That means no one is responsible...

On the contrary, it does mean that *everyone* is responsible.

Originally posted by Mary King:
...I know there are CM tools can help, but
anything can go wrong if everyone can do anything
through it.
I do not think real commercial projects can
use XP w/o modification.

Mary,
1. If you are in an environment where people are irresponsible enough that you need to fear anything going wrong then XP may not be a good idea - you may need to have the responsible/mature people be the keeper of the keys and do the builds, review all code before it is checked into your VCS, etc. But if that is the true situation then you have bigger problems to worry about.
2. As I understand it, XP evolved out of the practices used by Kent Beck, et al, on a payroll project for Chrysler -- does that qualify as a "real commercial project"? If not, then what does?
Burk