Finden Rotation und der resultierende Wissensaustausch auf freiwilliger Basis statt, ist das eine feine Sache. Sobald Zwang hinzukommt wird wahre Teambildung durch die entstehende Wettbewerbsituation beeinträchtigt. Bemerkung: Bei meiner XP-Lektüre hatte ich nicht denEindruck, daß die Freiwilligkeit bei Rotation eine besondere Rolle spielt... Sobald der falsche Manager den gleichen Eindruck wie ich von XP erlangt, fang ich dann wieder an mir Sorgen zu machen.

Ja, die Sorgen würde ich mir dann auch machen. Ich selber kenne und schätze eigentlich auch eine relativ freie Aufgabenwahl, allerdings ohne explizite Rotation.

• KomponentenTests erlauben automatisches Testen, etwas was mir z.b. bei Assertions wirklich fehlt. Der Aufwand für die Erstellung zusätzlicher Testklassen wird bei weitem durch den Einfluss auf das Design und die Sicherheit bei CodeRefactorings (die Assertions meiner Einschätzung nach nicht bieten können) aufgewogen.
• Nach meinem Verständnis sind KomponentenTests (z.B. JUnit) die eigentliche XP Spezialität. Wenn ich KomponentenTests mit Assertions vergleiche, fehlen mir bei den KomponentenTests die Fähigkeit Runtime Testing zu betreiben und der automatischen Dokumentation.
• Assertions sind nicht vom Code separiert, man kann Assertions während der Programmierung leichter pflegen (wer von uns schreibt schon von Anfang an den perfekten Test ?)
• Gäbe es be XP eine augeprägere Designphase, finde ich Testen schon währende des Designs wichtig.

• Pairprogramming ist inzwischen eine wertvolle Bereicherung in meinem Brufsalltag.
• Neue Betrachtungsweise ist wertvoll.
• Meine Erfahrung ist, Taskwechsel kosten Zeit - allerdings sind meine spezifischen Taskwechsel für XP wohl eher untypisch, somit sondern hilft es also schon, Taskwechsel nur weniger störend zu gestalten.
• Ausschliessliches Pairprogramming ist nicht immer notwendig (System.out.println kann ich alleine ...).

Das XP Planungsspiel ist mir zu wenig. Ich denke bei jeder Projektform ist

• eine feste Zeitplanung ein natürliches Ziel des Kunden .
• XP - Zeitschätzung ist trivial - evtl. sind alle anderen Zeitabschätzungen im Endeffekt auch trivial sind. Allerdings bietet die Kombination Zeitabschatzung & Risikomanagement meiner Meinung nach ein brauchbares Instrumentarium um auch einen festen Zeitplan sinnvoll zu bestimmen & einzuhalten.
• XP macht die Voraussage, dass der Kunde momentan noch gar nicht genau weiß, was er will. Er wird seine Meinung ändern, weil sich sein Verständnis des System ändert, während er mit der ersten Version arbeitet (weil er während der Entwicklung neue Ideen bekommt, sich sein Umfeld und damit seine Bedürfnisse ändern).

• Durch das frühe Herunterbrechen der Probleme auf Features und Karteikarten wird evtl. eine unglückliche Modul/Code Struktur begünstigt.

• Falsche Modularisierung ist häufig unproblematisch und manchmal muss man auch eine größere Story akzeptieren...

Siehe:

• XpKritikAktuelleDiskussion
• XpKritikUrsprünglicheTexte
• WardsWiki:ExtremeMisunderstanding
• WardsWiki:CritiqueOfXp

• ZweiPsychologischeProbleme