User-Stories auf Karteikarten – Pro/Contra

Benutzeranforderungen werden im eXtreme Programming (XP) mit Hilfe von Geschichten (Stories) jeweils auf einzelnen Karteikarten dokumentiert. In diesem Artikel wird diskutiert, was die Vorteile und Nachteile dieser Methode sind.

User Stories auf Karteikarten stellen Anforderungen eines Kunden auf eine möglichst einfache Weise dar, indem sie diese, aufgeschrieben auf einen Satz reduziert darstellen. Die nachfolgende Betrachtung geht von physischen Karten aus, obwohl bewusst ist, daß auch eine elektronische Variante existiert.

Vorteile

Karteikarten können innerhalb eines Teams schnell vor Ort erstellt werden, häufig auch mit dem Umstand, in relativ kurzer Zeit eine große Anzahl an Stories zu generieren.

Eine Anforderung wird für jeden Teilnehmer somit anfassbar da es sich nunmehr um ein physisches Objekt handelt. Genauso können Stories aufeinander aufbauen bzw. anknüpfen und somit in kurzer Zeit detaillierte Stories liefern. Aufgrund verschiedener Agglomeration z.B. sprachlich in Form zusammenhängender/ähnlicher Schlagworte oder optisch wenn die Karten gruppiert/umsortiert werden, ist es möglich, schnell solche Anforderungen zu identifizieren die einen hohen Kundennutzen aufweisen. Gleiches gilt umgekehrt betrachtet genauso für Karten die ggf. inhaltlich / optisch / sprachlich für sich alleine stehen.

Stories sind darüber hinaus idealerweise abgeschlossene Szenarien und können so Use-Cases zugeordnet werden bzw. dienen im Falle von Extreme Programming dem Entwickler direkt als Realisierungsgrundlage. Letztendlich sind sie ebenfalls gut nutzbar, um Anforderungen bei den Stakeholdern abzufragen (im Sinne einer Erhebungstechnik).

Nachteile

Jeder Teilnehmer muss die Fähigkeit besitzen zielgerichtet und präzise eine Anforderung zu formulieren – ein Umstand der nicht jedem Menschen liegt. Gerade wenn es Teilnehmer gibt, die an einer solche Anforderungsanalyse noch nie bzw. selten mitwirken.

Nachteilig wirkt sich außerdem aus, dass Geschichten eine informelle Spezifikation darstellen und als Prosatext nicht die strukturierte Anforderungsspezifikation mit der sog. Anforderungsschablone erfüllen. Dafür muss eine Methodik entwickelt werden, die zusammengehörigen bzw. aufeinander aufbauenden Stories zu kennzeichnen.

Es können außerdem schnell sehr viele Stories entstehen, die ggf. aufwendig zu konsolidieren sind. So genannte “falsche” bzw. doppelte Stories müssen frühzeitig erkannt und rausgefiltert werden, damit sie das Team nicht in eine falsche Richtung leiten bzw. behindern. Ein Umstand der sowohl Aufwand als auch Erfahrung bei der Leitung / Koordination von User stories erfordert.

Bezogen auf nachgelagerte Aktivitäten zur Anforderungsanalyse, erschwert die Karteikarte das Suchen bzw. Archivieren (im Gegensatz zur elektronischen Ablage).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert