SUPI: Iterative Entwicklung von Stories (oder auch: Dimensional Planning)
07.12.2019 – Sebastian Ossio
Sie kennen die Situation: Eines Morgens kommen Sie an Ihren Schreibtisch und da ist es – ein neues, glänzendes, agiles Projekt liegt auf dem Tisch.
Großartig! Und jetzt: einfach loslegen.
Aber wo kann man als Product Owner anfangen, um all diese Features entwickelt zu bekommen?
Sie haben vielleicht schon einmal von 'Elefantencarpaccio' gehört und wissen, dass Sie Funktionalitäten vertikal in Scheiben schneiden müssen. Sicher... aber wie noch mal?
Das Problem ist, dass Features normalerweise nicht in ein oder zwei Stories/Tickets erledigt werden, und dass Sie vor allem am Anfang viel Arbeit in diverse grundlegende Features stecken müssen. Außerdem: Wie gehen Sie vor, wenn die erforderliche Arbeit, um ein MVP – also die erste minimal funktionsfähige Iteration eines Produkts – zu erhalten, mindestens sechs Sprints entfernt ist?
Die Antwort liegt im sogenannten 'Dimensional Planning': ein iterativer Weg zur Entwicklung von Features. Das Konzept ist einfach: Sie machen Features so, dass die grundlegendste Struktur in der ersten Iteration gemacht wird, auf der Sie später aufbauen. Dadurch wird das Feature in jedem Durchgang vollständiger und ausgefeilter. Das Ergebnis: schöne, dünne Carpaccio-Scheiben statt Elefanten-Steaks.
Die Grundidee sollte inzwischen klar sein, aber ich finde die Analogie, die normalerweise für die dimensionale Planung verwendet wird, etwas daneben. Sie besagt, dass man das Highway-Feature nicht auf der ersten Iteration aufbaut, sondern sich bis zu diesem Feature hinaufarbeitet. Zuerst wird eine unbefestigte Straße gebaut, dann eine Kopfsteinpflasterstraße, dann eine gepflasterte Straße, und gerade dann beginnt man mit der Arbeit an der Autobahn. Abgesehen davon, dass die meisten agilen Projekte keine Bauarbeiten sind, ist die Analogie schwer zu übersetzen. Wie würde eine "Kopfsteinpflaster"-Version Ihres Features aussehen? Es ist mehr als eine "unbefestigte" Version, aber was ist der Unterschied? Wie hängt das zusammen?
Der "SUPI"-Ansatz
Lassen Sie uns stattdessen den SUPI-Ansatz ausprobieren: Skeleton, Usable, Practical, Ideal. Im Grunde genommen ist es die gleiche Idee, aber die Analogie ist bei agilen Projekten, insbesondere bei Software, leichter zu verstehen. Schauen wir uns die verschiedenen Dimensionen an.
SKELETON:
Wenn man ein größeres Projekt entwickelt, muss man immer zuerst grundlegende Aufgaben erledigen, um die Dinge in Gang zu bringen. Bei Software ist es meistens die Grundstruktur, die vervollständigt werden muss. Oftmals beginnt man sogar mit einem wandelnden Skelett – einer funktionierenden Konzeptversion des Produkts. Normalerweise möchte man nicht, dass jemand viel von dieser Version sieht. Es fehlt die glänzende Oberfläche und kann ein wenig beängstigend sein (was es allerdings zur idealen Software macht, um Benutzer an Halloween zu erschrecken). Mit anderen Worten: Dies ist die allerwichtigste Grundfunktionalität. Manchmal entwickeln wir Funktionen, die zu komplex sind, um diese Version überhaupt zu haben, aber wann immer möglich, ist es schön, eine zu haben.
Beispiel: Wenn unser Feature eine Liste aller früheren Bestellungen ist, zeigt diese Version möglicherweise nur eine Seite mit den Bestellnummern.
USABLE:
Gute Arbeit! Sie haben eine Version eingerichtet, die die grundlegendsten Funktionen beherrscht, aber ist sie wirklich nutzbar? Wahrscheinlich würde kein Benutzer diese Version anfassen wollen, geschweige denn, sie so lassen, wie sie ist. Deshalb geht es in der zweiten Iteration darum, ein Feature gerade so reichhaltig zu machen, dass es genau das ist: benutzbar. Nichts Glänzendes, manchmal sogar ein bisschen hässlich, sondern etwas, das die Funktionalität in der grundlegendsten Weise ermöglicht.
Beispiel: Unsere Bestellliste von SKELETON zeigt jetzt die Bestellungen in einer Tabelle mit nur den verknüpften Bestellnummern und dem Datum für alle früheren Bestellungen. Der Benutzer wird wahrscheinlich einige Funktionalität vermissen, aber er ist zumindest in der Lage, die Funktion zu nutzen.
PRACTICAL:
Vor diesem Iterationsschritt ist die Funktionalität in ihrer Grundform vorhanden, aber alles ist ein wenig unbequem. Die Benutzererfahrung ist nicht großartig. Unser nächster Schritt wird ein wenig unscharf, denn je nachdem, wie perfektionistisch Sie sind, kann der praktische Teil schon sehr weit gehen. Die Idee der praktischen Iteration ist, dass diese "umständliche" Art, Dinge zu tun, aus dem Weg geräumt wird. Sie könnte in späteren Iterationen noch ausgefeilt und perfektioniert werden, aber diese Version ist etwas, das für die meisten Anwendungsfälle ausreichen sollte.
Beispiel: Unsere Liste zeigt den Status der Bestellung auf der Tabelle und ist absteigend nach Datum geordnet. Man könnte nun argumentieren, dass eine Liste mit 100 000 Bestellungen im nutzbaren Schritt nicht funktioniert. Nun, da haben Sie Ihre praktische Antwort: Ihr nutzbarer Schritt hätte eine Paginierung mit sich bringen müssen. Für einen normalen Webshop ist die Paginierung auf der Bestellliste möglicherweise keine Voraussetzung, deshalb habe ich sie vorher nicht hinzugefügt.
IDEAL:
Hier bauen Sie den ganzen Schnickschnack. Jeder mögliche Wunsch, der in Ihrem Feature enthalten sein sollte, um perfekt zu sein (und nicht skelettartig, brauchbar oder praktisch ist), geht hier hinein. Ich würde mir wünschen, dass Sie die meiste Zeit damit verbringen können, Ihr Produkt idealer zu gestalten. Aber aus meiner Erfahrung sieht die Realität meist etwas anders aus. Meistens verbringen Sie Ihre Zeit mit den früheren Iterationen und sind froh, wenn Sie die Entwicklungsstufen gut genug voneinander unterscheiden können. Die ideale Version ist es, wenn Sie das Feature aufpolieren und es noch reicher an Funktionalität machen. Seien Sie sich aber bewusst, dass Sie wertvolle Zeit mit dem Polieren verbringen, anstatt eine skelettartige oder praktische Version des nächsten Features in der Reihe zu machen.
Beispiel: Sie ermöglichen die Sortier- und Suchfunktion in der Bestelltabelle unserer Liste und fügen weitere Details wie Lieferdatum und Kaufmenge hinzu.
Sicherlich werden Sie Fälle finden, in denen die eine oder andere Definition von SUPI nicht vollständig zutrifft, aber zumindest ermöglicht es Ihnen, die Arbeit so aufzuteilen, dass Sie vertikal geschnittene Features ausliefern und bei jedem Schritt eine gewisse Funktionalität ermöglichen. Auch wenn Sie manchmal das Feature ausblenden wollen, weil es einfach nicht zu den restlichen Erwartungen der Benutzer passt.
Einer der wichtigsten Teile dieser Namenskonvention und der Idee hinter Dimensional Planning ist, dass man dies mit Kunden und Anwendern ganz einfach diskutieren kann. Dadurch wird das Gespräch über die Arbeit und die Schritte, die erforderlich sind, um einen bestimmten Grad an Funktionsreichtum zu erreichen, sehr deutlich. Es ist also nicht nur ein wunderbares Planungswerkzeug, sondern ermöglicht auch eine bessere Kommunikation.
Was wir gelernt haben
Wir haben über die Dauer gelernt, dass sehr kleine Schritte eine Menge paralleler Arbeit ermöglichen. Dies wiederum macht die Erstellung eines Sprint-Ziels in Scrum komplexer und kann zu mehr Tickets führen, wodurch der Überblick über das Projekt für alle Beteiligten erschwert wird. Andererseits kann es Ihnen auch ermöglichen, Sprint-Ziele wie "Feature X und Feature Y nutzbar zu machen" zu erstellen –jedenfalls wenn Sie Scrum und Zielsetzungen verwenden. Aber selbst wenn nicht, erhalten Sie trotzdem einen Überblick, auf welcher Iterationsebene Sie arbeiten. Sie können sogar Gruppierungen für alle Tickets in einer bestimmten Iteration haben und versuchen, sich von Iteration zu Iteration durch das gesamte Produkt zu entwickeln.
Nach dem, was ich in diesem ganzen Prozess gelernt habe, würde ich immer dazu raten, diesen Ansatz zu verwenden, wenn es eine beträchtliche Anzahl zu planender Funktionen gibt. SUPI bietet einen sehr konzentrierten Ansatz, um jedes Feature in eine brauchbare oder praktische Version zu bringen, so dass komplexe Anforderungen sehr praxisnah gelöst werden können. Normalerweise erstellen wir ein Epic für ein gut definiertes Feature und unterteilen jede Version in eine Untergruppe von Stories. Denken Sie daran, dass die Skelettversion hässlich und wahrscheinlich unbrauchbar sein könnte, aber genau dies ermöglicht es, dass die zugrunde liegende Architektur einfach bleibt und oft eingesetzt werden kann. Von da an liegt es am Priorisierungsprozess, zu definieren, welches Niveau jedes Feature erreichen muss.
Wie bei allen agilen Werkzeugen gilt: Prüfen, ob es passt, und ein paar Mal ausprobieren. Jedes Projekt ist anders. Wir fahren damit bislang sehr gut und haben SUPI erfolgreich in unseren Projekten angewendet.
Viel Spaß beim Stories planen!