Praktisches & Grundsätzliches zur Informatik

Optimaler Agiler Software-Entwicklungs-Prozess, Vorgehensmodell SST

Software-Entwickler müssen über SCRUM hinaus denken

Schon seit Mitte der 60-Jahre macht man sich gezielt Gedanken darüber, wie Software-Entwicklung — und Software Engineering ganz allgemein — denn nun eigentlich betrieben werden müssen, damit man

sprechen kann.

Bis etwa 1995 sind so immer komplexere Definitionen wasserfallartiger Vorgehensmodelle entstanden — bis hin zu einem Punkt, an dem klar wurde, dass dieser Weg ausgereizt war und man damit in Zukunft viel zu schwerfällig werden würde.

Die Revolution wurde angestoßen durch ein Team von Wartungsprogrammierern, die bei General Motors (USA) ein riesiges, schon lange produktives Softwaresystem zu warten und ständig neuen Anforderun­gen anzupassen hatten.

Eines der Allheilmittel, an das sie zunächst glaubten, war Extreme Programming, speziell Pair-Programming und die Ansicht, dass sich ständig zu unterhalten besser sei als Dokumentation zu schreiben, die — kaum fertiggestellt — schnell an Wert verliert, da sie ständig zu aktualisieren kaum jemand gelingt.

Wege zu finden, Dokumentation so zu gestalten, dass sie leicht aktualisierbar ist, und uns über die SOLL-Funktionalität der Software stets detailliert Auskunft geben kann, wurde gar nicht erst versucht. Schlimmer noch: sie anzustreben hat man für eher unwichtig erklärt ( ein folgenschwerer Irrtum! ).

Den neuen, bis dahin als wenig professionell geltenden Ansatz durchzusetzen, haben jene Leute dann 2001 ein Manifest (das sog. Manifesto for Agile Software Development) herausgegeben und damit viel Staub aufgewirbelt. Plötzlich wollte jeder agil sein in ihrem Sinne. Nur leider dachten — und denken selbst heute noch — allzu viele Software-Entwickler, dass man damit den Stein der Weisen gefunden hätte. Wie er in etwa gedacht ist und heute praktiziert wird, beschreiben [1] und [2] recht gut.

Das Agile Manifest zeugt von beispielloser Naivität


Nur wenige Methodiker (sofern es sie heute noch gibt) wagen, der neuen Praxis zu widersprechen.

In ihrer Freude übersehen die Agilisten aber völlig,

Der erste Warnschuß, den man nicht mehr ignorieren konnte, kam von Gartner und aus den Erfahrungen der CIOs, die allzu schnell an den neuen Ansatz geglaubt hatten. Heute aber ist klar:


Wirklich durchdacht war das Manifest NICHT.

Sein Hauptmerkmal ist ganz beispiellose Naivität !!!


Berechtigt war lediglich die Beobachtung, dass völlig neue Anforderungen an die Geschwindigkeit, mit der es Entwicklungsvorhaben zu realisieren gilt, entstanden waren.

Was die Urheber agilen Gedankenguts uns gebracht haben, ist eigentlich nur die Einsicht, dass am allzu starres Wasser­fallmodell festzuhalten, nun definitiv nicht mehr akzeptabel ist, da sich Anfoderungen an die in Auftrag gegebene Software zunehmend schneller ändern — und zwar ganz massiv nun auch schon während der Zeitspanne, die mit des Auftraggebers erstem OK zum Pflichtenhefts beginnt, aber erst beendet ist, wenn die Lösung erfolgreich produktiv gesetzt wurde. Wer aber wird mit dem neuem System glücklich sein, wenn es Eigenschaften hat, die zwar ursprünglich so gefordert, jetzt aber so nicht mehr erwünscht sind?

Eine wirklich brauchbare Definition agilen Vorgehens muss das berücksichtigen, findet sich hier, hat vor 2011 aber so durchdacht noch gar nicht existiert.

Sie resultiert in einem Prozess, der

  • aus dem klassischen Wasserfallmodell ein  s p i r a l f ö r m i g e s  Vorgehensmodell macht,
  • die Verantwortlichkeiten von Software-Designer (speziell Software-Architekt) einerseits und Codierer andererseits klar gegeneinander abgrenzt
  • sowie sämtliche Designer und Software-Architekten auch für Testentwurf verantwortlich macht (weswegen sie sich — ganz anders als heute noch — auch um Testbarkeit des Systems bemühen werden).

    Dass gerade sie es sind, die am besten wissen, was der Testling zu leisten hat, ist ein zweiter, sehr willkommener Effekt: Er reduziert Testaufwand und macht Prüfungen deutlich effektiver.

Man nennt dieses Modell SST — Specify, Subcontract, Test, denn Programmierer (Codierer) werden nun als Subcontractor der Software-Designer gesehen (der Leute also, welche die Architektur der Lösung zu ent­werfen und die Schnittstellen zwischen all den Komponenten zu spezifizieren haben, die nicht sämtlich von ein und derselben Person codiert werden).

SST macht jene Designer nun auch dafür verantwortlich, dass die so entstehende Dokumentation stets aktuell bleibt. Die faule Ausrede, das sei nicht machbar, da bei weitem zu aufwendig, braucht nicht mehr akzeptiert zu werden, seitdem man gelernt hat, Software top down über sog. Responsibility Cards (= Specification bzw. Collaboration Cards) auf jeder denkbaren Abstraktionsebene zu beschreiben: Solch einfache, naheliegende Modularisierung allen Software Designs macht die Dokumente jederzeit problemlos aktualisierbar. Automatisch nach HTML gebracht und dort gut verlinkt, haben sie nun plötzlich sehr viel größeren Wert als in der von allzu vielen Kollegen immer noch verwendeten (klassischen) Aufsatzform.

Insgesamt kommt man so zu einem durchdachten, im positiven Sinne agilen Software-Entwicklungs-Prozess, der am ehesten Erfolg garantiert.


Folgende Seiten skizzieren, welcher Möglichkeiten und Gefahren man sich bewusst sein sollte:

Wie schon gesagt: Dieser Prozess ist ein echt  a g i l e r , da er ständiges Überdenken und Verfeinern der Anforderungen an die entstehende Lösung explizit erlaubt (natürlich nur im Rahmen eines durchdacht geregelten Change Management Verfahrens).

Einziger Fixpunkt sind folgende 5 Nebenbedingungen, die nicht verhandelbar sein dürfen (da sie am ehesten Erfolg garantieren):


Meine Meinung zu SCRUM:

SCRUM macht nur Sinn für eine Team, welches aus wenigen (maximal 4 oder 5) sehr kompetenten Entwicklern besteht, die sich einen Projektmanager sparen wollen durch kollektives, in eigener Verant­wortung durchgeführtes Projektmanagement. [Sie sollten dann aber einen Sprecher wählen, der das Team den Kunden gegenüber vertritt und die stets notwendige Rolle des Requirements Managers wahrnimmt.]

In jedem anderen Fall ist SCRUM nur dazu da, nicht offensichtlich werden zu lassen, dass der Projekt­manager unfähig ist, seiner Aufgabe alleine gerecht zu werden — er sollte dann durch einen kompeten­teren ersetzt werden.

Lies auch:



stw4277SCRUMADSCRUM . Agile . DesignerNews?

Mehr + B G E + S H A + More