mail 0658

Hi!

Ich hätte ein paar Fragen / Anmerkungen zu den u.a. best practises (Beitrag
657 von M. Gnatz):

- Pair Programming: kann man es sich in einem wirtschaftlich denkenden
Betrieb wirklich leisten, alle Implementierungsaufwände einfach kurzerhand
mit 2 zu multiplizieren? Ok, die Qualität wird sicher besser, aber das ist
bei einer Verdoppelung der Kosten ja wohl auch zu erwarten! Ist das nicht
eher für die Entwicklung von Systemen interessant, bei denen Fehler
"tödlich" sind, wie z.B. Weltraumprojekte, Flugzeugbau, Militär, etc...?

- Common Code Ownership: natürlich ist es mehr als nur toll, wenn jedes
Teammitglied jede Zeile Code kennt - aber ist das bei "ordentlichen"
Projekten auch machbar? Denken wir an Ungetüme a'la SAP oder Win XP ... an
10, 20, 50 100 Entwickler, die an einem System arbeiten: da ist Arbeits-
oder vielmehr "Wissensteilung" einfach ein notwendiges Übel, oder?

- Automatisierte Tests: Seit Jahren hören wir davon und seit Jahren kämpfen
die Tool mit dem Problem der Implementierung und Wartung der Testszenarien,
das sich einfach als enorm aufwändig und daher als nicht effizient
herausgestellt hat! Oder sollte es da neue Entwicklungen geben, die ich
einfach verschlafen (oder "verarbeitet") habe?

Bitte nehmen Sie diese Aussagen nicht als rhetorische Fragen hin, auch wenn
sie manchmal etwas pointiert formuliert wurden - ich bin wirklich daran
interessiert, ihre Meinung zu diesen Techniken zu erfahren! Letztendlich
diskutiert ja die halbe IT-Welt über agile Methoden, also muss ja mehr dran
sein, als man mit einer 3/4 Seite abhandeln kann ...

Grüße
Manfred Widmann

Dipl.-Ing. Manfred Widmann
Brief: Billrothstr. 81, A-4600 Wels
Tel.:  07242.54116
EMail: mpunktw@gmx.net
Home:  http://www.wima.at
       http://www.myhtl.org
Bitte verwenden Sie PGP für vertrauliche Mails!
-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet: Mittwoch, 05. 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 07.May.2004 by C. Freericks