"Lastenheft", das klingt nach dem lästigen Dokument, das man früher monatelanger harter Arbeit geschrieben hat. Und dabei hat scheinbar die Agilität gezeigt, dass man das gar nicht braucht. Alle hatten es schon immer geahnt und darum möglichst wenig Aufwand hinein investiert. Am Ende kam ja sowieso alles anders. Eine typische Self-Fullfilling Prophecy. Wenn man schon beim Schreiben glaubt, dass das Lastenheft keiner lesen wird und sich keine Mühe gibt, die Inhalte zu prüfen, dann wird es sich tatsächlich als irrelevant und nutzlos herausstellen, das lieblos gemachte Pseudodokument.
Aber ich glaube an das Lastenheft. Wenn man sorgfältig die Inhalte zusammensucht, konsolidiert und diszipliniert darstellt und qualitätssichert, dann hat man eine verlässliche Grundlage für die weitere Arbeit. Das habe ich schon so erlebt. Natürlich ändern sich Kundenwünsche, die Technik unterstützt dann doch nicht die Umsetzung so wie man sich das vorgestellt hatte, oder irgendetwas war dann doch nicht für den Entwickler verständlich gewesen. Hat der Requirements Engineer sorgfältig gearbeitet, kann es sich dabei jedoch nur um Kleinigkeiten handeln. Die fatalen Überraschungen bleiben aus.
Außer Lastenheften habe ich schon zahlreiche andere Bücher geschrieben, Fachliteratur und Belletristik. Eine Anforderungsspezifikation ist darum für mich nur "just another book I wrote". Übung spielt in jedem Fall eine Rolle. Nur die ersten zehn Bücher sind schwer zu schreiben. Anschließend fließt der Text nur so über die Tasten. Die schmerzhafte Disziplin für das mehrmalige Überarbeiten des eigenen Werks bringt nur der professionelle Autor auf, der weiß, dass und wie jede Formulierung sich noch verbessern lässt und dass kein Text jemals fertig wird. Das Schreiben ist genau darum eine so brutale Kunst, weil man im Gegensatz zum Maler, dem Schauspieler, Tänzer und Musiker sein Werk jederzeit noch ändern kann. Da gibt es keine Ausrede im Stil von "Am Tag der Première hatte ich leider Antibiotika genommen und war darum nicht in Bestform" und in Zeiten von digitalen Dokumenten, E-Books und Print on Demand auch keine Ausrede wie "Als ich den Tippfehler bemerkt habe, war die ganze Auflage schon gedruckt." Das Schreiben ist eine anstrengende Kunst.
Hinzu kommt bei Lastenheften noch ihr politischer, oft umstrittener Inhalt, der schnell veraltet. Das ist eine nicht zu unterschätzende emotionale Belastung für die verantwortliche Autorin.
Die agile Entwicklung scheint einen Ausweg aufzuzeigen: Niemand schreibt mehr alleinverantwortlich ein ganzes Buch. Stattdessen reden alle miteinander, und eine kurze stenographische Notiz auf einer Karteikarte genügt als Erinnerungshilfe.
Das Problem ist nur, dass die entstandene Software ihren Herstellungsprozess widerspiegelt. Wird sie auf Grundlage eines konsistenten Gesamtkonzeptes erstellt, dann fühlt sich auch ihre Benutzung entsprechend flüssig, konsistent und wohldurchdacht an. Die Software ist ein Gesamtkunstwerk, das durch das Lastenheft bereits entworfen und in Gedankenexperimenten aus Benutzersicht simuliert worden war. Die ganze Arbeit, die in das Lastenheft investiert wurde, spiegelt sich in der Software wieder: die Konkretisierung der Systemziele, die Benutzeranalyse, die Usability-Optimierung der Use Cases, die Komplettierung aller Alternativzenarien, die Definition von Styleguides für die Benutzeroberfläche, die Konsolidierung der Begrifflichkeiten in einem Glossar. Dies alles verbessert die- User Experience. Der unbedarfte Benutzer spürt das intuitiv, die Expertin kann direkt mit dem Finger auf die Fehler zeigen, die durch eine ungenügende Spezifikation und eine iterative Entwicklung typischerweise entstehen.
Zahlreiche agil und iterativ entwickelte IT-Systeme zeigen dieselben Schwächen:
- inkonsistente Bezeichnungen für dasselbe
- inkonsistente Benutzerführung (ähnliche Funktionalitäten sind an verschiedenen Stellen unterschiedlich zu bedienen)
- übervolle Benutzeroberflächen, wobei die Inhalte offensichtlich chronologisch in ihrer Implementierungsreihenfolge angeordnet sind, nicht entsprechend den Geschäftsprozessen oder Benutzerbedürfnissen
- unnötige, inzwischen nicht mehr benötigte Felder und Funktionalitäten, die man mal entfernen könnte
- schlechte Benutzerführung durch ein Nutzungsszenario
- zahlreiche Fallen, wo Benutzern leicht Fehler unterlaufen
- Gimmicks, die der Entwickler vermutlich sehr kreativ fand, die aber den Benutzer verwirren
- schlechte Performance
Natürlich findet man das alles auch bei Legacy-Systemen, aber erstens haben sich diese Fehler dort über Jahrzehnte zusammengeläppert und zweitens hätte man sie dort durch gutes Requirements Engineering und gelegentliches Refactoring vermeiden oder beheben können. Agil entwickelte Software wird aber sehr viel schneller zum Legacy-System, weil es nicht nachhaltig geplant wird. Ich denke hier insbesondere an die Prototypen, die ich von Start-ups schon zu sehen bekam, und die gleich von Anfang an Kunden in die Verzweiflung trieben. Schlimmstenfalls funktionierten wichtige Use Cases überhaupt nicht oder nur durch einen komplizierten Workaround, weil es angeblich technisch nicht besser ging. (Zusätzlich zur Anforderungsspezifikation war oft auch das Testen vernachlässigt worden. Der Kunde testet mit Echtdaten, und dann ist oft tatsächlich technisch nicht mehr viel Änderung möglich.)
Dass dies passiert, ist nur zu logisch. Stellen Sie sich vor, jemand schreibt einen Roman im Team. Alle Stakeholder dürfen einzelne Sätze vorschlagen. Diese werden dann priorisiert oder durch Storymapping in eine chronologische Reihenfolge gebracht. Eventuell fallen noch Gedankensprünge auf, und fehlende Sätze werden spontan ergänzt. Natürlich unter Zeitdruck wegen der Timebox. Vielleicht bringt man den Roman auch zunächst als Minimum Viable Product als Kurzgeschichte heraus und erweitert ihn iterativ im Zwei-Wochen-Rhythmus. Das würde wohl kaum einen hochwertigen Roman ergeben, sondern schnell als das entlarvt, was es ist: eine Liste von Einzelsätzen.
Genauso ist die agil entwickelte Software ebenfalls eine Sammlung von Feldern und Funktionalitäten. Aber leider kein Kunstwerk, das sich für den Benutzer "richtig" anfühlt. Die Spezifikation von IT-Systemen ist eine Kunst, die erlernt und jahrelang trainiert werden muss. Das ist kein aussterbendes Handwerk!