Welche Funktionalität ist in meiner Software? Diese Frage ist oft in agilen Projekten nicht einfach zu beantworten – zumindest seriös. Ist das Benutzerhandbuch die einzig valide Quelle? Folgende Vorgehensweise habe ich kennengelernt (es gibt auch viele andere):

1. User-Story Map

Als erstes versucht man die User-Stories zu priorisieren. Da kann eine User-Story Map helfen, um eine gute End-to-End-Sicht zu bekommen. Wichtig ist nur zu verstehen: Man soll nicht versuchen, alles in eine User-Story Map zu pressen – man kann ohne weiteres mehrere haben.

2. Refinement of User-Stories

User-Stories sind ja bekanntlich nur ein Reminder für ein Gespräch in der Zukunft. Also nimmt man die User-Story und wird mit den Stakeholdern das Gespräch führen. Aus meiner Sicht hat die Strategie den Status in JIRA zu pflegen und in Confluence den Inhalt immer gut funktioniert. Wichtig ist, dass in Confluence keine Transkription des Gesprochenen sein soll, sondern eine gut aufgearbeitet Inhalt. Auch Hilfsmittel wie

• Wiremocks (UI)
• Sketches
• Tabellen
• und vor allem UML

können helfen, die Anforderungen zu Blatt zu bringen.

Wie schon mal erwähnt gibt es ein Modell, welches die Realität abbildet und eines, welches das Design (die Lösung) abbildet. Oft geht man aber auch nur den Weg, das Design zu modellieren. Hilfreich habe ich es auch empfunden, in Beispielen zu denken. Erstens ist es einfacher nachzuvollziehen als rein-beschreibender-abstrakter Fließtext, andererseits hat man für Akzeptanzkriterien eine gute Vorlage.

3. The solution

Anhand der Anforderungen kann man dann eine Lösung kreieren, welche im Regelfall software-technologischer Natur ist. Sie spiegelt die nötigen Anpassungsschritte des Systems wider.

4. Implementation

Nach der Umsetzung wird das JIRA-„User-Story“ Ticket geschlossen. Sind alle „User-Stories“ geschlossen, wird auch der „Epic“ geschlossen. Und irgendwann auch die Capability.

1 year later

Das „Kundenerfassungsformular“ wurde inzwischen durch zahlreiche „User-Storys“ kontinuierlich erweitert und auch vorhandene Funktionalität wurde angepasst. Doch welche Funktionalität ist jetzt aktuell vorhanden? Das ist schwierig zu beantworten, da der JIRA-Ticket „User-Story“ bzw. die dazugehörige Confluenceseite sind nur von kurzer Lebensdauer. Folgendes Bild aus „Wiegers, Karl E., and Joy Beatty. Software requirements. Pearson Education, 2013.”:

„How user requirements lead to functional requirements and tests with the use case approach and the user story approach.”

Man sieht also, dass der Akzeptanzkriterien jenes Inkrement sind, welche „überleben“ und den eigentlichen „funktionalen Anordnungen“ entsprechen. Akzeptanzkriterien sollten testbar und für alle verständlich sein. Auch sollten Akzeptanzkriterien die Userperspektive widerspiegeln – das ist bei rein technischen Lösungen oft schwierig, weil die Userperspektive oft nicht so einfach erkenntlich ist.

Ein Beispiel sind für mich Services, welche ein großes Dokument via REST zur Verfügung stellen und updatebar machen. Was bedeutet es, wenn man Property X und A.B updated? Trotzdem wird es dazu irgendwo eine Userperspektive geben – diese sollte in einem Akzeptanzkriterium hinterlegt werden.

Es hat sich im agilen Umfeld eine starke Community entwickelt, welche die Akzeptanzkriterien automatisieren. Viele formulieren Akzeptanzkriterien in der Gherkin Notation, welche die Wiederverwendbarkeit einzelner „Schritte“ erleichtern, soll:

Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out

Wie in JIRA abbilden?

Ein Requirements-Management Tool lässt sich oft nicht einsetzen – daher muss JIRA herhalten. Gott sei Dank kann man Issue-Types und Workflows ergänzen. Z.B.

• Feature
  • hat mehrere Akzeptanzkriterien

States für ein Akzeptanzkriterium können z.B. sein: Draft, Active, Obsolete.

Wohin verschwinden die schönen Diagramme aus den User-Storie Confluence Pages?

Wie erwähnt wird man sich bei User-Stories Niederschriften auch mit Diagrammen behelfen. Wichtig ist, dass diese auch zentral verwaltet werden. Ein Vorlage, welche Struktur rein bringt, ist z.B. Arc42 oder das 4+1 View Model oder C4.

Optimal wäre natürlich, wenn man im Code ein sauberes Domain-Modell hat und die Diagramme automatisiert generiert. Man findet im Netz hier und da – aber noch kein Projekt hat genügend Rückenwind.