Der beste Zeitpunkt für eine Entscheidung ist immer genau “jetzt”. Auch wenn es schwer fällt, eingestehen zu müssen, dass die bisherige Entscheidung vielleicht doch nicht die richtige war. So ist das im Leben, aber nicht zwingend in großen Software-Projekten, wenn Millionen an eingesetztem Kapital auf dem Spiel stehen.

Gibt es ein “zu spät” um eine schlechte Entscheidung zu revidieren?

Bzw., was passiert wenn im laufenden Projekt festgestellt wird, dass eine weitreichende Architekturentscheidung, die eingangs getroffen, wurde falsch war?

Wir betrachten hier ein Szenario, bei dem es um eine solche Entscheidung ging.

Szenario (Problem):

Eine Single-Page-Application wurde ohne richtiges Framework umgesetzt.
Stattdessen sollten mit Stencil erstelle WebComponents benutzt werden.
Übliche Framework-Funktionen fehlten (State-Management, Event-Handling, Data-Binding, ...).
Es wurde viel eigener Code geschrieben, um einige dieser Funktionen nachzubilden.
Eine flexible und erweiterbare Komponenten-Library war nicht vorhanden.
Es mussten eigene Frontend-Komponenten gebaut werden, um die WebComponents zu handhaben.
Ein Großteil der User-Stories waren noch offen.
Die Velocity war zu gering, um das Projekt zum geforderten Zeitpunkt abzuschließen.

Aufgabe (Ziel):

Das Projekt soll sowohl monetär, als auch temporal im Budged bleiben. Sprich:

→ Prod-Deployment + Feature Complete in t -4 Monaten

→ Abschluss und Veröffentlichung in t -6 Monaten

Zwei Möglichkeiten:

So weitermachen wie bisher.

Nachimplementierung von Framework-Features.
Anpassung der vorhandenen WebComponents (durch das separate zuständige Team).
Beides sehr zeitaufwändig und fehleranfällig.
Beides muss aufwändig getestet werden.
Weiterhin großer Aufwand beim Umsetzen der restlichen User-Stories mit niedriger Velocity

Einführung eines Frameworks.

Feature-Freeze über 2 Sprints
Einführung des Frameworks, samt Linter, Prettier, Konfiguration, Paketen, Pipeline(s), ...
Nachimplementierung der bereits umgesetzten User-Stories.
Umsetzen der restlichen User-Stories mit stark erhöhter Velocity.
Gefahr mehr als zwei Sprints zu brauchen.

Ansatz (Lösung)

Gegenüberstellung der geschätzten Aufwände beider Ansätze bezüglich der Fertigstellungsfrist
Vorstellungen der Ergebnisse bei ProductOwner, Projektleitung und Kunden.

Da letzterer ein Vetorecht hatte war es entscheidend die Argumentation entsprechend schlüssig und nachvollziehbar aufzubauen.

Besonders interessant an dieser Stelle war der Vergleich der potenziellen mit der bisherigen Velocity:

Status Quo: 2 Entwickler, 12 Sprints
Neu-Implementierung: 6 Entwickler, 2 Sprints

Theoretischer Performance-Gewinn: +100%

Ergebnis

Der Vergleich hatte gezeigt, dass trotz des Feature-Freeze nur durch die Einführung eines Frameworks das Projekt annähernd fristgerecht hätte abgeschlossen werden können. Daher wurde die Einführung beschlossen. In einer weiteren Front-End-Runde wurde sich zudem speziell für Vue.js entschieden.

Die initiale Implementierung, samt Wiederherstellung des Entwicklungsstandes wurde in den dafür veranschlagten 2 Sprints abgeschlossen. Entsprechend hat sich die Velocity wie erhofft ca. verdoppelt und das Projekt konnte mit minimaler Verzögerung abgeschlossen werden.

Zwei Tage vor Projektabschluss ist es sicherlich zu spät um eine ineffiziente Implementierung durch eine effizientere auszutauschen. Hat man aber noch ein paar Sprints offen, ergibt es allemal Sinn eine objektive Gegenüberstellung der Möglichkeiten zu erheben.

PS:

Die Anwendung ging live, der Kunde war happy, das Projekt war ein voller Erfolg - und wird weitergeführt.