Ausgangspunkt der “Agil entwickeln” Beiträge ist ein Projekt namens SVG Editor. Diesem soll eine neue Interaktion, zum Export einer Grafik als PDF mit Wasserzeichen, hinzugefügt werden.
Im ersten Artikel habe ich gezeigt, wie User Stories vertikal zu technischen Anforderungen zerlegt werden.
Das Ergebnis war eine Interaktion mit den drei folgenden Features:
- Die Vektorgrafik soll in ein PDF konvertiert werden.
- Ein Wasserzeichen soll hinzugefügt werden.
- Das PDF soll als Datei gespeichert werden.
Der Schwerpunkt dieses Beitrags befasst sich mit der agilen Umsetzung dieser Anforderungen. Das Ziel ist möglichst viele ausführbare Durchstiche (Inkremente) zu generieren, zu denen regelmäßiges Feedback gegeben werden kann.
Anforderungen unters Messer legen
Zur Verdeutlichung der Vorgehensweise nehme ich wieder die Aspekte meiner bestehenden Anwendung zur Hand. Ich könnte jetzt einzelne Features aus der gesamten Interaktion herausnehmen mit dem Ziel, sie nacheinander umzusetzen. Beginnen könnte ich mit der Konvertierung eines SVG Objekts in ein PDF. Das Feature fällt in den Aspekt Domain.
Ich investiere etwa eine Woche Arbeit in die Lösung für dieses Feature für die Implementation inklusive Tests. Am Ende der Woche habe ich eine Klasse PdfConverter angelegt, die aus einem SVG ein PDF konvertieren kann. Die Anforderung ist umgesetzt, die Tests sind alle grün. Wunderbar. Aber – ich habe kein Ergebnis, das ich präsentieren kann, um ein Feedback zu bekommen. Ein Product Owner, oder jemand anders, den das Ergebnis interessiert, könnte dieses Feature nicht auslösen. Ich habe die Anforderungen horizontal geschnitten.
Ich habe mich auf einen Aspekt konzentriert und die übrigen außer Acht gelassen. Eine agile Umsetzung ist das nicht. Eine agile Umsetzung hat immer zum Ziel, Ergebnisse zu schaffen, zu denen Feedback generiert werden kann. Der einfache Trick ist, die Anforderungen nicht horizontal, sondern vertikal zu schneiden.
Ein Feedback kann nur gegeben werden, wenn die UI mit berücksichtigt wurde. Dort findet die Interaktion statt. Gleichzeitig wäre es unzureichend, sich ausschließlich auf die Implementierung der UI zu beschränken. Dann wiederum kann der Product Owner kein Feedback zur inhaltlichen Umsetzung geben. Das Ziel dieses Use Cases ist nicht eine Rückmeldung an die Oberfläche, sondern die Erstellung einer Datei. Nur Oberflächenlogik umzusetzen, würde kein Ergebnis liefern.
Kleine Schritte machen
Agil vorzugehen bedeutet, die Interaktion mit all ihren Features Stück für Stück zu implementieren. Genau wie in einem durch Scrum gesteckten Rahmen, teilen wir den Use Case in mehrere aufeinander folgende Iterationen. Am Ende jeder Iteration steht ein Inkrement. Das Inkrement ist – wie das Potentially Shippable Product Increment am Ende eines Sprints – ein funktionsfähiges Zwischenergebnis, zu dem Feedback gegeben werden kann. Dieser Ansatz ermöglicht es, Feedback schon innerhalb eines Sprints zu erhalten, statt erst nach zwei Wochen Entwicklungszeit. So können wir nach wenigen Tagen erste Rückmeldungen einholen und darauf aufbauen.
Die folgende Abbildung veranschaulicht eine mögliche Umsetzung des Use Cases in 4 Iterationen. Jede Iteration setzt einen Teil unseres Use Cases um. Die erste ermöglicht das Auslösen der Interaktion über den Button und stellt eine Funktion zu Verfügung, die eine zunächst leere PDF-Datei im Dateisystem speichert. Das mag ein kleiner Anfang sein, aber am Ende kann das schon ausgeführt werden. Und es gibt ein Gerüst, das im Folgenden mit Inhalt gefüllt werden kann. Im nächsten Schritt wird Domänenlogik ergänzt. Eine PDF-Converter-Klasse wird angelegt, die vorerst Dummy-Daten zurückgibt. Diese werden in die PDF-Datei gespeichert. Erneut ein kleines Inkrement. Erneut eine Möglichkeit, Feedback zu erhalten. In der dritten Iteration wird die tatsächliche Konvertierung aus dem SVG Objekt in das PDF implementiert. Das Ergebnis wird in die Datei gespeichert. Die vierte und letzte Iteration ergänzt das Wasserzeichen und die Möglichkeit für den Benutzer, über einen Dateibrowser Pfad und Namen für das PDF zu wählen. Die Logik zum Speichern wird entsprechend erweitert. Es wird deutlich, wie durch jeden Schritt ein vollständigeres Inkrement entsteht. Am Ende jeder Iteration kann das neue Ergebnis geprüft werden. Statt eines Feedbacks nach zwei Wochen bekommen wir dank dieses Vorgehens die Möglichkeit, drei Rückmeldungen über Zwischenstände zu erhalten. Das ist agile Implementierung.
Mit etwas Übung kann man den Output von Inkrementen in der eigenen Entwicklung deutlich erhöhen. Man sollte dabei nicht davor zurückschrecken, vielleicht an der einen oder anderen Stelle erstmal auf Dummy-Daten zurückzugreifen. Sie können helfen, frühzeitig Inkremente zu erzeugen. In den folgenden Iterationen werden sie nach und nach durch echte Logik ersetzt. Es ist sogar möglich, am Ende jedes Arbeitstages ein Inkrement zu erzeugen. Das ist doch eine bessere Aussicht, als erst nach 2 Wochen ein Ergebnis der eigenen Arbeit vorweisen zu können, oder?
Fazit
Agil zu implementieren ist so einfach wie hilfreich. Durch schrittweise Implementierung und Erzeugung vieler Inkremente erlangt man schnell auswertbare Ergebnisse und damit frühzeitig Feedback. Das ermöglicht selbst innerhalb eines Sprints Anpassungen vornehmen oder auf Wünsche eingehen zu können. Gleichzeitig bekommen Entwickelnde schnell Bestätigung und Übersicht über die eigene Arbeit. Und da es nur um eine Strukturierung der eigenen Arbeitsweise geht, steigt nicht einmal der Zeitaufwand.
German 
English