prinzipien scrum ergebnisse - das scrum plakat · product owner sprint backlog product backlog...
TRANSCRIPT
Product owner
Sprint Backlog
Product BacklogScrum Master
Team
Daily Scrum Meeting
Sprint Review
Sprint Retrospective
potenziell auslieferungs-fähiges Produkt
Sprint PlanningMeeting 1 & 2
Sprint
No Changes
Taskboard
Impediment Backlog
Burndown Chart
Meetings
Prinzipien
Scrum
Erg
eb
nis
seP
erso
ne
n
• DerProductOwner(PO)vertrittalleInteressengruppen
außerhalbdesProjektteams
• ErgibtdieVisionvor
• Wasmussentwickeltwerden,umgeschäftlichenErfolgzuhaben?
• DerPOformalisiertdieseAnforderungenineinerListe
vonFeatures,dem„ProductBacklog“
• DieAnforderungenwerdennachGeschäftswertpriorisiert
• ÄnderungenimProductBacklogsindzujederZeiterlaubt
Product Owner
• DasProductBacklog(PBL)beinhaltetalleerwünschtenFeatures
undzulieferndenErgebnisse
• DerPOpriorisiertdieEinträgenachdemgeschäftlichen
NutzenundderBewertungdesRisikos
• Einträgekönnenjederzeitgeändert,hinzugefügtoderentferntwerden
• DasPBListeinkontinuierlichgepflegterPlanum
denmaximalengeschäftlichenNutzenzuerreichen
Product Backlog
• BeinhaltetdieAufgabendienotwendigsind,umdasvereinbarte
Sprint-Zielzuerreichen
• EinträgegruppiertnachPBL-Einträgen
• BildetdieBasisfürdie(Selbst-)OrganisationdesTeams
währenddesSprints
• DarstellungaufdemTaskboard(Post-ito.Ä.)
Sprint Backlog
• DasImpedimentBacklog(IBL)listetdieidentifiziertenHindernisse
• imTeam
• inderOrganisation
• DasTeampriorisiertdasIBL
• DieBeseitigungvonIBL-Einträgenkannzuneuen
AufgabenimSprintBacklogführen
• WirdvomScrumMastergepflegtundverwaltet
Impediment Backlog
• DasBurndownChart(BDC)zeigtdennochzuerbringenden
RestaufwandfürdenaktuellenSprint
• GraphischeDarstellung,wirdtäglichaktualisiert
• SollteamEndedesSprintsaufNullstehen
Burndown Chart
• Voraussetzungistein„sauberes“ProductBacklog.D.h.essollte
• existieren,
• nachGeschäftswertpriorisiertsein,und
• jederEintragsollteeinAbnahmekriteriumenthalten(„howtodemo“)
• AnschließendwerdendieeinzelnenEinträgevomTeambeschätzt
• z.B.mitPlanningPoker
• ProductOwnerstehtfüretwaigeRückfragenbereit
• DasTeamwähltdannsovieleEinträgeausdemPBLaus,
wieesdenktimSprintumsetzenzukönnen
Sprint Planning Meeting 1
• Detailplanung
• EinträgedesSprintBacklogswerdeninAufgaben
vonmaximal1TagAufwandaufgebrochen
• AmEndederPlanungsollmanFolgendeserreichthaben
• ManhateinZielfürdenSprinterstellt
• sichaufeinSprintBackloggeeinigt
• TerminefürSprintReviewunddastäglicheStatusmeetingausgemachtund
• eineListederTeammitgliedersamtderenVerfügbarkeitzusammengestellt
Aber:
• BevoresendgültiglosgehtwirddasSprintBacklognochmalsvom
ProductOwnerabgenommen
Sprint Planning Meeting 2• täglich,stehendvordemTaskboard,immer<15min.
• 3Fragen:
• Washabeichseitgesternerledigt?
• Wasmacheichbismorgen?
• Wasbehindertmich/hatmichbehindert?
• AntwortenbewegenPost-its/AufgabenaufdemTaskboard.
• MeetingimTeamfürdasTeam(nichtzurStatuskontrolle)
• DasTeamaktualisiert
• SprintBacklog
• BurndownChart(WievieleAufgabensindnochzuerledigen?)
• ListederHindernisse(ImpedimentBacklog)
Daily Scrum Meeting
•Präsentationund„Abnahme“derfertiggestelltenProduct-Backlog-Einträge
•ÜberprüfungdesSprint-Zieles
•Präsentationineiner„echten“Umgebung
•FeedbackderBeteiligten,evtl.neueEinträgeimPBL
Sprint Review
• VereinbartesSprint-ZielundSprint-Endewerdennichtverändert
• ErmöglichtdemTeam,füreinengewissenZeitraumungestörtzuarbeiten
• DasProductBacklogdarfzujedembeliebigenZeitpunktgeändertwerden
• DieseÄnderungenwerdenaberfrühestensimnächstenSprintbearbeitet
• BeikritischenEreignissenkannderPOdenSprintabbrechen(unddirektdennächstenSprintstarten)
No Changes• Sprintshabeneinekonstante,vomTeamundPOzuBeginnfestgelegteDauer
• ScrumschlägtvierWochenvor.ÜblichsindSprintsvoneinbisvierWochen
• Sprintsfolgendirektaufeinander
• WichtigisteinnachhaltigesTempo,dasaufDauerdurchgehaltenwerdenkann
• SoentstehteinfesterRhythmusinderEntwicklung
SprintKreativeZielanalyse
• Ideenmanagement
• Stakeholdermanagement
• NutzungvorhandenerPrototypenetc.
Start
Extrem schlanker Prozess• 3 Rollen• 4 Artefakte• wenige Regeln
• EristCoachfürdieAnwendungvonScrum
• ErhilftdemTeamdurch:
• BeseitigungderorganisatorischenHindernisse
• SchutzvorstörendenEinflüssenundVersuchen
der„Einmischung“
• ErarbeitetmitdemProductOwnerzusammenundunterstützt
diesenbeiderPriorisierungnachgeschäftlichenNutzen
• ErkontrolliertZyklenvon„inspectandadapt“inScrum
• ErsorgtfürdieUnterstützungundAnerkennungderagilen
PrinzipiendurchalleProjektbeteiligten
Scrum Master
• OptimaleGröße:7+/-2Mitglieder
• Interdisziplinärbesetzt
• AlleFähigkeiten,umdasfertigeProduktzuerstellen
sindvorhanden(Architekten,Entwickler,Tester,…)
• DasTeammussdieVisiondesPOverstehen
• DasTeamorganisiertundverwaltetsichselbst
• DasTeamverpflichtetsich,vereinbarteZielezuerreichen
• JederträgtmitseinemgesamtenWissenzumErfolgbei
(unabhängigvonhierarchischerPositionundformellerQualifikation)
• Vertrauenskultur:Eswirddavonausgegangen,dassjederimmer
seinBestesgibt
Team
Sprint Retrospective•ErfahrungendesletztenSprintsführenzukonkretenVerbesserungen:
•ObersteDirektive–UnabhängigdavonwasinderRetrospektive
angesprochenoderdiskutiertwird,sindwirderÜberzeugung,dassjeder
unterdengegebenenUmständenseinBestesgegebenhat,umdasZiel
desSprintszuerreichen
•DreiFragen(Zeitachse):
•Wasistgutgelaufen?
•Waskannverbessertwerden?
(Team/Organisation)
•Werpacktesan?
• DasErgebniseinesSprintsistdiefertigeRealisierung
derimSprintzielvereinbartenFeatures.
• Fertigheißtpotenziellauslieferbar,fertigfürdenRollout:
• fertigimplementiert
• fertiggetestet
• CodeentsprichtStandardsundRichtlinien
• ausreichenddokumentiert
• DieDefinitionvon„fertig“erfolgtdurchdasTeam
(undkannsichverändern/verbessern)
potenziell aus-lieferungsfähiges Produkt
©CopyrightInterFaceAG•V.0.1-090707www.InterFace-AG.de
www.scrum-poster.de
Scrum ñ Sprint Retrospective
Scrum – Product Owner
Der Product Owner gibt die Vision vor – was muss entwickelt werden, um maximalen Erfolg zu haben
„Manifesto for Agile Software Development“
We are uncovering better ways of developing software by doing it and helpingWe are uncovering better ways of developing software by doing it and helpingothers do it. Through this work we have come to value:
Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools
Working software over comprehensive documentation
C t ll b tiCustomer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Prinzipien des „lean development“
• Eliminiere Verschwendung• Verinnerliche Qualität
E Wi• Erzeuge Wissen• Vermeide frühe Festlegungen• Liefere schnell
R kti d hät di M h• Respektiere und schätze die Menschen• Folge dem Pull-Prinzip• Optimiere nicht lokal, sondern global
V b t ti• Verbessere stetig• Vermeide (Lager-)Bestand
Probleme und Schwierigkeiten inProbleme und Schwierigkeiten inSoftwareprojekten
• Nicht alle Anforderungen sind ausreichend bekannt• Anforderungen ändern sich, neue kommen hinzu• Unstimmigkeiten bei der Bewertung, ob CR, Bug oder Featureg g, , g• Technische Rahmenbedingungen sind nicht klar oder ändern sich• Know-how-Träger verlassen das Team• Umfangreiche Bugfixing-Phaseng g g• Termine werden verändert• Prozesse werden nicht eingehalten oder nicht verstanden• geforderte Artefakte (Dokumentation) werden nur pro forma erstelltg ( ) p• …• …
GA ecaFretnI