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).

Diese Argumentation schiebt meiner Meinung nach den schwarzen Peter dem Kunden zu. Dadurch dass XP keine verbindlichen Zeitzusagen machen will, ist der XP - Entwickler zwar immer ehrlich, aber der Kunde erhält insgesamt weniger Dienstleitung und muss längere Projektlaufzeiten bezahlen.

siehe FestpreisVertrag

• 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...

Die Aufteilung in AnforderungsGeschichte'n dient nicht der Modularisierung des Designs, sondern der Aufstellung des ReleasePlan?'s mit möglichst großem Wert für den Kunden und zur Realisierung des Feedbacks über die EntwicklungsGeschwindigkeit?.

Modularisierung erfordert für mich, erst einen Problemüberblick zu erhalten. Die Karteikartenmethode begünstig aber eher linear ein Teilproblem nach dem anderen abzuarbeiten. Dadurch enstehen dann unguenstige Modulschnitte.

Ohne Zweifel kann ein Design, das für Iteration 1 geeignet schien, sich bereits in Iteration 2 als unzureichend erweisen (genau genommen geschieht das in viel kleineren Schritten - von TestFall zu TestFall). In diesem Fall sind die Entwickler angehalten, das Design per CodeRefactoring immer auf dem bestmöglichen Stand zu halten.

Also ehrlich, "auf ... Stand halten" hört sich für mich nach unelegant und unnötig viel Arbeit an.

Falsche Modularisierung ist tödlich, wenn man keine Möglichkeit hat, sie zu korrigieren. Falsche Modularisierung ist unproblematisch, wenn man Mittel und Wege kennt, sie zu korrigieren.

Die richtige Modularisierung für heute kann bereits für die morgigen Anforderungen ungeschickt sein; über den Lebenszyklus einer Software verschlimmert sich dies immer weiter, wenn man nicht gegenarbeitet. Um so besser die Modularisierung und umso kleiner die Korrekturschritte, desto unproblematischer die Korrekturen. Daher ist ständiges CodeRefactoring keine unnötige Arbeit, sondern Investition in die Wart- und Erweiterbarkeit des Codes, die sich sehr schnell auszahlt.

Das ist schon klar ... allerdings ist ein CodeRefactoring bei Modul-Schnittstellen recht teuer und mit Architektur kann ich diesen Aufwand vermindern. Natürlich ist keine Architektur perfekt für alle Anforderungen der Zukunft gerüstet. Aber wenn meine designten Schnittstellen 3-4 XP CodeRefactoring Zyklen überleben, ist das schon ein Gewinn, oder ?

Ich möchte mich hier nicht ausschliesslich an der Modularisierung aufhängen. Modularisierung ist nur eine der Stellen, an denen sich fehlendes Design besonders bemerkbar macht.

Was ich damit sagen will ist, dass mir XP mit dem Verzicht auf eine ausgeprägte Design Phase zuviel Richtung try&error geht. Ich denke mit Intelligentem Vorgehen kann man sich einige zufälligen try&error Schritte ersparen. Sozusagen Gen Design contra Evolution - mit allen bekannten Vor- und Nachteilen.

• Wenn ich AkzeptanzTests mit UseCaseDrivenTesting? gleichsetzen darf, frag ich mich inwieweit AkzeptanzTests tatsächlich automatisiert werden können.
• Erfahrungen scheinen zu zeigen, dass das in den meisten Fällen einfacher ist, als man annehmen mag.
• Nach meinem Verständnis sind KomponentenTests (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.

• Assertions sind nicht fähig, Objektinteraktionen oder eine Sequenz von Methodenaufrufen zu testen?

KomponentenTests sind für TestgetriebenesDesign unerlässlich. 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.

Hmm, ich denke eine Kombination Assertions und Komponententests sind mein Königsweg.

Damit wärst Du nicht alleine in der XpGemeinde?. Wichtig ist nur, die Vorteile und Kosten zu beobachten und seine Entscheidung danach anzupassen.

Fluktuations-Overhead wird nicht vermieden. Pair-Programming und Rotation nehmen den Fluktuations-Overhead nur vorweg. Argumente von mj:

• Meine Erfahrung ist, Taskwechsel kosten Zeit...
• Ausschliessliches Pairprogramming ist nicht immer notwendig (System.out.println kann ich alleine ...).

• Laut Untersuchung ist ProgrammierenInPaaren nicht weniger produktiv.
• Partner vermindert den Verlust eines Taskwechsels.
• Neue Betrachtungsweise ist wertvoll.

Vielleicht musst Du gar nicht die Taskwechsel verringern, sondern sie eher weniger störend gestalten. Ich könnte mir vorstellen, dass auch hier TestgetriebenesDesign (insbesondere durch seine MiniIterationen?) helfen kann.

Das kann ich gar nicht nachvollziehen. Jeder Taskwechsel stört mich und ich geb zu ich tendiere hier eher zu Tom DeMarco?, Taskwechsel sind verlorene Zeit.

Andere Idee: Verringere Taskwechsel, indem Du die Tasks kleiner gestaltest. Wenn jeder Task nur eine Stunde dauert, hast Du jede Stunde die Gelegenheit den Partner zu wechseln.

Hmmm inzwischen stimme ich da mit DIr üerein, siehe XPKritik. Ich wollte nur die alte Diskussuion noch nicht löschen ...