Controller Magazin 6/2019

17 Basis aller agilen Frameworks ist das soge- nannte agile Manifest 9 mit den Grundwerten · · Individuen und Interaktionen zählen mehr als Prozesse und Werkzeuge · · Funktionierende Software zählt mehr als umfassende Dokumentation · · Zusammenarbeit mit dem Kunden zählt mehr als Vertragsverhandlungen · · Reagieren auf Veränderungen zählt mehr als das Befolgen eines Plans Gesteuert wird dies über das „Agile Lasten- und Pflichtenheft“: Anforderungen werden im sogenannten Product Backlog durch den Pro- duct Owner verantwortet. Die Einträge, in unse- rem Fall-Beispiel basierend auf der Vision einer frist- und budgetgerechten Software-Imple- mentierung, werden jetzt nicht in Kapitel und fertigen Arbeitsanweisungen hinterlegt, son- dern erst in sogenannten Epic, z. B. vergleich- bar mit den Kapitelüberschriften: · · Stammdaten · · Auftrag · · Lager · · Einkauf · · Rechnungswesen · · Controlling Dies erfolgt in dem, in Abbildung 6 (gem. scr- umguides.org) dargestellten schematischen Product Backlog. Dies ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt benötigt wird. Es ist die einzige Anfor- derungsquelle für Änderungen am Produkt. Der Product Owner ist für das Product Backlog al- legt, mit einer maximalen Länge von 4 Wochen. Das Ergebnis jeden Sprints ist ein „shippable increment“ (in der Vorstellung eines Stapel- laufs: sie lassen ein Schiff ins Wasser: es schwimmt = shippable –0 es schwimmt nicht = not shippable). Bei einem so geforderten „shippable inkrement“ als Ergebnis ist die Wahrscheinlichkeit hoch, dass „Versteckte Fehler“ frühzeitig entdeckt und eliminiert wer- den können. Das teilfertige Produkt muss funkti- onieren, es wird dem Kunden gezeigt, bespro- chen, und es werden Antworten aktiv angefragt und gefordert. Grundlagen agiler Projekte In agilen Projekten der Scrum.org kommen die 3 Säulen von Scrum zur Geltung: 8 · · Inspektion – Wir müssen immer die konkrete Situation untersuchen, · · Adaption – so dass wir unsere nächsten Schritte anpassen können und · · Transparenz – das Inkrement muss voll­ ständig umgesetzt und benutzbar sein schnitt einen Unsicherheitsfaktor von 4 hat. Und so verhält es sich auch in unseren bekann- ten Projekten, z. B. dem „Bau des Stuttgarter Hauptbahnhofs“: · · November 1995: Bahn, Bund, Land und Stadt unterzeichnen eine Rahmenverein­ barung; Projektkosten fünf Milliarden Mark (ca. 2,6 Milliarden Euro). · · ... · · 26.01.2018: Der Aufsichtsrat der Bahn stimmt in Berlin einem größeren Finanz­ rahmen für Stuttgart 21 zu: 8,2 Milliarden und Eröffnungstermin 2025. · · 20.04.2018: Der vereinbarte Kostenrahmen für das gesamte Bahnprojekt Stuttgart-Ulm liegt bei 9,786 Milliarden Euro und wird gemeinsam von den beteiligten Projektpart- nern getragen. „Technical Debt“ in Wasserfall- und agilen Projekten Die Fehlerbehebung ist in einem Wasserfall- Projekt erheblich komplexer als in einem agilen Projekt und kann selbst wieder zu Folgefehlern führen, welche wiederum erst am Projektende auffallen, dies führte z. B. 2018 zu einem Leit- artikel im Kölner Express mit der Überschrift „Rheinbahn-Supergau“, die neuen Stadtbah- nen in Duisburg sind zu breit für U-Bahntunnel. 7 Die sogenannte „Technical Debt“ als „Versteck- ter Fehler“ kann zu einem nicht abschätzbarem Korrekturaufwand führen und auch weit nach Ende der Garantiezeit gewünschte Ergebnisse verfälschen. Je länger ein Projekt läuft, je grö- ßer wird die Unsicherheit über versteckte Feh- ler und deren Auswirkungen auf den Projekt- start und dessen Vorhersagbarkeit. In agilen Projekten wird natürlich auch nicht fehlerfrei gearbeitet, nur, hier werden Fehler wesentlich früher entdeckt, „Große Projekte“ werden, wie in Abbildung 5 dargestellt, in kurze Zyklen zer- Abb. 5: Agile Sprints mit „Working Software“ Abb. 6: Product Backlog Refinements/Verfeinerungen CM November / Dezember 2019