Ein Tag im Leben eines Analytikers #2/2*
Smartphone-Stories**
02 - Viele Userstories sind doch super - oder?
Kennen Sie auch folgende Aussagen: „Zu Beginn des Projektes werden die ersten 300 Userstories definiert.“ oder „Hier ist das 1000-seitige Pflichtenheft, jetzt kann die Entwicklung starten.“
Aber was sind diese ersten Anforderungen wert? Ist die richtige Granularität gewählt worden? Sind Goals, Epics oder Userstories – ohne Waste – definiert worden?
Wie erkenne ich, ob mein Pflichtenheft bzw. mein Lastenheft vollständig ist und den richtigen Abstraktionslevel hat?
Eine kurze Begriffsdefinition:
- Goals sind Highlevel-Ziele, z.B.: Markt-, Kunden-, Benutzer- oder Geschäftsanforderungen. Die Frage nach dem „Warum“ wird beantwortet.
- Userstories beschreiben die Anforderungen an eine Software aus Sicht des Anwenders (Als Benutzer möchte ich Funktion um Ziel zu erreichen.).
- Epics sind grobgranulare Produktanforderungen, die für die Realisierung in mehrere Userstories zerlegt werden („Story Decomposition“).
- Waste sind Aktivitäten, die Ressourcen vergeuden und keinen Mehrwert liefern.
- Im Pflichtenheft beschreibt der Auftragnehmer, wie die Anforderungen umgesetzt werden.
Und wie definiert sich jetzt der „richtige“ Abstraktionslevel? Alles im Detail zu erfassen ist gerade am Beginn noch möglich, aber auch nicht unbedingt zielführend.
Ich halte mich – egal welches Vorgehen (agil/traditionell) – dabei an Folgendes:
- Ziel der Anforderungserhebung definieren
- So wenig wie möglich – so viel wie notwendig
- Iterativ
- Timeboxed (= ein festgelegter Zeitrahmen für eine bestimmte Aufgabe)
Also konkret: Wenn ich die ersten Anforderungen für ein großes Vorhaben erhebe, frage ich, wofür diese gebraucht werden – um die Architektur zu definieren, die Kosten zu schätzen oder danach zu entwickeln? Dadurch kann der Abstraktionslevel abgeschätzt werden.
Sobald das Ziel des Erhebens klar ist, heißt es dann reden: Nämlich mit demjenigen, der mit diesen Anforderungen weiter arbeiten muss, um gemeinsam den „richtigen“ Detailgrad zu definieren (so viel wie nötig – so wenig wie möglich).
Zu viele Informationen bereits zu Beginn verhindern, dass man sich auf das Wesentliche konzentriert. Dabei: Iterativ vorgehen und regelmäßig reviewen, damit der vorher definierte Abstraktionslevel passt.
Und immer Timeboxed – das hilft um sich nicht in Details zu verstricken.
* Analytiker erheben Anforderungen bzw. Probleme von Organisationen und ermitteln die optimale Lösung für das Unternehmen. Andere bekannte Rollen in diesem Bereich sind: Entwickler, Tester, Anwender, Projektleiter.
** Smartphone-Stories - ... kurze, für das Smartphone abgestimmte Inhalte
