Agile Vorgehensmodelle in der Softwareentwicklung: Scrum
Agile Vorgehensmodelle in der Softwareentwicklung: Scrum
Agile Vorgehensmodelle in der Softwareentwicklung: Scrum
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
C A R L<br />
V O N<br />
O S S I E T Z K Y<br />
<strong>Agile</strong> <strong>Vorgehensmodelle</strong> <strong>in</strong><br />
<strong>der</strong> <strong>Softwareentwicklung</strong>:<br />
<strong>Scrum</strong><br />
Johannes Diemke<br />
Vortrag im Rahmen <strong>der</strong> Projektgruppe<br />
Oldenburger Robot Soccer Team<br />
im W<strong>in</strong>tersemester 2009/2010
<strong>Scrum</strong><br />
Was ist <strong>Scrum</strong>?<br />
◮ <strong>Scrum</strong> ist e<strong>in</strong> agiler Softwareprozess<br />
◮ <strong>Scrum</strong> unterteilt den gesamten Entwicklungsprozess <strong>in</strong> drei Phasen:<br />
Modellierung (Start Game)<br />
Entwicklung (Spr<strong>in</strong>t)<br />
Abschluss (End Game)<br />
◮ Das beson<strong>der</strong>e an <strong>Scrum</strong> ist die mittlere Phase<br />
◮ Die Entwicklung f<strong>in</strong>det iterativ <strong>in</strong> mehreren Spr<strong>in</strong>ts statt<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 2/21
<strong>Scrum</strong><br />
Was ist <strong>Scrum</strong>? (Forts.)<br />
◮ Nach jedem Spr<strong>in</strong>t können neue Anfor<strong>der</strong>ungen berücksichtigt<br />
werden<br />
◮ Eventuelle Fehler <strong>in</strong> den Anfor<strong>der</strong>ungen können so mit dem nächsten<br />
Spr<strong>in</strong>t leicht korrigiert werden<br />
◮ <strong>Scrum</strong> b<strong>in</strong>det das Entwicklerteam <strong>in</strong> das Management e<strong>in</strong><br />
◮ Das Team übernimmt zusammen mit dem Projektleiter die<br />
Kostenabschätzung und das Risikomanagement<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 3/21
<strong>Scrum</strong><br />
Rahmenbed<strong>in</strong>gungen von <strong>Scrum</strong><br />
◮ <strong>Scrum</strong> ist nicht für Teams mit mehr als 10 Personen geeignet<br />
Basiert zu großen Teilen auf Kommunikation, die <strong>in</strong> kle<strong>in</strong>en Teams<br />
besser möglich ist<br />
◮ <strong>Scrum</strong> funktioniert im Wesentlichen durch die Aufteilung des<br />
gesamten Problems <strong>in</strong> kle<strong>in</strong>e E<strong>in</strong>heiten, die unabhängig vone<strong>in</strong>an<strong>der</strong><br />
entwickelt werden können<br />
Daher ungeeignet für bspw. funktionale Programmierung<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 4/21
<strong>Scrum</strong><br />
Artefakte <strong>in</strong> <strong>Scrum</strong><br />
◮ S<strong>in</strong>d Übersichten über gefor<strong>der</strong>te und schon bearbeitete Aufgaben<br />
und ihre Kosten<br />
◮ Sie s<strong>in</strong>d bewusst e<strong>in</strong>fach gehalten<br />
Es s<strong>in</strong>d ke<strong>in</strong>e speziellen Werkzeuge nötig<br />
◮ Es gibt drei verschiedene Artefakttypen<br />
Product Backlog<br />
Spr<strong>in</strong>t Backlog<br />
Burndown Charts<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 5/21
<strong>Scrum</strong><br />
Product Backlog<br />
◮ Liste <strong>der</strong> gestellten Anfor<strong>der</strong>ungen an die zu entwickelnde Software<br />
Sortiert nach Priorität<br />
◮ Bildet nur e<strong>in</strong>e momentane Übersicht <strong>der</strong> gefor<strong>der</strong>ten Funktionalität<br />
Kann je<strong>der</strong>zeit umstrukturiert werden<br />
◮ Es werden nur die zu dem Zeitpunkt bekannten Anfor<strong>der</strong>ungen<br />
aufgenommen<br />
Ke<strong>in</strong>e Berücksichtigung eventueller Anfor<strong>der</strong>ungen<br />
◮ Än<strong>der</strong>ungen <strong>in</strong> den Anfor<strong>der</strong>ungen können direkt <strong>in</strong> das Product<br />
Backlog übernommen werden<br />
Die Än<strong>der</strong>ungen werden jedoch erst im folgenden Spr<strong>in</strong>t<br />
berücksichtigt<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 6/21
<strong>Scrum</strong><br />
Product Backlog (Forts.)<br />
◮ E<strong>in</strong>träge im Product Backlog:<br />
Gefor<strong>der</strong>te Funktionen<br />
Geschätzte Gesamtkosten<br />
Restkosten<br />
Spr<strong>in</strong>t <strong>in</strong> dem die Funktion implementiert werden soll<br />
Beispiel e<strong>in</strong>es Product Backlogs<br />
spr<strong>in</strong>t item estimated rema<strong>in</strong><strong>in</strong>g<br />
1 function1 80 46<br />
1 function2 57 35<br />
1 function3 12 0<br />
1 function4 60 60<br />
function5 49 49<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 7/21
<strong>Scrum</strong><br />
Spr<strong>in</strong>t Backlog<br />
◮ Übersicht <strong>der</strong> Funktionen, die <strong>in</strong> <strong>der</strong> aktuellen Iteration <strong>der</strong><br />
Entwicklung (dem Spr<strong>in</strong>t) bearbeitet werden sollen<br />
◮ Die Dauer e<strong>in</strong>es Spr<strong>in</strong>ts ist vorher festgelegt und <strong>der</strong> Umfang <strong>der</strong><br />
Funktionen im Spr<strong>in</strong>t Backlog darf diese Dauer nicht überschreiten<br />
◮ Der Umfang des Spr<strong>in</strong>t Backlogs wird dabei vom Entwicklerteam<br />
geme<strong>in</strong>sam festgelegt<br />
<strong>Scrum</strong> profitiert hier von <strong>der</strong> E<strong>in</strong>schätzung durch das gesamte<br />
Entwicklerteam<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 8/21
<strong>Scrum</strong><br />
Spr<strong>in</strong>t Backlog (Forts.)<br />
◮ E<strong>in</strong>träge im Spr<strong>in</strong>t Backlog:<br />
Gefor<strong>der</strong>te Funktionen<br />
Teammitglied welches die Funktion entwickelt<br />
Die geschätzten Gesamtkosten<br />
Die Restkosten für jeden Tag über die Dauer des Spr<strong>in</strong>ts<br />
Beispiel e<strong>in</strong>es Spr<strong>in</strong>t Backlogs<br />
item owner estimated 01.04 02.04 . . .<br />
function1 johannes 80 75 50 . . .<br />
function2 bernd 67 50 45 . . .<br />
function3 timo 80 75 40 . . .<br />
function4 sascha 93 86 80 . . .<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 9/21
<strong>Scrum</strong><br />
Burndown Charts<br />
◮ S<strong>in</strong>d grafische Darstellungen des Spr<strong>in</strong>ts<br />
◮ E<strong>in</strong>faches Diagramm, das die Restkosten e<strong>in</strong>es Spr<strong>in</strong>ts über se<strong>in</strong>e<br />
Dauer darstellt<br />
◮ Zeigt auf wie gut die Abschätzungen des Entwicklerteams waren<br />
◮ Ziel <strong>der</strong> Burndown Charts:<br />
Verbesserung <strong>der</strong> Abschätzungen des Entwicklerteam bzgl. <strong>der</strong><br />
Gesamtkosten zu implementieren<strong>der</strong> Funktionalität<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 10/21
<strong>Scrum</strong><br />
Burndown Charts (Forts.)<br />
◮ E<strong>in</strong> ideales Diagramm enthält e<strong>in</strong>en Graphen mit e<strong>in</strong>er Steigung von<br />
−1<br />
◮ In <strong>der</strong> Praxis enthalten alle diese Diagramme jedoch<br />
Treppenartefakte<br />
Beispiele für Burndown Charts<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 11/21
<strong>Scrum</strong><br />
Rollen <strong>in</strong> <strong>Scrum</strong><br />
◮ In <strong>Scrum</strong> werden drei verschiedene Rollen unterschieden:<br />
Product Owner<br />
<strong>Scrum</strong> Master<br />
Project Team<br />
Product Owner<br />
◮ Der Product Owner ist <strong>der</strong> Kunde des Produktes<br />
◮ Er muss die gefor<strong>der</strong>te Funktionalität und die Priorität je<strong>der</strong><br />
gefor<strong>der</strong>ten Funktion festlegen<br />
◮ Der Kunde kann dabei je<strong>der</strong>zeit auf den Product Backlog zugreifen<br />
um Än<strong>der</strong>ungen se<strong>in</strong>er Anfor<strong>der</strong>ungen o<strong>der</strong> <strong>der</strong> Prioritäten<br />
vorzunehmen<br />
◮ Er bewertet nach jedem Spr<strong>in</strong>t den entstandenen Prototypen<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 12/21
<strong>Scrum</strong><br />
<strong>Scrum</strong> Master<br />
◮ Der <strong>Scrum</strong> Master entspricht dem Projektleiter<br />
◮ Er muss an<strong>der</strong>s als e<strong>in</strong> klassischer Projektmanager kaum<br />
Entscheidungen alle<strong>in</strong>e treffen<br />
Viele Aufgaben des Management fallen nämlich dem Team zu<br />
◮ Er ist <strong>der</strong> Ansprechpartner für den Kunden<br />
◮ Ausserdem stellt er sicher, dass die Kundenwünsche erfüllt werden<br />
und muss Rückmeldungen des Kunden an das Entwicklerteam<br />
weitergeben<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 13/21
<strong>Scrum</strong><br />
Project Team<br />
◮ Das Project Team ist das eigentliche Entwicklerteam<br />
◮ Es ist für die Implementierung <strong>der</strong> gefor<strong>der</strong>ten Funktionen zuständig<br />
◮ An<strong>der</strong>s als beim klassischen Projektmanagement ist das Team aktiv<br />
am Management beteiligt<br />
Es nimmt geme<strong>in</strong>sam Abschätzungen <strong>der</strong> Funktionskosten und des<br />
Risikos e<strong>in</strong>zelner Funktionen vor<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 14/21
<strong>Scrum</strong><br />
Ablauf des Entwicklungsprozesses<br />
◮ Der <strong>Scrum</strong> Prozess besteht aus den drei Phasen:<br />
Start Game<br />
Spr<strong>in</strong>t (iterativ)<br />
End Game<br />
Start Game<br />
◮ Die erste Phase, das Start Game, besteht <strong>in</strong> <strong>der</strong> Modellierung<br />
◮ Es wird die zu Beg<strong>in</strong>n bekannte Problematik festgelegt und <strong>in</strong> das<br />
Product Backlog aufgenommen<br />
Die festgelegte Funktionalität muss dabei nicht endgültig se<strong>in</strong><br />
◮ Dieser Phase folgen mehrere Iterationen <strong>der</strong> Entwicklung (Spr<strong>in</strong>ts)<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 15/21
<strong>Scrum</strong><br />
Spr<strong>in</strong>t<br />
◮ Die eigentliche Entwicklung <strong>der</strong> Software f<strong>in</strong>det <strong>in</strong> so genannten<br />
Spr<strong>in</strong>ts statt<br />
◮ E<strong>in</strong> Spr<strong>in</strong>t ist die Lösung e<strong>in</strong>er bestimmten Anzahl von Problemen<br />
aus dem Product Backlog<br />
◮ Ziel ist es, e<strong>in</strong>en funktionsfähigen Prototypen mit dem Ablauf des<br />
Spr<strong>in</strong>ts zur Verfügung zu stellen<br />
◮ Dem Kunden wird <strong>der</strong> jeweils fertige Prototyp präsentiert<br />
Dieser nimmt dann falls nötig Nachbesserungen se<strong>in</strong>er Anfor<strong>der</strong>ungen<br />
vor<br />
◮ Spr<strong>in</strong>ts werden solange wie<strong>der</strong>holt, bis alle Aufgaben des Product<br />
Backlog erledigt s<strong>in</strong>d<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 16/21
<strong>Scrum</strong><br />
Spr<strong>in</strong>t (Forts.)<br />
◮ Während e<strong>in</strong>es Spr<strong>in</strong>ts sieht <strong>Scrum</strong> tägliche Treffen aller<br />
Teammitglie<strong>der</strong> vor:<br />
Diese dauern max. 15 M<strong>in</strong>uten<br />
Treffen f<strong>in</strong>den zudem <strong>in</strong> e<strong>in</strong>em extra Raum statt<br />
Der Raum sollte ke<strong>in</strong>e Stühle enthalten<br />
Es dürfen nur <strong>Scrum</strong> Master und das Project Team teilnehmen<br />
◮ Jedes Mitglied muss bei den Treffen drei Fragen beantworten:<br />
Was habe ich <strong>in</strong> den letzten 24 Stunden gemacht?<br />
Was werde ich <strong>in</strong> den nächsten 24 Stunden machen?<br />
Was für Probleme könnten mir dabei begegnen?<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 17/21
<strong>Scrum</strong><br />
Spr<strong>in</strong>t (Forts.)<br />
◮ Bei jedem dieser Treffen wird auch das Spr<strong>in</strong>t Backlog aktualisiert<br />
Es werden die Restkosten je<strong>der</strong> Funktion an den aktuellen Stand<br />
angepasst<br />
◮ Ist e<strong>in</strong> Spr<strong>in</strong>t abgeschlossen, wird <strong>der</strong> nächste Spr<strong>in</strong>t geplant<br />
◮ Mit jedem Spr<strong>in</strong>t steht e<strong>in</strong> neuer Prototyp zur Verfügung<br />
◮ Da schon nach dem ersten Spr<strong>in</strong>t e<strong>in</strong> Prototyp zu Verfügung steht,<br />
kann <strong>der</strong> Kunde schon sehr früh erkennen, an welchen Stellen das<br />
Produkt nicht se<strong>in</strong>en Anfor<strong>der</strong>ungen genügt<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 18/21
<strong>Scrum</strong><br />
End Game<br />
◮ Wird diese Phase betreten, müssen alle Funktionen bereits<br />
implementiert se<strong>in</strong><br />
◮ In dieser Phase werden ke<strong>in</strong>e Än<strong>der</strong>ungen <strong>der</strong> Funktionalität mehr<br />
erlaubt<br />
◮ Es wird die komplette Dokumentation erstellt und System- und<br />
Funktionstests durchgeführt<br />
◮ Wird diese Phase abgeschlossen, so ist das Produkt fertig<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 19/21
<strong>Scrum</strong><br />
<strong>Scrum</strong> im Überblick<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 20/21
Literatur<br />
<br />
<br />
Kent Beck et al.<br />
Manifesto for <strong>Agile</strong> Software Development<br />
http://agilemanifesto.org/<br />
Stefan Murawski<br />
<strong>Agile</strong> <strong>Softwareentwicklung</strong><br />
http://www.<strong>in</strong>f.fu-berl<strong>in</strong>.de/<strong>in</strong>st/ag-se<br />
Johannes Diemke <strong>Agile</strong> <strong>Vorgehensmodelle</strong> 23. November 2009 21/21
Change language