mail 0660

Hallo V-Modeller!

Die Diskussion um XP und das V-Modell finde ich interessant. Ich
antworte vor allem auf Herrn Widmann, der nach Erfahrungen fragte.
Letztes Jahr haben wir in der Arbeit ein paar Erfahrungen mit XP
gesammelt. Wir hatten drei Praktikanten, die für uns innerhalb von
sechs Wochen eine Teamdatenbank entwickelten. Unsere Ziele wurden
erreicht: das Programm wurde in Kosten und Zeit entwickelt (ist ja
nicht gerade selbstverständlich...) und wir können besser
einschätzen, ob XP und das V-Modell sich vertragen.

(Strenggenommen war es kein XP, sondern nur einzelne Praktiken von
XP. Denken Sie sich das einfach dazu, wenn ich im folgenden von XP
spreche... Und seien Sie nicht enttäuscht über den Telegrammstil: es
ist abend und ich bin müde...)

Hier in Kürze unsere Erfahrungen mit XP:

Charakterisierung unseres Projekts:
- drei Praktikanten als eXtreme Programmers, ohne XP-Wissen,
  ohne vertiefte Visual-Basic-Kenntnisse
- Auftraggeber: Software-Team aus 5 Personen; ich selbst war
  gleichzeitig XP-Coach und Haupt-Ansprechpartner
- Zeit: 6 Wochen
- Ziel: Teamdatenbank
- Storycards (Anforderungen): höchst unterschiedlich, was
  Umfang, Qualität, Funktionalität betrifft

Die Praktiken:

--- Einfacher Entwurf ---
Einfache Lösung bedeutet nicht: die erstbeste Lösung. Einfachheit ist
gut umzusetzen. Einfachheit hat sich in Streitfällen als
Entscheidungshilfe bewährt: statt zu streiten, ob Lösung A oder
Lösung B besser ist, lieferte die Frage "was ist einfacher?"
schnellere Lösungen.
Aber: manchmal ist es schwierig, *nicht* vorausschauend zu
programmieren. Besonders wenn man weiß, daß das nächste Arbeitspaket
viel einfacher wird, wenn man beim aktuellen Arbeitspaket nur die
"zweit-einfachste" Lösung umsetzt.

--- Refaktorisierung ---
Dafür blieb wenig Zeit, aber auch wenig Bedarf. Projekt vielleicht zu
klein.

--- Programmierrichtlinien ---
Wurden nicht explizit niedergeschrieben, bei 3 Personen erschien es
auch nicht unbedingt notwendig.

--- Gemeinsame Verantwortung ---
Hat sich von alleine eingestellt, sowohl beim Code als auch bei den
Rollen der Personen. Hat prima funktioniert.

--- Paarweises Programmieren ---
Sehr erfolgreich. Das Wechseln zwischen Programmieren und "Zusehen"
fand nicht so häufig statt wie vorgeschlagen: statt alle 15 Minuten
dauerte es bis zu zwei Stunden. Der Nicht-Programmierer empfand es
als Verschnaufpause. Hoher Kommunikationsaufwand, hoch konzentrierte
Arbeit. Kaum Codier-Fehler.
Die Arbeit im Paar führte auch dazu, daß das Wissen des Einzelnen
schneller wuchs. Innerhalb von 6 Wochen fanden die drei sich sehr gut
in Visual Basic zurecht und konnten komplexe Aufgaben lösen.

--- Kontinuierliche Code-Integration ---
Konnte nur rudimentär umgesetzt werden, weil (1) das Team zu klein
war und (2) keine Testumgebung zur Verfügung stand. Deshalb keine
Aussage dazu.

--- 40-Stunden-Woche ---
Die XPler definierten für sich eine Art Kern-Arbeitszeit, während der
alle drei vor Ort sein sollten. Das Planungsspiel führte dazu, daß
keinerlei Mehrarbeit notwendig war. Die tägliche/wöchentliche
Arbeitszeit war völlig im Rahmen der gesetzlichen Arbeitszeiten.

--- Kundenvertreter im Team ---
Wurde nicht umgesetzt, deshalb keine Aussage dazu. Der Kunde war
jedoch jederzeit ansprechbar und nur ein paar Türen entfernt.

--- Systemmetapher ---
Wurde nicht umgesetzt, weil die XPler keinen Sinn darin sahen;
deshalb keine Aussage dazu. Ich habe bei Nicht-Software-Fragen sehr
gute Erfahrungen mit Metaphern gemacht.

--- Kleine Releases ---
Zwei Releases (jeweils drei Wochen); pro Release drei Iterationen
(jeweils eine Woche); pro Iteration mehrere Arbeitspakete im Umfang
von einem halben Tag bis maximal 2 Tagen.

--- Planungsspiel ---
Der Überraschungserfolg! Ohne jede Erfahrung im Planen von Aufwänden
konnten die XPler die kleinen, selbstgeschnürten Arbeitspakete von
Anfang an sehr gut abschätzen. Beide Releases wurden rechtzeitig
fertig und hatten genau den vereinbarten Umfang.
Für uns als Kunden war es schmerzhaft, Prioritäten zu setzen und
geliebte Storycards nach hinten zu verschieben, bzw. aufzugeben. Die
Enttäuschung am Anfang wurde aber dadurch wettgemacht, daß der dann
vereinbarte Leistungsumfang *vollständig* und fast *fehlerfrei*
erbracht wurde.
Für beide Seiten die interessanteste Erfahrung!

--- (Automatisierte) Tests ---
Wurde nicht umgesetzt, weil keine Testumgebung existierte. Dennoch
eine Aussage dazu: unbedingt notwendig! Die fehlenden Tests führten
dazu, daß Schönheitsfehler erst bei der Kundenabnahme entdeckt
wurden. Der Erfolg der anderen Praktiken war durch die fehlenden
Tests stets gefährdet. Zumindest haben beide Seiten das so empfunden.




=== FAZIT ===
XP eignet sich dann als Prozeßmodell, wenn die Bedingungen erfüllt
sind, die die XP-Väter nennen, z.B. unklare/sich ständig ändernde
Anforderungen, keine explizite Doku notwendig, sehr große Nähe zum
Kunden, Bereitschaft aller Beteiligten.

ABER: XP ist kein Freibrief für Chaos. Man muß die Praktiken an die
eigene Situation anpassen und sehr genau umsetzen. Das heißt, man muß
sich bewußt mit ihnen auseinandersetzen und nicht einfach mit einer
vagen Vorstellung draufloswurschteln. Das Verständnis für die
Praktiken kommt aber sehr schnell und vertieft sich mit jeder
Release. Bei uns hieß das auch: wir haben einzelne Praktiken bewußt
weggelassen - nicht einfach im Laufe der Zeit fallengelassen.

Bei unserem Projekt haben alle Beteiligten die Zeit sehr intensiv
empfunden. Die XPler hatten viel Spaß an der Arbeit - und mindestens
ebenso viel Spaß am Erfolg.



Zum Schluß noch ein paar (wenige) Worte zum V-Modell:

So unverträglich sind die beiden nicht. Natürlich haben wir in
unserem XP-Projekt keine explizite Dokumentation, dabei wimmelt es im
V-Modell nur so von Produkten. Aber wenn man die Gedanken nimmt, die
(vermutlich) hinter dem V-Modell stehen, dann lassen sich
Ähnlichkeiten finden.

Beispiele:
o Storycards sind nichts anderes als SE1/SE2, nur in ungewohnter Form
(Karteikarten). Sie erfüllen aber viele Kriterien, die an
Requirements gestellt werden.
o Die Verfeinerung der Storys in Arbeitspakete entspricht SE3 bis
SE5.
o Das paarweise Programmieren vereint die Rollen des Implementierers
und des Qualitätssicherers auf zwei Personen im ständigen Wechsel -
aber die Rollen sind klar erkennbar.
o Automatisiertes Testen sowie die Reihenfolge "Erst der Test, dann
die Implementierung des Quellcodes" sind im V-Modell möglich; in
unseren V-Modell-Projekten wird beides immer häufiger gefordert und
manchmal auch umgesetzt.

Entscheidende Faktoren sind die Sich-ständig-ändernden-Anforderungen
und die Größe der Projekte. Wenn meine SE1/SE2 sehr gut ist und
relativ stabil bleibt, dann ist das V-Modell m.M.n. besser geeignet.
Wenn ich große Projekte habe (mehr als 15 Entwickler oder sehr lange
Laufzeit), ebenso. Bei kleinen Projekten, die schnelle Ergebnisse
benötigen und die extrem flexibel auf Änderungen reagieren müssen,
wäre XP mein Favorit.


Vetragen sich XP und das V-Modell? Müssen sie sich überhaupt
vertragen? Ich sehe beide als Vorgehensmodelle für unterschiedliche
Zwecke. Wenn es mir nur auf das Ergebnis ankommt, sprich: auf
funktionierenden Code, dann brauche ich vieles vom V-Modell nicht.
Wenn ich aber zusätzlich Wartbarkeit, Sicherheit, Nachvollziehbarkeit
haben möchte, dann würde ich XP nicht vertrauen.

Für beide gilt: das Niederschreiben des Prozesses hilft genauso wenig
wie das sture Befolgen aller Regelungen. Sowohl XP als auch V-Modell
funktionieren nur, wenn die Beteiligten den Prozeß verstanden haben
und ihn bewußt anwenden. Das ist für mich der entscheidende Punkt -
und nicht die Frage, welcher der Prozesse besser geeignet ist.


So, jetzt ist Schluß, mein Abendessen wartet...

Gute Nacht wünscht

Michael Erskine
Dipl.-Inform., München
--
NVLLA DIES SINE LINEA     J.Neudoerffer 1538
Michael Erskine,    E-Mail: erskine@fbmev.de
WWW: http://homepages.muenchen.org/bm836197/

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 07.May.2004 by C. Freericks