Interaktive Requirements-Modellierung im Scrum-Team

Abstraktion durch Modellierung ist im Software Engineering ein bewährtes Mittel. Dieses Mittel lässt sich in Scrum-Projekten gezielt im Team einsetzen, um effiziente Kommunikation zu gewährleisten. Der Schlüssel dabei sind die Wahl geeigneter Notationen sowie eine agile Vorgehensweise bei der Erstellung der Modelle. Durch die richtige Wahl der Lösungsabstraktion und einer dazu passenden Notation vermeidet das Team Missverständnisse untereinander und mit dem Product Owner konsequent. Das Team gewinnt ein besseres Verständnis indem es unterschiedliche Perspektiven der Aufgabenstellung durch die Modellierung gewinnt. Modellierung kann hinsichtlich Formalisierung und Tooleinsatz so eingesetzt werden, dass sie das Team in allen Scrum-Meetings unterstützt.

Vortrag von Susanne Mühlbauer & Philip Stolz, HOOD GmbH, am Swiss Requirements Day 2012.

In konventionellen Projekten sucht man eine schriftliche, möglichst vollständige Dokumentation der Anforderungen. In agilen Projekten geht man in Richtung Konversation, Just-in-Time, On-Demand.

Modelle helfen, ein gemeinsames Verständnis für das Projekt zu entwickeln: Sie abstrahieren die Wirklichkeit und stellen „nur“ gewünschte Aspekte dar. Sie trennen dadurch das Problem von der Lösung.

Modelle können als Skizze eingesetzt werden. Ist das Ziel erreicht, wird die Skizze weggeworfen.
Erstellt man eine Blaupause, so kann diese allenfalls als Dokumentation verwendet werden.
Ausführbare Modelle sind schon sehr nah am ausführbaren Code.

Vision

In allen Projekten braucht es eine kurze Produktbeschreibung. Man muss auch Begeisterung wecken, gemeinsame Zile formulieren und Orientierung schaffen.

Die Vision Box, das Elevator Statement oder ein Press Release sind agile Mittel dazu. Als Ãœbung erstellt man z.B. eine „Product Box“: Auf der Verpackung eines Produktes ist der Platz beschränkt, man muss sich alos auf das Wesentliche beschränken und gut kommunizieren.

Die Besprechung der Product Box deckt schnell auf, wer die Akteure/Stekeholder sind und welche Missverständnisse bei der Auftragvergabe aufgetreten sind.

Backlog Grooming

Im Backlog werden Prioritäten bestimmt, Anforderungen detailliert, Akzeptanzkriterien definiert. Auch hier ist Kommunikation ein wichtiger Aspekt: Was steckt wirklich dahinter? Was ist wirklich das Ziel? Ein Use-Case Diagramm stellt das „Was“ dar, von der Lösung hat man erst mal noch nicht gesprochen.

In einem Aktivitätsdiagramm stellt man typische Benutzungsvarianten der Lösung dar. Als Auftraggeber wird einem oft erst hier die Komplexität klar. Entsprechend klammert man Use-Cases aus und priorisiert neu nach wirklich relevanten Anwendungsfällen.

Planning Meeting

In der Sprintplanung werden die nächsten Funktionen zur Bearbeitung freigegeben. Dafür müssen die Anforderungen und die Abnahmekriterien klar sein. Der Product-Owner präsentiert die User-Story, potentiell anhand der zuvor erstellten Diagramme.

In einem Designmeeting wird die Lösung anhand von Mockups und Screendesigns erarbeitet.

Am Ende des Sprints ist die Definition von „Done“ relevant: Umfasst die Dokumentation auch die Darstellung eines Modells, z.B. ein Aktivitätsdiagramm?

Da die Kommunikation zentral ist, empfiehlt es sich, kein Tool für das Skizzieren der Modelle zu verwenden, sondern interaktiv zu zeichnen und zu besprechen. Ist man sich schliesslich einig, so kann man das finale Diagramm immer noch in einem Tool dokumentieren.