Agile & DevOps

Agilität in Code gegossen

Agile strukturiert: Von User Story über Planning Poker bis zum Code
2 Kommentare

Es gibt viele Methoden ein agiles Projekt zu führen. Backlog, Scrum und Kanban sind die Gängigsten. Sie funktionieren aber nur dann, wenn schon Aufgaben vorhanden und im Backlog eingepflegt sind. Wie wird aber ein Projekt agil organisiert und wie kann ein agiles Projekt abgeschätzt werden, noch bevor der erste Sprint startet?

In jedem Projekt gibt es die Menschen, die etwas wollen und die, die dieses „Wollen“ umsetzen können. Es ist darum sehr wichtig, dass dieses „Wollen“ richtig ausgedrückt wird. Und niemand kann das besser als der, der will.

Anforderungen müssen präzise beschrieben werden – sie sind das Fundament eines Projekts. Doch wie geht das richtig? Wie schafft man es als wollende Person, etwas für eine andere Person so zu beschreiben, dass diese Maßnahmen ergreifen kann, die gewollte Anforderung in die Realität umzusetzen? Oder einer wollenden Person zu helfen, dass sie die Anforderungen sauber beschreiben kann?

User Stories

User Stories helfen dabei, Struktur in Anforderungen einzuführen. Die Qualität, wie gut eine Anforderung beschrieben und wie leicht verständlich sie für die zu umsetzende Person ist, hängt von der Person ab, die diese User Story schreibt. Die User Story ist besser beschrieben, je mehr diese Person sich mit der User Story identifizieren kann. Daher ist es ratsam, dass der Kunde die User Stories schreibt, indem er sie beispielsweise in ein gemeinsames Wiki (z. B. Confluence) einpflegt.

Kann oder will der Kunde keine User Stories schreiben (was meistens der Fall ist), so sollten diese durch ein Meeting mit dem Kunden erarbeitet werden. Dabei ist es immer ratsam, dass der Kunde sich vorbereitet und zumindest in einer Aufzählungsliste einzelne Anforderungen beschreibt. Im Meeting sollten dann Anforderungen fokussiert durchgearbeitet sowie User Stories erstellt werden. Ein „goldenes Vorgehen“ gibt es in dem Fall nicht, das Einzige was hilft ist: machen.

Syntax einer User Story

Da eine User Story eine Struktur in eine Anforderung bringt, beginne ich mit der Syntax:

#<Nummer> Als <Rolle> möchte ich <Ziel>(, um ) <-- Optional

Kann eine User Story nicht mit dieser Syntax beschrieben werden, dann ist sie zu groß oder zu komplex. In diesem Fall muss versucht werden, die User Story aufzuteilen. Manchmal verstecken sich auch mehrere User Stories in einer. Da hilft dann nur gesunder Menschenverstand, um das zu erkennen und aufzuteilen.

Beispiel

Als Benutzer möchte ich mich mit Facebook, Twitter, Google einloggen können.

wird zu

Als Benutzer möchte ich mich mit Facebook einloggen können.
Als Benutzer möchte ich mich mit Twitter einloggen können.
Als Benutzer möchte ich mich mit Google einloggen können.

Semantik einer User Story

Eine User Story wird somit in die drei folgenden Bestandteile aufgegliedert:

  • Rolle
  • Ziel
  • Grund

Daraus lassen sich semantisch mehrere Komponenten ableiten, die für die spätere Bearbeitung wichtig sind:

  • Rolle | Zielgruppe
  • Ziel | Komplexität | Aufwand
  • Grund | Wirtschaftlichkeit | Dringlichkeit

Jedes Projekt sollte mit der Dokumentation der User Stories beginnen. Auch Projekte, die agile Arbeitsweisen adaptieren, sollten ihre User Stories nachträglich dokumentieren. Wichtig ist, dass diese mit einem Tool so effizient wie nur möglich eingetragen, ausgewertet und überblickt werden können.

Der Aspekt „so effizient wie nur möglich“ ist hierbei ein wichtiges Stichwort. Denn niemand möchte einen Mehraufwand erzeugen oder einen Reibungsverlust durch Kommunikation in der Dokumentation der User Stories haben. Dafür eignen sich gängige Tools wie etwa Confluence oder Jira.

Tipp: Nutzt jegliche Tools, um euch das Leben zu erleichtern.

User Stories helfen auch dabei, dass jeder aus dem Projektteam ein sauberes Briefing über die zu erfüllenden Aufgaben bekommt. Was damals noch ein schwer zu lesendes und ellenlanges Lastenheft war, ist heute eine User Story, die jeder versteht und nachvollziehen kann.

Des Weiteren helfen User Stories dabei, mit dem Kunden eine, wenn nicht dieselbe, Sprache zu sprechen. Wenn es nämlich um die Story #23.2 geht, dann weiß jeder, was gemeint ist – oder kann zumindest in der Dokumentation nachschauen und nachvollziehen, worum es geht. Sowas wird auch „allgegenwärtige Sprache“ genannt (DDD-Entwickler werden mich jetzt dafür hassen, dass ich den Begriff klaue).

Wichtig ist:

  1. Die Dokumentation der User Stories findet statt.
  2. Die Dokumentation der User Stories ist effizient.
  3. Die Dokumentation der User Stories ist vollständig (Kunde hat keine User Stories mehr hinzuzufügen).
  4. Die Dokumentation der User Stories ist einheitlich (folgt der Syntax).
  5. Die Dokumentation der User Stories ist für alle zugänglich (lesen, schreiben).

Zu Punkt 3: Es kann natürlich sein, dass dem Kunden im Nachhinein User Stories einfallen. Dies ist in der agilen Projektorganisation vorerst kein Problem, da der Kunde die neuen User Stories einfach kommunizieren kann. Jedoch muss darauf geachtet werden, dass das Kommunizieren einer User Story nicht der direkten Umsetzung gleicht.

Beispiel

Um beispielhaft zu zeigen, wie so eine Dokumentation der User Stories aussieht, werden die Anforderungen einer fiktionalen To-Do-Applikation benutzt.

# User Story Kunden Prio
1 Als Benutzer möchte ich Tasks auf eine To-Do-Liste schreiben. 1
2 Als Benutzer möchte ich To-Do-Listen mit jemanden teilen. 2
3 Als Benutzer möchte ich To-Do-Listen mit jemanden bearbeiten können. 3
4 Als Admin möchte ich eine Auswertung darüber haben, wie viele Tasks im Durchschnitt pro Tag erstellt werden. 2
5 Als Benutzer möchte ich, dass meine Tasks sicher in der Datenbank abgelegt werden, sodass niemand diese lesen kann. 1
6 Als Benutzer möchte ich so schnell und einfach wie möglich einen Task zu meiner To-Do-Liste hinzufügen. 1

Hier sind sechs verschiedene User Stories, die mit einer Priorität des Kunden vorliegen. Wir halten uns stets an die Syntax und nummerieren jede User Story. Diese Liste würde jetzt beispielsweise in ein gemeinsames Wiki (z. B. Confluence) eingetragen und für alle zugänglich gemacht werden.

Im nächsten Schritt muss geschaut werden, in welcher Reihenfolge die User Stories umgesetzt werden sollen. Bei sechs User Stories ist das erstmal kein Problem. Existieren jedoch 100, so müssen diese irgendwie geclustert und in eine Reihenfolge gebracht werden. Selbst bei sechs User Stories könnte man die Wichtigkeit einer Priorisierung erzwingen, indem gesagt wird, dass ein Release innerhalb von zwei Wochen erfüllt sein muss.

Milestone Prio

Die agile Organisation eines Projektes erlaubt es, die Anforderungen während der Umsetzung flexibel zu halten. Nichtsdestotrotz gibt es in unserer Welt Deadlines und Daten, an denen ein Release erfolgen muss. Dafür sind agile Methoden jedoch nicht ausgerichtet. Diese gehen in erster Linie davon aus, dass Sprint für Sprint eine Software entwickelt wird, ohne den Blick auf eine weite Zukunft zu richten.

Mit einer Milestone Prio wird genau dieser Blick getan, sodass dem Kunden gesagt werden kann: „Die User Story #1, #3, #5, …, #n schaffen wir bis 01.05 dieses Jahres. Die Milestone Prio ist ein Meeting, an dem am besten mindestens eine Person aus jedem Gewerk teilnimmt – also Design, Product Owner (PO), Backend, Frontend und Konzept und weitere.

Die Teammitglieder sollten sich selbst auf die Milestone Prio vorbereiten, indem sie die User Stories durchlesen.

Der PO bereitet die Milestone Prio vor, indem jede User Story auf ein DIN A5 (A6) Blatt ausgedruckt wird. Der Ausdruck sollte etwa 2-3cm Seitenrand besitzen, sodass weitere Notizen vorgenommen werden können. Innerhalb des Rahmens wird dann links oben die User Story Nummer, rechts oben die Kunden Prio und darunter in den Rest des Platzes bis zum Rahmenende die User Story reingeschrieben. Folgende Abbildung zeigt anschaulich solch ein Blatt.

Eine beispielhafte User Story aus der Milestone Prio

Wenn die Milestone Prio stattfindet, sollte ein Tisch komplett frei geräumt werden, sodass auf diesem gearbeitet werden kann. Auf dem Tisch werden unten Monate oder Kalenderwochen auf etwa gleich große Blätter geschrieben und hingelegt (alternativ auch einfach Post-Its). Welche Skalierung man hier nutzt, hängt von der Projektdauer ab.

Nun gehen die Teammitglieder die einzelnen User Stories durch und vergeben unabhängigen User Stories links oben in den Rahmen einen dicken Punkt; also denen, die von keiner anderen User Story abhängig sind. Rechts oben kommt ein dicker Anfangsbuchstabe des Gewerks hin, falls diese User Story nur von einem Gewerk erfüllt werden kann (meistens Implementierung wie Technik).

Unterhalb der User Story kommen nun die Abhängigkeiten zu anderen User Stories hin. Dabei sollten stets die Nummer der User Story und eine kurze Beschreibung (mit ein paar Worten) der User Story vorhanden sein, damit nicht ständig hin und her geschaut werden muss. Hierbei wird noch nicht priorisiert.

Im nächsten Schritt werden nun alle User Stories, die vom Kunden als Prio 1 gesetzt worden sind, ganz links und untereinander hingelegt. Alle User Stories, die keine Abhängigkeit haben, also einen großen Punkt links oben, kommen ganz oben links hin. Alle User Stories, die eine Abhängigkeit haben, kommen unter die unabhängigen Prio-1-User-Stories. Nun werden die Abhängigkeiten nach und nach aufgelöst. Also hat beispielsweise die User Story #5 eine Abhängigkeit zur User Story #1, dann wird die User Story #5 nach der #1 gelegt. Hat eine User Story #3 eine geringere Prio als User Story #1, aber User Story #1 ist abhängig von #3, so wird diese vor die #1 gelegt.

Wichtig ist bei der Milestone Prio, dass hier immer mit menschlichen Verstand gehandelt und dennoch Raum für Kreativität gegeben wird. Hat man eine Idee, wie das Vorgehen effizienter gestaltet werden kann, dann macht man das so. Wird geglaubt, dass die Priorisierung des Kunden keinen Sinn ergibt, dann ändert man diese (hier ist jedoch die Dokumentation vom PO wichtig, wieso etwas geändert worden ist).

Tipp: Agilität bedeutet nicht, dass alles nach einem Schema abgearbeitet wird, sondern dass ständig das eigene Vorgehen reflektiert und verbessert wird (iterativ und inkrementell).

Zuletzt werden alle Ergebnisse von einer Person aus dem Team (meistens PO) dokumentiert und wieder für alle zugänglich bereitgestellt.

Die Anordnung von User Stories in einem Prio-Meeting

Weiterhin verfolgen wir das To-Do-Listen-Beispiel. Hier wurden alle User Stories ausgedruckt und auf den Tisch gelegt. Unten wurden Post-Its mit Monatsname und Kalenderwochen versehen.

Oben links befindet sich nun das Ticket, von dem alle anderen abhängig sind. Gibt es mehrere solcher Tickets, können diese gruppiert werden. Gemeinsam hat jetzt das Team eine Priorisierung erarbeitet, bei der User Story #1 als allererstes entwickelt werden soll und anscheinend schafft das Team auch #5 und #6 im Sprint (zweiwöchige Sprints).

Wir sehen hier, dass die Prioritäten des Kunden berücksichtigt werden und wir einen Ausblick bekommen, wann das Team diverse Themen angehen könnte.

Wichtig ist: Das ist lediglich eine sinnvolle Reihenfolge der User Stories. Die Schätzung der einzelnen User Stories kommt im weiteren Verlauf.

Planning Poker

Viele Kunden wollen eine bestimmte Zahl hören: Die Zahl, die aussagt, wie viel nun das Projekt kostet. Bei der agilen Organisation eines Projektes ist es schwierig, eine Verbindlichkeit einzugehen, da das Projekt ja agil sein soll und sich spontan ändern kann. Dies wäre ein Widerspruch in sich.

Was aber gemacht werden kann, ist von 100 User Stories 80 zu priorisieren und für diese einen ungefähren Preis zu nennen. So kann der Kunde entscheiden, ob er bereit ist, das Geld für die 80 User Stories auszugeben. Es ist wichtig, dem Kunden klarzumachen, dass der Preis für den Umfang der gewählten User Stories ist. Soll das Projekt günstiger werden, so verkleinert sich auch der Umfang der User Stories.

Damit dem Kunden eine Zahl genannt werden kann, müssen die User Stories geschätzt werden. Dies funktioniert gut mit einem Planning Poker.

Tipp: Auch beim Planning Poker sollte immer im Hinterkopf behalten werden, dass Schätzungen nur Schätzungen sind und diese nie oder selten dem wahren Wert entsprechen.

Beim Planning Poker setzen sich alle Teammitglieder zusammen. Jedes Teammitglied bekommt entweder gekaufte oder selbst gebastelte „Planning Poker“-Karten. Auf jeder Karte steht eine Zahl der Fibonacci-Reihe (1, 2, 3, 5, 8, 13, …). Der Product Owner bringt die User-Story-Blätter aus dem Milestone-Prio-Meeting wieder mit. Da die meisten Teammitglieder bei der Milestone Prio dabei waren, müssten sie den Umfang und die User Stories kennen.

Nun fängt das Team bei den User Stories an, die links oben in der Milestone Prio waren. Dies hat den Grund, dass diese als aller erstes bearbeitet werden und die nachfolgenden User Stories auf ihnen aufbauen.

Die User Story wird nochmal vorgelesen und Teammitglieder eines Gewerks (z. B. Design) erklären zu der User Story, was gemacht werden muss. Dann legt jedes Teammitglied verdeckt eine Karte auf den Tisch. Diese Karte ist die Schätzung der Stunden oder Tage (je nach Skalierung). Hat jeder eine Karte hingelegt, werden alle Karten aufgedeckt. Nun wird geschaut, wie gut gemeinsam geschätzt worden ist. Weichen die Zahlen stark voneinander ab, muss ausdiskutiert werden, wieso die Zahlen abweichen. Haben sich die Teammitglieder auf eine Zahl geeinigt, wird diese dokumentiert (Tabelle, Jira etc.). Nun fahren weitere Gewerke fort. Dies wird mit allen User Stories gemacht.

Aus den dokumentierten Zahlen kann der PO eine Gesamtschätzung abgeben, indem alle priorisierten User Stories aus der Milestone Prio und alle Schätzungen der User Stories zusammengetragen werden.

Das Schöne an dem Verfahren ist, dass der PO dem Kunden gegenüber argumentieren kann, wie diese Zahlen entstanden sind. Daher ist es auch so wichtig, dass der PO bei beiden Meetings dabei ist und aufmerksam zuhört bzw. sich Notizen macht.

Nun kann ein Angebot (keine Rechnung!) erstellt werden. Die Tabelle mit den User Stories kann separat zum Angebot dazugelegt werden, wobei im Angebot nur noch die Nummern der User Stories stehen und die dazugehörigen Schätzungen. Daraus lässt sich mit dem Stundensatz der Mitarbeiter ein Wert berechnen, der die Leistung und den Preis rechtfertigt.

Festpreis vs. Aufwandsabrechnung

Viele Kunden haben noch den Irrglauben, dass Softwareprojekte mit einem Festpreis auskommen. Entweder gewinnt der Kunde, weil der Dienstleister dann bei einem günstigen Preis einknickt und sich dadurch Überstunden anhäufen oder der Dienstleister gewinnt, weil der Kunde einen so hohen Preis für eine einfache Arbeit bezahlt.

Nehmen wir die Festpreis-Idee auseinander. Auch sei an der Stelle erwähnt, dass wir hier nicht von fertigen Produkten sprechen, also Software, die schon fertig ist und weiterentwickelt wird, sondern von neuer Software, die implementiert werden soll.

Bei einem Festpreis wird der Umfang des Projektes geschätzt und mit dem Stundensatz der Mitarbeiter verrechnet. Hier geht der Dienstleister mit dem Kunden eine Verbindlichkeit ein und umgekehrt. Der Kunde bekommt für einen festen Umfang einen festen Preis, genauso wie der Dienstleister.

IT Security Summit 2019

Sichere Logins sind doch ganz einfach!

mit Arne Blankerts (thePHP.cc)

Hands-on workshop – Hansel & Gretel do TLS

mit Marcus Bointon (Synchromedia Limited)

 

Jetzt kommt aber das Problem: der Festpreis basiert auf Schätzungen und der Umfang basiert auf aktuellem Wollen. Wenn es eine Methode gäbe, Software so voraus zu planen, dass eine Minutenzahl herauskommt, dann gäbe es nur noch Festpreise. Da wir aber alle Menschen sind und unser Wille sich ändern kann und Projekte an Komplexität zunehmen können, was nicht in der Schätzung berücksichtigt wird, sind Festpreise mit einer Schätzung gleichgestellt.

Somit ergibt sich die Frage: Können Projekte auch anders abgerechnet werden?
Und die Antwort ist: Ja.

Denn dafür gibt es Aufwandsabrechnungen. Also eine Rechnung, in der die Aufwände aufgezählt und somit abgerechnet werden. Daher ist es sinnvoll, die Zeiten, die für eine User Story benötigt werden, sauber zu dokumentieren. Diese können dann in einem Leistungsnachweis der Rechnung angehängt werden, damit der Kunde sehen kann, wohin sein Geld fließt. Alles transparent, alles klar, basierend auf Vertrauen.

Wenn der Kunde vorab wissen möchte, wo die Reise mit seinem Geld hingeht, so kann nach dem Planning Poker eine ungefähre Schätzung des Projektes genannt werden. Der Vorteil gegenüber einem Festpreis ist für Dienstleister, dass wenn sie mehr Zeit für eine bestimmte User Story benötigen, das auch bezahlt wird.

Der Nachteil gegenüber einem Festpreis ist jedoch, dass das Geld erst fließt, wenn die Arbeit getan ist. Bei Festpreis-Projekten fließt nämlich das Geld schon weitaus vorher. Der Kunde bekommt ja sein Produkt. Ob er jetzt oder erst danach zahlt, ist egal.

Nichtsdestotrotz können aber partielle Rechnungen erstellt werden. Beispielsweise einmal im Monat, sodass monatlich Geld fließt. So kann alles abgerechnet werden, was schon erledigt worden ist. Das gibt dem Kunden und auch dem Dienstleister Freiraum zu reagieren. Beispielsweise wenn das Geld beim Kunden knapp wird oder der Dienstleister neue Mitarbeiter dazu bekommen hat, sodass der Umfang vergrößert werden kann: Agilität über Inflexibilität.

Task Breakdown

Hat der Kunde nun das Angebot akzeptiert und ist sich über einen ungefähren Preis sowie den Umfang im Klaren, so kann mit dem Projekt begonnen werden. Ab hier verschwimmen nun agile Methoden wie Scrum oder Kanban mit den zuvor vorbereiteten User Stories.

Damit aber wirklich mit Scrum oder Kanban begonnen werden kann, muss jedes Gewerk für sich Tasks (Tickets) anlegen. Denn der PO weiß nicht, welche Schritte benötigt werden, um eine UI zu designen oder das Deployment eines Projekts aufzusetzen. Das wissen die Mitarbeiter am besten, die das selbst bearbeiten werden. Somit sollten in einem Ticketsystem (z. B. Jira) die User Stories schon fertig übertragen worden sein, falls dies noch nicht passiert worden ist. Wichtig ist hierbei auch, dass nicht sofort alle Tickets erstellt werden, sondern die Tickets am besten erst in der Sprint-Planung oder einem vorherigen Meeting erstellt oder einfach als Task bis zur Sprint-Planung eingepflegt werden.

Ab dann können agile Methoden wie Scrum oder Kanban verwendet werden.

Wichtig ist, vergesst nicht, eure Retrospektiven zu machen! Nur diese lassen euch reflektieren und somit besser werden.

Anmerkung: Ich verwende in diesem Artikel das generische Maskulinum. Selbstverständlich kann in jedem Gewerk eine männliche, weibliche oder diverse Person vorkommen.
Danke an Christopher S., der die brillante Idee mit der Auflösung der Abhängigkeiten im Milestone Prio hatte.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

2 Kommentare auf "Agile strukturiert: Von User Story über Planning Poker bis zum Code"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Gast
Gast

Im Abschnitt „Nichtsdestotrotz können aber partielle Rechnungen…“ bricht der letzte Satz ab „Beispielsweise wenn das… ?“.

Ann-Cathrin Klose
Editor

Da hat sich ein Fehler eingeschlichen, ja. Danke für den Hinweis – ist korrigiert!

X
- Gib Deinen Standort ein -
- or -