Immer wieder stoße ich darauf, dass ich zwei Punkte an ExtremeProgramming nicht verstehe. XP ist so sehr auf Kommunikation und Feedback, auf den Teamprozess, also auch auf die reale Psychologie und das Tuning des Softwareentwicklungsprozesses ausgerichtet und scheint es doch nicht zu schaffen, mit zwei Ansichten angemessen umzugehen.

Ich übertreibe absichtlich, aber so kommt die Botschaft von XP bei vielen an:

• Erstens: der Kunde ist unberechenbar. Wenn er heute A will, will er morgen B. Das ist so sicher wie das Amen im Gebet. Aus diesem Grund versuchen wir gar nicht, längerfristig vorauszuplanen oder vorausschauend zu designen.
• Zweitens: Wer noch vorausschauendes Design macht, ist ein ineffizienter Dilettant. Da der Kunde unberechenbar ist und sich auch Umgebungssituationen jederzeit ändern können, macht man das Design besser "simple" ("on the fly","JIT").

Jetzt kann man darüber streiten, ob diese beiden Punkte zutreffen oder in welchen Ausmaß sie in realen Projekten anzutreffen sind. (IMHO: Die Realität ist eine Grauzone). Aber das ist nicht der Punkt.

Der Punkt ist, dass weder Kunden noch Analytiker gerne als Dummköpfe dastehen und dass aus diesem Grund starke Animositäten und Abstossungsreaktionen gegen XP unausweichlich sind.

Du hast sicher recht, dass die Botschaft bei vielen so ankommt. Aber wird sie auch so gesendet? Meiner Meinung nach meistens nicht. Worin liegt aber das Kommunikationsproblem begründet? -- IljaPreuß

(Vier mögliche Gründe sind im zweiten Abschnitt von http://www.agilemodeling.com/essays/agileModelingXP.htm aufgeführt...)

Die Frage ist, ob diese Überzeichnung notwendig ist und ob die XP-Welt ihre Überzeugungen nicht diplomatischer verpacken müsste um ihre Ideen mit größerer Akzeptanz verkaufen zu können.

Es wäre z. B. ganz leicht, für die Änderungen in den Projekten nicht die Kunden, sondern die immer schneller variierenden Umgebungsbedingungen, die immer höhere Flexibilität erfordern, verantwortlich zu machen.

Ein weiterer wichtiger Punkt ist, dass Software ja meistens eingesetzt wird, um einen Prozess zu verändern. Das führt dazu, dass der Einsatz der neuentwickelten Software die Voraussetzungen für ihren Einsatz selber beeinflusst. Wie weitreichend diese Beeinflussung sein kann, ist oft aber schwer vorherzusehen. Deswegen ist es vorteilhaft, diese FeedbackSchleife? beim Entwerfen der Software zu berücksichtigen.

Aber genau das wird doch getan! Niemand würde auf die Idee kommen, XP mit Lochkarten zu betreiben - essentiell ist eben das schnelle Feedback, und das haben wir erst mit modernen Tools.

Mein Eindruck ist, dass der größte Teil des Widerstandes vollkommen anders begründet liegt. Das Einbringen obiger Argumente in eine Diskussion über XP bringt meiner Erfahrung nach in den allerwenigsten Fällen etwas... :-( -- ip

...vier mögliche Gründe... [1] Diese werden angegeben als:

1. Second-hand knowledge of XP
2. Questionable sources of information regarding XP
3. Difficulty seeing beyond their current environment
4. Too much focus on the word “extreme”

Hier muss ich aber auch mal was persönliches beisteuern...: Mich hat der Begriff (bzw. die Formulierung) "Extreme" Programming EBENFALLS abgestoßen zu Beginn, und ich bin mir NICHT sicher, ob er das nicht auch noch immer tut! Ich habe ernsthafte (wohl psychologisch (sic!) zu erklärende) Probleme, zu so einem *Ansatz* Vertrauen zu fassen!! Mein ich ganz ernst... TATSACHE ist auch, dass so ein Begriff wirklich NUR im angelsächsischen (genauer US-amerikanischen) Raum hat entstehen können: Man stelle sich das mal auf Deutsch vor: ein methodischer Ansatz, der sich "Extremes Programmieren", oder "Extrem-Programmierung" nennt...: SCHAUDER!

Da hätte ich dann gleich auch noch einen Vorschlag... bzw. eine Anfrage an alle XP-ler, die hier ev. mitlesen...: Würde es dem "Wesen" des XPs eigentlich widersprechen, wenn man es statt "Extreme Programming" "Dynamic Programming" nennen würde (genannt hätte)??? : Die Übersetzung ins Deutsche "Dynamische Programmierung" bzw. "Dynamisches Programmieren" klingt in meinen Ohren UM WELTEN vertrauenserweckender! (Ausserdem erzeugt es --anders als das IM GRUNDE "nichtssagende" "Extreme Programming"-- ein m.E. (pos.) BILD der Sache beim Hören/Lesen...)

"DynamicProgramming?" ist leider schon für die Programmiertechnik vergeben, die darin besteht, eine Rekursion so umzueseln, dass häufig wiederverwendete Zwischenergebnisse gespeichert und nicht ständig neu berechnet werden. Warum diese Technik ausgerechnet "Dynamic Programming" genannt wurde, weiß ich nicht. -- HenningThielemann

Zur Begriffsklärung siehe etwa [2], [3] und [4]. --kg

Eine Anmerkung jedoch noch... ICH würde das aber eben NICHT als Too much focus on the word “extreme” sehen wollen: Das Wort "Extrem" IST eben "extrem"... :-( Und ehrlich gesagt, ist mir auch nicht ganz klar, WESHALB XP eigentlich so heißt... :-( // Warum OOP so heißt, wie es heißt, weiß ich z.B...

Um es ganz platt zu sagen: Mich STÖRT das wirklich an XP... (Sorry, tut mir leid, ist halt aber so...)
(Vgl. WardsWiki:DontCallItExtreme)

Das Ganze als Frage formuliert: WasIstExtremAnXp?

Ich denke, "Extreme" ist eine der größten Schwächen, aber auch eine der größten Stärken im Namen von XP. Ein PL oder TL, der die Schmerzen eines schwergewichtigen Prozesses schon durchlebt hat (bzw. sein Team dabei beobachtet hat, wie sie es tun) wird bei "extreme" sofort hellhörig werden. Er wird sofort vermuten, dass dies eben nicht das n+1-te Vorgehensmodell ist, sondern wird zunächst einmal in Ruhe lesen, was das alles soll.

Es braucht jedoch (im Moment noch) ziemliche Distanz zum eigenen Arbeitsalltag, um einmal einen Schritt zurück zu tun und zu fragen: "Lebe ich eigentlich den Prozess, den ich glaube zu haben?" Mehr und mehr Projektleiter erkennen heute, dass die Antwort ehrlicherweise "nein" lauten muss. Bis zur Einflussnahme auf den Prozess ist es allerdings immer noch ein Schritt, denn meist wird dieser außerhalb des Teams gebaut, nicht im Team. Der PL muss sich trauen, zum Prozessverantwortlichen zu laufen und Änderung zu verlangen.

MatthiasBohlen