mail 0652

Hallo,

auf die Postings #648 - #650 möchte ich eingehen. Dabei möchte ich betonen,
dass ich kein Apologet der agilen Methoden (a.M.) bin. Vieles ist nur alter
Wein in neuen Schläuchen.

Beginnen wir mit ihrer Idee.
Das Credo der agilen Ansätze (niedergelegt durch das Manifest der agilen
Softwareentwicklung) lässt sich in etwa so zusammenfassen:
- die Zusammenarbeit zwischen Menschen ist wichtiger als definierte Prozesse
und komplexe Werkzeuge
- das Ziel der Softwareentwicklung ist ein lauffähiges System, kein Wust von
Papier
- durch Verträge kommt man nicht zum Ziel, nur durch Zusammenarbeit mit dem
Auftraggeber
- statt Pläne zu erstellen, sollte man besser flexibel auf die Veränderungen
reagieren

Dieses Manifest sehe ich als Reaktion auf den Dokumentenwust, der in den
Vereinigten Staaten bei der Softwareentwicklung, insbesondere für die
öffentliche Hand, anzufertigen ist. Hier stellt sich dem (nicht ganz)
unbedarften Betrachter wirklich die Frage, ob Software erstellt oder ein
Berg von Papier erzeugt werden soll.

Das V-Modell und die agilen Methoden befinden sich an zwei entgegengesetzten
Enden des Spektrums der Vorgehensmodelle. Die "Philosophien" beider Ansätze
weichen stark voneinander ab. Das V-Modell würden die Vertreter der agilen
Methoden als dokumentenzentriert, formal/starr und "schwergewichtig"
bezeichnen.

Ohne Zweifel lassen sich die zur Umsetzung dieses Credos angewandten
Techniken auch in das V-Modell "irgendwie" integrieren. (Aufzählung
unvollständig: kurze Releases, Test first, User stories, fortlaufende
Integration, ständiges Refactoring, gemeinsame Verantwortung und Eigentum,
Pair programming, Reviews, Design für heute, Anforderungsdefinition im
Dialog) Aber diese Techniken sind nicht neu, sondern schon länger bekannt
und wirklich gut. Vieles davon wird mit Erfolg verwendet - auch ohne die
Plakette "AGIL".

Die grundlegende Idee beider Vorgehensweisen weicht aber doch zu stark
voneinander ab, um wirklich kompatibel zu sein. V-Modell und agile Ansätze
gehen von unterschiedlichen Prämissen aus. Die a.M. sind stark von den Ideen
selbstregulierender und selbstorganisierender Systeme beeinflusst, deshalb
hat das Management nur eine Moderatorfunktion. Die Zukunft ist von starker
Unsicherheit geprägt, wodurch eine Planung prinzipiell nur geringen Wert
hat. Entwickler sind selbstverantwortlich und wollen möglichst gute
Ergebnisse abliefern, deshalb ist ein aufwändiges QM nicht notwendig.
Dokumente können die Software nicht ersetzen, deshalb sollte man so schnell
wie möglich "etwas zum Laufen bringen". Verträge sind für Juristen, deshalb
sollte man besser "richtig" zusammenarbeiten.
Hier sollte man nicht das V-Modell verbiegen. Oder gilt hier im
übertragenden Sinne: richtige Programmierer programmieren immer in FORTRAN?

Ich stimme völlig mit Frau Gehrecke (#650) und Herrn Dr. Kollischan (#649)
überein, die auf die weichen Faktoren Kommunikation, Motivation, Klima
hinweisen. Das sind Themen, die durch die a.M. zu Recht wieder in den Fokus
gerückt wurden. Oft wird vernachlässigt, dass "software engineering is a
peoples business" (P. Coad). Projekte scheitern aus unterschiedlichen
Gründen, aber selten an technologischen Problemen. Viele Vorgehensmodelle
sind auch zu stark an den Prinzipien der Industriebetriebslehre
(Taylorismus, stark arbeitsteilige und funktional orientierte Organisation)
orientiert, die dem Gegenstand Software einfach nicht gerecht wird. Hier
sollte einmal der aktuelle Stand der Organisationslehre rezipiert werden.
Man baut zwar extrem komplexe Systeme, aber weder Maschinen noch
Kathedralen. Es handelt sich also auch um keinen Fertigungsprozess, sondern
um Informationsverarbeitung. Das wird meines Erachtens nicht genug
berücksichtigt.

Die a.M. suggerieren aber, sie hätten für die tatsächlich vorliegenden
Probeme eine - dazu noch einfache - Lösung. Aus industriesoziologischer und
betriebswirtschaftlicher Sicht ist das oft zu einfach, insbesondere zu
idealisiert gesehen.

Zu Herrn Midderhoff (#648) angemerkt: Wir haben mit MDA sehr gute
Erfahrungen gemacht. Die Trennung von plattformunabhängigen (fachlichen)
Modellen (=PIM) und plattformspezifischen (technischen) Modellen (=PSM)
setzen wir mit Erfolg ein. Durch die automatische Transformation des Ersten
in das Zweite erzielen wir hohe Produktivitätsgewinne, weil ein Großteil der
Programmquellen nicht von Hand programmiert werden muss. Die PSM gewinnen an
Übersichtlichkeit und bilden tatsächlich "das Geschäft ab". Das Verfahren
gewinnt insbesondere an Schubkraft, wenn die Entwicklung auf der Basis einer
generierungsfähigen Softwarearchitektur (einem objektorientierten Framework,
einem Application Server o.ä.) beruht. Einen entsprechenden Baukasten zur
Entwicklung von MDA-Werkzeugen stellen wir demnächst als Open Source unter
Source Forge ein.

- Oliver Linssen

____________________________________________
Oliver Linssen
Geschäftsführer LIANTIS GmbH
Mobil: +49 (0) 163/2469006
http://www.liantis.com

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 16.Nov.2006 by C. Freericks