Love it, leave it or change it: eine Fallstudie

Der beste Zeitpunkt für eine (Um-)Entscheidung ist immer genau “jetzt”. Auch wenn es schwer fällt, sich oder dem Team eingestehen zu müssen, dass der bisherige Weg ein durchaus schlechter war. Bei großen Software-Projekten können da durchaus 7-stellige Beträge 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 genau um eine solche Entscheidung ging.

Szenario (Problem):

  • Eine Single-Page-Application wurde ohne richtiges Framework umgesetzt.
  • Stattdessen sollten nur 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.
  • Das Gros der User-Stories war noch offen.
  • Die Velocity war viel zu gering, um das Projekt auch nur ansatzweise zum geforderten Zeitpunkt abschließen zu können.

Aufgabe (Ziel):

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

Sprich:

→ Prod-Deployment + Feature Complete in 4 Monaten

→ Abschluss und Veröffentlichung in 6 Monaten

Zwei Möglichkeiten:

  1. 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
  2. Vollständige Neuimplementierung unter Verwendung eines etablierten 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.

Wichtig zu erwähnen ist, dass für die Neuimplementierung von vorn herein nur zwei Sprints zur Verfügung standen.

Ansatz (Lösung)

Als ersten haben wir Entwickler einen Schlachtplan ausgearbeitet, diskutiert, vorgestellt und durchgeführt:

  • 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

Rein rechnerischer 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.