mail 0666

die Diskussion der letzten Wochen hat m. E. gezeigt, dass eine
*Agilisierung des V-Modells* nicht schon durch eine Integration der
elementaren XP-Praktiken (Pair Programming, etc.) i. S. einer
Methodenzuordnung erreicht werden kann - obgleich eine derartige
Zuordnung prinzipiell möglich und von Fall zu Fall wohl auch sinnvoll
ist.

Wie kann ein agilisiertes VM erreicht werden?
Als wesentlich erachte ich immer noch die weichen Faktoren wie
Kommunikation etc. und darüber gab es ja auch breiten Konsens. Wenn das
organsisatorische Umfeld "stimmt", das V-Modell gut an die Belange des
Unternehmens bzw. des Projekts angepasst und implementiert wurde,
vermute ich - ohne es beweisen zu können - dass dieses "gelebte"
V-Modell auch agiler ist.

Diese Punkte betreffen jedoch nicht so sehr das V-Modell "an sich" bzw.
dessen Weiterentwicklung, sondern wie und unter welchen Randbedingungen
es in einer Organisation eingesetzt wird.

Was kann noch getan werden?
Im OO-Spektrum Jan/Feb. 03 stellt Jens Coldewey vor dem Hintergrund
iterativ-inkremneteller Entwicklung wesentliche Grundlagen für die agile
Entwicklung dar: Um überhaupt agil sein zu können, gilt es, die beiden
"gefährlichsten Gegner der Änderbarkeit" unter Kontrolle zu bringen,
diese sind Codekomplexität und die Wahrscheinlichkeit durch Änderungen
bereits existierende Code zu zerstören. Diese Kontrolle erreicht man
durch klassische Techniken wie leistungsfähige Architekturen,
verständliche Programmierung kombiniert mit Refactoring und
automatischem Testen (gutes Bsp. für Integration von XP-Techniken). Ich
möchte noch hinzufügen, dass ein leistungsfähiges Änderungs- und
Konfigurationsmanagement unabdingbar ist.
Durch diese Maßnahmen - unterstützt durch geeignete Tools - kann ein
gehöriges Mass an Agilität erreicht werden.
(Im "Manifesto" findet man übrigens "Humans over tools and processes" -
aber dies ist wohl eher in dem Sinne zu verstehen, dass Prozesse und
Tools nicht um ihrer selbst wegen exzessiv eingesetzt werden - wie Hr.
Linnsen schreibt: XP und agile Methoden sind eine Gegenreaktion auf den
Dokumentationswust, der in den USA bei der Softwareentwicklung für
öffentliche AG anzufertigen ist - und wie jede Gegenreaktion sind sie
eben auch etwas "extrem").

Dazu musste man das V-Modell (als abstraktes Modell, nicht als
"gelebtes") immer noch nicht ändern (außer dass "Refactoring" als
Methode aufgenommen wurde).

Weitere Möglichkeiten (das folgende hat ausgesprochen spekulativen Charakter!)
könnten darin bestehen,dass man bestimmte V-Modell -Blöcke aus dem Masterprozess
"auslagert"und möglichst agil abwickelt ...dies müsste aber im Detail untersucht
werden.Vielleicht kann ein "agiles Szenario" in der Handbuchsammlung beschrieben werden.
Hier liesse sich aber ggf. der Bogen schlagen zu der Frage, wie denn die
ursprüngliche Zielsetzung des VM als Verbesserung der AG-Seite erreicht
werden könne.
Der AG verbindet ja im wesentlichen zwei Interessen mit dem VM:
1) Verfolgung des Projektfortschritts
2) Erhöhung der Erfolgswahrscheinlichkeit durch Vorgabe eines definierten Prozesses

Falls der AG sich unter 2) ein XP-ähnliches Vorgehen wünschen sollte, oder aus anderen
Gründen nicht an Details interessiert ist, könnte eine AG-Sicht auf das V-Modells definiert
werden, die auch der Vertragsgestaltung zugrundeliegt (hier habe ich eine Frage an die
Experten: hat jmd. Erfahrung mit der Vertragsgestaltung iterativ-inkrementeller Projekte?)

Mal sehen, was mit unserem V-Modell noch so alles passiert!

Mit freundlichen Grüßen
Karl Kollischan

Dr. Karl Kollischan
IT-Consultant
PRO DV Software AG
Mobil: 0170 6357210
mailto:karl.kollischan@prodv.de
http://www.prodv.de

-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet am: Freitag, 7. März 2003 16:09
An: Multiple recipients of V-Modell-Mailingliste
Betreff: Re: Extreme Programming und das V-Modell (665)

Sehr geehrte V-Modell-Gemeinde,

als ein Kollege, der an der Erstellung des V-Modell'97 im Bereich
Methodenzuordnung mitgewirkt hat und heute hauptsächlich im Kontext
V-Modell-Beratung tätig ist, möchte ich einige Anmerkungen zu den bisherigen
Mails, speziell Nr 662 (Hr. Strixner), machen:

1) Wie aus den Artikeln deutlich wird, besteht die Möglichkeit Elemente aus XP
auf
>das V-Modell abzubilden. Also müsste es nur noch Methodendefinitionen
>Methodenzuordnung. Dann wäre es möglich V-Modell konform XP zu
>betreiben.
Es erscheint mir sehr gefährlich, XP auf die Stufe von Elementarmethoden zu
stellen (zu reduzieren). Dies wäre wohl technisch "möglich", würde im
Ergebnis wohl kaum den Grundwerten von XP (bzw. der agilen
Software-Entwicklung) entsprechen. Die meisten Beteiligten nehmen von XP nur
die Techniken wahr. Dahinter steht jedoch eine bestimmte Philosophie. Das
erfolgversprechende an XP ist die Philosophie und nicht die Techniken.
(Siehe auch Mail Nr 652 Hr Linsen)

2)
>** FRAGE AN DIE EXPERTEN: Gibt es solche Bestrebungen? XP als
Methodendefinitionen?
Halte ich nicht für den richtigen Weg. Wobei ich zugebe, das einzelne (!!)
Techniken durchaus gewinnbringend integriert werden könnten.
HINWEIS: Laut mehreren XP-Experten wird XP hauptsächlich durch EINE Technik
agil (Zitat Ende):
* Tuning Workshops
Tuning Workshops haben das Ziel, eine kontinuierlich Prozessverbesserung
bzw. Prozessdefinition zu erreichen. Hier wird nach jeder Iteration (max.4
Wochen) eine Feedbackrunde mit allen Projektmitarbeitern durchgeführt und
der Prozess ggf. verändert / definiert. Wohlgemerkt es wird KEINE
Prozessüberprüfung im Sinne von QS 3 durchgeführt, ganz im Gegenteil.

3)
** FRAGE AN DIE EXPERTEN: Steht das V-Modell mittlerweile auf dem
Studienprogramm der angehenden Informatiker in Deutschland? Oder eher
RUP / XP?
Hm, in meinem Beratungsalltag treffe ich viele Kollegen und Kolleginen, die
Software oder Systeme entwickeln. Jeder/jede kann meist mehrere
Programmiersprachen (aus Studium oder berufl. Weiterbildung). Wenige kennen
jedoch Entwicklungsprozesse (egal welchen). Aber ich kann Ihnen meine
Vortrags-Erfahrung hierzu berichten. Da ich regelmäßig auf Konferenzen (z.B.
OOP) / Seminaren zu dem Thema "Entwicklungsprozesse" oder "V-Modell vs. RUP"
vortrage, habe ich festgestellt, das in der Gemeinde der Prozesskenner die
Anzahl der V-Modell-Anwender immer noch um den Faktor 2-3 grösser ist, als
die Anzahl der RUP-Anwender.

4)
>* Fazit aus der Diskussion
>- V-Modell und XP ist möglich
So ohne weiteres nicht (nach meiner Meinung). Ein "agilisiertes" V-Modell
ist jedoch ein interessantes Denkmodell.
Hierzu wäre zuerste zu klären, an welcher Stelle die beiden
grundverschiedenen Philosophien eine Annäherung zulassen.

>- XP ist aber als Methode noch nicht im V-Modell definiert
siehe Punkt 2

>- V-Modell hat durch Unwissenheit ein schlechtes Image, "Behördenstandard"
...leider wahr...

>- V-Modell alleine ist nicht die Lösung für alle Probleme im Projekt
...wird aber gerne als Entschuldigung für Probleme im Projekt angeführt...

>- XP ist nicht für alles die Lösung
...korrekt. Die Fokusierung auf das Ziel (und nicht auf den Weg) würde
jedoch so manchem "Heavy-Weight"-Projekt gut tun.

>- V-Modell Anpassung an neue Herausforderungen scheint notwendig.
Dies geschieht derzeit im Rahmen des V-Modell Weiterentwicklungsprojektes
WEIT (siehe Mail 651).
Mann darf jedoch nicht vergessen, das V-Modell'97 wurde mit Blick auf den
AuftragGEBER (Bund) erstellt.

Im Rahmen von WEIT wurde folgede interssante Frage gestellt:
Ausgangspunkt des V-Modells war, dass die IT-Projekte im militärischen und
behördlichen Umfeld durch den
Auftraggeber nicht mehr kalkullierbar waren, was die benötigte Zeit, die
auftretenden Kosten und die
erreichte Qualität betraf. Vor diesem Hintergrund wollte man dem
Auftraggeber ein Instrument - das
V-Modell - zur Verfügung stellen, mit dem IT-Projekte für den Auftragnehmer
beherrschbarer sind.

Diese sehr grobe Zielsetzung findet man auch in den einleitenden Absätzen,
der meisten Veröffentlichungen
über das V-Modell, die sich mit der Historie des V-Modells beschäftigen.
Betrachtet man nun das V-Modell 92 und 97 so stellt man fest, das im
V-Modell im Wesentlichen die
Auftragnehmer-Seite geregelt wird, nur am Rande die Schnittstelle zum
Auftraggeber und die
Auftraggeber- Seite, fast überhaupt nicht.

Nun stellt sich zu Recht die Frage, ob mit diesem Ansatz die ursprüngliche
Zielsetzung, die Verbesserung
der Auftraggeber-Seite, erreicht werden kann? In letzter Konsequenz würde
das bedeuten, dass man alle
Auftragnehmer internen Themen nicht im V-Modell regeln sollte, somit würde
beispielsweise das Submodul Systemerstellung (SE) in nur sehr
eingeschränktem Umfang im
Regelungsteil des V-Modells auftauchen!

Mit freundlichen Grüssen
Markus Reinhold
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
CoCOO
Competence Centre ObjectOrientation
Michael Haslbeckstr. 7a
D-85640 Putzbrunn
Germany

Tel. +49 89 462 89 930
Fax +49 89 462 89 931
Internet http://www.cocoo.de
email reinhold@cocoo.de
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Links to V-Model

not defined

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