mail 0728

Von:            	"von Hagen, Ulrich (LDS)" 


Hallo,

ich möchte noch einmal einen Aspekt der Diskussion zu "Agilen Methoden und neues
V-Modell" vom März letzten Jahres aufgreifen und komme zurück auf die
Einschätzung von Herrn Gnatz vom 04.03.2003 zum Thema "Planungsspiel", der bei
einem sehr iterativen Planungsspiels Probleme hinsichtlich der
Planungssicherheit sieht (s.u.)

Für mich stellen sich dann allerdings folgende Fragen:

Wie geht man denn dann mit Kunden um, die zwar regelmäßig die Anforderungen
ändern (was sicherlich deren gutes Recht ist, wenn sie hierfür hinreichend
zahlen), die aber andererseits jeweils mehrere Wochen benötigen, bis sie den
Entwicklern eine Rückmeldung (z.B. zu unklaren Anforderungen) geben?
Wie sieht#s denn hier tatsächlich mit der - soviel beschworenen -
Planungssicherheit aus?
Welche Möglichkeiten/Maßnahmen gibt's denn hier, um vorgesehene
Realisierungstermine einzuhalten?

U.v.Hagen - LDS NRW

-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet: Mittwoch, 5. März 2003 19:24
An: Multiple recipients of V-Modell-Mailingliste
Betreff: Agile Methoden im neuen V-Modell (657)


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

Links to V-Model

not defined

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