Der folgende Beitrag aus dem XpForum (20. Sep 2001 "[xp-forum]XP und V-Modell") stammt von MalteFinsterwalder:

> Frage: > Aber wie seht ihr das in Bezug auf Untermengen? > > Die Kombination (UnitTests+Refactoring) scheint doch > in sich geschlossen in vielen Situationen einsetzbar. Ich denke daß etliche Techniken auch in "Isolation" eingesetzt werden können. Wenn auch zum Teil in leicht abgewandelter Form. Isolation meine ich natürlich nur gegenüber anderen XP-Techniken. Wirklich isoliert sind die Techniken ja eh nie. Ich kann Unit Tests schreiben und Refactoring betreiben ohne irgendwelche anderen XP-Techniken. Es ist klar, daß ich damit nicht den gleichen Effekt erhalte, als wenn ich alle XP-Techniken einsetze. Trotzdem wird meine Software etwas besser aussehen und weniger Fehler enthalten wird, also ohne diese Techniken. Ich denke man muß das in Relation sehen. Programmieren ohne Unit Tests und Refactoring ist IMHO immer schlechter als mit, egal in welcher Umgebung. Daß ich das ganze durch Pair Programming noch weiter verbessern kann ist klar. Dadurch würde ich die Qualität weiter verbessern und zusätzlich bessere Wissensverteilung erreichen, aber das muß eben nicht sein, wenn es die Umstände nicht zulassen. Ob ich Simple Design durchführen, oder Big Design Up Front ist wieder ein ganz anderer Punkt. Natürlich schaffe ich mir durch Simple Design viel Ballast vom Hals und werde agieler, aber das ist keine Grundvoraussetzung um Unit Tests schreiben zu können. Ich denke es ist sogar möglich in einem Big Design Up Front-Prozeß Unit Tests und Refactoring einzusetzen. Die größte Schwierigkeit wird sein, daß man das Design entsprechend modifizieren muß. Es kann auch sein, daß man deswegen einige Refactorings nicht durchführen wird. Auch hier gilt, daß das Programm trotzdem besser sein wird, als wenn ich gar kein Refactoring anwende und warscheinlich schlechter als wenn ich Refactor Mercyless praktizieren würde. Ich muß nicht unbedingt Test First arbeiten um Unit Tests zu schreiben. Ich muß nicht einmal Simple Design durchführen um Test First arbeiten zu können. Selbst wenn ich schon die nächsten 200 Tage Programmierarbeit vorausgeplant und designed habe kann ich trotzdem jeden Schritt Test First umsetzen. Ich habe natürlich nicht mehr die gleiche Freiheit bei der Umsetzung, da das Design vorgegeben ist, aber trotzdem erreiche ich eine hohe Testabdeckung und dadurch weniger Fehler in der Software. Ich könnte sogar ein modifiziertes Planning Game verwenden um meinen Big Design Up Front-Prozeß zu planen. Anforderungen auf Karten zu schreiben, mit Aufwand zu versehen und bei Änderungen die Aufteilung anzupassen, bzw. das resultierende Fertigstellungsdatum zu ermitteln ist auch bei Iterationen von 6 Monaten länge und mehr möglich. Ich sage nicht, daß man ein XP-artiges Arbeiten erreicht, wenn man einige XP-Techniken einsetzt. Sicher macht man große Abstriche. Aber nichts desto trotz kann man seine täglichen Arbeitsweisen und die resultierende Software verbessern, auch wenn man nur einige Techniken einsetzt. Welche Techniken wie eingesetzt werden können hängt natürlich vom jeweiligen Umfeld ab. Und man sollte sich darüber klar sein, was man verliert, wenn man bestimmte Techniken nicht einsetzt und wie man diesen Verlust einigermaßen ausgleichen kann. Wenn man ein XP-Projekt machen will, dann braucht man alle Techniken. Wenn man einen anderen Prozeß verwendet, kann man trotzdem einige XP-Techniken einsetzen. Gruß, Malte

Vielleicht kann man das sogar generalisieren und verschärfen:

Man muss aus Entwicklungs Prozessen die einzelnen Techniken isolieren und darf nur die jeweils sinnvollen Teile einsetzen.

... Das ist meine gelebte Grundeinstellung ...

Verfeinert:

Ich benutze aus allen Prozessen das (für meine Begriffe) Beste, und wende das dem Projekt angepasst an. D. h. ich habe eine Reihe von Prozessbausteinen (Tools, Komponenten, ...?) deren Einsatzgebiet und deren Vor- und Nachteile ich kenne. Wenn ich nun ein neues Projekt (mit-) aufsetze und plane, dann such ich mir aus meinem Werkzeugsatz auch die sinnvollen Prozessbausteine aus. Ein grosses Projekt durchläuft andere Phasen als ein kleines ...

Begründung:

• Ich glaube nicht an die Weltformel :-)
• Ich glaube auch nicht an den allgemeingültigen unumstösslichen Prozess (ISO9000, RationalRose), diese Prozesse können zwar zufällig mal irgendwo passen, sind imho aber zu gross und unhandlich und werden desshalb nicht gelebt.
• Mein Entwicklungs Prozess kann sich schnell wandeln und muss sich nicht evolutionär entwickeln (kontinuierliche Prozess Verbesserung). Daher kann sich der Prozess schnell auf geänderte Anforderungen einstellen (Änderungen von Projekt zu Projekt, nicht unbedingt während eines Projekts).
• Dieser Art des Entwicklungs Prozesses kann stufenweise eingeführt und nach Bedarf und selektiv erweitert werden.
• [utopisch] Ich suche immer noch Freiwillige, die meine Denkweise über 10 Jahre hinweg gegen einen anderen Prozess konkurierend einsetzen, um einen direkten Vergleich zu erhalten ... :-)

-- MichaelJerger

Diskussion

Wenn man das weiterdenkt, dann müsste man an einem Katalog von Grundtechniken arbeiten, die möglichst wenig miteinander gekoppelt sind. Gleichzeitig am Aufbau des Know-How über die Wechselbeziehungen und Auswirkungen des Einsatzes dieser Techniken. ExtremeProgramming wäre dann als bewährtes Paket von Techniken zu sehen, das für bestimmte Projekttypen "as is" eingesetzt werden kann? -- HelmutLeitner

Ja, exakt an diesem Punkt bin ich inzwischen in mehreren Diskussionsrunden angelangt.

Ich denke, dass ein solcher Katalog sicher einen Versuch wert wäre, oder? -- MichaelJerger

Geht bei der Zerlegung der Blick fürs Ganze verlohren, war die Zerlegung schlecht. Es besteht immer die Möglichkeit, die Komplexität in die Struktur zu verteilen und nicht in die Teilprobleme. Aber als Programmierer weiss ich, daß man mit einer geeigneten Problemzerlegung viel erreichen kann. -- mj

Ich weiß nicht, so alt ist XP nun auch wieder nicht. Ich seh's eher so: Auch die bisherigen Modelle können bei Ihrer langen Evolution auch nicht in allen Punkten falsch liegen oder ? -- mj

Und letzlich glaube ich, dass so ein Versuch den XP-Vertretern ziemlich auf den Nerven gehen würde, weil er Dilettanten Tür und Tor öffnen könnte: "wir kombineren 7 XP-Techniken mit unserer XYZ-Methode und erhalten noch höhere Effizienz". -- hl

Ich glaube, das können wir verkraften. Was eher nervt ist "wir kombinieren 2 XP-Techniken mit unserer XYZ-Methode und unser Projekt geht den Bach runter. Die XP-Techniken funktionieren nicht." -- IljaPreuß

Ich hoffe ich gehe keinem auf die Nerven ... aber alles in allem erfüllt XP nicht die Anforderungen unserer Projekte, allerdings finde ich XP in Teilen durchaus interessant und wir haben schon begonnen, diese interessanten Teile einzuführen - und ich denke, nicht ohne Erfolg. --mj

Keine Sorge. --hl

Und Ausserdem: Diletanten sterben aus ... das ist Evolutiuon ;-) -- mj

Es sei denn, es handelt sich um Diletanten, die sich sehr gut an ihre Umgebung angepasst haben - diese fallen die Karriereleiter nach oben. Das ist leider auch Evolution... ;-) -- ip

...XP erfüllt nicht die Anforderungen unserer Projekte...

Eine Frage im Hinblick auf die aktuelle Diskussion im XpForum: Sind das eher technische oder eher 'kulturelle' Anforderungen, die nicht erfüllt werden? -- IljaPreuß

Technisch :-), mir fehlt bei XP eine Designphase, wobei unser Projekt aber auch eher nicht XP geeignet erscheint. Ich bin z. Zt. in der Frameworkentwicklung tätig, d. h. Architektur und Design sind unerlässlich.

So wichtig, dass wir uns in XP unaufhörlich damit beschäftigen, nicht nur in einer bestimmten Phase.

Hmmm ... jeder Benutzer des Frameworks wird wirklich begeistert sein, vom Code-, Design- und Architekturrefactoring in jeder Phase !-) --mj

Du hast natürlich recht, das ein Framework ab einem bestimmten Zeitpunkt (dem ersten öffentlichen Release) eine gewisse Stabilität der Schnittstelle erfordert. Wie erreicht Ihr diese Stabilität in Eurem jetzigen Prozess? Können wir AnforderungsGeschichten schreiben, die zu einer ähnlichen Stabilität führen?

Im Endeffekt dadurch, dass wir im Gegens. zu XP eine dedizierte Designphase haben. Diese Designphase kann charaktereisiert werden, wie folgt:

* Pair Design

* Test im Design. Bis jetzt wird unser Design von eine 'externen' Team (Architekt mit Kunde zusammen) getestet, ich denke aber das könnte zum 'Test Driven Design' (aber auf der Design Ebene im Gegensatz zum XP-TestGetriebene? Design) werden.

* Explizites Risikomanagement. Instabilitäts Risiken werden bestimmt, 'gespiked' und überwacht.

* Dokumentation der Designentscheidungen und der Architektur (kompakt, evtl. per Video).

Durch ein langes und sorgfältiges Design kommt i.R. ein tragfähige Architektur&Design zustande, keine Regalware. Änderungsanforderungen werden frühzeitig berücksichtigt und (kleine) sind später leichter möglich.

Das Problem dabei ist die Personalplanung, Idealerweise benötigt unser Prozess im Design 3-7 Architekten/Tester und in der Impl. erst viele Implementierer. Das ist eine Idealvorstellung, die durch Projektverschränkung angenährt werden kann, sich aber nicht immer so aufrechterhalten lässt. Auch dem (eigenen) Mangement ist schwer beizubringen, dass es kontraproduktiv ist, ein 'dringendes' Projekt in schon im Desing mit 50 Mann zu betreiben ...

Aber auch bei anderen Projekten möchte ich nicht darauf verzichten ... --mj

Du hast recht, das ist ein wirklich überzeugender technischer Grund... ;->

Technisch in dem Sinne, das Architektur & Design bei einem Framework ein besonderes Mass an Stabilität der Schnittstellen erfordern :~) --mj

Na ja, mich würde auch interessieren was das "andere Projekte" beinhaltet. Bzw. erhebt sich die Frage FürWelcheProjekteIstXpNichtGeeignet. -- hl

Bei uns ist das mit der Kultur und der Technik nicht wirklich zu trennen. Wir bauen Standardsoftware auf Basis von Charter Client-Projekten. Ich muss also kontinuierlich darüber nachdenken, was neben dem Charter Client andere Kunden (besonders in anderen Ländern mit anderen Geschäftsgewohnheiten und Gesetzen) brauchen, und was von den Anforderungen der Charter Clients Standard ist (und was nicht). Teilweise müssen wir dann dem Client sagen, dass er eben gewisse Funktionen über Kunden-Erweiterungsmöglichkeiten im Rahmen seiner Implementierungsprojekte realisieren muss. Aus den genannten Gründen brauchen wir einen ersten Wurf einer ausgearbeiteten und dokumentierten Architektur up-front, genau wie zumindest ein Grobdesign. Daher kann man bei uns nur Teile von XP oder anderen agilen Prozessen verwenden. Wie Craig Larman auf einem Vortrag (war's die OOP '02?) so schön gesagt hat: man sollte halt bewußt die Komponenten von Vorgehensmodellen kombinieren, die für das eigene Projekt Sinn machen; denken muss man halt noch selber :-))