4
PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation mit Scrum Im Agilen Manifest, welches als Grundlage agiler Soft- wareentwicklung angesehen werden kann, finden sich unter anderem folgende Aussagen: „Menschen und Interaktionen sind wichtiger als Prozesse und Werk- zeuge“ und „Funktionierende Software ist wichtiger als umfassende Dokumentation.“ Bei einer falschen Inter- pretation könnte man zu dem Schluss kommen, dass in Scrum nicht dokumentiert wird bzw. die Mitarbei- ter selbst darüber entscheiden – dies spiegelt sich in entsprechenden Vorurteilen wider. In Unternehmen, in denen Struktur und Dokumentation zwingend notwendig und auch gesetzlich vorgeschrie- ben sind, führt dies schnell zu einer generellen Ableh- nung der Methode. Umso wichtiger ist es daher, sich frühzeitig entsprechende Gedanken zu machen und gerade bei Pilotprojekten solchen Vorurteilen proaktiv entgegenzuwirken. Ausgangspunkt „Definition of done“ Scrum bietet als Ausgangspunkt für Struktur und Doku- mentation eine sogenannte „Definition of done“ (Dod) an. Hier wird festgehalten, wann man im jeweiligen Unternehmen von einer potenziell produktiv einsetzba- ren Software sprechen kann. Das heißt, man legt die unternehmens- und ggf. projektspezifischen Parameter fest, in welcher Form von wem dokumentiert werden muss und welche Tests erfolgen müssen. Das Befül- len dieser „Dod“ ist also in jedem Scrum-Projekt die Grundlage für ein erfolgreiches und auch revisionssi- cheres Erstellen von Software. Strukturen schaffen In fast jedem Unternehmen gibt es Vorgaben, wie Projekte abzuwickeln und welche damit verbundenen Strukturen einzuhalten sind. Betrachtet man ausgehend „Struktur“ und „Dokumentation“ sind zwei Erfolgsfaktoren für Projekte. Spätestens im produk- tiven Einsatz, bei der Wartung und Weiterentwicklung der Software werden Fehler und Lücken in diesem Bereich bestraft. Scrum macht zur erforderlichen Dokumentation jedoch keinerlei konkrete Vorgaben. Bereits vor Projektstart muss man sich Gedanken machen, wie man die Scrum-spezifische Dokumentation optimal mit bereits vorhandenen unternehmensspezifischen Vorgaben verbinden kann. Als Ergebnis muss eine geordnete Struktur entstehen, deren Inhalte alle Anforderungen des Unternehmens an eine potenziell produktiv einsetzbare Software er- füllen. Der Weg dorthin soll in diesem Beitag aufgezeigt werden.

Scrum & Dokumentation: kein Widerspruch - pentasys.de · PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation

Embed Size (px)

Citation preview

Page 1: Scrum & Dokumentation: kein Widerspruch - pentasys.de · PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation

PENTASYS-Blickpunkte

Scru

m &

Do

kum

enta

tion

Scrum & Dokumentation: kein WiderspruchStrukturierte und vollständige Dokumentation mit Scrum

Im Agilen Manifest, welches als Grundlage agiler Soft-wareentwicklung angesehen werden kann, finden sich unter anderem folgende Aussagen: „Menschen und Interaktionen sind wichtiger als Prozesse und Werk-zeuge“ und „Funktionierende Software ist wichtiger als umfassende Dokumentation.“ Bei einer falschen Inter-pretation könnte man zu dem Schluss kommen, dass in Scrum nicht dokumentiert wird bzw. die Mitarbei-ter selbst darüber entscheiden – dies spiegelt sich in entsprechenden Vorurteilen wider.In Unternehmen, in denen Struktur und Dokumentation zwingend notwendig und auch gesetzlich vorgeschrie-ben sind, führt dies schnell zu einer generellen Ableh-nung der Methode. Umso wichtiger ist es daher, sich frühzeitig entsprechende Gedanken zu machen und gerade bei Pilotprojekten solchen Vorurteilen proaktiv entgegenzuwirken.

Ausgangspunkt „Definition of done“Scrum bietet als Ausgangspunkt für Struktur und Doku-mentation eine sogenannte „Definition of done“ (Dod) an. Hier wird festgehalten, wann man im jeweiligen Unternehmen von einer potenziell produktiv einsetzba-ren Software sprechen kann. Das heißt, man legt die unternehmens- und ggf. projektspezifischen Parameter fest, in welcher Form von wem dokumentiert werden muss und welche Tests erfolgen müssen. Das Befül-len dieser „Dod“ ist also in jedem Scrum-Projekt die Grundlage für ein erfolgreiches und auch revisionssi-cheres Erstellen von Software.

Strukturen schaffenIn fast jedem Unternehmen gibt es Vorgaben, wie Projekte abzuwickeln und welche damit verbundenen Strukturen einzuhalten sind. Betrachtet man ausgehend

„Struktur“ und „Dokumentation“ sind zwei Erfolgsfaktoren für Projekte. Spätestens im produk-tiven Einsatz, bei der Wartung und Weiterentwicklung der Software werden Fehler und Lücken in diesem Bereich bestraft. Scrum macht zur erforderlichen Dokumentation jedoch keinerlei konkrete Vorgaben. Bereits vor Projektstart muss man sich Gedanken machen, wie man die Scrum-spezifische Dokumentation optimal mit bereits vorhandenen unternehmensspezifischen Vorgaben verbinden kann. Als Ergebnis muss eine geordnete Struktur entstehen, deren Inhalte alle Anforderungen des Unternehmens an eine potenziell produktiv einsetzbare Software er-füllen. Der Weg dorthin soll in diesem Beitag aufgezeigt werden.

Page 2: Scrum & Dokumentation: kein Widerspruch - pentasys.de · PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation

2 PENTASYS-Blickpunkte

vom klassischen Projektmanagement (z.B. nach IPMA/GPM, Prince 2 und PMI) die vorgegebenen Strukturen mit den dazugehörigen verpflichten-den Dokumenten, so kann man diese auch auf Scrum übertragen bzw. die Scrum-Dokumentation an den notwendigen Stellen ergänzen. Der erste Schritt besteht nun darin, die vorhandenen Dokumentationsstruktu-ren abzubilden und sich im darauffolgenden Schritt zu überlegen, welche Dokumentation bestehen bleibt und welche gezielt durch Scrum-spezifi-sche Dokumente ersetzt oder ergänzt wird.

Zielbeschreibung / Business CaseIm klassischen Projektmanagement bildet zumeist eine Zielbeschrei-bung bzw. ein Business Case die Basis für das Projekt. In Scrum lassen sich diese Inhalte über die Produktidee, die Projektvision und das daraus erstellte initiale Product Backlog fast vollständig ersetzen. In der initialen Product Backlog Version sollten die Themen des Projekts und erste Stories bereits ausformuliert sein. Die wirtschaftliche Betrachtung eines Projekts, welche in einem Business Case beinhaltet ist, ergibt sich in Scrum jedoch erst nach Durchführung des ersten Sprints. Auf Basis der hier erledigten Stories lässt sich entnehmen, welcher Gesamtaufwand zur Erstellung des Gesamtproduktes notwendig ist. Wenn der Auftraggeber/Kunde schon vor dem ersten Sprint eine wirtschaftliche Betrachtung erhalten möchte, so ist diese nach den üblichen Schätzmethoden des klassischen Projekt-managements vorab durchzuführen. Die Schätzung nach Scrum-Metho-dik inkl. der Durchführung eines ersten Sprints liefert jedoch zumeist eine deutlich genauere Einschätzung. Es bietet sich also in jedem Falle an, diese Schätzungen nach dem ersten Sprint entsprechend zu präzisieren.

RessourcenmanagementAusgehend vom klassischen Ressourcenmanagement, dessen Verwal-tung zum Beispiel über MS Project erfolgen kann, kann man dieses sinn-voll durch einen projektspezifischen Teamkalender ergänzen. In diesem wird die Verfügbarkeit der Teammitglieder kombiniert mit der Abarbeitung der Storypoints pro Sprint. Daraus lässt sich dann nach Abschluss eines Sprints eine Prognose treffen, wie viele Storypoints das Team rein rech-nerisch in den kommenden Sprints abarbeiten könnte. Diese Größe sollte jedoch grundsätzlich nur als Orientierungshilfe dienen. Die Entscheidung, wie viele Storypoints (bzw. Stories) in einem Sprint als Commitment mitge-nommen werden, wird immer vom Team am Ende des Sprint Planning 1 getroffen. In direktem Zusammenhang mit dem Ressourcenmanagement steht das Releasemanagement, welches von den Ressourcen und deren Geschwindigkeit direkt abhängig ist1.

RisikomanagementIn vielen Projekten wird ein Risikomanagement durchgeführt. Es beinhal-tet die Risikobewertung mit Eintrittswahrscheinlichkeit, Schadensausmaß, proaktiven und reaktiven Maßnahmen, zusammen mit deren finanzieller Bewertung, welche Kosten eine entsprechende Maßnahme verursachen wird. Dieses Vorgehen lässt sich ohne weiteres mit der Betrachtung von Impediments (eingetretene Behinderungen des Teams) verknüpfen. Einzig proaktive Maßnahmen scheiden aus, da es sich um bereits eingetretene Risiken handelt, welche vorab nicht identifiziert werden konnten. Der Scrum Master bzw. Projektleiter kann also ein und dasselbe Dokument zur Bear-beitung nutzen.1 Aufgrund der Komplexität dieses Themas ist hierzu ein weiterer Artikel geplant.

Page 3: Scrum & Dokumentation: kein Widerspruch - pentasys.de · PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation

PENTASYS-Blickpunkte 3

BerichtswesenDie meisten Unternehmen fordern für die Abwicklung von Projekten eine genau festgelegte Berichterstattung. Auch hier lassen sich diverse Scrum-Dokumente zur Unterstützung und idealen Ergänzung heranziehen. Ein Burndown Chart liefert eine Übersicht, wie viele Storypoints pro Sprint abgearbeitet wurden. Ausgangswert ist dabei die Gesamtmenge der Story-points, die im Product Backlog enthalten waren. In Kombination mit einem Velocity Chart, welches die Entwicklung der Geschwindigkeit der Abar-beitung von Storypoints pro Sprint wiedergibt, ergibt sich ein sehr guter Rückblick und bei fortgeschrittenen Sprints auch ein Ausblick auf die Performance des Teams.Für Lessons Learned lassen sich die Ergebnisse aus den Retrospek-tiven des Teams heranziehen. Dies hat den Vorteil, dass man hier eine gebündelte Teammeinung vorfin-det (nicht nur die des Projektleiters) und die Erkenntnisse aus den Retro-spektiven bereits im eigenen Projekt zur kontinuierlichen Verbesse-rung genutzt werden. Für Wochen- oder Monatsberichte erhält man im Scrum-Prozess über die Daily Scrums und das abschließende Review ausreichende Inhalte, ohne dass weitere Punkte vom Team abgefragt werden müssen.

Technische und fachliche DokumentationJe nach Aufbau und Detailgrad des Product Backlogs und den daraus entstehenden Sprint Backlogs kann man sowohl eine technische als auch fachliche Dokumentation ergänzen oder ersetzen. Im Gegensatz zu schwer-gewichtigen Konzepten steht in einem Sprint Backlog nur das, was am Ende auch umgesetzt wurde. Es ist also Aufgabe des Product Owners mit Unterstützung des Teams, die hier genannten Scrum-spezifischen Arbeits-mittel entsprechend der Ergebnisse aus den zentralen Besprechungsmee-tings (Estimation Meeting, Sprint Planning 1 + 2, Review und auch Daily Scrum) zu ergänzen, zu präzisieren und auf dem aktuellen Stand zu halten. Am Ende eines Sprints und auch des Gesamtprojektes sollten diese Doku-mente 1:1 der vorgenommenen Umsetzung entsprechen, je nach dem vom Unternehmen geforderten Detaillierungsgrad. Der Vorteil ist dabei, dass keinerlei überflüssige Dokumentation an der Stelle erzeugt wird.

Weitere DokumenteEs gibt jedoch auch einige Dokumente, die sich nicht durch Scrum-spe-zifische Dokumente ersetzen lassen. Hierzu gehören zum Beispiel das Organigramm, die Stakeholder Analyse, der Kommunikationsplan und die Rollenbeschreibung. Ein Organigramm ist in einem Projekt mit nur einem Scrum-Team (Product Owner, Scrum Master und Team) natürlich nicht sinn-voll. Oftmals trifft man aber auf komplexere Projekte mit mehreren Scrum-Teams und entsprechendem Überbau (zentraler Product Owner, Lenkungs-

49

64

36,3

76 68

4849

113

149,3

225,3

293,3

341,3

0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

360

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

Sto

rypo

ints

Sprints

Velocity Chart

Velocity

Velocity Prognose

Storypoints gesamt

Storypoints Prognose

Storypoints linear

Page 4: Scrum & Dokumentation: kein Widerspruch - pentasys.de · PENTASYS-Blickpunkte Scrum & Dokumentation Scrum & Dokumentation: kein Widerspruch Strukturierte und vollständige Dokumentation

PENTASYS AGRüdesheimer Straße 980686 MünchenTel.: + 49 89 5 79 52 0

PENTASYS AG, Geschäftsstelle FrankfurtSolmsstraße 4160486 Frankfurt am MainTel.: + 49 69 70 79 83 9 0

PENTASYS AG, Geschäftsstelle KölnDülkenstraße 951143 KölnTel.: + 49 22 03 93 54 87 6

PENTASYS SAS1, Passage du Génie75012 ParisTel.: + 33 (0)1 76 36 02 90

redaktion@blickpunkte.dewww.pentasys.dewww.pentasys.frwww.pentasys.co.uk

©2013 P

EN

TAS

YS

AG

. Stand O

ktober 2013

Die PENTASYS AG mit Sitz in München, Geschäftsstellen in Frankfurt am Main und Köln, sowie dem Tochterunternehmen PENTASYS SAS in Paris, ist ein Beratungs- und Systemhaus, das darauf spezialisiert ist, Geschäfts-prozesse unter besonderer Berücksichtigung spezifischer Kundenbedürf-nisse mit maßgeschneiderten IT-Anwendungen zu optimieren. Das Leistungs-spektrum der ISO-9001/2008 zertifizierten PENTASYS AG reicht dabei von der Bedarfsanalyse über das Projektmanagement bis hin zur Entwicklung und Implementierung der IT-Lösungen, die die Kunden bei der Stärkung ihrer Marktposition unterstützen. 1995 gegründet, beschäftigt PENTASYS heute mehr als 350 Mitarbeiter, die mit ihrer hohen fachlichen Qualifikation, ihrer sozi-alen Kompetenz und der außergewöhnlichen Motivation das ideale Bindeglied zwischen Unternehmen, Geschäftspartnern und Kunden bilden.

Sämtliche Inhalte des Newsletters, auch Konzepte und Design, sind urheber-rechtlich geschützt. Das Copyright/Urheberrecht liegt bei der PENTASYS AG.

Die Blickpunkte sind ein kostenloser Newsletter der PENTASYS AG.

ausschuss u.a.). Hier spricht nichts gegen ein Organigramm, ebenso wie die Aufstellung eines Kommunikationsplans und unter Umstän-den auch einer Rollenbeschreibung. In dieser werden zum Beispiel die Rechte und Pflichten die zentralen Product Owners und die Aufga-benverteilung der weiteren Product Owner festgehalten. Die Pflichten sollten dann auch direkten Einfluss auf die Dod erhalten (Wer hat welche Pflichten zur Erstellung einer produktiv einsetzbaren Software, zum Beispiel Testmat-rix, Testpläne, Dokumentation). Die klassische Stakeholder Analyse geht auch deutlich über die Berücksichtigung der Beteiligten in Sprint Planning 1 und 2 und dem Review hinaus. Es wird das gesamte Projektumfeld beleuchtet und nicht nur die direkt notwendigen Beteiligten.

Übersicht schaffenNicht zu vernachlässigen ist die Ausgestaltung des Teamrooms. Neben den üblichen Arbeits-mitteln wie Taskboard und Sprint Burndown Chart sollte in jedem Falle die Dod aushän-gen, welche auch als eine Art Checkliste für die korrekte Erledigung der Stories gesehen werden kann. Weiterhin ist der Aushang eines Prozess-schaubildes vorteilhaft, um eine schnelle Über-sicht über alle Prozesselemente, Meetings und der beteiligten Rollen zu erhalten.

Die Tool-FrageAnhand der zahlreichen möglichen Dokumente stellt sich die Frage, ob sich der Einsatz eines Tools lohnt. Auf dem Markt gibt es derzeit die unterschiedlichsten Produkte mit den unterschiedlichsten Ausprägungen. Vor der Anschaffung sollte man sich aber grundsätzlich

die Frage stellen, ob es für die unternehmens-spezifischen Ausprägungen geeignet ist bzw. sich entsprechend anpassen lässt. Unabhän-gig von den Anschaffungs-/Lizenzkosten sollte zudem berücksichtigt werden, dass entspre-chende Schulungen notwendig sind. Gerade in einer Pilotphase ist es fraglich, ob diese Kosten gerechtfertigt sind, oder ob man zunächst auf Templates mit einfachen Mitteln (MS Office Produkte) zurückgreift, welche zumeist von den Mitarbeitern bereits beherrscht werden und zur Standardsoftware der Unternehmen gehören. Pentasys hat im Rahmen zahlreicher Projekte solche Templates entwickelt und kontinuierlich verbessert. Ein Start mit Scrum ist damit prob-lemlos möglich.

ZusammenfassungÜberlegen Sie sich anhand der unternehmens-spezifischen Vorgaben, welche strukturellen und dokumentationsspezifischen Vorgaben in Ihrem Unternehmen existieren. Schaffen Sie eine entsprechende Struktur und kombinie-ren Sie die bisherige Dokumentation mit der neuen Scrum-Dokumentation. In regelmäßi-gen Abständen kontrollieren sie den Arbeits-fortschritt und korrigieren Sie ggf. die Abwei-chungen vom IST- zum SOLL-Zustand. Diese Schritte helfen Ihnen entscheidend bei der Durchführung erfolgreicher Scrum-Projekte.

Scru

m &

Do

kum

enta

tion

Johannes Meffert ist bei PENTASYS als Projektlleiter und Coach für agile Metho-den tätig. Ein Tätigkeitsschwerpunkt liegt dabei in der Einführung von Scrum bei Banken und Versicherungen.