Wissensvermittlung in agilen Projekten

< Beitrag >

< Thread >

Agile Projekte und das V-Modell

Avatar von hesconsult

hesconsult

16 Beiträge

25.01.2013 13:13 Permalink
Ich bin nicht so ganz einverstanden mit dem kategorischen entweder
Agilität oder (z.B.) V-Modell

Warum?

Ich glaube, das kommt daher, weil der Begriff V-Modell als identisch
mit dem Wasserfall-Modell verwendet wird. 

Das ist aber so nicht richtig. Auf einen verkürzten Nenner gebracht
bedeutet das V-Modell: Plan-Do-Check - oder auch: 

1. Erfasse die Anforderungen und dazu gehören auch die
Testanforderung (Ein leidges Thema - weil immer wieder die
Testanforderungen häufig erst dann erstellt werden, wenn man sich auf
der rechten Seite des V-Modell befindet. Das ist aber kein Fehler des
V-Modells, sondern des Projekt-Teams).

2. Plane die Umsetzung -> bevor ich z.B. mit dem Coding starte, mache
 ich mir sicherlich schon Vorstellungen darüber, wie ich das umsetzen
will - also das Design.

3. Setze die Anforderungen um (codieren - und in dem Pfad gehören die
low-lewel Test natürlich schon mit rein, ist halt recursive)

4. Verfiziere die Umsetzung gegen die Anforderungen. 

5. Review alle Produkte in allen Phasen (-> z.B. 4 Eyes Prinzip)

6. Dokumentiere jede Phase - ich weiss, eines der größten Probleme
für SW-Entwickler oder Kreative überhaupt...

Das hat auch was mit Diziplin zu tun, siehe weiter unten bezüglich
Agilität und Selbstdiziplin ;)

Aber wenn z.B. die SW Einfluss auf die Produkt-Sicherheit hat,
könnten hier haftungsrechtliche oder gar strafrechliche Belange ein
ausreichender und für alle nachvollziehbarer Grund zur Dokumentation
sein - da spielt dann nämlich auch die TRACEBILITY mit rein - aber
das ist ein Thema für sich.

Auch in einem agilen Entwicklungsmodell werde ich zuerst die
Anforderungen definieren, dann umsetzen und dann testen, ob die
Anforderungen erfüllt werden, halt nur in einer viel feineren
Granularität, die es mir erlaubt, rechtzeitg umzusteuern, wenn des
dem Kunden so nicht gefällt oder wenn ich auf eine ganz falschen
"Dampfer" war. 

Dabei ist es völlig egal, ob ich dem TimeBox-, dem SCRUM-, dem FDD- ,
dem XP- oder sonst einem agilen Modell den Vorzug gebe. 

Denn: ein agiles Vorgehen sollte nie mit chaotischem Vorgehen
verwechselt werden. Von einem agilen Team wirde eine wesentlich
höhere Selbstdisziplin und Verantwortlichkeit für sich selbst,
gegenüber dem Team und dem Kunden erwartet, als man gemeinhin vom
"normalen" Entwickler erwartet.....

Herzliche Grüsse

Heinrich   

Thread-Anzeige einblenden

Anzeige