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

• aus dem klassischen Wasserfallmodell ein spiralförmige Vorgehensmodell macht,
• eine klare Trennung der Verantwortlichkeiten von Software-Designer (Software-Architekt) einerseits und Codierer andererseit kennt und
• als wichtigsten Tester des Software-Architekten selbst sieht.
  
  Man nennt dieses Modell deswegen SST — Specify, Subcontract, Test: Programmierer (Codierer) sind hier Subcontractor der Software-Designer (der Leute also, die die Architektur der Lösung definieren sowie die Schnittstellen zwischen all den Komponenten spezifizieren, die durch unterschiedliche Personen codiert werden müssen.
  
  Insgesamt kommt man so zu einem agil (im positiven Sinne) zu lebenden Software-Entwicklungs-Prozess, der mir über folgende Kurzartikel recht brauchbar beschrieben scheint:
  
  
  • Ausgangspunkt
  • Erfahrungswerte
  • Basiswissen
  • Wie dokumentieren?
  • Use Cases
  • Software Design
  • — Standardarchitektur
    — SOA Design
    — Top Down Design
    — Formales ERD Design
    — Formales OO Design
    — Interaction Design
    — Design Patterns
    — Praktisch ist ...
  • Oft vergessen
  • Software Test
  • Prozessreife
  • Um nicht zu scheitern
  • Transparenz + QS
  • Agiles Vorgehen?
  • Nur ok, wenn SST
  • Brainstorming?
  • Peer Value
    
    
  
  
  Dieser Prozess ist maximal agil zu leben. Einziger Fixpunkt sind 5 Nebenbedingungen, die nicht verhandelbar sind (da erst sie Erfolg garantieren):
  
  
  • Codiert darf nur werden, wozu es ein durch Software-Architekten und Designer verantwortete, laufend nach Versionen fortgeschriebene Schnittstellen-Spezifikation gibt.
  • Zu jedem Zeitpunkt muss klar sein, welche dieser Versionen Vorgabe für den oder die Codierer ist.
  • Der für diese Spezifikation Verantwortliche hat auch entsprechendes Test-Design zu verantworten.
  • Auftraggeber und Auftragnehmer bestellen je eine Person, die als Product Owner bzw. Implementation Owner in enger Kooperation miteinander das WAS und das WIE von Abnahmetest 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 liefert.
  • Eigenschaften der Lösung, die zum Zeitpunkt der Bereitstellung zur Abnahme des Systems in jener Testspezifikation nicht berücksichtigt sind, gelten als nicht beauftragt.
    
    
  
  
  
  
  stw4508SCRUMAE — SCRUM . Agile . Entwickler — News?
  
  Mehr + B G E + S H A + More
   
   
  Wissenswertes zu
  Optimaler Agiler Software-Entwicklungs-Prozess