Ein Erfahrungsbericht aus dem XpForum (23. Sep 2001 "[xp-forum]XP und V-Modell" - http://groups.yahoo.com/group/xp-forum/message/2423) von StefanRoock:

Bei einem aktuellen Projekt haben wir mit Pair-Programming begonnen. Kurz darauf Stand-Up-Meetings. Parallel haben wir Short-Releases eingeführt. Da haben wir ganz langsam angefangen und zunächst ein Release alle 3 Monate angestrebt. Dann haben wir Iterationen zusätzlich eingeführt. Diese waren zunächst 6 Wochen lange, jetzt drei. Kurz nach Einführung des Pair-Programming haben wir Collective-Ownership eingeführt. Dann kamen Unit-Tests und Refactoring. Dann kamen Planning-Game und etwas später On-Site Customer. Code-Conventions haben wir erst relativ spät eingeführt, ebenso wie Continuous-Integration (bedingt durch Schwierigkeiten mit VAJ). Exlizite Metaphern kamen ganz zum Schluss. Zur Einordnung: Wir haben 6-8 Monate gebraucht, um alle Techniken zu installieren. Natürlich verlief diese "Installation" nicht nur "vertikal", sondern auch horizontal. Wir haben also jede Technik erstmal in einer Basisversion eingeführt und dann "hochgedreht", während parallel weitere Techniken eingeführt wurden.

Frage

Wie kann man sich die Basisversion und das Hochdrehen der einzelnen Techniken vorstellen? Bei vielen Techniken (Pair-Programming, Unit-Tests, On-Site Costomer, ...) scheint das doch eine ja/nein Entscheidung zu sein.

Antwort

Generell muss mal jede XP-Technik erlernen und das geht nicht am Wochenende. Das braucht seine Zeit. In diesem Sinne ist das hochdrehen ein ganz natürlicher Prozess. Beim Pair-Programming z.B. dürften die wenigsten Entwickler in der Lage sein, von heute auf morgen sinnvoll 8 Stunden am Tag im Paar zu entwickeln.

Natürlich ist Lernen ein iterativer Prozess. Allerdings kann ich das Zusammenspiel der Praktiken nur lernen, wenn ich auch wirklich alle Praktiken benutze. Meine Erfahrung ist, dass das schrittweise Einführen ein eher schleppender, unbefriedigender Prozess ist.

Was das ProgrammierenInPaaren angeht, so ist es war dass es Charaktere gibt, die sich anfangs damit schwer tun. Ich habe aber noch niemanden erlebt, der nicht mittelfristig dafür zu begeistern gewesen wäre. Vielleicht hatte ich aber auch einfach nur Glück.

Dem Vergleich mit CMM kann ich übrigens nicht ganz nachvollziehen... -- IljaPreuß

Auch CMM beschäftigt sich mit den Prozessen rund um Softwareentwicklung. Auch wenn sich ein direkter Vergleich nicht unbedingt aufdrängt, es geht in beiden Fällen darum, (neue) Prozesse zu etablieren. Die Strategie bei CMM besteht aus einer schrittweisen Fokussierung auf eine Anzahl Schlüsselprozesse. In Stufe 2 sind das andere als in Stufe 3. Man versucht aber zunächst auf Stufe 2 zu kommen, bevor man sich mit Stufe 3 beschäftigt.

Ich kritisiere CMM gelegentlich mit einem Bild: Das Düngen von Pflanzen bringt dann am meisten, wenn man gleichmäßig düngt. Die CMM Philosophie gleicht eher dem Hausbau: Ich kann nicht das Dach bauen, bevor ich das Fundament gelegt habe. Hat auch was für sich, setzt aber Einigkeit darüber voraus, was zum Fundament und was zum Dach gehört. CMM krankt daran, dass das Haus nie fertig wird. Ich bin also durchaus ein Freund des ganzheitlichen Ansatzes. Bei XP habe ich dagegen mehr den Eindruck, eine Kirche zu betreten: Entweder ich glaube daran, oder ich bin fehl am Platze. Dabei sind die Ideen zum Teil wirklich gut und auch partiell umsetzbar. Ich sehe z. B. kein Problem darin, testgetrieben zu entwickeln, kontinuierlich zu integrieren, inkrementell zu liefern aber auf Pairprogramming zu verzichten.

-- SDö