Kritikpunkte

• Nicht exponentielle Kostensteigerung. Eine Vorraussetzung für XP ist, dass die Kosten für einen Fehler mit der Zeit nicht exponentiell teurer werden. Wenn dies eine essentielle Vorraussetzung für XP ist, ist mir hier Kent Beck's Manifest einerseits zu vage und andererseits zu stringent.
• Einerseits fehlt ein wesentlicher Zusammenhang zw. der Kostenetenwicklung und der Projektbeschaffenheit, die Qualität der Schnittstellen. Sind wenige stabile Schnittstellen vorhanden, kann viel 'horizontaler' Code mit einer flachen Kostenkurve entwickelt werden.
• Werden andererseits Schnittstellen (und der zugehörige Code) entwickelt, von denen viel 'horizontaler' Code abhängt, tut man gut daran, diese Schnittstellen schnell und möglichst endgültig stabil zu bekommen, da sich hier Änderungskosten exponential auswirken. So dürfte XP z.B. auf unser aktuelles Projekt (eine Framework Entwicklung) definitiv nicht angewandt werden. Wir praktizieren XP unter Berücksichtigung der o.g. Besonderheit in weiten Teilen aber dennoch erfolgreich.

• GemeinsameVerantwortlichkeit
• Dadurch wird der Kommunikationsaufwand gesteigert.
• Der natürlich vorhandene ModulVerantwortliche? wird in XP nicht erwähnt.

• Auf Managementebene notwendige Dokumentation wird nicht unterstützt.
• Rechtlich verbindliche ProjektDokumentation? ist z.B. Personal- / Zeit- und Bugetplanung.
• Politisches Planen heisst im endeffekt, wer schreibt, gewinnt. Konkret, wenn ich, bei einem Problem im Projekt, für Vorstand Müller einen detailierten neuen (graphischen) Plan aus der Tasche zaubern kann, bekomme ich eine Unterschrift auf meinen Plan und niemand mischt sich ins Projekt ein.

• Unklare Rollenverteilung hemmt Entscheidungsfähigkeit
• XP sagt nicht, wer bei einer anstehenden Entscheidung die Autorität hat. In den meisten Fällen lässt sich sowas durch Diskussion lösen. Aber wenn's einen Glaubenskrieg gibt, muss die Autorität die Entscheidung treffen.
• In einem Team gibt es immer eine natürliche Autorität - ich weiss nicht, ob das wirklich immer so ist, und ist dies auch die optimale Autorität?

• Fehlende Unterstützung für feste Zeitpläne
• Es gibt mehrere Kunden gleichzeitig - was ist dann zu tun ?
• Rotation kann unbeliebte Teammitglieder persönlich treffen, Mobbing ist möglich.

Diskussion

• Unklare Rollenverteilung hemmt Entscheidungsfähigkeit
• XP sagt nicht, wer bei einer anstehenden Entscheidung die Autorität hat. In den meisten Fällen lässt sich sowas durch Diskussion lösen. Aber wenn's einen Glaubenskrieg gibt, muss die Autorität die Entscheidung treffen.
• In einem Team gibt es immer eine natürliche Autorität - ich weiss nicht, ob das wirklich immer so ist, und ist dies auch die optimale Autorität?
• Zu diesem Thema hatte KentBeck vor, ein Buch zu schreiben - das Manuskript und die Diskussion die dazu vor einigen Monaten stattfand ist unter http://groups.yahoo.com/group/extremeleadership/ zu finden.

Manche der hier angeführten Themen scheinen mir allgemeine gruppendynamische Probleme zu sein (z. B. Rollenverteilung, Mobbing), die nicht sehr XP-Spezifisch sind. -- HelmutLeitner

Stimmt, ich denke aber, ein Entwicklungsprozess sollte genau diese Probleme auch addressieren. Das tut XP ja auch in Teilen (z.B. Motivation). Zum Thema Konfliktlösung und -erkennung schweigt sich XP aber weitgehend aus ... ich denke das sollte ganz klar gesagt werden. -- mj

Was sollte XP zu diesen Themen sagen? (Das ist eine ernst gemeinte Frage, von der ich mir konstruktive Vorschläge erhoffe...) Wie gehen andere Prozesse mit diesen Problemen um?

Hmmm, wenn ich so darüber nachdenke, fällt mir ein:

• Zuerst erwarte ich mir von XP einen expliziten Hinweis auf das vorhandene Problem. Vor allem da XP anfälliger für ein solches Problem ist.
• In einem Gespräch mit allen Parteien eine win-win Situation suchen.
• Evtl. versuche ich das Konfliktteam mit Autorität zu dem Punkt zu bringen, an dem es sein gemeinsames Erfolgserlebnis hat. D.h. auch ein Konfliktteam sollte den Team - Benefit erfahren.
• Als letzten Ausweg ernste Konsequenzen androhen und durchführen.

Was fällt euch dazu sonst noch so ein ? Das ganze eskaliert mir fast etwas zu schnell ...

Andere Prozesse haben dieses Problem nicht, da Teamarbeit hier nicht mit allen stattfindet. D.h. es gibt immer eine Möglichkeit einen vorhandenen Konflikt durch räumliche und logische Distanz zu entschärfen.

Hast Du es schon einmal ausprobiert? Die meisten, die ProgrammierenInPaaren eine reale Chance geben, scheinen recht schnell auf den Geschmack zu kommen. Eine gewisse Bereitschaft zur Zusammenarbeit muss natürlich schon vorhanden sein - ohne diese hat ein Entwicklungsteam meiner Meinung nach aber eh größere Probleme als das Bilden von Programmier-Paaren...

TestgetriebeneEntwicklung ist eigentlich mehr eine Design-Praktik als eine Test-Praktik; das automatische Testen fällt quasi nebenbei mit ab. Und der Begriff "Test-Infected" ist ja nicht irgendwo im stillen Kämmerlein entstanden, sondern tatsächlich "in der Wildnis" beobachtet worden.

Eher "Unsere Arbeit ist unsere Arbeit". Die meisten Entwickler die ich kenne, finden es sogar eher angenehm, Verantwortung mit anderen teilen zu können.

Dann findest Du also auch, dass es erstrebenswert wäre? Mag einfacher zu erreichen sein, als Du Dir vorstellst - immerhin *gibt es* Teams, die XP praktizieren (auch in Deutschland).

Wie kommst Du auf die Idee???

Macht auch wenig Sinn nach "dem XP-Guru" zu fragen, wenn das ganze Team XP praktiziert, oder?

Ich frage mich ernsthaft, wo Du diese Ideen her hast...

Ich habe viele der XP-Praktiken an einem privaten Zwei-Personen-Projekt gelernt ( http://sf.net/projects/bloodball), und die einzigen Projekte, bei denen ich zögern würde XP einzusetzen, wären solche, die zu groß (bzgl. Anzahl Entwickler) sind.

-- ip