sybit ausgabe 4 agile · scrum dagegen ist eine sogenannte agile projektmanagement - methode (kein...

agile Agile Softwareentwicklung im Fokus

Ausgabe 4Sybit agile

In der heutigen Ausgabe erfahren Sie von unserem Qualitätsmanager Dr. Friedrich-Karl Koschnick, wie Sie mithilfe von CMMI und Scrum, Projekte effizient und erfolgreich durchführen. Außerdem erläutert unser Certified Scrum Professional Marc Löffler, was Sie beim Schreiben von User Stories unbedingt vermeiden sollten (ab S. 6). Wir wünschen Ihnen eine spannende Lektüre!

Projektmanagement mit CMMI und ScrumDr. F. K. Koschnick, Qualitätsmanagement, Sybit GmbH

Der Schlüssel, um Projekte effizient, erfolgreich und zur Zu-friedenheit des Kunden durchzuführen, ist ein gutes Projektma-nagement. Es gibt viele Ansätze, wie gutes Projektmanagement realisiert werden kann1. Wir sind den Weg gegangen die agile Projektmanagement-Methode Scrum2 mit Ideen aus dem eher traditionellen Prozessmodell CMMI for Development3, zu kom-binieren. Damit haben wir nicht nur eine deutlich höhere Trans-parenz der Projekte erreicht, sondern auch den Kundennutzen bei der Bearbeitung der Projekte in den Vordergrund gestellt.

Es hat sich klar gezeigt, dass unsere Projekte nach der Einfüh-rung von Prozessen nach CMMI und der Scrum-Methodik deut-lich bessere Ergebnisse liefern als vorher, sowohl in Hinblick auf die Qualität und die Kundenzufriedenheit als auch auf die Einhaltung von Terminen und des Projektbudgets. Organisati-onsweit ist außerdem ein erheblich genauerer Überblick über alle Projekte (Multiprojektsicht) entstanden.

Das Capability Maturity Model Integration, kurz CMMI, ist ein Prozessmodell für die Software- und Hardware-Entwicklung. Es wurde vom SEI4 entwickelt, basiert darauf, dass Projek-te nach definierten Prozessen durchgeführt werden und ist organisationszentriert. Organisationszentriert bedeutet dabei im Wesentlichen, dass CMMI Mittel in die Hand gibt, um die Pro-zesse in der Organisation zu verankern (zu institutionalisieren). Wie die Prozesse aussehen (implementiert sind), darüber gibt es wohlweislich keine Vorschrift im CMMI-Modell. Es müssen nur sogenannte spezifische und generische Ziele für die Prozess-gebiete des CMMI-Modells mit Hilfe der implementierten Pro-zesse erreicht werden5. Das CMMI-Modell in aller Schönheit zu erklären, würde den Umfang dieses Artikels sprengen. Daher haben wir in einem separaten Aufsatz eine kleine, durchaus subjektive Zusammenfassung über CMMI erstellt6. Scrum dagegen ist eine sogenannte agile Projektmanagement-methode (kein Prozessmodell!), die nach den Prinzipien des Agilen Manifesto7 konzipiert wurde. Bei dieser Methode stehen das Projektteam und nicht die Prozesse im Mittelpunkt. Außer-dem ist diese Methode projektzentriert. Es wird nicht beschrie-ben wie Scrum in der Organisation institutionalisiert wird. Die erfolgreiche Anwendung der Scrum-Methode verlangt vom Scrum-Team eine hohe Disziplin. Weiterhin ist es unerlässlich, erfahrene Entwickler im Scrum-Team zu haben. Eine wichtige Grundidee ist es, sich auf die Wertschöpfung zu konzentrieren. Mit anderen Worten, jede Tätigkeit im Projekt muss zum Ziel haben, Mehrwert für den Kunden zu erzeugen. Das wird unter anderem durch eine sehr enge und vertrauensvolle Zusammen-arbeit mit dem Kunden realisiert. Eine gute Übersicht über Scrum findet man in http://www.mountaingoatsoftware.com/topics/scrum.

Wenn es vor einigen Jahren meist durch Missverständnisse, Ignoranz oder Fehlinterpretationen von beiden Seiten, tiefe Gräben zwischen den CMMI-Anhängern und den Anhängern agiler Methoden gegeben hat, so ist dieser „Konflikt“ jetzt entschärft. Mittlerweile gibt es eine Menge Veröffentlichungen darüber, dass agile Vorgehensweisen wie Scrum sehr gut mit den Zielen von CMMI korrespondieren8. Das eröffnet die Chance, die Vorteile der agilen Methoden mit den Vorzügen, die Prozesse nach CMMI bieten, zu kombinieren.

Auf der einen Seite werden eine große Zahl der Ziele, die in den Prozessgebieten von CMMI beschrieben werden, durch Scrum abgedeckt und auf der anderen Seite liefert CMMI die Bordmit-tel, um Scrum in der Organisation zu institutionalisieren. CMMI hilft also, Scrum als Methode in der Organisation zu festigen. Zusätzlich bietet CMMI Anhaltspunkte, um unterbelichtete Aspekte bei Scrum, wie z.B. das Budget-Controlling zu verbes-sern. Und damit kommen wir auch schon zum nächsten Kapitel. Projektmanagement Die Projektmanagementvorgänge, die weiter unten beschrieben sind und aus Praktiken von CMMI und Scrum resultieren, werden bei der Sybit GmbH für Festpreisprojekte durchgeführt. Die typische Größenordnung von Festpreisprojekten liegt bei uns im Bereich von ca. 50 - 2000 Personentagen. Die Bearbeitung eines Festpreisprojekts mit der Scrum-Methode ist eine gewisse Herausforderung, da bei einem Festpreisprojekt das Projekt-budget und der Lieferumfang vorgegeben sind. Der Kunde möchte natürlich im Vorfeld eines Projekts wissen, was er geliefert bekommt, was es kostet und wann Lieferungen erfolgen. Beim Vorgehen nach Scrum dagegen möchte man die genaue Spezifikation der Anforderungen und die detaillierte Projektplanung möglichst lange offen lassen. Das hat für den Kunden den großen Vorteil, auch im Projektverlauf noch Ände-rungen an den Anforderungen vornehmen zu können. Wer weiß denn im Vorfeld des Projekts schon jedes Detail?

Einen Königsweg haben wir noch nicht gefunden, um aus die-sem Spannungsfeld herauszukommen, fester Preis und fester Lieferumfang auf der einen Seite und möglichst hohe Flexibilität (Agilität) auf der anderen Seite. Jedoch gilt: Je enger die Kunden-beziehung und je höher das Vertrauen zwischen Lieferanten und Kunden ist, umso besser gelingt es, trotz Festpreis, einen erfolgreichen Projektverlauf mit hoher Agilität hinzubekommen. Es ist dann im Projektverlauf immer noch möglich, die Priorität von Anforderungen zu ändern oder die Anforderungen selbst zu modifizieren. Sollte durch eine Modifikation ein erhöhter Aufwand entstehen, ist auch ein Tauschen von Anforderungen denkbar. Vielfach hat sich auch ein separates CR-Budget, das bei Bedarf eingesetzt werden kann, bewährt.'

Abb. 1: Übersichtsgrafik über den gesamten Prozess eines agilen Festpreisprojekts

AngebotAuftrag /KickOff

Sprintplanung detallierteAnforderungen

Grob-Design Architektur /Design

Implementierung Integration Sprintabschluss /Retrospektive

Auslieferung /Release

Integration

Release

Sybit agile | Ausgabe 42

Alle im Folgenden beschriebenen Vorgänge, die direkt aus der Scrum-Methodik hervorgehen, sind mit „Scrum“ bezeichnet. Zusätzliche Vorgänge, die wir für ein verbessertes Projekt-management eingeführt haben und bei denen wir uns von CMMI haben leiten lassen, sind mit „Zusätzlich“ bezeichnet. Alle beschriebenen Vorgänge tragen zur Erfüllung der Ziele für die CMMI-Projektmanagementprozessgebiete bis Level 3 bei. Für die CMMI-kundigen oder -interessierten Leser sind die CMMI-Prozessgebiete und Ziele, die unterstützt werden, in Klammern hinter den Vorgängen angegeben. Was sich dahinter verbirgt ist in Ausgabe 3/20106 zu finden.

Scrum: Generell achten wir im Projekt darauf, dem Prinzip der Lean-Production9, das den agilen Methoden zugrunde liegt, zu folgen. Möglichst alles soll der Wertschöpfung dienen. Wir wollen keine Write-Only-Dokumente produzieren. Beispiels- weise vermeiden wir, interne Meeting- oder Review-Protokolle anzulegen, weil diese entweder nicht gelesen werden oder (noch schlimmer) weil dadurch wichtige Informationen unsys-tematisch auf diverse Protokolle verstreut werden. Besser ist es da, gleich Stories im Product Backlog (siehe unten) oder Aufgaben im Issue-Tracker anzulegen. Angebot Scrum: In der Angebotsphase wird ein Product Backlog erstellt, das dann im Projektverlauf weiterentwickelt wird. Auf Basis des Product Backlogs wird eine Aufwandsschätzung durchgeführt. Das Product Backlog ist meist eine simple Excel-Liste und ist das zentrale Arbeitsprodukt im Rahmen der Scrum-Methode. In ihr werden die Anforderungen oder im Scrum-Jargon: die Stories, gepflegt. Diese Liste kann optional (meist bei Projekt-beginn) mit Makros in unseren Issue-Tracker importiert werden. Im Prinzip ist es aber unerheblich, ob das Product Backlog im Projektverlauf als Excelliste oder als Issueliste in einem Issue-Tracker verwaltet wird. (REQM: SG1)

Auftrag / KickoffZusätzlich: Der Auftrag vom Kunden ist gekommen, das Projekt kann starten. Der Geschäftsprozess für das neue Projekt, der in unserer Process Asset Library (PAL) dokumentiert ist, wird ausgewählt, die Rollen im Projekt und das Team werden festge-legt. Eine Checkliste für das Aufsetzen des Projekts führt dabei durch den ausgewählten Prozess. (IPM: SG1, alle Prozessgebiete GP3.1, alle Prozessgebiete GP2.4)

Zusätzlich: Die Kommunikation mit dem Kunden wird festge-legt. Das beinhaltet auch die Festlegung der Ansprechpartner beim Kunden für die Anforderungen. Die Kommunikation mit dem Kunden läuft immer über den Product-Owner, der bei Scrum die Produktverantwortung hat und den Kunden vertritt. Bei uns nimmt er eine ähnliche Rolle wie der Projektleiter ein. Der Kunde stellt den Product-Owner in der Regel nie. Extrem wichtig – insbesondere bei weniger strukturierten Kunden – ist ein klar geregelter Ablauf wie Anforderungen in das Projekt fließen. (PP: SG2, REQM: GP2.7, IPM: SG2) Zusätzlich: Daten- und Konfigurationsmanagement werden definiert. D.h.: Es werden auf einem Laufwerk mit Backup eine definierte Ordnerstruktur, die bei uns für alle Projekte gleich ist, ein Repository und im Issue-Tracker eine Issue-Verwaltung für das Projekt angelegt. Damit sind die Ordnung im Projekt und die Versionierung von Arbeitsprodukten (auch der Arbeits-produkte des Projektmanagements) gewährleistet. (PP: SG2, CM: SG1, alle Prozessgebiete GP2.6)

Zusätzlich: Die Entwicklungsumgebung wird eingerichtet, wenn sie nicht schon vorhanden ist und es wird eine Continuous-Inte-gration-Umgebung angelegt. (IPM: SG1, PI: SG1)

Abb. 2: Auszug aus unserer Projekt-Checkliste

Sybit agile | Ausgabe 4 3

Scrum: Mit Hilfe des Product Backlogs wird eine Release- und Sprint-Planung erstellt. Dabei wird der Kunde in die Priorisie-rung der einzelnen Anforderungen / Stories mit einbezogen. Die Termine für die Releases sind fix (Timeboxing), während sich der Lieferumfang der Releases je nach Projektverlauf in Abstimmung mit dem Kunden ändern kann. (PP: SG2)

Zusätzlich: Auf Basis des Releaseplans wird dann in unserem Multiprojektmanagementsystem ein sehr einfacher Projekt-plan mit Ressourcenzuordnung erstellt. Dieser enthält nur die Releases, bei kleineren Projekten allenfalls die Sprints. Gegen die Releases oder ggf. die Sprints buchen die Projektmitarbei-ter ihre Projektzeiten. Über die Releases oder Sprints ist eine Tracebility zwischen Projektplan und Anforderungen gegeben. (PP: SG2, PMC: SG1, MA: SG1, REQM: SG1)

Zusätzlich: Sind Beschaffungen für das Projekt nötig oder werden Unteraufträge extern vergeben, so werden diese mit einem Beschaffungsplan verwaltet. In der Angebotsphase müssen dann entsprechende Angebote von Unterauftragnehmern ein-geholt worden sein. (SAM: SG1, SG2)

Zusätzlich: Es wird eine Stakeholderanalyse durchgeführt, bei der die Bedürfnisse und Wünsche der relevanten Stakeholder an das Projekt festgestellt werden. Außerdem wird dokumentiert, wer die Projektansprechpartner sind und wer Anforderungen oder Anforderungsänderungen an den Product-Owner geben darf (siehe auch Kommunikation weiter oben). (PP: SG1, GP2.7, PMC: GP2.7, IPM: SG2, GP2.7, REQM: GP2.7)

Sprints

Sprint-PlanungScrum: Auf Basis der Sprint-Vorplanung (siehe weiter unten), bei der einzelne Stories im Product Backlog mit dem Kunden abgeklärt und für den nächsten Sprint priorisiert wurden und aufgrund der Kennzahlen der vergangenen Sprints (Velocity), wird die Sprint-Planung im Team durchgeführt. (PMC: SG1, SG2, REQM: SG1, RSKM: SG2, SG3)

Zusätzlich: Es wird eine Risikoanalyse auf Basis der Anforde-rungen / Stories und der Stakeholderanalyse durchgeführt. Die Risikoanalyse ist am effektivsten, wenn sie im Team durch-geführt wird. Die Risiken werden in einer Risikomatrix mit den üblichen Kennzahlen (Wahrscheinlichkeit und Schwere) bewertet. Bei gravierenden Risiken müssen Gegenmaßnahmen definiert werden. Diese Gegenmaßnahmen können im Rahmen von Scrum durchaus wieder als Stories behandelt werden. Bei den Team-Meetings muss das Thema Risiken immer wieder angesprochen werden. (PP: SG2, RSKM: SG2, SG3)

Sprint (Architektur/Design, Implementation, Integration)Scrum: Regelmäßige Sprint-Vorplanungsmeetings des Product-Owners mit dem Kunden haben sich als Erfolgsfaktor heraus-gestellt und werden optimalerweise jeweils in der Mitte eines Sprints durchgeführt. (PMC: SG1, IPM: SG2)

Abb. 3: Beispiel eines einfachen Projektplans, der außer Projektover-

head, Go Live Support und Gewährleistung nur die Releases enthält

Abb. 4: Beispiel für ein Burn-Down-Chart. Der Restaufwand ist in

Story-Points, was eine Kennzahl für den Aufwand darstellt, über

der Zeit aufgetragen. Jeder Punkt im Diagramm entspricht einem

Sprint. Der Restaufwand wird aus der Summe aller Story-Points

von noch nicht abgearbeiteten Stories berechnet. Die Gerade ist

eine lineare Extrapolation auf den Endtermin. Die Steigung der Ge-

raden ist ein Maß für die Velocity (Implementationsgeschwindigkeit)

des Teams.


Scrum: Sogenannte Daily Scrums (ca. 15-minütige, im Stehen und sehr effektiv abgehaltene Team-Meetings) werden jeden Morgen um die gleiche Uhrzeit abgehalten. Der Scrum-Master, der im Wesentlichen für die Einhaltung des Scrum-Prozesses sorgt und Hindernisse für das Team aus dem Wege räumt, mo-deriert. Die Meetings werden vor dem Scrum-Board abgehalten, an dem sämtliche Stories des aktuellen Sprints in Form von Kärtchen fixiert sind. (PMC: SG1, SG2, IPM: SG2, RSKM; SG2, SG3)

Sprint-Abschluss / RetrospektiveScrum: Während der Projektlaufzeit werden Projektfortschritt und Projekttermine mit einem Burndown-Chart überwacht. Das Controlling findet immer am Ende eines Sprints statt. Der Fertigstellungsgrad einzelner Stories ist entweder 0 oder 100%. Eine Story gilt nur als fertig (100%), wenn sie vom Product-Ow-ner abgenommen wurde. Eine Abnahme wird nur erteilt, wenn die Implementation und die Integration abgeschlossen bzw. die Dokumentation erstellt ist, die Abnahmekriterien aus dem Pro-duct Backlog erfüllt werden und ein Code-Review durchgeführt wurde. (PMC: SG1, SG2, MA: SG2, VAL: SG2, VER: SG2, SG3)

Zusätzlich: Das Budget-Controlling, das die Scrum-Methode nicht liefert, wird mittels Reports aus dem Multiprojektmanagement-system durchgeführt. Hier können Plan/Ist-Vergleiche der Auf-wandszeiten abgerufen werden. Schätzungen des Restaufwands im Multiprojektmanagementsystem werden anhand der Informa-tionen aus Product Backlog und Burndown-Chart erstellt. Für das Management stehen Multiprojektübersichten zur Verfügung, ähnlich einem Projekt-Cockpit. Außerdem gibt es regelmäßige Berichte des Product-Owners mit vordefinierten Präsentations-vorlagen an das Management. (PMC: SG1, MA: SG1, SG2)

Scrum: Der Scrum-Master wacht über den Scrum-Prozess. In der Sprint-Retro werden nach jedem Sprint projektbezogene Prozessverbesserungen diskutiert - Prozesskontrolle leicht gemacht! (PPQA: SG1, PP: GP2.9, PMC: GP2.9, IPM: GP2.9)

Auslieferung / ReleaseZusätzlich: Vor jedem Release gibt es eine interne Abnahme. Diese besteht aus der Integration am CI-Server, mit Auswer-tung diverser Software-Metriken, manuellen Tests, sowie einer formalen Gesamtabnahme durch Product-Owner und Scrum-Master (PI: SG3, VER: SG3, PPQA: SG1).

ProjektendeZusätzlich: Um auch ein projektübergreifendes Lernen zu er-möglichen, wird am Projektende ein Lessons Learned durch-geführt. Dieses wird in einem Projektabschlussbericht, der auch eine Nachkalkulation des Projekts und weitere wichtige Kennzahlen enthält, an das Management weitergereicht. Das

Lessons Learned wird ggf. in der PAL veröffentlicht. (GP3.2 für alle Prozessgebiete)

FazitNatürlich haben wir mit diesen Vorgängen den Verlauf unserer Software-Projekte nicht erschöpfend dargestellt. Es wurde aber ein Querschnitt der wichtigsten Projektmanagementvorgänge in einem agilen Softwareprojekt dargestellt. Scrum als Projekt-managementmethode fügt sich also problemlos in die Imple-mentierung von Prozessen nach CMMI ein und wir kommen mit diesem Traumpaar unserem Ziel, Projekte effizient und effektiv durchzuführen, sehr viel näher.

Unsere Erfahrungen mit dieser Kombination sind sehr positiv. Es wurde nicht mehr am Kunden vorbeientwickelt. Termine wurden definitiv besser gehalten und auch Budgetüberzüge sind seltener geworden. Die Projekte sind für das Management erheblich transparenter und der Prozess vom Angebot bis hin zur Faktura läuft definierter und damit geordneter ab.

Quellennachweis

[1] http://www.gpm-infocenter.de,

http://www.sei.cmu.edu,

http://agilemanifesto.org

[2] http://www.mountaingoatsoftware.com,

http://www.scrumalliance.org

[3] http://www.sei.cmu.edu/cmmi

[4] http://www.sei.cmu.edu

[5] http://www.sei.cmu.edu/cmmi/tools/dev/download.cfm

[6] http://www.sybit.de/de/industry/sybit-agile/CMMI_als-_Leitfaden_

nicht_als_Gaengelband.html

[7] http://agilemanifesto.org

[8] http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm,

http://www.agile2007.org/agile2007/index.

php%3Fpage=sub%252F&id=425.html

[9] http://wirtschaftslexikon.gabler.de/Definition/lean-production.html

Dr. Friedrich-Karl Koschnick ist promovierter Physiker. Er hat Erfahrung als Software-Entwickler und Entwicklungsleiter, ist CMMI-Assessor und zertifizierter Scrum-Master. Bei der Sybit GmbH ist er für das Qualitätsmanagement und für das Projekt-Controlling verant-wortlich.

ZUM AUTOR

Dr. Friedrich-Karl Koschnick


In agilen Projekten setzen sich User Stories mehr und mehr als Basis für das Product Backlog durch. Auf den ersten Blick scheint es sich dabei um ein einfaches Konzept zu handeln und doch werden bei der Anwendung viele Fehler gemacht, die es verhindern, dass das volle Potential von User Stories ausge-schöpft wird. Im Folgenden werden wir auf die häufigsten Fehler im Umgang mit User Stories eingehen und mögliche Lösungen im Kontext von Scrum ansprechen.

Fehlende RollenEin häufiger Fehler ist eine fehlende Rollendefinition. Sowohl aus Sicht der Applikation selbst, als auch aus der Sicht der User Stories, ist es wichtig, möglichst alle relevanten Rollen

zu definieren. Es ist viel leichter, aus der Sicht einer konkreten Rolle eine User Story zu schreiben, als aus der Sicht einer ge-nerischen Rolle. Wenn ich weiß, dass ich User Stories für einen Administrator schreibe, fallen mir schnell einige sinnvolle Sto-ries ein. Wenn ich beispielsweise von einem „Benutzer“ spre-che, wird nicht klar, um wen es sich hier konkret handelt und was dieser Benutzer alles können soll und darf. Ein weiterer Vorteil von konkreten Rollen ist, dass ich auch nach Wochen und Monaten, auf einen Blick verstehe, um was es in der User Story geht. Bevor man also damit beginnt, User Stories zu schreiben, sollte man sich die Zeit nehmen und alle Rollen im Kontext der Applikation definieren.


Zu lange BeschreibungMan sollte darauf achten, dass die Beschreibung der User Story selbst so knapp wie möglich gehalten wird. Wenn die Beschrei-bung der User Story zu lang ist, kann man meist davon aus-gehen, dass sie mit Akzeptanzkriterien vermischt wurde. Eine klare Trennung der User Story und den dazugehörigen Akzep-tanzkriterien, erhöht die Lesbarkeit und das Verständnis. Hier ein Beispiel:

„Als Administrator will ich die Profile der Benutzer editieren

können, indem ich in die Administrationsoberfläche gehe, dort den

Benutzer in einer Liste auswähle und im Kontextmenü, welches

beim Betätigen der rechten Maustaste aufklappt, „Editiere Profil“

auswähle, damit ich in der Lage bin die Profile der Benutzer ggf.

anzupassen.“

Hier kann man sehr schön sehen, wie die eigentliche Beschrei-bung bereits mit Akzeptanzkriterien vermischt wurde. Besser ist es so:

„Als Administrator will ich die Profile der Benutzer editieren können,

damit Änderungen an den Benutzerdaten vorgenommen werden

können.“

Die Beschreibung enthält also lediglich das „Was“, während in den Akzeptanzkriterien das „Wie“ erläutert wird.

Zu früh zu detailliertUser Stories sollten erst dann detailliert werden, wenn sie kurz vor der Implementierung stehen, nicht vorher. Leider lässt sich das nicht immer verhindern, denn gerade in Festpreisprojekten muss man von Anfang an wissen, was genau zu implementieren ist. Und doch hat sich gezeigt, dass zu viel Detail am Anfang wenig Sinn macht, weil man oft erst im Laufe des Projekts ge-nau weiß, wie man bestimmte Dinge implementiert haben will. Manch einer wird die Situation kennen, wenn man im Architek-turbüro sein Haus bis ins letzte Detail geplant hat und dann im fertigen Haus feststellt, dass der Lichtschalter/die Steckdose an einer anderen Stelle mehr Sinn gemacht hätte. Erst wenn man ein Teil der Applikation wirklich vor sich sieht, bekommt man ein Bild, wie man die neue Funktionalität am besten implementie-ren und integrieren kann.

Das optimale Product Backlog enthält genau so viel detaillierte User Stories, dass es für die nächsten 1-2 Sprints reicht. Eine solche User Story sollte nur so groß sein, dass sie innerhalb eines Sprints abgearbeitet werden kann. Zugleich bedeutet das, dass der Product Owner ständig mit dem Product Backlog ar-beiten muss: neue User Stories hinzufügen, aufteilen, priorisie-ren und mit dem Team diskutieren.

User Stories werden in Stein gemeißeltJeder User Story liegt ein Versprechen zu Grunde und zwar das Versprechen zur Konversation („A promise for conversation“). Dieses Versprechen ist der Kern des User Story Konzepts und wird doch oft ignoriert. Genau hier liegt aber die eigentliche Stärke. Oft werden User Stories wie normale Anforderungen behandelt, die meist fix und unabänderlich sind. Zwar definieren auch User Stories Anforderungen, allerdings verbunden mit der Auffor- derung, darüber zu diskutieren und sie gegebenenfalls anzu-passen und zu erweitern. Dies gilt insbesondere für die Akzep-tanzkriterien, die sich oft erst kurz vor der eigentlichen Imple-mentierung der Story klar abzeichnen. Bei Scrum bspw. werden die Akzeptanzkriterien im Sprint Planning Meeting finalisiert, also kurz vor der Implementierung. Aber selbst nach dem Sprint Planning kann es sein, dass sich die Akzeptanzkriterien gering-fügig ändern, sobald die ersten Ergebnisse sichtbar werden.

Damit die Konversation stattfindet, ist es wichtig, diese von Anfang an zu fördern, sowohl während der Sprint Plannings als auch während des eigentlichen Sprints. Den Entwicklern muss klar gemacht werden, dass sie jede User Story hinterfragen dürfen und sollen. Nur so wird eine optimale Implementierung sichergestellt. Aus diesem Grund ist es natürlich ein großer Vorteil, wenn der Product Owner beim Team oder zumindest in deren Nähe sitzt. Auch der Product Owner muss dazu animiert werden, so oft wie möglich bei den Entwicklern vorbei zu schau-en, um mit ihnen Implementierungsdetails zu besprechen und die Akzeptanzkriterien gegebenenfalls anzupassen. Eine User Story sollte leben und nicht wie in Stein gemeißelt behandelt werden.


Das INVEST Modell wird ignoriertAls Mike Cohn in seinem Buch1 erstmals das Konzept der User Stories ausführlich behandelt hat, hat er auch das Akronym INVEST eingeführt, das helfen soll, gute User Stories zu schrei-ben. Die einzelnen Buchstaben stehen für

Ì Independent: Jede User Story sollte (so gut wie möglich) un-abhängig von den anderen User Stories sein. Abhängigkeiten zwischen den Stories erschweren die Planung und Priori-sierung der Story. Meist kann man Abhängigkeiten auflösen, in dem man sie entweder mit anderen kombiniert oder in mehrere kleine Stories aufteilt.

Ì Negotiable: Jede Story sollte verhandelbar oder diskutierbar sein. Legt man von Anfang an zu viele Details fest, kann man eine Story nur noch schwer diskutieren.

Ì Valuable: Jede Story sollte einen Mehrwert für den Kunden liefern.

Ì Estimable: Jede Story sollte so klar beschrieben sein, dass die Entwickler in der Lage sind, den Aufwand für die Story zu schätzen. Probleme an dieser Stelle können sein, dass die Story zu groß ist, dann sollte man diese aufteilen oder dass den Entwicklern das Domänenwissen fehlt, in diesem Fall sollte man verstärkt über die Story diskutieren.

Ì Small: Jede Story sollte so klein sein, dass 2–3 Entwickler sie innerhalb einer Woche entwickeln können. Auf keinen Fall sollte eine Story so groß sein, dass sie nicht während eines Sprints implementiert werden kann.

Ì Testable: Jede Story sollte am Ende testbar sein. Man sollte sich immer an die Regel halten, dass man nur das entwickeln sollte, was man auch testen kann. Wenn man eine Story nicht testen kann, weiß man nie, wann man damit fertig ist.

Wenn man sich an die oben genannten Punkte hält, ist man auf dem besten Weg gute User Stories zu schreiben und die Macht der User Stories optimal für sich zu nutzen.

Quellennachweis[1] User Stories Applied: For Agile Software Development (ISBN 0321205685)

© 2

011

Sybi

t Gm

bH ·

All

e R

echt

e vo

rbeh

alte

n · F

otos

: Yur

i Arc

urs,

mik

eled

ray

/ ww

w.s

hutt

erst

ock.

com

Sybit ist führender IT-Dienstleister mit Fokus auf Beratung & Lösungen zur Optimierung von Geschäftsprozessen. Das Un-ternehmen wurde im Jahr 2000 gegründet und realisiert mit derzeit 110 Mitarbeitenden in den drei Geschäftsbereichen CRM, Media und Industry IT-Lösungen auf Basis von Java-, Portal-, Mobile- und SAP Technologien.

Ein hohes Maß an Transparenz für den Kunden und Effizienz in den Arbeitsabläufen schaffen wir durch die Anwendung moderner Projektmanagement-Methoden wie z.B. Scrum.

ZU SYBITMarc Löffler ist Projektleiter und Scrum Coach bei der Sybit GmbH. Er ist Certified Scrum Professional (CSP) und hilft unseren Kunden, agile Vorgehensmodelle wie Scrum und Kanban in ihren Unternehmen zu etablieren und zu verbessern.

ZUM AUTOR

Mark Löffler

Sybit GmbH Sankt-Johannis-Str. 1–5 D-78315 Radolfzell Tel. +49 (0) 7732 9508-0 [email protected]

sybit ausgabe 4 agile · scrum dagegen ist eine sogenannte agile projektmanagement - methode (kein...

Documents