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

von wirklich p r o f e s s i o n e l l e m Vorgehen
und vor allem auch von akzeptabler Q u a l i t ä t der Projektergebnisse

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 Anforderungen 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,

wie einseitig man im Manifest denkt
und welch beschränkten Nutzen die speziell dafür erdachten Prozessmodelle SCRUM, Kanban, etc. haben.

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 Wasserfallmodell 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 entwerfen 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):

Codierer implementieren nur Bausteine, zu denen es eine durch Software-Architekten oder ihnen verantwortliche Designer erstellte und verantwortete Architektur-Spezifikation gibt. Sie hat mindestens die Aufrufschnittstelle des Bausteins — Datentypen, Funktionen, deren Parameter sowie deren Zweck und Gebrauch — komplett zu definieren.
Zu jedem Zeitpunkt muss klar sein, welche Versionen dieser Vorgabe für den oder die Codierer die momentan verbindliche ist.
Der für diese Spezifikation Verantwortliche hat auch entsprechendes Test-Design zu verantworten.
Auftraggeber und Auftragnehmer bestellen je eine Person, die in den Rollen Product Owner bzw. Implementation Owner in enger Kooperation miteinander das WAS und das WIE von Acceptance Test spezifizieren und dafür sorgen, dass erste Versionen dieser Spezifikation so früh wie nur irgend möglich Input für System-Architekten und Designer liefern.
Eigenschaften der Lösung, die zu Beginn der Abnahmefrist in jener Acceptance Test Specification nicht berücksichtigt waren, gelten als nicht beauftragt, so dass ihr Fehlen kein Grund sein kann, die erbetene Abnahme zu verhindern. Diese Regel vorweg zu vereinbaren kann bei Festpreis-Projekten dem Auftragnehmer viel Geld und Ärger ersparen. Sie wird auf jeden Fall zur Folge haben, dass die Auftraggeber sich frühest möglich klar darüber äußern, welche Eigenschaften der Lösung sie für unverzichtbar erachten.

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 Verantwortung 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 Projektmanager unfähig ist, seiner Aufgabe alleine gerecht zu werden — er sollte dann durch einen kompetenteren ersetzt werden.

Lies auch:

SCRUM ohne einen Systemarchitekten steuert ins Verderben: Nur er kann garantieren, dass wirklich entsteht, was der Product Owner sich wünscht.
Requirements Management and all the Communication with Stakeholders are to be Responsibilities of the Product Owner.
SCRUM kann ein kleines Team koordinieren — niemals aber ein nennenswertes Projekt.

stw4277SCRUMAD — SCRUM . Agile . Designer — News?

Mehr + B G E + S H A + More

Wissenswertes zu
Vorgehensmodell SST, Optimaler Agiler Software-Entwicklungs-Prozess