Über 20 Jahre ist es her, dass das Agile Manifest veröffentlicht wurde. Seitdem hat sich in der Softwareentwicklung einiges geändert. Die früher üblichen Wasserfallmodelle wurden durch Entwicklungsstrategien ersetzt, die für Software weitaus angepasster sind. Management-Tools wie Kanban oder Scrum sind mittlerweile in vielen Firmen vertreten. Sie stellen den Rahmen für die agile Arbeit. Mit dem Wandel haben sich neue Berufsbilder gefunden: der Scrum Master, der Product Owner, der Agile Coach und andere.
Agil Entwickeln lebt nicht nur innerhalb der Entwicklungsabteilung. Es zieht sich durch die Unternehmen. So gesehen sind die meisten Entwickler scheinbar vertraut mit dem Begriff Agil und wenden ihn bei der Arbeit mit Scrum oder Kanban an. Doch damit sollte es nicht genug sein. Im folgenden Artikel möchte ich etwas tiefer gehen und ein paar Anregungen geben, wie Entwickler heutzutage wirklich agil arbeiten können. Ein wichtiger Aspekt in der täglichen Arbeit ist das vertikale Zerlegen von Anforderungen.
Anforderungen lesen lernen
Entwickelnde arbeiten mit Anforderungen. Sie freuen sich über detaillierte Anforderungen. Sie fragen, hoffentlich, bei lückenhaften Anforderungen nach. Sie übersetzen die Anforderungen in Code und liefern ein Ergebnis. Sie wissen, dass dieses Ergebnis nicht immer dem entspricht, was der Product Owner sich wünscht. Daher ist es so wichtig, häufig und regelmäßig Feedback generieren zu können. Scrum hat sich als Management-Tool etabliert, um häufige und regelmäßige Feedbacks ermöglichen zu können. Dafür nutzt es Sprints, die über den Zeitraum von zwei bis drei Wochen ein bestimmtes Set an Anforderungen liefern sollen. Am Ende eines Sprints bekommt der Product Owner ein Ergebnis, zu dem er ein Feedback geben muss. Damit ist der Rahmen gesteckt. Aber wie sieht es innerhalb dieses Rahmens aus? Die Anforderungen werden in der Regel als User Stories oder Epics formuliert. Aus diesen User Stories sollen die Entwickelnden eine Lösung implementieren.
User Story ungleich Use Case
Viele Programmierende lesen eine User Story und zücken direkt das Keyboard, um in der Code-Basis neue Methoden zu ergänzen. Viel zu früh! Eine User Story ist eine hervorragende Art für Anwendende, ihre Wünsche an die Software zu formulieren. Für die technische Umsetzung ist sie ungeeignet. Die technische Übersetzung von User Stories sind Anwendungsfälle (Use Cases). Dabei kann eine User Story ein oder mehrere Use Cases beinhalten. Ein Anwendungsfall repräsentiert eine Interaktion des Users mit dem System. Die erste Aufgabe von Entwickelnden ist es, eine User Story in Anwendungsfälle umzuwandeln. Ein Beispiel:
Das Ausgangsprodukt ist ein Grafikprogramm zum Erstellen von Vektorgrafiken. Neue Anforderungen soll hinzugefügt werden. Die zugehörige User Story lautet:
Als Grafikdesigner möchte ich über einen “Exportieren als PDF”-Button eine Vorschau meiner Grafik mit dem Wasserzeichen “Preview” als PDF Datei speichern können.
Ich habe sofort ein Bild vor Augen. In meiner Vorstellung entsteht eine grafische Benutzeroberfläche. Der Button wird angezeigt, ich drücke drauf und als nächstes öffnet sich ein Datei-Browser, in dem ich eine PDF Datei mit einem gewünschten Namen ablegen kann. Eine sehr bekannte, oberflächliche Betrachtung aus der Sicht eines Anwendenden. Ich gewinne nicht wirklich eine Vorstellung davon, was der zugehörige Code an Transformationsarbeit leisten muss, um diese Anforderung erfüllen zu können. Bevor ich gleich durchstarte und einen neuen Button in die GUI einbaue, sollte ich in die Sicht des Entwickelnden wechseln. Ein genauerer Blick offenbart mir drei Aspekte in der Anwendung, die von dieser Anforderung berührt werden.
Der Block in dieser Grafik repräsentiert Anforderungen aus der User Story. Er ist aufgeteilt in die drei von den Anforderungen berührten Aspekte unserer Anwendung. Der Aspekt UI stellt die grafische Benutzeroberfläche dar. Der Aspekt Domain umfasst die Logik, die unsere Anwendung erfüllen soll. Und der Aspekt Ressource bildet die Zugriffe auf externe Dienst ab, in diesem Fall das Dateisystem. Im nächsten Schritt werden die Anforderungen den Aspekten zugeordnet.
Natürlich bleibt der Button selbst eine dieser Anforderungen. Über ihn startet der Anwendende die Interaktion, die das PDF generieren soll. Darüber hinaus lese ich drei Features, die Teile dieser Interaktion sind:
- Die Vektorgrafik soll in ein PDF konvertiert werden.
- Ein Wasserzeichen soll hinzugefügt werden.
- Das PDF soll als Datei gespeichert werden.
Jetzt habe ich die Übersetzung der User Story in einen Use Case. Eine Interaktion mit drei Features. Ausserdem eine Zuordnung der Features zu den vorhandenen Aspekten.
Fazit
Die User Story ist eine horizontale Beschreibung der Anforderungen. Sie vermittelt die Sichtweise und Wünsche der Nutzenden an das System. Der Aspekt der UI gewinnt die größte Bedeutung. Die Interaktion des Benutzers mit der Anwendung steht im Vordergrund, technische Details sind unbekannt. Im ersten Schritt einer vertikalen Betrachtung setzen wir die User Story in Bezug zu den Aspekten der Anwendung. Die Aspekte sind eine Schablone, mit der die Informationen der User Story verknüpft werden. Daraus ergeben sich die Use Cases, oder Interaktionen, und die zugehörigen Features. Sie repräsentieren die technischen Details in allen Teilen des Systems.
German 
English