Agile Softwareentwicklung mit Scrum1 von 19http://bambo.it
AgendaÜber ScrumDer ProzessDie RollenDie Prinzipien2
Über ScrumEin Framework für das Management komplexer ProjekteTechnische Unwägbarkeiten/MachbarkeitSich ändernde AnforderungenEin einfaches Framework für iterative und inkrementelle SoftwareentwicklungNicht iterativ vs. iterativ3
WasserfallmodellEs wird zu weit in die Zukunft geplantVerlauf 1: Software entspricht nicht den AnforderungenVerlauf 2: Anforderungen ändern sich zu undefinierten Zeitpunkten 4
ScrumEs werden nur 2 – 4 Wochen konkret geplant.Definierter Zeitpunkt für AnforderungsänderungenSoftware entspricht den Anforderungen nach jeder Iteration5
Der Prozess6
Das ProductBacklogEine Liste von priorisierten und geschätzten User Stories (Anforderungsworkshops)Eine User Story beschreibt eine konkrete Funktionalität aus Sicht des AnwendersEine User Story ist in der Sprache des Kunden beschrieben und liefert einen konkreten MehrwertTemplate: Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>]7
Das Selected BacklogEine Liste der höchstpriorisierten User Stories aus dem ProductBacklog (Sprint Planning I)Festlegung des Sprint ZielesVorstellung, Analyse und Commitment8
Das Sprint BacklogAusgewählte User Stories werden in ihre Einzeltasks zerlegt. (Sprint Planning II)Eine Liste von priorisierten Einzeltasks.Die Umsetzung eines Task sollte nicht länger als einen Arbeitstag dauern.Tasks sind meist Programmieraufgaben können aber auch Infrastrukturarbeiten oder Managementaufgaben sein. 9
Der SprintEine Entwicklungsphase fester Länge, an deren Ende das Team funktionierende Software ausliefert.Während des Sprints darf niemand dem Team nicht geplante Arbeiten aufdrückenDas Team organisiert sich während des Sprints vollständig selbst und synchronisiert sich im Daily Scrum.10
Das Daily ScrumDas Team trifft sich jeden Tag zu einer festen Zeit zu einem Stand-upMeeting. (15min)Teammitglieder äußern sich der Reihe nach zu folgenden drei Punkten:Was habe ich gestern erreicht?Was plane ich heute?Welche Hindernisse oder Probleme haben sich mit in den Weg gestellt.11
Sprint Review/DemoZiel: Feedback von der AußenweltDer Scrum Master erklärt welche User Stories erreicht bzw. nicht erreicht wurdenDas Team stellt jede User Story am laufenden System vorÄnderungen oder neue User Stories werden ins ProductBacklog eingetragen12
Sprint RetrospektiveZiel: ständige Verbesserung (Kaizen)Daten Sammeln (Positiv/Negativ)Einsichten generieren (Warum-Fragen)Entscheiden, was zu tun ist (Dot-Voting)Ziele formulieren und Aktionen planen13
Die Rollen14
Das TeamDas Team entwickelt die Software und ist für den Erfolg des Sprints verantwortlich.Innerhalb des Teams gibt es keine Hierarchien oder Führungsrollen.Niemand sagt dem Team wie es zu arbeiten hat.Selbstorganisiert: Keiner weist jemanden Tasks zu. Kanban-Pull-System.15
Der Scrum MasterEr ist verantwortlich für das Einhalten von Scrum-Werten und -Techniken.Er schützt das Team vor negativen Einflüssen von außen und beseitigt Hindernisse.Er hat keine Weisungsberechtigung und ist kein Projekt- oder Teamleiter.Er nimmt keine Verantwortung ab, sondern sorgt dafür, dass andere Rollen ihre Verantwortung annehmen.16
Der ProductOwnerEr repräsentiert den Kunden.Er ist verantwortlich für das ProductBacklog und hat als einziger schreibrechte darauf.Er füllt das Backlog mit User Stories, priorisiert diese und schätzt sie mit Hilfe des Teams.Er ist während des Sprints immer für das Team verfügbar um Story Details zu klären.Nimmt „Fertige“ User Stories ab.17
Scrum Prinzipien ITransparenz: Schlechte Dinge sichtbar machenBeobachten & Anpassen: Tests, Prioritäten, Entwicklungsgeschwindigkeit (Velocity)Timeboxing: Daily, Sprint Planning, SprintDinge Abschließen: User Story, „Definition ofDone“, „Technical Debt“18
Scrum Prinzipien IIMaximierung von Geschäftswerten: Priorisierung, Mehrwert, Risiko Teams scheitern nicht: keine Schuldzuweisung, daraus lernen, Velocity anpassenErgebnisorientiert: nicht die Dauer sondern das Ergebnis zählt, „Definition ofDone“19

Scrum

  • 1.
    Agile Softwareentwicklung mitScrum1 von 19http://bambo.it
  • 2.
    AgendaÜber ScrumDer ProzessDieRollenDie Prinzipien2
  • 3.
    Über ScrumEin Frameworkfür das Management komplexer ProjekteTechnische Unwägbarkeiten/MachbarkeitSich ändernde AnforderungenEin einfaches Framework für iterative und inkrementelle SoftwareentwicklungNicht iterativ vs. iterativ3
  • 4.
    WasserfallmodellEs wird zuweit in die Zukunft geplantVerlauf 1: Software entspricht nicht den AnforderungenVerlauf 2: Anforderungen ändern sich zu undefinierten Zeitpunkten 4
  • 5.
    ScrumEs werden nur2 – 4 Wochen konkret geplant.Definierter Zeitpunkt für AnforderungsänderungenSoftware entspricht den Anforderungen nach jeder Iteration5
  • 6.
  • 7.
    Das ProductBacklogEine Listevon priorisierten und geschätzten User Stories (Anforderungsworkshops)Eine User Story beschreibt eine konkrete Funktionalität aus Sicht des AnwendersEine User Story ist in der Sprache des Kunden beschrieben und liefert einen konkreten MehrwertTemplate: Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>]7
  • 8.
    Das Selected BacklogEineListe der höchstpriorisierten User Stories aus dem ProductBacklog (Sprint Planning I)Festlegung des Sprint ZielesVorstellung, Analyse und Commitment8
  • 9.
    Das Sprint BacklogAusgewählteUser Stories werden in ihre Einzeltasks zerlegt. (Sprint Planning II)Eine Liste von priorisierten Einzeltasks.Die Umsetzung eines Task sollte nicht länger als einen Arbeitstag dauern.Tasks sind meist Programmieraufgaben können aber auch Infrastrukturarbeiten oder Managementaufgaben sein. 9
  • 10.
    Der SprintEine Entwicklungsphasefester Länge, an deren Ende das Team funktionierende Software ausliefert.Während des Sprints darf niemand dem Team nicht geplante Arbeiten aufdrückenDas Team organisiert sich während des Sprints vollständig selbst und synchronisiert sich im Daily Scrum.10
  • 11.
    Das Daily ScrumDasTeam trifft sich jeden Tag zu einer festen Zeit zu einem Stand-upMeeting. (15min)Teammitglieder äußern sich der Reihe nach zu folgenden drei Punkten:Was habe ich gestern erreicht?Was plane ich heute?Welche Hindernisse oder Probleme haben sich mit in den Weg gestellt.11
  • 12.
    Sprint Review/DemoZiel: Feedbackvon der AußenweltDer Scrum Master erklärt welche User Stories erreicht bzw. nicht erreicht wurdenDas Team stellt jede User Story am laufenden System vorÄnderungen oder neue User Stories werden ins ProductBacklog eingetragen12
  • 13.
    Sprint RetrospektiveZiel: ständigeVerbesserung (Kaizen)Daten Sammeln (Positiv/Negativ)Einsichten generieren (Warum-Fragen)Entscheiden, was zu tun ist (Dot-Voting)Ziele formulieren und Aktionen planen13
  • 14.
  • 15.
    Das TeamDas Teamentwickelt die Software und ist für den Erfolg des Sprints verantwortlich.Innerhalb des Teams gibt es keine Hierarchien oder Führungsrollen.Niemand sagt dem Team wie es zu arbeiten hat.Selbstorganisiert: Keiner weist jemanden Tasks zu. Kanban-Pull-System.15
  • 16.
    Der Scrum MasterErist verantwortlich für das Einhalten von Scrum-Werten und -Techniken.Er schützt das Team vor negativen Einflüssen von außen und beseitigt Hindernisse.Er hat keine Weisungsberechtigung und ist kein Projekt- oder Teamleiter.Er nimmt keine Verantwortung ab, sondern sorgt dafür, dass andere Rollen ihre Verantwortung annehmen.16
  • 17.
    Der ProductOwnerEr repräsentiertden Kunden.Er ist verantwortlich für das ProductBacklog und hat als einziger schreibrechte darauf.Er füllt das Backlog mit User Stories, priorisiert diese und schätzt sie mit Hilfe des Teams.Er ist während des Sprints immer für das Team verfügbar um Story Details zu klären.Nimmt „Fertige“ User Stories ab.17
  • 18.
    Scrum Prinzipien ITransparenz:Schlechte Dinge sichtbar machenBeobachten & Anpassen: Tests, Prioritäten, Entwicklungsgeschwindigkeit (Velocity)Timeboxing: Daily, Sprint Planning, SprintDinge Abschließen: User Story, „Definition ofDone“, „Technical Debt“18
  • 19.
    Scrum Prinzipien IIMaximierungvon Geschäftswerten: Priorisierung, Mehrwert, Risiko Teams scheitern nicht: keine Schuldzuweisung, daraus lernen, Velocity anpassenErgebnisorientiert: nicht die Dauer sondern das Ergebnis zählt, „Definition ofDone“19