Bericht vom Workshop

Autor: Norbert Claudel

Zum insgesamt achten Mal fand das Jahrestreffen der Fachgruppe WI-VM (ehemals 5.11) (Vorgehensmodelle für die betriebliche Anwendungsentwicklung) statt. Das diesjährige Tagungsthema 'leichte Vorgehensmodelle' sollte dazu beitragen, sowohl aktuelle Marktentwicklungen und Tendenzen kritisch zu hinterfragen, als auch zu Kritiken gegenüber der angeblichen Komplexität von Standardmodellen Stellung zu nehmen.

Zu diesem Zweck gab es unterschiedliche Vorträge, die sich allesamt von der pragmatischen und praktischen Seite mit den verschiedenen Sichten auf ein Vorgehensmodell (VM) beschäftigten und dabei verschiedenste Schwerpunktaspekte wie z.B. eXtreme Programming, Open Source, Rational unified process, Ergonomie und Toolunterstützung mit einbezogen.

Dabei ist es augenscheinlich, dass die mitunter schwerfällig anmutenden Vorgehensweisen in der Praxis immer mehr von wirtschaftlicher Vernunft bestimmt werden. Während man durchaus in den letzten Jahren den Eindruck gewinnen konnte, dass die Informatik als Wissenschaftsdisziplin gerne in bestimmten Teilaspekten eine Inselbetrachtung pflegt, halten in der gelebten IT-Welt mittlerweile, quasi durch die Hintertür, Erkenntnisse anderer Wissenschaftszweige Einzug. Themen wie Ergonomie, Mitarbeitermotivation, gruppendynamische Prozesse, Kosten-/Leistungsrechnung basieren dabei auf Erkenntnissen aus Psychologie, Soziologie und Betriebswirtschaft. Betrachtet man nun dabei die bewußt oder unbewußt in verschiedenen praktizierten Vorgehensmodellen angewandten Techniken und Methoden aus o.g Disziplinen, tritt deutlich zutage, dass dabei fast immer ein Qualitätszuwachs erreicht wird, und das auch noch basierend auf empirisch abgesicherten Theorien.

So kann zum Beispiel der Ansatz des eXtreme Programming, betrachtet durch die Brille der betriebswirtschaftlichen Organisationstheorie derart bewertet werden, dass dort besonders die Aspekte der partizipativen Mitarbeiterführung, der Grad der Eigenbestimmung und daraus resultierend die Stärke der Motivation hervorstechen. Dagegen finden in diesen Ansätzen klassische Punkte wie Mitarbeiterauswahl, Fortbildung und Führung kaum Berücksichtigung. Sie sind aber durchaus kritische Erfolgsfaktoren, nur werden sie implizit als vorhanden vorausgesetzt und in den Modellbeschreibungen quasi nur am Rande erwähnt.

Das Gleiche gilt für die Open-Source Entwicklungen, die ja explizit gar kein Vorgehensmodell im engeren Sinne haben, sondern nur auf der Basis eines gemeinsamen Zieles und der Einhaltung allgemeiner Spielregeln zum Erfolg kommen. Hier bleibt zum Beispiel die Frage nach der Effizienz einer solchen Entwicklung weitgehend offen, erste Untersuchungen scheinen jedoch zu ergeben, dass der Gesamtaufwand dabei der einer klassischen Entwicklung ähnlich ist. Es wird also der eventuelle Mangel an zentraler Projektkoordination durch erhöhte Eigenmotivation und vermeintlich höhere Qualifikation der Beteiligten kompensiert.

Nicht zuletzt auch aus der OO-Entwicklung kommen schon seit längerem Ansätze zu einer iterativen Entwicklung mit relativ kleinen Inkrementen. So ein dynamisch flexibles Vorgehen steht nicht unbedingt im Widerspruch zu klassischen Vorgehensmodellen, zeigt aber in der konkreten Durchführung einige neue Aspekte. Ein Ansatz ist dabei die These, dass eine vollständige, aktuelle und korrekte Spezifikation quasi nie existiert, da sich die fachliche und technische Umgebung eines Projektes permanent im Wandel befindet. Damit befindet es sich aber von Anfang an in einem Wartungszyklus. Der Schluß daraus ist, möglichst schnell Entwicklungsergebnisse zu erzeugen, die dann auch marktnah implementiert werden. Dazu muß die Entwicklung auf einer Architektur basieren , die den Aspekt der schnellen und effizienten Änderbarkeit im Vordergrund trägt. Das Endprodukt wächst somit quasi mit der Spezifikation. Aber auch hierfür gibt es wiederum eine Reihe kritischer Erfolgsfaktoren. Erfahrene Entwickler die entsprechende Architekturen aufsetzen können, Patterns und Standards kennen, sowie die notwendigen Werkzeuge beherrschen, sind zwingend notwendig. Ebenso sind die Ansprüche an die Kommunikationsfähigkeit höher, das Team muß zudem eine besondere Homogenität aufweisen. Das obere Management muß Vertrauen in diese im Detail eher anarchisch anmutende Projektführung haben und daran glauben, dass trotz des Risikos eines fehlerhaften oder unvollständigen Inkrements das Endziel dennoch erreicht wird. Die Planungssicherheit ist hierbei sicher reduziert. Das Team sollte weiterhin die Möglichkeit haben, über das konkrete Vorgehen/Tailoring selbst zu bestimmen und damit Aktivitäten und Produkte festzulegen. Bei kurzen Entwicklungszyklen sind natürlich die Verwendung moderner Tools mit umfangreichen Test- & Debugginghilfen und integriertem Konfigurationsmanagement erforderlich. Automatisierte Testabläufe sind wegen des permanenten Zeitdrucks unabdingbar, ebenso wie die starke Einbindung des Nutzers in den gesamten Entwicklungsprozeß. Es kann eben nicht mal eine Woche auf die Spezifikation gewartet werden. Der Entwicklungszyklus ist eng geschlossen.

In der Endbetrachtung zeigen sich somit deutlich die Unterschiede sogenannter moderner leichter Vorgehensweisen zu den klassischen Vorgehensmodellen. Sie sind eigentlich gar keine echte Alternative, sie betonen lediglich Teilaspekte des Ganzen, schaffen also andere Schwerpunkte, die allerdings viele kritische Erfolgsfaktoren beinhalten. Nichtsdestotrotz sollte man aus den neuen Ansätzen lernen. Ein flexibles Umgehen mit einem mächtigen VM ist angebrachter denn je. Die Fokussierung auf Fragen der Ökonomität, Ergonomie und Motivation ist in der Arbeitswissenschaft nicht neu, bisher aber explizit zu selten im Zusammenhang mit der Anwendung von Vorgehensmodellen betrachtet worden. Ähnlich wie vor einigen Jahren noch Methoden oder SE-Tools, sind Vorgehensmodellen oftmals als alleiniger Heilsbringer angepriesen worden, ohne zu erwähnen, dass die Umsetzung von Menschen getrieben wird - und die funktionieren eben nicht wie Maschinen - auch der angeblich rationale Softwareentwickler nicht.

Gemäß den Rückmeldungen der Teilnehmer waren die Vorträge mit dem besten Inhalt von Hrn. Reinhold, Fr. Wiemers und Hrn. Blum / Hrn. Gambert. Die besten Präsentationen boten Fr. Wiemers, Hr. Reinhold und Hr. Coldewey. Die Bewertungen für den Workshop bezüglich Programm, Organisation, Räumlichkeiten und dem Gesamteindruck ergaben eine Durchschnittsnote von 1,6.

Die nächste Sitzung der Fachgruppe wird im kommenden Jahr im März wieder in Glashütten stattfinden. Ein neuer Arbeitskreis zu Software-Qualitätsmanagement ist geplant. Als erstes soll dieser AK gemeinsam mit einem AK der FG 2.1.7 (Test, Analyse und Verifikation von Software) das Thema Qualifikation von QM-Personal angehen.

Norbert Claudel
Gorbit mbH
E-Mail: norbert.claudel(a)t-online.de

Letzte Änderung: 2010-08-17 durch Dr. Oliver Linssen