Praktisches & Grundsätzliches zur Informatik

Erfolgreiche 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 komplere 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 Wartungsprogrammieren, 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 ständig Papier zu schreiben, die — kaum fertiggestellt — schnell an Wert verloren, da sie in ihren Aussagen einfach nicht aktuell zu erhalten waren.

Den Ansatz durchzusetzen haben jene Leute dann in 2001 ein Manifest (das sog. Manifesto for Agile Software Development) herausgegeben und damit viel Gegenliebe gefunden. Plötzlich wollte jeder agil sein in ihrem Sinne — nur leider dachten — und denken bis heute — allzu viele Software- und Methoden-Entwickler, dass sie damit den Stein der Weisen gefunden hätten.

In ihrer Freude übersehen sie völlig,

  • wie einseitig man im Manifest denkt
  • und welch beschränkten Nutzen die dann erdachten Prozessmodelle SCRUM, Kanban, etc. haben.

Der erste Warnschuß, den man diesen Leuten vor den Bug zu setzen hatte, kam von Gartner und den CIOs, die allzu schnell an den neuen Ansatz geglaubt hatten.

Heute aber ist klar: Er war bei weitem zu naiv!

Was wir gelernt haben, ist eigentlich nur, dass ein allzu starres Wasserfallmodell nicht mehr akzeptabel ist, da sich Anfoderungen an die in Auftrag gegebene Software zunehmend schneller ändern — und dass sie sich vor allem auch während der Zeitspanne ändern, die mit einer ersten Abnahme des Pflichtenhefts beginnt, aber erst endet, wenn die Lösung erfolgreich produktiv gesetzt worden ist. Eine wirklich brauchbare Definition agilen Vorgehens muss das berücksichtigen und ist erst 2011 zum ersten Mal publiziert worden.

Sie resultiert in einem Prozess, der