Sybit agile Ausgabe 4 Agile Softwareentwicklung im Fokus 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 Scrum Dr. F. K. Koschnick, Qualitätsmanagement, Sybit GmbH Der Schlüssel, um Projekte effizient, erfolgreich und zur Zufriedenheit des Kunden durchzuführen, ist ein gutes Projektmanagement. Es gibt viele Ansätze, wie gutes Projektmanagement realisiert werden kann 1. Wir sind den Weg gegangen die agile Projektmanagement-Methode Scrum 2 mit Ideen aus dem eher traditionellen Prozessmodell CMMI for Development 3, zu kombinieren. Damit haben wir nicht nur eine deutlich höhere Transparenz 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ührung von Prozessen nach CMMI und der Scrum-Methodik deutlich 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. Organisationsweit 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 SEI 4 entwickelt, basiert darauf, dass Projekte nach definierten Prozessen durchgeführt werden und ist organisationszentriert. Organisationszentriert bedeutet dabei im Wesentlichen, dass CMMI Mittel in die Hand gibt, um die Prozesse 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 Prozessgebiete des CMMI-Modells mit Hilfe der implementierten Prozesse erreicht werden 5. 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 erstellt 6. Scrum dagegen ist eine sogenannte agile Projektmanagementmethode (kein Prozessmodell!), die nach den Prinzipien des Agilen Manifesto 7 konzipiert wurde. Bei dieser Methode stehen das Projektteam und nicht die Prozesse im Mittelpunkt. Außerdem ist diese Methode projektzentriert. Es wird nicht beschrieben 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 Zusammenarbeit 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 korrespondieren 8. 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 Bordmittel, 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 verbessern. 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 Projektbudget 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 Änderungen 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 diesem 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 Kundenbeziehung 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.' Release Integration Angebot Auftrag / KickOff Sprintplanung Grob-Design detallierte Architektur / Anforderungen Design Implementierung Integration Sprintabschluss / Retrospektive Auslieferung / Release Abb. 1: Übersichtsgrafik über den gesamten Prozess eines agilen Festpreisprojekts 2 Sybit agile Ausgabe 4
Abb. 2: Auszug aus unserer Projekt-Checkliste 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 Projektmanagement 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/2010 6 zu finden. Scrum: Generell achten wir im Projekt darauf, dem Prinzip der Lean-Production 9, das den agilen Methoden zugrunde liegt, zu folgen. Möglichst alles soll der Wertschöpfung dienen. Wir wollen keine Write-Only-Dokumente produzieren. Beispielsweise vermeiden wir, interne Meeting- oder Review-Protokolle anzulegen, weil diese entweder nicht gelesen werden oder (noch schlimmer) weil dadurch wichtige Informationen unsystematisch 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 Projektbeginn) 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 / Kickoff Zusä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 festgelegt. 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 festgelegt. 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 Arbeitsprodukte 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-Integration-Umgebung angelegt. (IPM: SG1, PI: SG1) Sybit agile Ausgabe 4 3
Sprints Sprint-Planung Scrum: 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) Abb. 3: Beispiel eines einfachen Projektplans, der außer Projektoverhead, Go Live Support und Gewährleistung nur die Releases enthält Scrum: Mit Hilfe des Product Backlogs wird eine Release- und Sprint-Planung erstellt. Dabei wird der Kunde in die Priorisierung 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 Projektplan mit Ressourcenzuordnung erstellt. Dieser enthält nur die Releases, bei kleineren Projekten allenfalls die Sprints. Gegen die Releases oder ggf. die Sprints buchen die Projektmitarbeiter 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: Es wird eine Risikoanalyse auf Basis der Anforderungen / Stories und der Stakeholderanalyse durchgeführt. Die Risikoanalyse ist am effektivsten, wenn sie im Team durchgefü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 herausgestellt und werden optimalerweise jeweils in der Mitte eines Sprints durchgeführt. (PMC: SG1, IPM: SG2) 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 eingeholt 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) 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 Geraden ist ein Maß für die Velocity (Implementationsgeschwindigkeit) des Teams. 4 Sybit agile Ausgabe 4
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, moderiert. 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 / Retrospektive Scrum: 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-Owner abgenommen wurde. Eine Abnahme wird nur erteilt, wenn die Implementation und die Integration abgeschlossen bzw. die Dokumentation erstellt ist, die Abnahmekriterien aus dem Product 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 Multiprojektmanagementsystem durchgeführt. Hier können Plan/Ist-Vergleiche der Aufwandszeiten abgerufen werden. Schätzungen des Restaufwands im Multiprojektmanagementsystem werden anhand der Informationen 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äsentationsvorlagen 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 / Release Zusätzlich: Vor jedem Release gibt es eine interne Abnahme. Diese besteht aus der Integration am CI-Server, mit Auswertung diverser Software-Metriken, manuellen Tests, sowie einer formalen Gesamtabnahme durch Product-Owner und Scrum- Master (PI: SG3, VER: SG3, PPQA: SG1). Projektende Zusätzlich: Um auch ein projektübergreifendes Lernen zu ermöglichen, wird am Projektende ein Lessons Learned durchgefü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) Fazit Natü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 Projektmanagementmethode fügt sich also problemlos in die Implementierung 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 ZUM AUTOR 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 verantwortlich. Dr. Friedrich-Karl Koschnick Sybit agile Ausgabe 4 5
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 ausgeschö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 Rollen Ein 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 generischen Rolle. Wenn ich weiß, dass ich User Stories für einen Administrator schreibe, fallen mir schnell einige sinnvolle Stories ein. Wenn ich beispielsweise von einem Benutzer spreche, 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. 6 Sybit agile Ausgabe 4
Zu lange Beschreibung Man sollte darauf achten, dass die Beschreibung der User Story selbst so knapp wie möglich gehalten wird. Wenn die Beschreibung der User Story zu lang ist, kann man meist davon ausgehen, dass sie mit Akzeptanzkriterien vermischt wurde. Eine klare Trennung der User Story und den dazugehörigen Akzeptanzkriterien, 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 Beschreibung 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 detailliert User 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 genau weiß, wie man bestimmte Dinge implementiert haben will. Manch einer wird die Situation kennen, wenn man im Architekturbü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 implementieren und integrieren kann. User Stories werden in Stein gemeißelt Jeder 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 Aufforderung, darüber zu diskutieren und sie gegebenenfalls anzupassen und zu erweitern. Dies gilt insbesondere für die Akzeptanzkriterien, die sich oft erst kurz vor der eigentlichen Implementierung 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 geringfü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 schauen, 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 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 arbeiten muss: neue User Stories hinzufügen, aufteilen, priorisieren und mit dem Team diskutieren. Sybit agile Ausgabe 4 7
Das INVEST Modell wird ignoriert Als Mike Cohn in seinem Buch 1 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 schreiben. Die einzelnen Buchstaben stehen für Independent: Jede User Story sollte (so gut wie möglich) unabhängig von den anderen User Stories sein. Abhängigkeiten zwischen den Stories erschweren die Planung und Priorisierung 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. 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) 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. ZUM AUTOR ZU SYBIT 2011 Sybit GmbH Alle Rechte vorbehalten Fotos: Yuri Arcurs, mikeledray / www.shutterstock.com Mark Löffler Marc 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. Sybit ist führender IT-Dienstleister mit Fokus auf Beratung & Lösungen zur Optimierung von Geschäftsprozessen. Das Unternehmen 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. Sybit GmbH Sankt-Johannis-Str. 1 5 D-78315 Radolfzell Tel. +49 (0) 7732 9508-0 info@sybit.de