Upload
buibao
View
241
Download
0
Embed Size (px)
Citation preview
Seite 1 von 21
Scrum–aufdemBierdeckelerklärtBegriffe,Konzepte,Grundverständnis
Dezember2015,Version1
Seite 2 von 21
Über diesen Artikel DieserArtikelführtinScrumein.ErerläutertdiegrundlegendenBegriffeundKonzepteunderläutert,wiediesezusammenhängen.DieScrum-MechanikistnurdieeineSeitederMedaille.DiedahinterstehendenWerteundPrinzipiensindmindestensgenausowichtig.DaherfindetsichnachderScrum-EinführungeineBeschreibungdesagilenManifestes,dasdieagilenPrinzipiendefiniert.DanachfindetsicheineÜbersichtüberdieScrum-Rollen,-Artefakteund–Meetings,diezumNachschlagengeeignetist.
DerArtikelhilftdemScrum-Neuling,sicheinenerstenÜberblicküberdieFunktionsweisevonScrumzuverschaffen.DiesesGrundverständnisdientalsOrientierungshilfefürdieweitereVertiefunginScrum,diedurch Scrum-Einführungsbücher1oder Schulungen2erfolgen kann. Auf keinen Fall sind Sie nach derLektüre dieses kurzen Artikels in der Lage, Scrum einzuführen. Den Abschluss des Artikels bildet einAbschnittzudenHerausforderungenbeiderScrum-Einführung.
StefanRoock
CEOundManagement-Beraterbeiit-agile
[email protected],Tel.0172/4297617
1z.B.StefanRoock,HenningWolf:„Scrum-verstehenunderfolgreicheinsetzen“2z.B.http://www.it-agile.de/schulungen
Seite 3 von 21
Inhalt
SCRUM–DREIPERSPEKTIVEN 4
PRODUKTPERSPEKTIVE 5
ENTWICKLUNGSPERSPEKTIVE 7
VERBESSERUNGSPERSPEKTIVE 8
DASAGILEMANIFEST 9
ÜBERBLICKÜBERDIESCRUM-ROLLEN,-MEETINGSUND-ARTEFAKTE 11SCRUM-MASTER-AUFGABEN 11PRODUCT-OWNER-AUFGABEN 13AUFGABENDESENTWICKLUNGSTEAMS 13DAILYSCRUM 14SPRINTPLANNING 14SPRINT-REVIEW 15SPRINT-RETROSPEKTIVE 16BACKLOGREFINEMENT 16RELEASEPLANNING 17PRODUCTBACKLOG 17SPRINTBACKLOG 17PRODUKTINKREMENT 18SPRINTBURNDOWNCHART 18RELEASEBURNUPCHART 18
SCRUMEINFÜHREN 20
UNTERSTÜTZUNGDURCHIT-AGILE 21
Seite 4 von 21
Scrum – Drei Perspektiven MankannScrumineinemSatzbeschreiben:
Scrumbedeutet:AutonomeEntwicklungsteamsmitBusiness-Fokus,
dieihrenProzessinBesitzundVerantwortungnehmen.
In diesem Satz werden drei Perspektiven sichtbar,ausdenenmanScrumbetrachtenkann:
1. Die Produktperspektive (Business-Fokus)beleuchtet, wie Produkte definiert undverbessertwerden.
2. Die Entwicklungsperspektive (autonomeEntwicklungsteams) beleuchtet,wie TeamsProdukteentwickeln.
3. Die Verbesserungsperspektive (Prozess inBesitz und Verantwortung nehmen)beleuchtet, wie Zusammenarbeit undProzesseverbessertwerden.
Diese drei Perspektiven werden im das Scrum-Frameworkintegriert,dassoeinfachist,dassesaufeinenBierdeckelpasst(sieheAbbildungrechts)3.
WirbeschreibendiedreidargestelltenPerspektivenindenfolgendenAbschnittenausführlicher.
3Den dargestellten Scrum-Bierdeckel gibt es im it-agile-Shop:http://www.itagileshop.de
Seite 5 von 21
Produktperspektive DieProduktperspektivebeginntmitderProductOwner-Rolle. Der Product Owner verantwortet denProdukterfolg, indem er den Produktnutzen durch diePriorisierung der Produkt-Features optimiert. DerProduct Owner ist derjenige, der die Softwareentwickelthabenmöchte.WenndiesePersondieRolleselbst nicht ausfüllen kann oder möchte, kann sie dieProduct Owner-Rolle vollständig an jemand anderenabgeben. Auf jeden Fallmuss der Product Owner aberbevollmächtigt sein, die Produktentscheidungen zutreffen. Man kann sich den Product Owner auch alsUnternehmerimUnternehmenvorstellen.
FürdenProductOwnergiltdasHighlander-Prinzip:„Eskann nur einen geben.“ Die Rolle kann in Scrum nichtvonmehrerenPersonengeteiltwahrgenommenwerdenundschongarnichtdurcheinKomitee.Manmöchte inScrum, dass der Product Owner mit einer StimmegegenüberdemTeamunddenStakeholdernsprichtundEntscheidungenschnellfällenkann.
Der Product Owner verfolgt eine Produktvision.Passend zur Produktvision pflegt der Product OwnereinProductBacklog, indemdieProdukteigenschaftenbeschriebensind,diefürdenProdukterfolgnotwendigerscheinen. Das Product Backlog wird durch denProduct Owner priorisiert und durch dasEntwicklungsteamgeschätzt.
Scrum legt nicht fest, wie genau die Einträge desProduct Backlogs gestaltet sind. Viele Teamsmachengute Erfahrungen mit User Stories: ExemplarischeBenutzungsszenarien aus Sicht eines Benutzers. UserStories haben eine andere Qualität als klassischeAnforderungen. Bei User Stories liegt der Fokusdarauf, ein gemeinsames Verständnis bei allenBeteiligten zu erzeugen und nicht darauf, dass dieBeschreibung vollständig, widerspruchsfrei undkorrektist.
Die Entwicklung erfolgt in Iterationen, die in ScrumSprints heißen. Sprints haben eine immer gleicheLänge vonmax. 4Wochen.Was im Sprint entwickeltwird,wird imSprintPlanning festgelegt.Hierwerdenhochpriorisierte Einträge aus dem Product Backlogausgewählt, von denen das Entwicklungsteammeint,dasssiesie imSprintumsetzenkönnen.DasErgebnisist ein lieferbares Produktinkrement. Ob dasProduktinkrement tatsächlich anKunden ausgeliefertwird, entscheidet der Product Owner. Die imProduktinkrement implementierten Features müssenaberaufjedenFallproduktsreifsein(mind.entwickeltundqualitätsgesichert).
Seite 6 von 21
Das Entwicklungsteam demonstriert dasProduktinkrement im Sprint Review denStakeholdern4, damit diese Feedback zum Produktgeben können. Das Feedback wird vom ProductOwner entgegengenommen und nach seinemErmessenindasProductBacklogintegriert.
Gute Fragen, um nützliches Feedback zu erhalten,sind:
• „Was hindert uns daran, das vorliegendeProduktinkrementproduktivzubenutzen?“
• „Wie kann das vorliegendeProduktinkrementnochwertvollergestaltetwerden?“
4Stakeholder ist in Scrum jeder, der Interesse am Produkt oderEinfluss auf die Entwicklung hat: Kunden, Anwender, Sponsoren,Manager,Betriebsratetc.
Seite 7 von 21
Entwicklungsperspektive Das Entwicklungsteam entwickelt ausgehend vomSprint Backlog ein lieferbares Produktinkrement. DasEntwicklungsteam besteht aus 3-9 TeammitgliedernundenthältalleFähigkeiten,dienotwendigsind,umdasSprintBacklogindasProduktinkrementzuüberführen.Entwickler sind demnach nicht nur Programmierer,sondern je nach Kontext auch UX-Experten, Designer,Handbuch-AutorenoderTester.
DasEntwicklungsteamorganisiertsichselbst.Eswedereine formelle Hierarchie noch herausgehobene RollenoderPositionenimEntwicklungsteam.
Das Entwicklungsteam bestimmt im Sprint Planning,wievielArbeit es indenSprint aufnimmt.Eswendetdas Pull-Prinzip an (es „zieht“ Arbeit in den Sprint).Für die ausgewählten Einträge aus dem ProductBacklog erstellt dasEntwicklungsteameinenPlan fürdie Umsetzung im Sprint. Die ausgewählten Einträgeaus dem Product Backlog zusammen mit demUmsetzungsplanbildendasSprintBacklog.
Das Entwicklungsteam macht so eine Vorhersage(Forecast) darüber, was es im Sprint schaffen kann.Diese Vorhersage soll die Qualität einerWettervorhersage haben. In der Regel sollte dasEntwicklungsteam das liefern, was es eingeplant hat.Es sollte aber niemand übermäßig überrascht sein,wenndashinundwiedernichtklappt.
Während des Sprints treffen sich die Teammitgliederwerktäglich zum Daily Scrum, um sich über denArbeitsfortschritt und die nächsten Aufgaben imSprint abzustimmen. Dazu kommen dieTeammitglieder jeden Werktag zur gleichen Uhrzeitam immer gleichen Ort für maximal 15 MinutenzusammenundbeantwortendreiFragen:
1. Was habe ich seit dem letzten Daily Scrumerledigt,dasunsdemSprintzielnäherbringt?
2. Welche Hindernisse sehe ich auf dem WegzumSprintziel?
3. Wasplane ich,biszumnächstenDailyScrumzu erledigen, das uns dem Sprintzielnäherbringt?
DerProductOwner ist ein optionalerTeilnehmer amDailyScrum.
Seite 8 von 21
Verbesserungsperspektive Der ScrumMaster ist ein Coach für alle Beteiligten. Ersorgtdafür,dassProductOwner,dasEntwicklungsteamund Manager verstehen, wie Scrum funktioniert undhilftIhnen,Scrumeffektivanzuwenden.GegenüberdemEntwicklungsteamschafftereinenRahmen,indemsichdasTeamselbstorganisierenkannundhältdemTeamimmer wieder den Spiegel vor. Der Scrum Masterkümmert sich außerdem darum, dass Hindernisseidentifiziert und beseitigt werden. Er moderiert dieScrum-Meetings.
Der kontinuierliche Verbesserungsprozess ist beiScruminzweiMeetingsverankert.ZumeinennehmenVerbesserungen ihrenAusgang imDailyScrum,wennHindernisse identifiziert werden. Hindernisse sind inScrum alles, was die Arbeit an aktuellen Aufgabenblockiert oder verlangsamt. Der Scrum MasterkümmertsichumdieBeseitigungderHindernisse.Dasbedeutetnurselten,dasserdasHindernisalleineausder Welt schafft. Er wird dazu in der Regel mitweiteren Parteien im Unternehmen interagierenmüssen (z.B. um finanzielle Mittel für schnellereRechnungzubeschaffen).
AmEndedesSprintsfindetnachdemSprintReviewdie Sprint Retrospektive statt. Hier reflektiert dasEntwicklungsteam zusammen mit dem ProductOwner darüber, was im letzten Sprint gut undwaswenigergutgelaufenist.AufdieserBasisdefinierensie Verbesserungsmaßnahmen, die sie im nächstenSprint umsetzen wollen. Die Sprint RetrospektivewirddurchdenScrumMastermoderiert.
Seite 9 von 21
Das agile Manifest Für agile Entwicklung gibt esmit demAgilenManifest5einLeitbilddafür,wasAgilitätbedeutet.
DiesesLeitbildbeginntmitvierWertaussagen:
• IndividuenundInteraktionensindwichtigeralsProzesseundTools
• Laufende Software ist wichtiger alsausführlicheDokumentation
• ZusammenarbeitmitdemKundenistwichtigeralsVertragsverhandlungen
• Reagieren auf Veränderungen ist wichtiger alsPlanbefolgung
Das heißt, obwohlwir dieWerte auf der rechten Seitewichtig finden, schätzen wir die Werte auf der linkenSeitehöherein.
In klassischen Kontexten generieren die Dinge auf derrechtenSeite subjektivwahrgenommeneSicherheit.Wersich an die Prozesse hält und die vorgeschriebenenTools einsetzt, wer jede seiner Tätigkeiten haarkleindokumentiert, wer alle Eventualitäten in Verträgenberücksichtigt undwer sich andenPlanhält, kannbeiProblemennachweisen,dassernichtSchuld ist.Leidergenerierenwir auf dieseWeise in komplexenMärktenkeinen Geschäftswert. In dynamischen MärktenbrauchenwirdieFlexibilität,dieunsdieDingeaufderlinkenSeitegeben.
Dieser Gegensatz erklärt,warum die Einführung agilerVerfahren in der Praxis häufig so schwierig ist. AlleBeteiligten müssen ein Stück dieser „Sicherheit durchStatik“ loslassen, um auf den Kunden und denGeschäftswertfokussierenzukönnen.
Ergänzt werden die vier Wertaussagen durch zwölfPrinzipien, die konkretisieren, wie die Werte sich aufdietäglicheArbeitauswirken:
1. Unsere höchste Priorität ist es, den Kundendurch frühe und kontinuierliche AuslieferungwertvollerSoftwarezufriedenzustellen.
2. Heiße Anforderungsänderungen selbst spät inder Entwicklung willkommen. Agile Prozessenutzen Veränderungen zumWettbewerbsvorteildesKunden.
3. Liefere funktionierende Software regelmäßiginnerhalb weniger Wochen oder Monate undbevorzugedabeidiekürzereZeitspanne.
4. FachexpertenundEntwicklermüssenwährenddesProjektestäglichzusammenarbeiten.
5. Errichte Projekte rund um motivierteIndividuen. Gib ihnen das Umfeld und dieUnterstützung, die sie benötigen und vertrauedarauf,dasssiedieAufgabeerledigen.
6. Die effizienteste und effektivste Methode,Informationen an und innerhalb einesEntwicklungsteams zu übermitteln, ist imGesprächvonAngesichtzuAngesicht.
5http://agilemanifesto.org
Seite 10 von 21
7. Funktionierende Software ist das wichtigsteFortschrittsmaß.
8. Agile Prozesse fördern nachhaltigeEntwicklung.DieAuftraggeber,EntwicklerundBenutzer sollten ein gleichmäßiges Tempo aufunbegrenzteZeithaltenkönnen.
9. Ständiges Augenmerk auf technische ExzellenzundgutesDesignfördertAgilität.
10. Einfachheit-dieKunst,dieMengenichtgetanerArbeitzumaximieren-istessenziell.
11. Die besten Architekturen, Anforderungen undEntwürfe entstehen durch selbstorganisierteTeams.
12. In regelmäßigen Abständen reflektiert dasTeam,wieeseffektiverwerdenkannundpasstseinVerhaltenentsprechendan.
Seite 11 von 21
Überblick über die Scrum-Rollen, -Meetings und -Artefakte
DieserAbschnittgibtprägnanteÜbersichtenundChecklisten für die Rollen 6 , Meetings undArtefakte von Scrum. Diese sollten auf keinenFalldogmatischverwendetwerden.Esgibtnichtdie eine richtige Form, die Meetingsdurchzuführen, die Rollen auszuleben oder dieArtefakte zu gestalten. Dieser Abschnitt kannaber als Kurzreferenz helfen sowie alsStartpunkt, um überhaupt einmal mitirgendetwas anzufangen. Wer Scrum allerdingsnach fünf Sprints immer noch genausopraktiziert, wie es in den Übersichten undCheckliste dargestellt ist, macht etwas falsch:Inspektion und Adaption (Inspect&Adapt) desProzessesfehlt!
Scrum-Master-Aufgaben DieMeetingsmacheninScruminderSummeca.10%derZeitaus.RechnenwirfürdieVor-undNachbereitung noch einmal dieselbe Zeit,verbleibtdocheinerheblicherAnteilArbeitszeit,in denen der Scrum Master sich auf andereWeise nützlich macht. Welche Aufgaben ScrumMaster in der Praxis übernehmen, hängt vomUnternehmen, vom Projekt und von der Reifedes Teams ab. Im Folgenden findet sich eineListe mit Beispielen aus der Praxis. Die fettgesetzten Punkte sind die Aufgaben, die derScrumMasteraufjedenFallwahrnehmenmuss.
Teamebene
1. Gemeinsam mit dem Team
Retrospektiven-Maßnahmenumsetzen
2. Die Entwickler unterstützen, ein besserestechnischesVerständnis zuerwerben,dabeiggf. an Entwicklermeetings teilnehmen undagile Entwicklungspraktiken einführen
6Die Aufgabenlisten für ScrumMaster und Product Ownerbasieren zum Teil auf Vorschlägen unseres Ex-KollegenBerndSchiffer.
(testgetriebeneEntwicklung,kontinuierlicheIntegration,PairProgramming)
3. Gerade für neue Scrum-Teams: demTeam beim Umgang mit Veränderungen
helfen, die beim Umstieg auf Scrum
anstehen
4. Materialnachschub fürs Taskboardorganisieren
5. Einzelgespräche mit Entwicklern führen;generell ein Ohr am Team haben, ummitzubekommen,waslosist
6. Impediments aufnehmen und bei der
Behebung unterstützen: Diese könnenkonkret aus einzelnenEntwicklungsaufgaben resultieren,Teamprobleme sein,Kommunikationsprobleme im Team, mitdem Product Owner oder zu Stakeholdern,sich aber auch auf Organisationsebenebefinden.(WasdarfdasTeam,werstörtdasTeam?)
7. Teammitglieder an die vereinbarten
Spielregelnerinnern
8. Für Festlegung von Teamspielregeln
sorgenunddiesegutsichtbarmachen9. Einzelgespräche mit Teamfokus: Was
brauchstdu im/vomTeam?Wiegehtesdirgerade?Wiezufriedenbistdu?Feedbackandich, Feedback von dir?Wie sehe ich deineRolle im Team und deinen Beitrag fürsTeam?WostehstdudemTeamimWeg?Wokönntest du dich mehr einbringen?(Empfehlung: Einzelgespräche alle zwei bisdrei Wochen mit jedem TeammitgliedinklusiveProductOwnerführen.)
10. Aha-Momente oder Leidensdruck
erkennen als Initialpunkt für sofortige
Veränderung (nicht immer nur Input fürRetrospektiven,oftauchdirektumsetzbar)
11. Netzwerk durchforsten für Ideen, wie manProbleme/Herausforderungen des Teamslösenkönnte(Optionenschaffen)
12. BeurteilungderSituationmitScrum-Master-Kollegen, Coaches oder Netzwerkdiskutieren, um wach zu bleiben und nichtauf die eigene Perspektive beschränkt zubleiben
13. InformativenWorkspace gestalten bzw. dasTeamanregen,ihnzugestaltensowieaktuellundhilfreichzuhalten
14. Organisatorische Aufgaben wie das BuchenvonMeetingräumenetc.(abernichtso,dassdie Teammitglieder das nicht mehr selbstkönnen)
Seite 12 von 21
15. Social Events für das Team-Buildingorganisieren (das kann auch das BestärkenvonKollegensein,diedanndieOrganisationübernehmen)
16. Auf Missstände hinweisen, selbst wenndieseerstmal fürdasTeamkeingroßes
Problem zu sein scheinen (Beispiel:Sprints werden nicht geschafft, was dasTeam zwar nicht so dramatisch findet, derScrum Master oder die Stakeholder aberschon.)
17. Konfliktemoderieren18. Beteiligung an Diskussionen,
insbesondere um zu helfen, mehr
Optionen zu schaffen und auf Daten
aufmerksam zu machen sowie
Beobachtungenwiederzugeben (auchmalauf Gutes hinweisen, also Dinge, die schongutlaufen)
19. Sessions zum ThemaEigenverantwortlichkeitorganisieren
20. Die Erstellung eines Teamvertrags
moderieren
21. DemTeamhelfen,Akzeptanzkriteriendirektin testbare Form zu bringen und dannentsprechendautomatisiertzutesten
22. In Konfliktsituationen Einzelgespräche mitTeammitgliedernführen
23. DasTeamvorunerwünschtenEinflüssenvon außen schützen, also z.B.Teammitgliedern den Rücken stärken, dievon ihrem Chef für nicht vereinbartezusätzliche Aufgaben abgezogen werdensollen
TeamübergreifendeOrganisationsebene
24. Unterstützung bei der Organisation vonteamübergreifendem Wissenstransferzwischen Entwicklern, Testern etc.,beispielsweise in Communities of Practice(CoP)
25. Austauschmit anderenScrum-Mastern (z.B.in einer Scrum-Master-CoP, aber auch überCommunity-Events), um überHerausforderungen und Verbesserungen zusprechen und um neue Ideen fürVerbesserungsmaßnahmenzubekommen
26. NeueScrumMasterausbilden27. TeilnahmeanMeetingsundGesprächenmit
ZuliefererndesTeamsoderEmpfängernvonTeamergebnissen gemeinsam mitTeammitgliedern und dem Product Owner,damit das Team optimal in dieGesamtprozesseeingebundenistundimmer
alle nötigen Informationen hat (undweitergibt)
28. Scrum erklären: Rollen,Meetings,Werteerklären für das Team, aber auch für
weitere Personen im Unternehmen oder
beiKunden
29. Wenn es schon halbwegs läuft� mit Scrum,an Organisationsmeetings teilnehmen, diedas Team� betreffen (könnten), umAnregungenfürmehroder� konsequenteresScrum zu geben, die Teambedürfnisse zukommunizieren und um direktereKommunikationmitdemTeamherzustellen
30. Teamübergreifenden Austausch anregen(aufProduct-Owner-undTeamebene)
31. Mit Rat und Tat Fragen zu Scrumbeantworten für das Team und
Außenstehende
32. Mit Managern, Projektleitern,
Teamleitern etc. über Rechte und
Pflichten der Teams sprechen und
darüber,wiedieTeamsgestärktwerden
können
33. Scrum/agilderPersonalabteilungerklären34. Zusammenspiel/Abstimmung zwischen
Teamsverbessern
35. Manager dabei unterstützen, das Team fürschwierigepersonelle SituationenLösungenfinden zu lassen, anstatt selbst Lösungenvorzugeben
36. DieinternenScrumMasterunterstützenundcoachen
37. Änderungen der Team-Zusammensetzungmoderieren
38. DasControllingmitderneuenScrum-WeltinVerbindungbringen
39. Die unternehmensinterne Vernetzung derScrum Master und „Agilen“ über Spartenhinausbegleiten
Anforderungsebene und Product Ownerunterstützen
40. Bei Story-Schnitt und Backlog-
Organisation den Product Owner
unterstützen
41. Den Product Owner beim Stakeholder-Managementunterstützen
42. MitdemProductOwnerundauchmitdenEntwicklern das Schreiben von User
Storiesüben
43. Die Product Owner dabei unterstützen,die Anforderungsflut strukturierter zu
bewältigen
Seite 13 von 21
44. Die Prozessfindung beimPortfoliomanagement der Product OwnerundStakeholderbegleiten
Product-Owner-Aufgaben Die Aufgaben des Product Owners variierenabhängig von Unternehmen und Projekt. Diefolgende Liste enthält Beispiele von Product-Owner-Aufgaben aus der Praxis. Die fettgesetzten Punkte sind die Aufgaben, die derProduct Owner auf jeden Fall wahrnehmenmuss.
Produkteigenschaften
1. Produktvisionerstellen2. Produktvision an Stakeholder und
Entwicklunsteamkommunizieren
3. Schreiben von User Stories (allein, mitStakeholdern,mitdemEntwicklungsteam)
4. Akzeptanzkriterien für User Stories
formulieren (in der Regel zusammen mitdemEntwickungsteam)
5. Ordnen/Priorisieren des Product
Backlogs (inkl. Entscheidung, wasentwickeltwirdundwasnicht)
6. Die bereits entwickelten
Produktinkrementekennen
7. Mit den bereits entwickelten
Produktinkrementen„herumspielen“
8. DieWertschöpfungdesProduktsdefinieren9. DieWertschöpfungdesProduktskennen,
messenundoptimieren
10. Produktbezogene Feedbackschleifeninstallierenundverkürzen
ZusammenarbeitmitdemTeam
11. RefinementdesProductBacklogs (in derRegelzusammenmitdemTeam)
12. Zu großeUser Stories aufsplitten (in derRegel zusammen mit demEntwicklungsteam), sodass sie in Sprintspassen
13. Eine Sprint-Ziel-Skizze in das SprintPlanningmitbringen
14. Hoch priorisierte, gut ausgearbeiteteProduct-Backlog-Einträge in das Sprint
Planningmitbringen15. MitarbeitimSprintPlanning16. Beantwortung fachlicher Fragen des
Entwicklungsteams im Sprint Planning
undwährenddesSprints17. TeilnahmeanDailyScrums18. Teilnahme an und Mitarbeit in Sprint-
Retrospektiven
19. Dem Entwicklungsteam helfen, seinenProzesszuverbessern
20. DefinitionderDefinitionofReadyzusammenmitdemEntwicklungsteam
21. Definition der Definition of DonezusammenmitdemEntwicklungsteam
22. Feedback zu implementierten Featuresan das Team im Sprint oder im Sprint-
Review23. Dem Entwicklungsteam eigene
Unzufriedenheiten deutlich machen und
erklären. Mitarbeit bei der Suche nachLösungen.
24. Dem Entwicklungsteam die relevantenGeschäftszahlen/KPIstransparentmachen
25. Dem Entwicklungsteam verdeutlichen, wiedas Produkt auf dem Markt bzw. bei denKundenankommt
Kunden/Anwender
26. Kundenbedürfnisse verstehen (mitKunden/Anwendernsprechen)
27. DenMarktverstehen28. Ausgewählte Kunden/Anwender in die
Sprint-Reviewsintegrieren
29. Aufsetzen und Durchführen geeigneterErfolgsmetriken (z.B. KundenzufriedenheitüberdenNetPromoterScoremessen)
30. Risikomanagement über die
Ordnung/Priorisierung des Product
Backlogs
31. Annahmen über
Kunden/Anwender/Märkte testen (z.B.miteinemMinimumViableProduct)
ManagementsonstigerStakeholder
32. Dafür sorgen, dass die richtigen
StakeholderzumSprint-Reviewkommen
33. Erstellung und Aktualisierung desReleaseplans
34. AktualisierungdesReleaseBurnupCharts35. Kommunikation von Releaseplan und
ReleaseBurnupChartandieStakeholder36. Stakeholder über neue
Produkteigenschafteninformieren37. Budgetkontrolle
Aufgaben des Entwicklungsteams Die Aufgaben des Entwicklungsteams variierenabhängigvonUnternehmenundProjekt.Waszuden Aufgaben des Entwicklungsteams gehörtund was nicht dazu gehört, wird zum GroßteilüberdieDefinitionofReadyunddieDefinitionofDone formuliert. Die folgende Liste enthält
Seite 14 von 21
Beispiele von Aufgaben des EntwicklungsteamsausderPraxis.DiefettgesetztenPunktesinddieAufgaben, die das Entwicklungsteam auf jedenFallinScrumwahrnehmenmuss.
Arbeitsorganisation
1. Umsetzungsplan im Sprint Planning
erstellen
2. Organisation der Teamarbeit im Daily
Scrum3. PairProgrammingmitTeammitgliedern4. EinarbeitungneuerTeammitglieder
Technisch
5. Produktinkremente programmieren,
testenunddokumentieren
6. Automatisierte Tests (Unit Tests,Integrations-, Last-, Akzeptanztests)erstellenundkontinuierlichdurchführen
7. System- und Softwarearchitektur
erstellen
8. SoftwaretechnischerEntwurf9. AuswahlgeeigneterTechnologienfürdie
Umsetzung
10. Betrieb und Support der entwickeltenSoftware
BezogenaufStakeholder
11. Usability-Testsdurchführen12. UserAcceptanceTestsdurchführen13. Umgebung für Continuous Integration
aufsetzenundamLaufenhalten14. Produktinkremente im Sprint-Review
demonstrieren
15. UserExperiencegestalten16. Bugsbeseitigen
UnterstützungdesProductOwners
17. SchätzungdesProductBacklogs18. Den Product Owner bei der Konzeption
unterstützen.19. Zusammen mit dem Product Owner
Product Backlog Items erstellen und im
Refinementverfeinern
Verbesserung
20. Sich selbst bzw. Technologien, das
Vorgehen und die fachliche Domäne
weiterentwickeln
21. Zusammen mit dem Product Owner dieDefinitionofReadyformulieren
22. Zusammen mit dem Product Owner dieDefinitionofDoneformulieren
Daily Scrum n Ergebnis: Einsatzplanung für das Team für
denTagn Dauer:max.15Minuten(jedenWerktagzur
selbenUhrzeitamselbenOrt)n Teilnehmer: Entwicklungsteam und Scrum
Master; Product Owner optional;Stakeholder optional (Stakeholder dürfenzuhören,abernichtsprechen)
n Vorgehen (dieTeammitgliederbeantwortendreiFragen):• Washabeichgesternerledigt,dasmeinemEntwicklungsteam geholfen hat, dasSprint-Zielzuerreichen?
• Habe ich Hindernisse gesehen, die michoder das Entwicklungsteam daranhindern,dasSprint-Zielzuerreichen?
• Was werde ich heute erledigen, ummeinem Entwicklungsteam zu helfen, dasSprint-Zielzuerreichen?
n Empfehlungen:• Das Daily Scrum findet vor einemphysikalischenTaskboardstatt.
• Die ersten beiden der obigen Fragenwerden einzeln vondenTeammitgliedernbearbeitet.WenndiesebeidenFragenvonjedemTeammitgliedbeantwortetwurden,wirddiedritteFragegemeinsamimTeambeantwortet.
• Hindernisse,diedieWeiterarbeitaneinerUser Story oder einem Task blockieren,werden mit roten Haftnotizen direkt aufden zugehörigen User Stories bzw. Taskskenntlichgemacht.
• Andere Hindernisse werden in der NähedesTaskboardsvisualisiert.
Sprint Planning n Ergebnisse: selektierte Einträge aus dem
Product Backlog, Plan für die Umsetzung,Sprint-Ziel
n Dauer: maximal zwei Stunden pro Sprint-Woche (also vier Stunden für einenzweiwöchigenSprint)
n Teilnehmer: Product Owner, ScrumMaster,Entwicklungsteam, bei Bedarf eingeladeneFachexperten für spezifische anstehendeFachfragen
n Vorgehen:• Der Scrum Master fragt beimEntwicklungsteam die Anzahl der für denSprintverfügbarenPersonentageab.
Seite 15 von 21
• DerProductOwnerstelltseineIdeefüreinSprint-Ziel vor sowie die hochpriorisiertenUserStories.
• Der Scrum Master fragt dasEntwicklungsteam,obdieersteUserStoryin den Sprint passt. Beantwortet dasEntwicklungsteam die Frage positiv, fragtder Scrum Master, ob die zweite UserStoryzusätzlichindenSprintpasst.DiesesVerfahren wird so lange wiederholt, bisdas Team Zweifel hat, ob es noch mehrschaffenkann.
• JetztwirddasSprint-Zielüberarbeitetundfinalisiert. Der Product Owner schätzt ab,obderSprinteinenpositivenROI(Returnon Investment) hat, wenn die gewähltenUser Stories umgesetzt werden können.Wenn dies nicht der Fall ist, geht dasScrum-TeamzurückzumerstenSchritt.
• Dann wird der sogenannte Task-Breakdown durch das Entwicklungsteameingeleitet. Dazu werden Kleingruppenvon jeweils zwei bis drei Entwicklerngebildet.JedeKleingruppewählteinenTeilderUserStoriesausunderstelltdieTasksfürdieUmsetzung.
• Die erstelltenTaskswerden anschließendim Plenum vorgestellt, und es wirdFeedback eingesammelt. Gegebenenfallswird eine zweite RundeKleingruppenarbeitangeschlossen.
• Es wird auf Basis der erstellten Tasksgeprüft, obdie ausgewähltenUser Storiestatsächlich im Sprint umgesetzt werdenkönnen.
• Der Product Owner wird über dasErgebnis der Abschätzung informiert.Gegebenenfalls wird eine User Story ausdem Sprint Backlog entfernt oder eineweitere hinzugefügt. Wenn notwendig,wirddasSprint-Zielangepasst.
n Empfehlungen:• DerBeamerbleibtaus.DerProductOwnerbringtdieUserStoriesaufPapiermit.DieTaskswerdenebenfallsaufPapiererstellt.
• Der Product Owner bleibt während desTask-Breakdown imRaum. (Häufig tretenbei dieser Tätigkeit weitere fachlicheRückfragenauf.)
• Für die Tasks gilt die Regel, dass siemaximal einen Personentag an Aufwandgroß sein dürfen. Tasks müssen alsoentsprechendkleingestaltetsein.
• Mit so kleinen Tasks kann man für diefinale Abschätzung, ob man die UserStories im Sprint schaffen kann, einfachdieTaskszählenundmitdenverfügbarenPersonentagenimSprintvergleichen.
Sprint-Review n Ergebnisse: Klarheit darüber, was am
ProduktmithoherPrioritätnochzu tun ist;Änderungen am Product Backlog; ggf.FortschreibungdesReleaseplans
n Dauer: ca. eine Stunde pro Sprint-Woche(also zwei Stunden für einen zweiwöchigenSprint)
n Teilnehmer: Product Owner, Scrum Master(Moderation), Entwicklungsteam,Stakeholder (insbesondere Kunden undAnwender)
n Vorgehen:• Demonstration des Produktinkrementsdurch das Entwicklungsteam. DieDemonstration erfolgt auf einer vorhervereinbarten Test- undIntegrationsumgebung und nicht aufeinem Entwicklerrechner. Es darf nurgezeigtwerden,wasgemäßderDefinitionof Done komplett erledigt ist. Der ScrumMaster bestätigt, dass die Definition ofDoneeingehaltenwurde.
• Gegebenenfalls Akzeptanz der Featuresdurch den Product Owner (wenn nichtbereitsimSprinterfolgt)
• GegebenenfallsAktualisierungdesReleaseBurnupCharts(sieheunten)
• FeststellungdurchdenProductOwner,obbzw. inwieweit das Sprint-Ziel erreichtwurde
• Sammeln von Feedback zum Produkt;Festhalten des Feedbacks durch denProductOwner
• Feststellen, welches Feedback besondersdringlich ist. Anpassung des ProductBacklogs bezüglich dieses dringlichenFeedbacksdurchdenProductOwner
• Gegebenenfalls Anpassung desReleaseplans
n Empfehlungen:• Der Product Owner sorgt dafür, dass dierichtigen Stakeholder beim Sprint-Reviewanwesendsind.
• Die Demonstration desProduktinkrements basiert auf demSprint-ZielunderzählteineGeschichte,die
Seite 16 von 21
es den Stakeholdern erleichtert, dasGezeigte in einen geeigneten Kontext zusetzen.
• DerScrumMastersorgtdurchModerationdafür, dass die Stakeholder nützlichesFeedbackzumProduktgeben.
• Bei vielen Stakeholdern im Sprint-Reviewsorgt der Scrum Master durch geeigneteTechniken der GroßgruppenmoderationfürdieeffektiveDurchführungdesSprint-Reviews.
Sprint-Retrospektive n Ergebnisse: Verbesserungsmaßnahmen, die
das Entwicklungsteam im nächsten Sprintumsetzenwill
n Dauer:ca.eineStundeproSprintwoche(alsozwei Stunden für einen zweiwöchigenSprint)
n Teilnehmer: ScrumMaster (als Moderator),ProductOwner,Entwicklungsteam
n Vorgehen:• Set the stage: Der Scrum Master eröffnetdie Retrospektive und stellt eineArbeitsumgebung her, in der sich alleTeilnehmerengagierenmöchten.
• Gather data: Die Teilnehmer sammelnqualitative und quantitative Daten überdenletztenSprint.
• Generate insights: Die Teilnehmergewinnen Einsichten darüber, warumbestimmte positive oder negative Effekteaufgetretensind.
• Decide what to do: Die Teilnehmerentscheiden, was sie tun wollen, umnegative Effekte zu beseitigen oder zudämpfen und um positive Effekte zuverstärkenoderzuerhalten.
• Closing: Der Scrum Master beendet dieRetrospektive und sorgt dafür, dass sichjemandumdieErgebnissekümmert.
n Empfehlungen:• Es sollten nur wenige Maßnahmenvereinbart werden, die das Team auchrealistisch im nächsten Sprint umsetzenkann.
• Es sollte auch über Stimmungen undGefühlegesprochenwerden.
• Der ScrumMaster sollte die verwendetenTechnikenvariieren.
• Es sollte geprüft werden, ob dieMaßnahmen der letzten Retrospektive
umgesetztwurdenundwelcheEffektedieMaßnahmengezeigthaben.
Backlog Refinement n Ergebnisse: Product Backlog in einem
aktuellen,aufgeräumtenZustandn Dauer: ca. zwei Stunden pro Sprint-Woche
(häufigjedeWochezweiStundenamselbenWochentag zur selben Uhrzeit; z.B.donnerstags10–12Uhr).
n Teilnehmer: ScrumMaster (als Moderator),Product Owner, Entwicklungsteam,Fachexperten(aufEinladung)
n Vorgehen:• Entfernen obsoleter Einträge aus demProductBacklog
• HinzufügenneuerEinträge indasProductBacklog (Vorstellung der neuen EinträgedurchdenProductOwner)
• Schätzungder neuenEinträge imProductBacklog
• Neuschätzung der Einträge im ProductBacklog,dieeinerNeuschätzungbedürfen
• ÜberarbeitungderPriorisierung• Verfeinerung hoch priorisierter ProductBacklogItemsfürdienächsteneinbisdreiSprints (Product Backlog Items auf eineangemessene Größe aufteilen; fachlicheDetails klären; Akzeptanzkriterienergänzen)
n Empfehlungen:• Es handelt sich um einen Workshop, indem Product Owner undEntwicklungsteam gemeinsam dieVerantwortung für die Vorbereitung dernächstenSprintsübernehmen.
• DerBeamerbleibtaus.DerProductOwnerbringt die Product-Backlog-Einträge aufPapiermit.
• Beim Aufteilen von Product-Backlog-Einträgen arbeiten die Entwickler mit.Auch neue Product-Backlog-Einträgekönnen von den Entwicklern erstelltwerden.
• Akzeptanzkriterien werden gemeinsamzwischenProductOwnerundEntwicklernfestgelegt.
• Das Meeting ist optional und nicht injedem Kontext notwendig bzw. sinnvoll.Experimentieren Sie ggf. mitverschiedenenAnsätzen.
Seite 17 von 21
Release Planning n Ergebnisse: mit den Stakeholdern
abgestimmterReleaseplann Dauer:½bis1Tagn Teilnehmer: ScrumMaster (als Moderator),
Product Owner, Entwicklungsteam (oderTeiledavon),Stakeholder
n Vorgehen:• Vor dem Release-Planning wurde dasinitialeProductBacklogerstellt, geschätztundpriorisiert.
• Der Product Owner stellt dieProduktvisionvor.
• Der Product Owner stellt das priorisierteProductBacklogvor.
• Der Scrum Master oder dasEntwicklungsteam stellt dieEntwicklungsgeschwindigkeit (Velocity)vor.
• Der Product Owner legt Product BacklogItemsgrobaufdieZeitachse.
• Die daraus resultierenden Konsequenzenwerden gemeinsam diskutiert.Gegebenenfalls werden Änderungen anReleasedatum oder Product Backlogvorgenommen.
• Eswirdvereinbart,wiederProductOwnerdie Stakeholder über den Fortschritt imRelease und Änderungen am Releaseplaninformiert.
n Empfehlungen:• DerBeamerbleibtaus.• Das Meeting ist optional und nicht injedemKontextnotwendigbzw.sinnvoll.
Product Backlog n Zweck: Überblick über die noch
ausstehenden Eigenschaften/Features desProdukts
n Eigenschaften:• Einträge beschreiben das Was und nichtdasWie.
• Geordnet(inderRegelnachPriorität)• Hoch priorisierte Einträge sind klein unddetailliertausgearbeitet.
• NiedrigpriorisierteEinträgesindgroßundnurgrobskizziert.
• IstGeschätzt.• Transparent für das EntwicklungsteamunddieStakeholder
• Enthält nur die noch offenenEigenschaften/Features (und nicht diebereitsabgeschlossenen)
n Verwendung:• Ordnung/PriorisierungdurchdenProductOwner
• SchätzungdurchdasEntwicklungsteam• BasisfürReleaseplanungund–Controlling
n Empfehlungen:• DasProductBacklogexistiertphysikalisch(Karteikarten/HaftnotizenanderWand).
• Beschränkungaufmaximal70–80Einträgepro Release (noch besser: ein bis zweiDutzend)
• Unterscheidung in Einträge, die für dasaktuelle Release geplant sind und solchefürspäter(Ideen)
• User Stories und Epics als ProductBacklogs Items (wenn im Unternehmennicht bereits ein anderes gutfunktionierendesFormatetabliertist)
• GruppierungderEinträgenachThemen• Bugs, die nicht sofort beseitigt werden,werdeninsProductBacklogaufgenommenunddurchdenProductOwnerpriorisiert.
Sprint Backlog n Zweck: Überblick über die noch
ausstehendenArbeitenimSprintn Eigenschaften:
• Enthält die für den Sprint ausgewähltenProduct-Backlog-Einträge sowie den PlanfürdieUmsetzung
• Geordnet(inderRegelnachPriorität)• ZeigtdenZustandderPlanumsetzung.
n Verwendung:• Wird im Sprint Planning durch dasEntwicklungsteamerstellt.
• Aktualisierung durch dasEntwicklungsteamimDailyScrum
n Empfehlungen:• DasSprintBacklogexistiertphysikalischinForm eines Taskboards(Karteikarten/Haftnotizen an der Wand)imTeamraum.
• DieReihenfolgeaufdemTaskboardbildetdie Priorisierung der Product-Backlog-Einträgeab.
• Spalten:UserStory,ToDo,Doing,Done• DarstellungvonSprint-ZielundDefinitionofDoneaufdemTaskboard
Seite 18 von 21
• UserStoriesundTasksalsEinträge(wennimUnternehmennichtbereitseinanderesgutfunktionierendesFormatetabliertist)
• Eigene Zeile oben auf dem Taskboard fürungeplante Bugs, die noch im Sprinterledigtwerdenmüssen
Produktinkrement n Zweck:WertschöpfungfürdasUnternehmen
undden/dieKundenn Eigenschaften:
• Lieferbar (gemäßderDefinitionofDone),mindestens:
- funktionsfähig unterProduktionsbedingungen
- qualitätsgesichert- dokumentiert
n Verwendung:• Erstellung und Qualitätssicherung im
SprintdurchdasEntwicklungsteam• Demonstration im Sprint-Review auf
einer vorher vereinbarten Test- undIntegrationsumgebung, um FeedbackzumProduktzubekommen
n Empfehlungen:• Automatisierte Unit Tests und
Continuous Integration als InstrumentezurQualitätssicherung(inkl.Regression)
• Testgetriebene Entwicklung undRefactoring, um bei inkrementellerEntwicklung eine Erosion derEntwurfsqualitätzuvermeiden
• Notwendige Dokumentation über dieDefinitionofDonevereinbaren
Sprint Burndown Chart n Zweck: frühe Einschätzung der
Erfolgswahrscheinlichkeit des Sprints fürdasEntwicklungsteam
n Eigenschaften:• Prognostiziert den weiteren Fortschritt
imSprintaufBasisderbereits imSprinterledigtenArbeit.
• Visualisiert dazu bereits die im SprinterledigteArbeitunddenangenommenenFortschrittfürdenRestdesSprints.
• DieoptionaleIdealliniezeigtdenidealenArbeitsfortschritt, damit Abweichungenfrüh erkannt und diskutiert werdenkönnen.
n Verwendung:• Aktualisierung direkt vor oder im Daily
ScrumdurchdasEntwicklungsteam
• Betrachtung im Daily Scrum, um dasweitereVorgehenimSprintzuplanen
n Empfehlungen:• Handgezeichnet auf DIN A3 oder
Flipchart• HängtdirektnebendemTaskboard.• RestaufwandbasiertaufdenTasks(bzw.
dem Umsetzungsplan für die Product-Backlog-Einträge).
• RestaufwandermittelndurchZählenvonTasks (ohne denOverhead, Reststundenzuschätzen)
• FortgeschritteneTeams,diesehrwenigeProduct-Backlog-Einträge parallel inArbeit haben, können das SprintBurndown Chart auf Basis erledigterProduct-Backlog-Einträge (statt Tasks)führen.
• Das Sprint Burndown Chart ist einoptionales Artefakt. Es ist in langenSprints sehr nützlich und wenigernützlichinsehrkurzenSprints.
Release Burnup Chart n Zweck: frühe Einschätzung des Umfang des
Releases bzw. des Releasetermins für denProductOwnerunddieStakeholder
n Eigenschaften:• Prognostiziert den weiteren Fortschritt
im Release auf Basis der bereitserledigtenProduct-Backlog-Einträge.
• Visualisiert dazu bereits erledigteFeatures und den angenommenenFortschrittfürdenRestdesReleases.
• DieoptionaleIdealliniezeigtdenidealenArbeitsfortschritt, damit Abweichungenfrüh erkannt und diskutiert werdenkönnen.
n Verwendung:• AktualisierungimSprint-Review
Seite 19 von 21
• Betrachtung im Sprint-Review, um dasweitereVorgehenimReleasezuplanen
• Der Restaufwand basiert auf denSchätzungen des Product Backlogs (z.B.StoryPoints).
n Empfehlungen:• Handgezeichnet auf DIN A3 oder
Flipchart• Hängt direkt neben dem Product
Backlog.• Das Release Burnup Chart ist ein
optionales Artefakt. Es ist in langenReleases sehr nützlich und wenigernützlich in sehr kurzen Releases (undkomplett überflüssig beikontinuierlichenReleases).
Seite 20 von 21
Scrum einführen AgileEntwicklungerfordertveränderteVerhaltens-undDenkweisen bei allen Beteiligten. Nur die Scrum-Mechanikzuinstallieren,reichtalsonichtaus.
Die notwendigen Verhaltensänderungen lassen sichnicht über Anweisungen herbeiführen, wienebenstehende Abbildung zeigt. Jeder hat einWertesystem im Kopf. Ein Glaubenssatz könnte z.B.sein: „Vertrauen ist gut, Kontrolle ist besser.“ DiesesWertesystemprägtdas konkreteVerhalten, daswir andenTaglegen,z.B.„Hr.Müller,ichvertraueIhnendieseAufgabe an und möchte, dass sie mir morgen frühBerichtüberdenFortschritterstatten.“DiesesVerhaltenerzeugt im gegebenen Kontext bestimmte Reaktionenund Ergebnisse und prägt damit die Erfahrungen, diewirmachen.SoerfahrenwirvielleichtamnächstenTag,dassHr.MüllermitderihmanvertrautenAufgabenochnicht mal angefangen hat. Diese Erfahrungen wirkenzurück auf unser Wertesystem („Gut, dass ichkontrolliert habe.“). In der Regel haben sich Zyklenentwickeln, in denen sich Werte und Erfahrungengegenseitig verstärken („Nächstes Mal kontrolliere ichambestenhalbtäglich.“).
Die neuen Verhaltensweisen müssen schrittweiseerlernt werden. Ein verändertes Verhalten erzeugteandere Erfahrungen und schließlich ändert sich unserWertesystemimKopf.
Werschonmalversuchthat,abzunehmenodermitdemRauchenaufzuhören,weiß,wieschweresist,angelernteVerhaltensweisen abzulegen. So geraten wir immerwiederinSituationen, indenenwirunswiderbesseresWissen unpassend verhalten. Und selbst wennwir diegewünschteVerhaltensweiseineinerSchulungeingeübthaben, fallen wir in Stress-Situationen häufig wiederzurückinalteVerhaltensmuster.
Coaching(durchdenScrumMasterodereinenexternenScrum-Coach) hilft dabei, Verhalten nachhaltig zuändern. Dazu muss der Coach verstehen, was agileEntwicklung wirklich bedeutet und dazu muss er esbereits praktiziert haben – ansonsten hat der denProzess der Verhaltensänderung selbst noch nichtdurchlaufen.
Für eine erfolgreiche Scrum-Einführungmuss also dasWissen vermittelt und Verhaltensweisen geändertwerden. Eine Kombination aus Schulungen undCoachingistunabdingbar.
Seite 21 von 21
Unterstützung durch it-agile Wir freuen uns, wenn Sie unsere Unterstützung inAnspruch nehmen. Unsere (festangestellte) Berater-Gemeinschaft kumuliert mehrere hundert JahreErfahrung mit agilen Transitionen: Wir haben kleinenUnternehmen mit nur einem Team geholfen, agiler zuwerden und Transitionen mit mehreren tausendMitarbeitern begleitet (wir stellen Ihnen konkreteFallbeispielegerneimpersönlichenGesprächvor).
Dabei beschränkt sich unser Unterstützungsangebotnicht auf die IT oder einzelne Teams. Umden größtenVorteilausagilenAnsätzenzuziehen,solltediegesamteWertschöpfung betrachtet und ganzheitlich optimiertwerden.WirbeziehendaherdieverschiedenenFacettendes Unternehmens und der Wertschöpfung in unsereBeratungundunserCoachingmitein.
Nehmen Sie gerne Kontaktmitunsauf:
StefanRoock
Tel.0172/4297617
http://www.it-agile.de