Kann Man Xp Techniken Isoliert Einsetzen
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Im September 2001 ergab sich im XpForum eine Diskussion darüber, ob man einzelne XP-Techniken isoliert einsetzen kann. Manche sind der Meinung sein, dass man schwergewichtige Prozesse damit anreichern kann. Andere meinen, dass dies nicht sinnvoll möglich ist.


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:

Und noch etwas, ich kann nur dann bewusst steuern, wenn ich mindestens zwei Alternativen habe und deren Auswirkungen abschätzen kann ...

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

Möglich, aber ich glaube, dass so ein Versuch aus verschiedenen Gründen problematisch wäre. Einmal kann beim analytischen Zerlegen der Blick für das synthetische Ganze leicht verloren gehen.

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

Dann muss man sehen, dass ExtremeProgramming viele Jahre und Projekte für die Feinabstimmung der Techniken investiert hat; ich sehe das wie ein feingetuntes Rennauto, bei dem eben Reifen, Fahrwerk und Aerodynamic etc. untrennbar gekoppelt sind. Es ist möglicherweise relevanter, ExtremeProgramming im Detail zu verstehen, als theoretische Variationsmöglichkeiten zu untersuchen.

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

Auf der diesjährigen OOP wurden übrigens mehrere Agile Prozesse mit genau dem Kochbuchgedanken vorgestellt. Sobald's was im Netz gibt, werd ich mal suchen und ein paar Quellen dazu zitieren. -- 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

Ich denke ich habe unser Problem inzwischen lokalisiert: 'Der nicht exponentielle Kostenanstieg' ist in der Framework Entwicklung nicht gegeben (siehe auch ExtremeProgramming/Kritik).

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 :-))
-- Jörg
siehe XpMaturityModel
KategorieXp
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 14. Januar 2004 12:13 (diff))
Suchbegriff: gesucht wird
im Titel
im Text