mail 0668

Hallo V-Modellierer,

die Beiträge von Herrn Reinhold (#665), Herrn Kollischan (#666) und Herrn
von Hagen (#667) bestätigten die Einschätzung, dass V-Modell und Agile
Ansätze nicht einfach zu integrieren sind, weil durch unterschiedliche
Leitbilder geprägt. Aus dem V-Modell wird insbesondere kein agiler Ansatz
durch die Integration einiger oder aller XP-Techniken. Aber diese Techniken
sind auch in einem schwergewichtigen Vorgehensmodell verwendbar (s.u.).

XP und die übrigen Agilen Ansätze enthalten viele wertvolle Ideen. Wertvolle
Techniken sind für mich u.a. Test-first, inkrementelle Vorgehensweise,
permanente Integration und die Anforderungsdefinition im Dialog. Aber
dadurch ensteht keine agile Vorgehensweise.

Durch Test-first wird eine frühe Prüfung der Entwicklungsergebnisse
erzwungen.
Für uns (hier spreche ich für unser Haus) gehört zwingend dazu, dass
Anforderungen und Abnahmekriterien immer zusammen erfasst werden. Ohne
Abnahmekriterien keine Anforderung. Die Funktionalität einzelner Module
(Methoden, Klassen, Kollaborationen) prüfen wir durch Komponententests.
Dadurch reduziert sich der Aufwand in der Systemtestphase erheblich. Dort
testet man dann eigentlich die Zusammenarbeit der einzelnen Module und die
Oberfläche. Wem dort der Aufwand aus dem Ruder läuft, sollte sich auf das
Prüfen der Funktionalität beschränken und die Mensch-Maschine-Schnittstelle
außen vor lassen. Die ändert sich sowieso bis zu Auslieferung häufig.
Effekt: Der Testberg flacht ab.

Durch eine inkrementelle Vorgehensweise mit einer permanenten (=sehr häufig
und deshalb in kleinen Schritten) Integration gewinnt man früh ausführbare
(und auslieferbare) Ergebnisse. Man erzielt dadurch insbesondere zwei
Effekte: 1. Die häufig scheiternde Big-bang-Integration wird vermieden. 2.
Der Kunde sieht viel schneller, ob seine Vorstellungen wunschgemäß umgesetzt
wurden. Eine noch so präzise (und damit häufig ausufernde und extrem teure
Anforderungsanalyse) ist nicht so gut wie lauffähige Software. Ich halte die
Dokumentation der Anforderungen für extrem wichtig. Aber der Lackmustest ist
und bleibt das lauffähige System. Gerade bei großen Projekten entsteht ein
hohes Abbruchrisiko durch den Umstand, dass zu lange gebraucht wird, um
irgendetwas Lauffähiges zu erstellen. Je schneller das geschieht, desto
beruhigter ist der Kunde/Auftraggeber/das Management.

Wir halten die Anforderungsdefinition zusammen mit den Stakeholdern für
wichtig und notwendig, weil nach unserer Ansicht nur der Kunde *seine*
Fachlichkeit kennt (...hoffentlich...). Unsere Fachlichkeit (=Expertise) ist
die Softwareerstellung - das Fachwissen haben die Stakeholder. Erst im
Dialog können die vielen Unklarheiten beseitigt werden. Nachteil des
Verfahrens: Hohe Anforderungen an die zeitliche Verfügbarkeit und das
Fachwissen der Stakeholder. Das kann durchaus zu einem großen Problem
werden.

Wie eingangs gesagt: Das ist dadurch noch kein agiles Vorgehen. Traurig ist
auch, dass die Agilen Ansätze für sich reklamieren, den Menschen wieder in
den Mittelpunkt gerückt zu haben. Da scheint man es in der Vergangenheit
etwas mit der Fabrik- und Fertigungsmetapher übertrieben zu haben.

Zum Thema "leichtgewichtig" möchte ich einmal pointiert fragen: Sind die
leichtgewichtigen Ansätze deshalb so leicht, weil sich sich nicht weiter mit
den Problemen des KM, QS und PM auseinandersetzen? Bei der Lektüre vieler
Veröffentlichungen habe ich durchaus diesen Eindruck gewonnen. Zumindest für
den Teilbereich PM glaube ich sagen zu können: von etablierten Techniken des
PM relativ geringe Spuren.

Was wird (bezogen auf das V-Modell) aus den Teilmodellen PM, QS und KM?
Wäre (vor dem Hintergrund der Entstehungsgeschichte des V-Modells) z.B. ein
Auftraggeber der öffentlichen Hand damit einverstanden?

Aber vielleicht sollte man sich mit folgendem Aspekt beschäftigen:
Wenn die agilen Ansätze eine Reaktion auf schwergewichtige Vorgehensmodelle
sind, scheint dort irgendwo ein Problem vorzuliegen, selbst wenn es nur ein
vermeintliches ist. Mögliche Ursachen könnten sein (eine unvollständige
Liste):
- Im Prozeß wird viel zu spät begonnen, lauffähige Software zu erstellen.
Man gleicht das durch Dokumente aus, die die nicht vorhandene Software
beschreiben.
- Der Prozeß wird nicht richtig angewendet. Man führt einen Prozeß aus, ohne
ihn wirklich zu verstehen. Eigentlich wird nur einem Formalismus genüge
getan. Dass dadurch Motivationsprobleme entstehen und die Dokumente ihren
eigentlichen Zweck nicht erfüllen, ist auf der Hand. Kurz: möglicherweise
eher ein Ausbildungsproblem.
- Das Management/der Auftraggeber/der Projektleiter will sich absichern.
Viele Dokumente vermitteln (Schein-)Präzision.
- Es werden sinnlose Dokumente produziert, weil sie durch einen Prozeß
gefordert werden.
- Zu geringer Aufwand in der Planungsphase und zu geringe Bereitschaft,
Planabweichungen durch regelmäßige Planrevisionen zu integrieren, wenn die
Abweichung durch Steuerungsmaßnahmen nicht kompensiert werden kann. Wem kann
man es verdenken, wenn er von Planungen und Vorgehensmodellen nichts hält,
wenn diese keinen Zusammenhang mit der Realität besitzen?
- Der Prozeß ist einfach falsch. Diese Möglichkeit *muß* man seriöserweise
im Auge behalten.
- Die Idee / das Leitbild / das Credo des Prozesses ist nicht klar. Wenn ein
Vorgehensmodell die Umsetzung eines solchen Leitbildes ist, wie soll man ihn
"verstehen", ohne das Leitbild zu kennen? Gerade beim V-Modell haben hier
vielleicht viele ein Problem.

Ich freue mich auf einer weiterhin fruchtbare Diskussion und wünsche ein
schönes Wochenende,

Oliver Linssen

____________________________________________
Oliver Linssen
Geschäftsführer LIANTIS GmbH
Mobil: +49 (0) 163/2469006
http://www.liantis.com

Free your work. Liantis.

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 16.Nov.2006 by C. Freericks