Blog-Serie – Teil 2 von 5
Wenn man von Epic, Feature, Story oder manchmal nur Epic und Story spricht hat man häufig unterschiedlich grobe Dinge im Kopf. Epic eher grob und unausgereift und eine Story konkret und ausgearbeitet. Auch spielt die Größe eine Rolle und dabei üblicherweise der Gedanke, ob man es in einer Iteration umsetzen kann.
Unterschiedliche Ebenen (von grob bis detailliert) ergeben sich üblicherweise automatisch. Dabei ist erstmal egal wie wir diese nennen.
Aus der ersten Idee, beispielsweise eine komfortable Türsteuerung (in einem Smart Home System) wird, über mehrere Arbeitsschritte hinweg, die konkrete Beschreibung, dass durch Wischen nach rechts auf dem Smartphone die Tür entriegelt werden kann.
Die Idee, die am Anfang steht, muss üblicherweise konkretisiert werden, bevor wir sie umsetzen können. Das bedeutet Requirements Engineering!
Nach einiger Zeit intensiver Analyse werden aus den groben Ideen – meistens über Zwischenstufen – konkrete Anforderungen, die umgesetzt werden können.
Außer wir lassen alle Freiheiten, wie die Idee umgesetzt wird und sind mit allem zufrieden, was als Lösung kommt. Dann könnten wir bei den groben Ideen aufhören.
Das ist im klassischen Vorgehen, wie auch im agilen prinzipiell das gleiche. Natürlich gibt es viele Unterschiede aber die Grundidee ist die gleiche.
Die unterste (konkrete, detaillierte) Ebene benötigen wir für die Umsetzung. Denn dort wird konkret geklärt, was wir haben möchten, und es werden die Fragen, die in der Umsetzung auftreten geklärt. Dafür wäre eine Idee wie „komfortable Türsteuerung“ einfach noch zu schwammig.
Wenn wir allerdings die konkreten Anforderungen betrachten, brauchen wir zum Verständnis Informationen zum Kontext. Einzelne, detaillierte Anforderungen sind meistens schwer nachzuvollziehen. Deswegen werden Anforderungen immer im Bezug zu einem Kontext gesetzt. Das kann in einem Anforderungsdokument durch die Kapitelstruktur realisiert werden. Arbeiten wir mit einem Product Backlog geschieht dies durch die Zuordnung zu Epics bzw. Features.
Häufig ist die Zuordnung zu der ersten Idee gut, aber nicht ausreichend. Unser Beispiel, die komfortable Türsteuerung, kann sehr viel enthalten. Remote die Tür für Gäste öffnen, Haus ohne Schlüssel betreten, Türen remote verriegeln und vieles mehr. In solchen Fällen ist die Zwischenebene hilfreich, da sie dem besseren Verständnis der Anforderungen dient.
Es gibt auch andere Gründe für eine Zwischenebene. Zum Beispiel könnte man eine leichtere Zuordnung zu Releases ermöglichen oder Konfigurationsmöglichkeiten abbilden. Die Gründe sind vielfältig.
Wir sehen, wir haben unterschiedliche Ebenen bei Anforderungen, die jeweils ihren Zweck erfüllen:
- Grob für die ersten Ideen
- Mittel für z.B. Releasezuordnungen
- Konkret für die Umsetzung
In den nächsten Beiträgen dieser Blogserie wollen wir uns diese Ebenen genauer ansehen. Wie nutzt man diese im agilen?
Wie sieht es aus, wenn wir im skalierten agilen Umfeld unterwegs sind?
Und im diesem Zuge schauen wir uns Epic, Feature und Story genauer an.
Bleiben Sie dran und diskutieren Sie gerne über Kommentare zu den einzelnen Beiträgen mit.
Ihre SOPHISTen