Wir bauen um! (Teil 2)

Im ersten Blogpost aus dem smaboo-Entwicklungslabor, hatten wir einen groben Umriss über die Version 2 gegeben. Jetzt gehts hier um die verwendete Entwicklungsmethodik, denn spannend ist aber nicht nur WAS wir machen, sondern auch WIE wirs machen.
Wir verwenden mit “Scrum” eine agile Softwareentwicklungs-Methode, die auf so genannten “User Stories” basiert. Der Vorteil von User Stories, d.h. der Funktionalitäts- und Prozessbeschreibung aus Benutzersicht, liegt ganz klar in der Einfachheit. Dadurch kann ein grösserer Teil des Teams in die Spezifikationsarbeit einbezogen und eingebunden werden und man gewinnt dadurch an Geschwindigkeit. Ein weiterer grosser Vorteil: der Fokus und Detailgrad von Stories kann sich im Verlauf des Projekts verändern. So werden am Anfang typischerweise sogenannte “Epic Stories” erfasst, d.h. die Bedienungsmuster als grosses Ganzes. Im Verlaufe der Sprints (das sind die Umsetzungshorizonte, vergleichbar mit Iterationen nur viel kürzer) können dann die Stories immer weiter herunter gebrochen und an die im Projektverlauf gemachten Erfahrungen angepasst werden.
Der Aufbau einer Story ist dabei sehr einfach gehalten:
As a <type of user> I want to <specific goal> so that <specific reason/business value>.
Ebenso einfach definiert sind die typischen Inhalte einer User Story:
-
* Karte: Hier wird die eigentliche Spezifikation mit Verhaltensmustern und erwarteten Ergebnissen definiert.
* Diskussion: Dies ist das Gefäss für Diskussionen zu den einzelnen Details und Fragen.
* Tests: Hier werden die Akzeptanzkriterien definiert, d.h. wann eine Story korrekt erfüllt ist und wann nicht.
In der Heimatsprache der Methodik klingt dieser Dreiklang natürlich sehr viel schöner: Card, Conversation, Confirmation.
Wer noch etwas mehr zum Thema Scrum und User Stories erfahren möchte, dem seien die folgenden Ressourcen ans Herz gelegt:
- Artikel Advantages of the “As a user, I want” user story template.
- Powerpoint Slides von Mike Cohn “Effective User Stories for Agile Requirements”

