Wenn neue Organisationsstrukturen, Prozesse oder neues Vorgehen vorgestellt wird, ist eine häufige Reaktion: “Alter Wein in neuen Schläuchen!”, “Das hatten wir eh schon alles!”, “Für mich ändert sich daraus nichts Wesentliches!”. Das dürfte eine grundlegend menschliche Reaktion sein und ich reagiere oft nicht anders. Bei Methoden agiler Softwareentwicklung ist dieses auch oft zu beobachten, sei es bei Continuous Integration, Test Driven Development oder Anforderungen mit User Stories.
Sehen wir uns mal an, wie wir ein agiles Projekt mit User Stories starten:
- Als Entwickler möchte ich eine lokale Entwicklungsumgebung mit IDE und eine Continuous Integration Pipeline, damit ich die Applikation entwickeln kann.
- Als Tester möchte ich zwei Integrationstestumgebungen, eine User Acceptence-Test Umgebung, zwei Schulungsumgebungsumgebungen, eine Systemtestumgebung und eine Lasttestumgebung, damit ich Qualitätssicherungsmaßnahmen durchführen kann.
- Als Architekt und Entwickler möchte ich eine (Datenbankhersteller deiner Wahl)-Datenbank und die Tabellen für die Applikation zur Verfügung haben, damit ich die benötigten Daten speichern kann.
Zur selben Zeit an der amerikanischen Westküste: Von einem schrecklichen Albtraum geplagt, wird Kent Beck aus dem Schlaf gerissen.
Kent Beck ist neben Ward Cunningham und Ron Jeffries Erfinder von Extreme Programming, im Zuge dessen auch Test Driven Development (TDD) und User Stories entwickelt wurden. Wer TDD praktiziert, sei es auch nur hin und wieder in einem Coding Dojo, der hat wahrscheinlich schon einmal das Staunen erlebt, dass mit TDD plötzlich das Problem gelöst wurde, ohne dass man genau weiß warum. Dass die Lösung einfacher ist, als man zuvor für möglich gehalten hat und dass sie wie von alleine entstanden ist. Die Innovation bei TDD liegt eben nicht darin, dass für jeden produktiven Code ein Test geschrieben wird, sondern, dass die Lösung aus den Tests heraus entwickelt wird. Der Entwicklungsprozess wird von den Tests getrieben. Das ist fundamental anders als der Analyse – Design – Implementierung Prozess, bei dem die Lösung zuerst im Kopf entworfen wird und dann “nur” noch niedergeschrieben wird.
Mit User Stories soll nun dieses TDD Erlebnis auf das Anforderungsmanagement ausgeweitet werden. Der Nutzer des zukünftigen Produkts erzählt seine Geschichte, seine Vision, was das Produkt leisten soll. Diese Geschichten treiben die Entwicklung und im besten Fall entsteht ein Produkt mit einem Innovationsgrad, den sich vorher niemand vorstellen konnte.
Das Gegenteil dessen, was die Erfinder von User Stories erreichen wollten, wird durch die oben skizzierten Anforderungen repräsentiert. “Als Architekt und Entwickler möchte ich eine (relationale) Datenbank und die Tabellen für die Applikation zur Verfügung haben.” Dass es sich beim Architekten und Entwickler nicht um Nutzer des zukünftigen Produktes handelt, mag ja noch durchgehen, aber dass einem Entwickler unterstellt wird, dass er in einer objektorientierten Programmiersprache mit einer relationalen Datenbank arbeiten will, ist sagen wir einmal mutig. Es gibt gute Gründe Objekt-Relationales Mapping zu machen, aber richtig Spass macht das nicht. Und der Architekt soll sich in den ersten Phasen des Projekts auf eine Datenbank festlegen wollen? Hier kommt einem der großartige Uncle Bob mit der Aussage in den Sinn: “The database is just an IO-Device. The database is a detail!” und “Gute Architektur zeigt sich durch Entscheidungen, die man nicht treffen muss bzw. auf später verschieben kann. Architekten wollen sich daher nicht frühzeitig auf eine Datenbank festlegen. Die obigen Sätze repräsentieren “Big Design Up Front” und keine agile Methodik.
Was manchmal von außen wie eine User Story aussieht, kann das Gegenteil von dem sein, was wir mit User Stories erreichen wollen. Es muss aber auch nicht jeder User Stories nutzen, nicht für jeden ist TDD die ideale Entwicklungsmethode. Vielleicht kennt man das Problem so gut, dass ohnehin im Vorhinein alle Details klar sind. Vielleicht habe ich dasselbe Programm schon früher gemacht und kopiere nur aus vergangenen Projekten. Wie dem auch sei, wir sollen aber nicht “User Story” nennen, was keine User Story ist.
