XP löst das Problem zusätzliche sich ändernder Anforderungen elegant. Der Kunde hat jederzeit das Recht zu Änderungen und Erweiterungen. Er muss nicht schon vorher wissen was er am Ende genau will! Allerdings ist auch institutionalisiert, dass eine Änderung nicht einfach irgendwo "eingeschmuggelt" wird; Sie muss explizit als AnforderungsGeschichte geschrieben werden, unterliegt einer Kostenschätzung und verteuert das Projekt (es sei denn der Kunde verzichtet auf andere Features). Also, wenn das nicht revolutionär ist!

Bei XP wird ständig Aufwand geschätzt, wobei alle Mitarbeiter einbezogen sind. Der Planende schätzt im Konflikt mit dem Kunden und im Konflikt mit dem Programmierer. Der Programmierer ist gezwungen seine Realzeit zu schätzen und einzuhalten. Es gibt ständige Rückkopplungen für alle Beteiligten und zunehmende Erfahrungswerte. Außerdem ergibt sich für jeden Einzelnen die Möglichkeit des messbaren Wettbewerbs innerhalb des Teams, sowohl bei der Schätzung als auch bei der Implementierung.

Kunde und Programmierer erarbeiten in gemeinsamer Diskussion den Entwicklungsplan, indem der Kunde Anforderungen definiert, die Programmierer deren Realisierungsaufwand schätzen und der Kunde schließlich die Prioritisierung festlegt. Einen außenstehenden 'Planer' gibt es in diesem Sinne dabei nicht.

Die Programmierer schätzen nicht Realzeit, sondern Idealzeit. Das Verhältnis zwischen Idealzeit und Realzeit wird ständig gemessen und der Entwicklungsplan bezüglich der daraus gewonnenen Erkenntnisse korrigiert. Jedem muss klar sein, dass Schätzungen eben nur Schätzungen sind; die Programmierer gehen lediglich die Verpflichtung ein, den Kunden sofort zu informieren, sollte sich eine Schätzung als falsch herausstellen, damit dieser seine Prioritisierungen anpassen kann.

Der Realzeit:Idealzeit-Faktor ist kaum ein sinnvoller Indikator zur Leistungsbewertung, da Idealzeit ein sehr subjektiver Wert ist. Die reine 'Programmierleistung' ist jedoch sowieso kein angemessenes Bewertungskriterium für ein Mitglied eines Projektteams.

Ein zusätzlicher Anreiz könnte sein, dass der Kunde die Entwicklung zu jedem Zeitpunkt abbrechen kann, und dann ein funktionierendes System bekommt, in dem die von ihm als am wertvollsten eingestuften Features realisiert sind.

Mögliche Probleme:

• XP ist nur für ein relativ kleines Segment an Softwareprojekten tauglich.
• ProgrammierenInPaaren in Verbindung mit der erforderlichen Rotation führt zu sinnvollen Teamgrößen von ca. 4-10 Personen. Auch die XP Leute selbst halten größere Projekte für nicht sinnvoll.
• Das C3Projekt hatte ein 15-Mann-Team (richtig?). Bei wesentlich größeren Teams müssen zwangsweise Formalien eingeführt werden, da nicht mehr sinnvoll jeder mit jedem kommunizieren kann.
• ProgrammierenInPaaren erlaubt durchaus, dass sich lose 'Splittergruppen' bilden, die sich auf ein gewisses Teilgebiet spezialisieren.
• Der Kunde muss bereit sein, eine Person ins Team zu entsenden (relativ hoher Aufwand), d. h. er muss viel Vertauen in XP haben.

Das ist nicht ganz korrekt. Der Kundenvertreter muss nur seinen Arbeitsplatz beim Team haben, er muss nicht full-time für das Team zur Verfügung stehen. Der Aufwand sollte nicht grösser sein als sonst. Der Vorteil für die Entwickler ist, dass sie sich nur umdrehen müssen um auch auf eine "kleine" Frage eine Antwort zu kriegen. Wenn kein Kundenvertreter vor Ort sitzt (in Rufweite!), fallen viele dieser kleinen Fragen unter den Tisch, da man nicht unbedingt eine Mail schreiben möchte oder gar das Telefon zur Hand nehmen will. Das führt zu einer Häufung von kleinen Fehlern in der Implementation, die dann erst viel später (wenn überhaupt) entdeckt und korrigiert werden.--PeterGassmann

Es wäre allerdings interessant zu erfahren, wie gut es Kunden gelingt, diese Entscheidungs- und Auskunftskompetenz in einer Person zu konzentrieren. Das ist keine Problem von XP, sondern ein grundsätzliches Problem auf der Kundenseite. --hl

Häufig geht es weniger um Entscheidungen, sondern mehr um fehlendes Detailwissen. Zum Beispiel in welchem Range ein Wert typischerweise sein kann, wie viele verschiedene Arten es maximal geben kann, etc. Das Problem der Entscheidungskompetenz ist tatsächlich vorhanden, XP hat aber den Vorteil dass das Problem früher explizit sichtbar wird (spätestens beim ersten CommittmentMeeting?)! Damit wird eher eine Lösung dafür gesucht, als wenn es lange unterschwellig bleibt. --PeterGassmann

• Ein KundeVorOrt verschafft dem Kunden die seltene Möglichkeit, die Entwicklung aus erster Hand zu erfahren und jederzeit einzugreifen. Die durch die äußerst direkte Kommunikation gesparrte Zeit schlägt sich in bares gesparrtes Geld nieder.
• Der Kunde muss mehr daran interessiert sein, eine Software um jeden Preis zu erzeugen, als eine fixierte Leistung um einen Pauschalpreis zu bekommen. D. h. XP eignet sich am besten für (1) Startups (2) "In-House-Corporate-Software".
• Und für Kunden, denen klar ist, dass bei einem Festpreis zwangsweise die Qualität auf der Strecke bleibt. Und für Kunden, die gerne bekommen möchten, was sie brauchen, nicht das, was die Entwickler denken, verstanden zu haben.
• Was ich vermutlich sagen wollte ist: in vielen Situationen muss man dem Kunden zusätzlich zur Problemlösung auch noch die Philosophie von XP verkaufen. Dies ist eine mögliche Schwierigkeit im Marketingbereich. Offenbar ist man sich dessen auch bewusst und arbeitet heftig an entsprechendem "hype", um vielleicht aus diesem Nachteil sogar einen Vorteil zu machen.

• XP ist vermutlich nur dort geeignet, wo Personen komplett einem Projekt zugeordnet werden. Eine Aufteilung von Spezialisten, die gleichzeitig für mehrere Projekte tätig sind, scheint nicht praktikabel (wäre für den Kunden nicht transparent).
• Unter welchen Umständen erscheint solche Arbeitsweise denn als praktikabel??? Und inwiefern ist eine Aufteilung bei XP weniger transparent, als ohne???

Gibt es Bestandteile, die wichtiger sind als andere? Oder sind alle Bestandteile unverzichtbar?

... wichtiger ...

PerfekteTests? dann ProgrammierenInPaaren

... unverzichtbar ...

Nichts. XP ist ja das Prinzip des Flusses. Die Anpassung des Prozesses an lokale Gegebenheiten ist da wichtig.