Suchen

Klassisch, agil, und dann? – Teil 2

Agile Ansätze im Requirements Engineering

Seite: 6/9

Agile Techniken: User Stories und Product Backlog

Im Folgenden werden mit den User Stories und dem Produkt Backlog zwei wesentliche Techniken der agilen Ansätze näher erläutert.

User Stories sind eine Alternative zu aufwendigen Methoden wie objektorientierter Analyse und Design oder eines Pflichtenheftes. Anforderungen des Kunden werden am Anfang einer Entwicklung durch User Stories von ihm selbst erhoben und formell dokumentiert, um den Umfang eines Systems zu identifizieren. Dabei notiert er die Benutzerziele z.B. auf eine Karteikarte. Dies können im einfachsten Fall auch nur einer oder zwei Sätze sein. Auf der Rückseite der Story-Karten werden Erweiterungen, sogenannte Akzeptanzkriterien, notiert. Diese eignen sich vor allem für Qualitäten wie z.B. Benutzbarkeit und Performanz.

Bildergalerie

Folgende zusätzliche Informationen werden darüber hinaus erfasst:

  • Nr. oder Identifikation der User Story z.B. durch einen Bezeichner.
  • Priorität (vergeben durch den Kunden) (von 1 bis 10, wobei 1 die höchste Priorität ist, oder hoch, mittel, niedrig).
  • Aufwand zur Implementierung der Anforderung (z. B. in Stunden für ein 2er-Team). Die Schätzung erfolgt durch die Entwickler.

Eine User Story sollte so formuliert sein, dass eine Aufwandsschätzung durch die Entwickler möglich ist. Um diese teamorientiert schätzen zu können, haben sich Story Points etabliert, welche mit verschiedenen Schätzverfahren vergeben werden können. Sofern der formulierte Aufwand zu umfangreich ist, ist dieser auf mehrere Karten aufzuteilen.

Während der Entwicklungsphase können auch neue Anforderungen hinzukommen oder entfernt werden. Aus diesem Grund ist eine fortlaufende Priorisierung, also eine Auswahl der als nächstes zu realisierenden Szenarien, sehr wichtig. Zur Abstimmung der Details muss während der Entwicklung ein Austausch zwischen dem Entwickler und dem Kunden erfolgen können. Darüber hinaus können sich die Anforderungen der User Stories auch während des Projektes ändern.

Im Extreme Programming können Testfälle direkt aus den User Stories abgeleitet werden (Padberg und Tichy, 2007).

Zusammengefasst lässt sich festhalten, dass User Stories sehr leicht zu erstellen sind und ein enger Kundenkontakt gepflegt wird. Nachteilig wirkt sich aus, dass Kunden nicht für die Spezifikation von Anforderungen ausgebildet sind. Die Schätzung des Aufwandes und einen Überblick über das Gesamtsystem zu erhalten, ist schwierig. Darüber hinaus ist diese Methode stark von der Kompetenz der eingesetzten Entwickler abhängig. Nichtfunktionale Anforderungen und Restriktionen sind schwer zu berücksichtigen. Aufgrund der iterativen Ausarbeitung der Anforderungen werden die Karteikarten oft umgeschrieben, somit muss auch der Code häufig umstrukturiert werden.

Produkt Backlog

Das Produkt Backlog beinhaltet alle Anforderungen und Aufgaben die in einem Projekt realisiert werden sollen. Erstellt und aktualisiert wird es durch den Produktverantwortlichen (Product Owner). Ausgangspunkt für das Produkt Backlog ist das Produktkonzept. Alle Einträge sind priorisiert und der jeweilige Aufwand wurde von Team durch Story-Points geschätzt. Diese werden dann zur Planung eines Sprints in Personentage umgerechnet.

Die Priorisierung wird anhand der Markterfordernisse vom Produktverantwortlichen durchgeführt, hier spielt die technische Realisierbarkeit eine untergeordnete Rolle. Darüber hinaus sind dem Produkt Backlog auch die Inhalte der einzelnen Inkremente und Releases zu entnehmen.

Sofern während eines Sprints oder im Sprint Review neue Anforderungen oder Ideen festgestellt werden, sind diese in das Produkt Backlog zu übernehmen, um sie anhand ihrer Priorisierung in einer der nächsten Sprints umzusetzen.

Artikelfiles und Artikellinks

(ID:42704398)