Background:
We are using eXtreme programming since 1999 in a number of development
projects. On the one hand at the University for teaching purposes and at
the other hand inside the company for professional software development
projects. We have just finished a project where we developed a set of tools
for another software company within 11 weeks, with 7-8 developers and unclear
and changing requirements. We managed to finish it successfully with about
1000 integrations, 1-2 releases per week (1-2 releases per day at the peek),
using pair-programming and most of the other XP values and techniques.
As you can see we did a lot extreme programming and gained experience in
realizing XP for real world problems. These days we run about 5 XP projects
within the company, all of them with a different team size and different
application domains in different settings. We distilled a number of advises,
tricks and best practices we would like to share and discuss. Some of them
are described very briefly here.
Continuous Integration:
The XP process is fragile. As we moved to XP with our framework development
project, the longest running project inside the company, we tried to establish
continuous integration for the framework development process. In the beginning,
we failed to use the one physical integration machine and the XP process
broke. Then we reified the continuous integration technique with a nice
artifact, the JWAM IntegrationServer, which provides an extremely easy
and fast way to use continuous integration (extending a version management
system with additional rules and conventions would have been the alternative).
We have been using our tool very successfully since one and a half year
and thus found out that providing good artifacts (in addition to the XP
values) is useful to stabilize the process.
The Customer Role:
It is our thesis that XP, in its current form, fails to address the
actual situation at the client’s organization in a suitable way. The main
stakeholder, i.e. the users and their management, are merged into a single
role: the customer. This one role cannot address the different forces in
a development project. The users of the future system know their application
domain in terms of tasks and concepts, but they rarely have an idea of
what can be implemented using current technologies. Moreover, it is often
misleading to view the users of the future system as the goal donor. They
are unfamiliar with the strategic and business goals related to a project
and, more important, they do not control the money. Therefore we make a
distinction between the role of the user and the role of the client. The
users have all the domain knowledge and therefore are the primary source
for the application requirements. The client sets the goals of the development
project from a business point of view. The client will only pay for a development
project if these goals are met to a certain degree.
The Story Cards Approach in the "Exploration Phase":
We found the Story Cards/Task Cards approach to work very well when
the basic structure of the software under construction was already present
and the continuous, iterative process was running smoothly. On the other
hand, when starting from scratch, we found Story Cards to not work so well
(unless the customers has a rather concrete idea of the software to be
build, which we encountered rarely). In the absence of the ideal customer
(see our remarks on the customer role above), we come to rely on techniques
like interviews and the writing of use cases and glossaries to get a grasp
of the current work situation, the processes and the domain language. We
apply the short releases rule to these documents to get feedback from the
users/clients and start an iterative, participative development that guides
us to the construction of prototypes. These help us to find a base where
we can start using the Story Cards/Task Cards approach of XP’s Planning
Game.
Pair Programming:
What can you do if you have to work with programmers that refuse to
program in pairs? Is "kicking them out" the only possibility? We are going
to share some experiences and thoughts on that.