www.stephanbauer.me

 

Usecase-Analyse++

Als Methode für die Analysephase ist für mich nach wie vor eine Usecase-basierte fachliche Beschreibung - im Sinne der "Effective Usecases" von Alistair Cockburn - eine sehr effiziente Möglichkeit, die Dynamik in den fachlichen Abläufen zu spezifizieren. Ich habe mehrmals erlebt, dass in Projekten, in denen keine Usecases aufgeschrieben wurden, letztlich der Überblick über komplexere Zusammenhänge verlorenging und die Diskussionen über spätere Änderungswünsche deutlich schwieriger wurden.

Das klassische Beispiel schlechthin sind die "Variationen" des sog. "Haupterfolgsszenarios" eines Usecase. Hat man keine Usecases, werden häufig diverse Nebenabläufe übersehen. Dies führt unweigerlich dazu, dass dieser Teil der Anforderungen erst später entdeckt wird und somit weitere Änderungswünsche erst in einer noch späteren Entwicklungsphase nachgeschoben werden müssen. Da der "Produktionstermin" dann schon viel näher gerückt ist, steckt hier das Potential, dass die Entwickler unter dem Zeitdruck ihre eigenen Qualitätsstandards (sofern sie welche haben) über Board werfen um vermeindlich schneller ausliefern zu können. Dies ist insbesondere dann der Fall wenn die Qualitätsstandards nicht fest vom Kunden vorgegeben sondern vom individuellen Know-how des einzelnen Entwicklers abhängen. Entwickler, die die "Clean-Code-Prinzipien" bewusst einsetzen sollten hierfür zwar nicht anfällig sein, aber leider sind die Prinzipien in der von "Uncle Bob" konsolidierten Form (noch?) nicht sehr verbreitet.

Und warum heißt die Überschrift "Usecase-Analyse++"? Zu den Usecases gehören in der Regel auch Entwürfe der Eingabe-Masken sowie punktuell detailliert beschriebene Requirements. Dies passt m.E. auch sehr gut zur agilen Vorgehensweise. Leider scheint es nach wie vor so zu sein, dass gute und erfahrene Usecase-Autoren rar sind. Da ich die Usecase-Analyse in diversen Projekten federführend durchgeführt habe, möchte ich mich bei aller Bescheidenheit durchaus dazuzählen.

Als Freund der agilen Vorgehensweise ist mir zwar bewusst, dass ich Änderungen jederzeit "willkommen heißen" muss. Dieser Umstand ist meiner Meinung nach jedoch kein Freibrief dafür, im Vorfeld der Entwicklung auf eine ausreichend gute Basis der fachlichen Anforderungen zu verzichten. Hier gilt m.E. als grobe Hausnummer der klassische 80:20-Ansatz: D.h.  etwa 80% eines Usecases, der in die Umsetzung gehen soll, sollte im Vorfeld definiert sein. Die letzten 20% - welche häufig die meiste Arbeit machen - können im Rahmen der Umsetzung on-the-fly geklärt werden. Dabei sollten die Usecasebeschreibungen  "uptodate" gehalten werden, da sie ja sonst einen ihrer Haupt-Benefits einbüßen, nämlich dass sie als Diskussionsgrundlage mit dem Fachbereich weiterverwendet werden können. Außerdem muss jeder Usecase im Kontext seiner übergeordneten Usecases bis zum Toplevel-Usecase eingeordnet sein, da die Systematik sonst nicht klappt.

Darüber hinaus stellen Usecases auch eine sehr gute Basis für die Ermittlung der Backlog-Items sowie für die Erstellung von Aufwandsabschätzungen dar. Ich war selbst bereits 2 Mal in der Situation, die Aufwände für ein Festpreisprojekt verbindlich im Vorfeld schätzen zu müssen. Mein eigenes Einkommen hing davon ab und ich musste die Puffer sehr klein halten, da ich den Auftrag sonst nicht bekommen hätte. In so einer Situation überlegt man sich sehr genau, wie man vorgeht. Ich hatte als Grundlage nur Prosa-Fachkonzepte. Ich investierte 5 Manntage, um daraus Usecases zu ermitteln, die ich mit dem Kunden noch vor der Schätzung grob abstimmte. Das war definitiv der Schlüssel zum Erfolg und quasi mein "Lebensretter". Ein Projekt wurde komplett "in-time und "in-budget" fertig. das andere dauerte 3 Wochen länger, da sich eine der eingesetzen, neuen Technologien als komplexer herausstellte als zunächst erwartet.

 

Stephan Bauer, Senior Software-Entwickler, Architekt und Coach (Java / JEE) | +49 176 84647991