mail 0657

Hallo,

dem Statement von Herrn Kollischan (#649) bzgl. der Anwendbarkeit von XP im
Zusammenhang mit dem V-Modell würde ich mich durchaus anschließen.

Ich bin kein Gegner von XP und glaube, dass man durchaus einige Dinge gut
auch für V-Modell Projekte übernehmen könnte. Ein paar Widersprüche sehe ich
aber doch zum V-Modell:

Zu 1. Planungsspiel:

Das ist wohl nur sehr eingeschränkt möglich - zumindest dann, wenn man es
iterativ jede Woche wieder aufs neue macht (ich glaube, das ist die
Grundidee von XP?). Meistens möchte ja der Auftraggeber eine gewisse
Planungssicherheit haben und einen Kunden, der stets vor Ort ist und
Anforderungen aufs neue priorisiert hat man ja auch höchst selten im
Projekt.

Das V-Modell muss Vertragsgrundlage sein können! Daher favorisiert das
V-Modell ein inkrementelles Vorgehen, bei dem zumindest der Gesamthorizont
der Anforderungen zu Beginn des Projektes abgesteckt werden muss.

Zu 4. Einfaches Design und 6. Refactoring:

Für langlebige Dinge, die gewartet werden müssen, ist ein zu einfaches
Design u.U. zu einfach. Das V-Modell ist ja insbesondere für Software mit
"hohen Wartbarkeitsanforderungen" geeignet - diese Art Software hat man ja
durchaus nicht selten. Den Entwurf einer stabilen Architektur würde ich dem
Prinzip Refactoring vorziehen.

Pair Programming, Common Code Ownership, automatisierte Tests, fortlaufende
Integration, viel Kommunikation und 40 Stunden pro Woche sind alles super
Ideen!

Aber ich glaube, im neuen bzw. fortgeschriebenen V-Modell, das ja
Regelungscharakter hat - also für Aufträge der öffentlichen Hand
Vorschriften macht - haben derartige Best Practices nichts zu suchen...
oder?

Viele Grüße
 Michael Gnatz


PS: Ich bin im V-Modell Fortschreibungsprojekt tätig und muss mir auch
Gedanken zu den agilen Methoden machen...


Michael Gnatz
Institut für Informatik
Technische Universität München
Raum 00.11.053, Boltzmannstr. 3, 85748 Garching

Tel. +49 (89) 2 89-1 73 88
Fax. +49 (89) 2 89-1 73 07

mailto:michael.gnatz@in.tum.de


> -----Ursprüngliche Nachricht-----
> Von: vm-d-l [mailto:vm-d-l@gmx.de]
> Gesendet: Donnerstag, 20. Februar 2003 13:30
> An: Multiple recipients of V-Modell-Mailingliste
> Betreff: Re: Prüf-Grundsatz , XP etc. (649)
>
>
> Hallo,
>
> den Diskussionen vor etwa zwei Wochen bin ich sehr aufmerksam
> gefolgt. Nachdem diese ja nun noch nicht ganz eingeschlafen
> ist, möchte ich etwas zur Frage von Herrn Midderhoff
> anmerken, welche XP-Elemente man auch im V-Modell anwenden könne.
>
> Grunsätzlich alle, würde ich mal behaupten. XP ist ja im
> wesentlichen eine Sammlung von sog. Best Practices, die sich
> bei der Softwareentwicklung bewährt haben. Nur ihre
> Kombination und ihr Zusammenspiel macht XP aus, wenn ich Kent
> Beck richtig verstehe.
>
> XP verwendet Praktiken:
>
> 1. Planungsspiel:  Das VM macht keine Vorgaben, wie das
> Projektmanagement im Detail auszusehen hat - einem
> Planungspiel steht nichts im Wege.
>
> 2. Kurze Releasezyklen: ebenfalls prinzipiell möglich, aber
> eher untypisch. Am ehesten m. E, praktikabel als "interne
> Releases", die nicht jedesmal ausgeliefert werden.
>
> 3. Metapher: m. E. gute Ergänzung zum V-Modell
>
> 4. einfaches Design: sollte auch durch das VM gefördert werden
>
> 5. Testen: XP zielt hier im wesentlichen auf automatisches
> Testen ab (J-Unit etc.), wäre VM zukünftig durchaus als
> Methoden und Werkzeugempfehlung denkbar
>
> 6. Refactoring: siehe 5.
>
> 7. Pair Programming: das VM macht keine Vorgaben, wieviele MA
> vor einem Rechner sitzen sollen.
>
> 8. Gemeinsame Verantwortlichkeit: kein Aussage des VM
>
> 9. fortlaufenende Integration: vgl. 2.
>
> 10. 40 Stunden Woche: kein Aussage des VM
>
> 11. Kunde vor Ort: wenn man denn einen hat...
>
> 12. Programmierstandards: klar!
>
> Kent Beck schreibt, dass diese Praktiken - Testen ausgenommen
> - für sich genommen nicht sonderlich wirksam sind. Das
> Zusammenspiel mache XP aus.
> Ob nun das VM zusammen mit diesen XP-Praktiken auch etwas
> XP-ähnliches ist, kommt sicherlich auf den speziellen Fall an
> - und ob sowas überhaupt gewollt ist.
>
> Neben diesen Praktiken spielen die 4 Werte - Kommunikation,
> Mut, Feedback, Einfachheit - eine wesentliche Rolle bei XP
> (ähnlichen agilen Methoden).
>
> Gute und offene Kommunikation z. B. im Projektteam ergibt
> sich im wesentlichen aus dem organisatorischen Umfeld
> (Unternehmenskultur, Motivation und Zufriedenheit der MA,
> etc...). Eine gute Kommunikation ist sicherlich für jedes
> Projekt hilfreich, egal welches Vorgehensmodell verwendet wird (wenn
> überhaupt eines).
>
> Die Frage, inwieweit die Kommunikation im Projektteam (über
> das Berichtswesen hinausgehend) durch das VM beinflusst wird,
> bzw. beeinflusst werden kann möchte ich hiermit zur
> Diskussion stellen.
>
> Schöne Grüße (bei merkwürdigerweise immer noch herrlichem
> Winterwetter)
>   Karl Kollischan
>
> Dr. Karl Kollischan
> IT-Consultant
> PRO DV Software AG
> Mobil: 0170 6357210
> mailto:karl.kollischan@prodv.de
> http://www.prodv.de

Links to V-Model

not defined

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