In einem meiner letzten Projekte haben wir ein schaurig-schönes Lehrstück zum Thema „Trennung von Problem- und Lösungsraum“ erleben dürfen. Diese Erfahrung möchte ich gerne mit Euch teilen:
Für die Ansteuerung eines Motors und zweier Bremsen gab es vom Kunden neben ein paar wenigen natürlich-sprachlichen Requirements auch eine Spezifikation in Tabellenform. Dieses Excel-Dokument hatte zu Projektbeginn 8 Tabellenblätter auf denen Statemachines beschrieben waren: States in Spalten, Inputs in Zeilen. Manche dieser Tabellen kamen mit 3×4 Zellen aus, andere umfassten bereits 10×6 Zellen. Viele Randbedingungen waren über Fußnoten zu den einzelnen Zellen beschrieben. So weit, so gut.
Im Laufe des Projekts stellten wir immer wieder Inkonsistenzen und Probleme mit diesen Tabellen fest. Manchmal stellte sich heraus, dass das resultierende Verhalten des Motors nicht den Wünschen des Kunden entsprach. Ein anderes Mal waren nicht alle möglichen Fehlerfälle durch die Tabellen abgebildet.
Der Kunde veränderte und erweiterte sein Tabellendokument aufgrund unserer Rückmeldungen immer weiter und weiter. Es kamen 2 weitere Tabellenblätter hinzu. Die States, die alphabetisch benannt waren, näherten sich rapide dem Buchstaben Z…
Der Kunde war etwas unglücklich, denn ich kam nicht umhin einen Change-Request von einige Zehntausend-Euro für die Mehraufwände zu stellen. Wie konnte es sein, dass sie plötzlich so viel bezahlen sollten, obwohl sie doch gar nichts anderes wollten als zu Projektbeginn? Sie hatten doch sogar Ihr Dokument freundlicherweise für uns angepasst, damit wir es besser implementieren können. Bei uns hingegen türmten sich die Aufwände: Anpassen riesiger Statemachine, Unittests schreiben und pflegen für Switch-Case-Anweisungen mit über 1.000 Zeilen ist kein Vergnügen!
Damit es bei der Umsetzung des Change-Requests nicht zu weiteren Änderungen kommt, sondern wir einen wirklich finalen Stand haben, wollte der Kunde das Tabellen-Dokument noch einmal intern reviewen und freigeben. Als ich nach 3 sehr schönen Urlaubswochen wieder im Büro war, stellte ich überrascht fest, dass sie das Tabellendokument überhaupt nicht überarbeitet hatten. Stattdessen hatten sie eine vollständig neue Spezifikation des gewünschten Verhaltens in einem Word-Dokument mit ein paar Statemachine-Diagrammen erstellt.
Der Schock war zunächst groß! Das schöne Tabellendokument! Unsere Implementierung basierte 1 zu 1 auf diesen Tabellen – inklusive Benennung der States und Events. Jetzt sollte es nur noch diese High-Level-Spezifikation geben?! Sollten wir nun daraus die riesigen Tabellen selbst ableiten?!
Ich begann zu prüfen, ob die High-Level-Spezifikation denn wenigstens zu den bestehenden Tabellen passt. Eine Sisyphusarbeit! Lieber nochmal von der anderen Seite probieren und aus der High-Level-Beschreibung die Tabelle generieren. Und siehe da: eine Tabelle die vorher fast 400 Zellen hatte, schnurrte auf handliche 50 Zellen zusammen! Wie konnte das sein? Hatte ich etwas übersehen? Die Komplexität nicht verstanden? Oder: Warum hatte ich es vorher nicht gesehen?
Es lag an der zauberhaften Trennung von Problem- und Lösungsraum!
Erst jetzt, wo die High-Level-Spezifikation geschrieben war; nachdem das vom Kunden gewünschte Verhalten deutlich – und vor allem frei von Lösungsvorschlägen – dargestellt wurde, war es möglich geworden eine effiziente Lösung für das Problem zu finden. Das Tabellendokument hatte von Anfang an versucht eine Lösung zu beschreiben. Aber bevor die High-Level_Spezifikation existierte, war gar nicht klar, zu welchem Problem diese gehören sollte.
Auch wenn es nun endlich möglich war eine effiziente Lösung für das Problem zu finden: Der Aufwand und die Kosten für den Change-Request sind bei einer beachtlichen Größe geblieben. Denn wir mussten viel rückbauen, verwerfen und überarbeiten. Späte Erkenntnisse sind leider immer teure Erkenntnisse!
Daher schließe ich mit der Empfehlung: Erst das Problem verstehen, dann die Lösung suchen.
Birgit Feld