Ein Software-Produkt entsteht durch einen konkreten Bedarf (englisch: need) einer Fachabteilung in einem bestimmten Geschäftsfeld. Oft steckt hinter dem Bedarf eine Vision oder Idee, wie ein Problem gelöst oder ein Prozess optimiert werden kann. Die Reduktion von Kosten oder eine Gewinnmaximierung ist in unserer wirtschaftlich geprägten Welt ebenfalls eine große Motivation der Auftraggeber. Der Product-Owner oder ein Business-Analyst hat die Aufgabe, eine Anforderung des Auftraggebers (englisch: requirement) für alle im Projekt “begreifbar” zu machen. Wir kennen unser System und bewerten und beschreiben den konkreten Wunsch eines Stakeholders, “sein” Produkt zu verändern.

Ein Epic ist das Ergebnis der Anforderungsanalyse.

In der Methode CARDS+ untersuchen wir jede Anforderung vom Groben (als Epic) ins Feine (als Case). Über den beiden schwebt noch die Zuordnung zum Aufgabenbereich (als Topic).

Motivation

Durch den Baustein Epic sollen sowohl Stakeholder als auch das cross-funktionale Team einen Überblick (englisch: big picture) über ein bestimmtes fachliches Problem bekommen. Bei der Analyse werden häufig Entscheidungen getroffen, die maßgeblich den Umfang und die Komplexität der fachlichen Lösung beeinflussen. Diese Informationen sind es, die wir erhalten wollen.

Ein Ergebnis bei der Analyse einer Anforderung ist die Abgrenzung zu anderen, geplanten oder bereits umgesetzten Anforderungen. Anforderungen können sich ergänzen, aber auch widersprechen. Es kommt auch vor, dass eine Anforderung bereits umgesetzt ist, also ein Duplikat ist. Diese Konflikte müssen vom Product-Owner zusammen mit den Stakeholdern geklärt werden.

Ein ganz wichtiges Ziel der Methode CARDS+ ist es, die ursprüngliche Vision oder Idee einer Anforderung zu erhalten und sie jedem Projektmitarbeiter zu vermitteln. Dazu wollen wir die Macht der Bildsprache nutzen.

„Ein Bild sagt mehr als tausend Worte“ ist ein Sprichwort und eine Metapher für den Mehrwert von Bildern gegenüber ausschließlichem Text. Es bezieht sich darauf, dass komplizierte Sachverhalte oft mit einem Bild oder einer Darstellung sehr einfach erklärt werden können und ein Bild meist einen stärkeren Eindruck auf den Betrachter ausübt als ein umfangreicher Text (Quelle: wikipedia).

Was in dieser Definition mitschwingt wird aber sehr oft übersehen: Es geht um ein Bild oder eine Darstellung, die komplizierte Sachverhalte einfach erklären. In der Realität der Software-Projekte entsteht aber sehr oft eine Flut unterschiedlichster Bilder und Diagramme. Jeder Stakeholder und Projektmitarbeiter verwendet sein eigene Art der Darstellung. In der Kommunikation zwischen Stakeholder und Projektmitarbeiter geht dadurch viel Information verloren oder wird unterschiedlich interpretiert. So wie ein Bild mehr als tausend Worte sagt kann ein Bild auch dutzende Bedeutungen haben. Denken sie an Handzeichen, die hier und in anderen Teilen der Welt unterschiedliche Bedeutung haben.

Unser Ziel ist es, für jedes Epic eine gemeinsame Sprache mit eindeutigen Begriffen und – wenn möglich – klarer Bildsprache zu entwickeln.

Ein Foto genügt ja schon, um den Film vor dem inneren Auge zu starten. Ich muss hier nur schreiben: »Wo waren Sie, als Mario Götze das 1:0 im Endspiel schoss?«, prompt haben Sie den Moment wieder präsent (Quelle: SZ).

So eine Bildsprache muss von Business-Analysten und Entwicklern gleichermaßen verstanden werden. Nur so können wir im Team zwischen Analyse und Entwicklung eine Brücke schlagen. Eine gute Bildsprache, die von allen Projektmitarbeiter “gesprochen” wird, unterstützt uns, komplizierte Sachverhalte schneller zu klären. Die Qualität der Kommunikation und letztendlich durch Feedback auch die Qualität der Dokumentation wird steigen.

Die Bildsprache kann trainiert werden, wenn sie in Form einer Legende dokumentiert ist. Als sehr positiver Effekt wird so eine Bildsprache gerne in einem Workshop oder Meeting verwendet, um ein neues Problem zu erläutern oder einen komplizierten Sachverhalt zu erklären. Auf einem Flipchart entstehen dann oft die Entwürfe der Darstellungen, die Business-Analysten oder der Product-Owner dann für das Wiki übernehmen. Alle Projektmitarbeiter haben von Anfang an das gleiche “Bild” der Lösung.

Die Verwendung von Personas hat sich als sehr nützlich erwiesen. Die Persona stellt einen Prototyp für eine Gruppe von Nutzern dar, mit konkret ausgeprägten Eigenschaften und einem konkreten Nutzungsverhalten.

In meiner Artikelserie “Dialoge” benutze ich ebenfalls eine Persona, um meinem “Gesprächspartner” im Dialog nicht nur eine Rolle zu geben. Durch die Persona soll der Gesprächspartner auch einen Charakter bekommen. Natürlich ist Name und Biografie frei erfunden und ich benutze Initialen als Abkürzung der Rolle.

Beispiel: Pirmin Ofner (kurz PO), ein Product-Owner

Auch spezielle grafische Darstellungen sind – wenn sie die Stakeholder gut kennen – sind vorteilhaft. Sie helfen ganz wesentlich bei der Klärung von Fragen oder Problemen im Zusammenhang mit der Anforderung.

Im Personen-Nah- und Fernverkehr gibt es die Zeit-Wege-Linien. Mit diesem sehr einfachen, aber speziellen Diagrammtyp lassen sich viele Anwendungsfälle bei Betriebsabläufen sehr einfach darstellen.

Auch die Verwendung von grafischen Sprachen wie UML oder BPMN können wir nur empfehlen. Allerdings sind diese Sprache meist so mächtig, dass es zur Vorbeugung vor Missverständnissen notwendig ist, eine für das Epic spezifische Einschränkung vorzunehmen oder eine eindeutige Interpretation der Elemente vorzugeben.

Fachklassen werden sehr häufig mit einem UML-Klassendiagramm dokumentiert. Auch wenn die Symbole mittlerweile jedem Entwickler bekannt sind, repräsentieren die Symbole die Entscheidung für eine bestimmte technische Lösung! Klassen können zusätzlich noch mit Stereotypen versehen werden, was erst recht der Hinweis auf eine bestimmte Realisierung ist, die dokumentiert werden muss.

Gerade im Zusammenhang mit einer Software-Architektur, die auf Entwurfsmuster wie microservices, SOA, EAI oder EDA setzen, bietet sich der Einsatz maßgeschneiderte Diagramme an.

Apache Camel ermöglicht die Erstellung von Regeln für Routing und Transformationen. Dabei wird definiert, von welcher Quelle Daten abgerufen werden, wie sie zu verarbeiten sind und zu welchen Zielen diese Daten dann weitergeleitet werden. Dieser Baukasten aus unterschiedlichen Entwurfsmustern kann sehr einfach durch Bilder dargestellt werden. Entwickler werden auf der Projektseite motiviert, eine Bildsprache zu verwenden. Hinter jedem Bild steckt eine ganz konkrete Implementierung mit Apache Camel.

Definition

Beschreibung

Der Baustein Epic ist das Artefakt in unserer Systembeschreibung, mit dem wir die Ergebnisse der Analyse einer Anforderung sichern. Er gibt einer Anforderung einen eindeutigen Namen und enthält die grobe Ausarbeitung der fachlichen Problemstellung. Er aggregiert Vorgänge, Anwendungsfälle, Sonderfälle und Fehlersituation zu einem sinnvollen Ganzen.

Ein Epic wird aus Sicht des Nutzers geschrieben. Es benennt Dinge, die das zu System für den Nutzer tun soll. Es ist für jeden im Team verständlich und drückt den Kundennutzen klar aus.

Im Epic erfassen wir das “wer”, “warum” und “wann” einer fachlichen Anforderung auf einfache, präzise Art und Weise.

Aber eines ist ganz wichtig: Ein Epic ist

  • kein technisches Umsetzungskonzept.
  • kein Änderungskonzept.
  • nicht die Anforderung.

Insbesondere soll ein Epic ein “Feature” des Produktes repräsentieren. Ein Epic kann durch weitere Anforderungen schrittweise um Cases erweitert werden, die in der ersten Anforderung noch nicht enthalten waren.

Struktur

Abschnitt Motivation

Der Abschnitt vermittelt einen Überblick über ein Epic und beantwortet die Fragen

  • Wer sind die Nutzer?
  • Warum benötigen die Nutzer die Funktionen?
  • Wann verwenden die Nutzer die Funktionen?

So vermitteln wir das “Big Picture” für dieses Epic. Wir führen wir wichtigsten Begriffe aus dem Glossar ein, die für das Verständnis der Anforderung relevant sind.

Zusätzlich können wir aussagekräftige Abbildungen oder Diagramme aus der Medienbibliothek verwenden. Auch die Verwendung einer Persona ist eine gute Idee, um den fachlichen Kontext zu verstehen.

Abschließend bekommt der Leser gegebenenfalls noch Hinweise auf weitere Dokumente der Fachabteilungen in Form einer Link-Sammlung.

Abschnitt Abgrenzung

Der Abschnitt enthält Hinweise, was wir nicht betrachten wollen.

Abschnitt Verwendete Layouts

Der Abschnitt enthält eine einfache Auflistung aller Layouts, in denen dieses Epic eine Rolle spielen.

Abschnitt Untergeordnete Cases

Der Abschnitt enthält eine einfache Auflistung aller Cases, die in diesem Epic gebündelt werden.