tekom-Jahrestagung 2012 - ActiveDoc

User Assistance
UA 11
Workshop
Kurze und knackige
Anforderungen
Scrum, Sprints und
Inkremente
Karteikarten und Bierdeckel: User Stories
für Dokumentation und Entwicklung
Anne Hoffmann & Ann-Cathrin Mackenthun, parson communication, Hamburg
In der agilen Software-Entwicklung werden Anforderungen nicht mehr
in Pflichten- und Lastenheften geschrieben, sondern in Form von handlichen
User-Stories festgehalten, die auf einer Karteikarte oder einem
Bierdeckel Platz haben. Doch wie schreiben Sie kurze und knackige
Anforderungen, die nützlich für die Entwickler sind und eine gute Basis
für aufgabenorientierte Dokumentation darstellen?
Die Verwendung von User Stories als Anforderungsbeschreibungen
für die Software-Entwicklung geht auf agile Entwicklungsverfahren
wie Scrum zurück. Ein nach Scrum geführtes Projekt wird nicht von
Anfang an durchgeplant. Stattdessen arbeiten die Entwickler in kurzen
Entwicklungszyklen, Sprints genannt. Zudem werden nur kleine und in
sich geschlossene Funktionen (Inkremente) entwickelt, z. B. eine neue
Schaltfläche mit einer Druckfunktion. Diese Inkremente bestehen aus
allen notwendigen Einzelbestandteilen, wie z. B. Datenbankanbindung,
funktionalem Code und Oberfläche. Theoretisch kann die Software am
Ende jedes Sprints mit den neuen Funktionen ausgeliefert werden.
Abb. 1: Inkrement in der Software-Entwicklung
User Stories
Kryptische Notizen
Die Definition von Anforderungen in Scrum unterscheidet sich deutlich
von anderen, herkömmlichen Entwicklungsmethoden. Bei der Definition
der Anforderungen wird der Nutzer in den Mittelpunkt gerückt. Die
User Stories beantworten dem Entwickler kurz und knapp die wichtigsten
Fragen: Wer braucht warum welche Funktion? Für das Beispiel mit
der Druckfunktion könnte die User Story folgendermaßen lauten: „Als
Labor-Mitarbeiter möchte ich die grafische Darstellung des Ergebnisses
der Untersuchung 3aXX direkt aus dem Grafik-Dialog heraus drucken
können.“
Was sich so einfach liest, ist im Alltag der Software-Entwicklung nicht
immer so einfach umzusetzen. Oft wird ein Teil der Informationen weggelassen,
weil „das macht eh Kollege Meier, der weiß schon, was gemeint
ist“. Oder das Team schreibt direkt die technische Umsetzung auf,
tekom-Jahrestagung 2012
521