Inhaltsverzeichnis

Transcription

Inhaltsverzeichnis

Erstellung_eines_eBooks_zum_Thema_?SCRUM?
Hochschule:
Standort:
Studiengang:
Veranstaltung:
Betreuer:
Typ:
Themengebiet:
Autor(en):
Studienzeitmodell:
Semesterbezeichnung:
Studiensemester:
Bearbeitungsstatus:
Prüfungstermin:
Abgabetermin:
Fallstudienarbeit
Hochschule für Oekonomie & Management
Düsseldorf
Bachelor Wirtschaftsinformatik
Fallstudie / Wissenschaftliches Arbeiten
Prof._Dr._Uwe_Kern
Fallstudienarbeit
Blended Learning
Louise Hees, Adam Grzeganek
Abendstudium
SS12
2
Bearbeitung abgeschlossen
11.06.12
10.06.12
Inhaltsverzeichnis
• 1 Einleitung
♦ 1.1 Problemstellung
♦ 1.2 Aufbau der Arbeit
• 2 Technologieauswahl
• 3 Fachinhalt
♦ 3.1 Grundlagen
◊ 3.1.1 Definition Agiles
Projektmanagement
◊ 3.1.2 Definition Scrum
◊ 3.1.3 Geschichte
◊ 3.1.4 Ziele
♦ 3.2 Scrum - Rollen
◊ 3.2.1 Product Owner
◊ 3.2.2 Das Team
◊ 3.2.3 Scrum Master
◊ 3.2.4 Customer
◊ 3.2.5 Management
♦ 3.3 Scrum - Meetings
◊ 3.3.1 Sprint Planning
Meeting
⋅ 3.3.1.1 Sprint
Planning
Meeting 1
⋅ 3.3.1.2 Sprint
Planning
Meeting 2
◊ 3.3.2 Daily Standup
Meeting
◊ 3.3.3 Sprint Review
Meeting
◊ 3.3.4 Sprint
Retrospektive Meeting
♦ 3.4 Scrum - Artefakte
Inhaltsverzeichnis
1
◊ 3.4.1 Product Backlog
◊ 3.4.2 User Story
◊ 3.4.3 Selected Product
Backlog / Sprint Backlog
◊ 3.4.4 Burn Down Chart
♦ 3.5 Scrum - Sprint
♦ 3.6 Scrum - Prozess
• 4 Bewertung des Projekts
• 5 Schlussbetrachtung
• 6 Kontrollfragen
♦ 6.1 Fragen
♦ 6.2 Lösungen
• 7 Abbildungsverzeichnis
• 8 Fußnoten
• 9 Literatur- und Quellenverzeichnis
1 Einleitung
1.1 Problemstellung
Softwareentwicklung nimmt immer komplexere Züge an. Die zu analysierenden Kundenanforderungen und
Bedürfnisse werden umfangreicher. Es ist teilweise nicht mehr möglich, zu Beginn des Projektes die
Anforderungen des zu entwickelnden Produktes komplett zu beschreiben und alle Projektschritte bis ins Detail zu
planen. Daher stoßen die klassischen Projektmethoden wie z.B. Wasserfall oder V-Modell an ihre Grenzen. Ihre
Bestandteile wie Lasten- und Pflichtenheft und feste Zeitpläne lassen sich während des Projektverlaufes nur sehr
begrenzt anpassen. Hier bieten die agilen Softwareentwicklungsmethoden wie Scrum oder Extreme Programming
mehr Flexibilität. Mit Scrum wird der Produkterfolg beispielsweise dadurch erreicht, dass die Anforderungen
während des Sprints, dem zentralen Element dieser Methode, verändert werden können. Die Flexibilität muss bei
komplexen Softwareentwicklungen gegeben sein, um Änderungen während der Laufzeit zu berücksichtigen und
ein qualitativ hochwertiges Produkt ausliefern zu können[1].
Viele Firmen bieten Schulungen und Seminare zum Thema Scrum an. Mit blended Learning lassen sich jedoch
bereits die Kernaussagen von Scrum seht gut vermitteln. Blended Learning ist eine Mischung von
unterschiedlichen Lernkonzepten. Beispielsweise werden häufig Präsenzlernphasen mit elektronischen
Lehrkonzepten wie Computer Based Training oder E-Learning Bausteinen verknüpft. Somit sollen die Vorteile
der jeweiligen Lernform voll ausgenutzt und evtuelle Nachteile kompensiert werden. Blended Learning soll einen
größtmöglichen Lernerfolg bieten. Es fördert außerdem das selbstgesteuerte Lernen[2].
Ziel dieser Fallstudie ist es, dem Leser einen detaillierten Einblick in die agile Methode SCRUM zu bieten.
1.2 Aufbau der Arbeit
Zu Beginn dieser Fallstudie werden nach einer kurzen Erläuterung der verwendeten technologischen Mittel die
1 Einleitung
2
Grundlagen des agilen Projektmanagements sowie im Speziellen die Definition und Ziele der Methode Scrum
erläutert. Es folgt die Beschreibung der in Scrum vorhandenen Rollen, sowie der zu durchlaufenden Meetings.
Anschließend werden die während des Scrumprozesses verwendeten Artefakte detailliert beschrieben. Sie stellen
im Reportingprozess eine wesentliche Rolle dar. Diese drei Kapitel definieren die Begriffe, die im folgenden für
die Darstellung des Sprint - dem zentralen Baustein von Scrum - benötigt werden. Das Kapitel 3.6 zeigt den
Ablauf vom ersten Meeting bis zum Abschluss eines Sprints. Im Anschluss erfolgt die Gesamtbewertung des
Projekts in Bezug auf die Erstellung des eBooks. Die Schlussbetrachtung fasst anschließend nocheinmal die
wesentlichen Bausteine von Scrum zusammen. Im Kapitel 6 sind Kontrollfragen im Multiple-Choice-Stil
angegeben, die dem Selbstlerncharakter des eBooks entsprechen.
2 Technologieauswahl
Der aktuelle Standard für ein E-Book ist das Format EPUB. EPUB steht für electronic publication. Dieses Format
kann von gängigen E-Book-Readern und Smartphones gelesen werden. Um ein bestehendes Dokument in EPUB
zu überführen werden im Internet meherere Tools und Möglichkeiten angeboten. Eine Variante besteht darin,
seine Dateien auf die Seite eines Anbieters hochzuladen, der das Umwandeln übernimmt und anschließend das
Dokument im gewünschten EPUB-Format zur Verfügung stellt. Neben dem Nachteil, die Datei erst hochladen zu
müssen gibt es hierbei oft Begrenzungen im Datenvolumen. Wir haben daher ein Tool gesucht, dass lokal
installiert werden kann und bei dem der Anwender alle Schritte selbst ausführt. Dabei wurde darauf geachtet, dass
es sich um Freeware, also freie und kostenlose Software handelt. Die Wahl ist abschließend auf Calibre in der
aktuellen Version 0.8.55 (http://calibre-ebook.com/) gefallen. Mit Calibre können zahlreiche Formate in EPUB
überführt werden, z.B. HTML, PDF oder TXT-Dateien. Es bietet zahlreiche Fuktionen für
Anpassungsmöglichkeiten während der EPUB Konvertierung. Ein Inhaltsverzeichnis kann z.B. automatisch
erkannt oder manuell vorgegeben werden. Die Seiteneinrichtung lässt sich für eine Vielzahl von mobilen
Endgeräten optimiert einstellen. Des Weitern kann der Quelltext bei einigen Eingabeformaten wie z.B. HTML
noch angepasst werden, um ein wunschgemäßes eBook im EPUB-Format zu erhalten.
3 Fachinhalt
3.1 Grundlagen
3.1.1 Definition Agiles Projektmanagement
Agil bedeutet flink und wendig zu sein. Beim agilen Projektmanagement geht man darauf ein, dass
Entwicklungsprojekte immer größere und komplexere Formen annehmen und somit nicht mehr von Anfang an bis
ins Detail planbar sind. Beim agilen Vorgehen wechseln sich kurze Planungs- und Entwicklungsphasen ab[3]. Die
Kerninhalte von agiler Softwareentwicklung sind Kommunikation und Einfachheit[4].
Im Februar 2001 trafen sich Vertreter vieler agiler Methoden und beschlossen das folgende Manifest als
Grundlage für alle agilen Methoden:
"* Individuen und Interaktionen mehr als Prozesse und Werkzeuge
1.2 Aufbau der Arbeit
3
* Funktionierende Software mehr als umfassende Dokumentation
* Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
* Reagieren auf Veränderung mehr als das Befolgen eines Plans"
[5]
Die Werte auf der rechten Seite wurden von den Teilnehmern für wichtig befunden, jedoch schätzten sie die
Werte auf der linken Seite höher ein.
3.1.2 Definition Scrum
Scrum bedeutet wörtlich übersetzt "Gedränge" und steht für einen Spielzug im Rugby. Scrum ist ein Modell für
die Abwicklung von Projekten, und wird in der Regel bei komplexen Softewareerstellungen genutzt. Es folgt den
Grundsätzen der agilen Softwareentwicklung. Es basiert auf Meetings, Artefakten und klar definierten Rollen[6].
Rugby ist zwar ein raues aber sehr diszipliniertes Spiel. Genau wie bei Scrum gibt es nur wenige Regeln, diese
werden jedoch genauestens befolgt[7].
3.1.3 Geschichte
In den 1990er-Jahren wurde Scrum erstmal in den USA durch Jeff Sutherland und Ken Schwaber angewendet. Sie
haben für das Modell den Begriff "Scrum" gewählt in Anlehnung an japanische Studien der 1980er-Jahre. Nonaka
und Takeuchi beschrieben mit dem Wort die Zusammenarbeit mehrerer Fachdisziplinen bei der
Produktentwicklung[7]. 1995 stellten Sutherland und Schwaber Scrum erstmals auf die OOPSLA (Object-Oriented
Programming, Systems, Languages & Applications) vor.
3.1.4 Ziele
Ein zentraler Baustein von Scrum ist die kontinuierliche Kommunikation. Dies führt zu einer ständigen
Prozessverbesserung und einer Steigerung der Qualität des Endergebnisses. Durch die ständige Überprüfung
lassen sich Fehlentwicklungen vermeiden bzw. schnell korrigieren. Dadurch soll eine schnelle und kostengünstige
Fertigstellung des Produktes, gemäß der Kundenvision, erreicht werden. Durch die Priorisierung der
Anforderungen wird zuerst die Software bereitgestellt, die der Kunde am dringendsten benötigt. Ein frühes
Release bedeutet einen schnellen Return of Investment (ROI)[8].
3.2 Scrum - Rollen
Die Beteiligten eines Scrum-Projektes werden in drei Hauptrollen beschrieben: Product Owner, Development
Team und Scrum Master. Als Nebenrollen sind der Kunde, ohne den es kein Scrum-Projekt geben würde, sowie
das Management zu nennen.
3.2.1 Product Owner
"Der Product Owner ist der fachliche Projektleiter und für den Gesamterfolg des Projekts verantwortlich[9]." Er
steuert die Produktentwicklung und repräsentiert den Kunden mit seinen Anforderungen. Er übernimmt nicht die
Rolle des Vorgesetzten im Projektteam, sondern priorisiert die gewünschten Kundenanforderungen und nimmt am
Daily Scrum (Kapitel 3.3.2.) passiv teil. Er steht jederzeit für Rückfragen der Teammitglieder zur Verfügung und
3.1.1 Definition Agiles Projektmanagement
4
übernimmt die Kommunikation mit dem Kunden.
In seiner Verantwortung liegen zu Beginn des Projektes die Konzeption und die Übermittlung der Vision des
Kundenproduktes. Er versucht durch seine Gestaltungsmöglichkeiten den wirtschaftlichen Nutzen für die eigene
Unternehmung zu steigern[10]. Der Product Owner "trifft zeitnah die notwendigen Entscheidungen und arbeitet
kontinuierlich am Product Backlog" (Kapitel 3.4.1) und dem Releaseplan[11]. Er allein pflegt das Product
Backlog, dass die Produkteigenschaften und User Stories beinhaltet und bestimmt wann eine Story fertig gestellt
ist.
3.2.2 Das Team
Das Entwicklungsteam entwickelt das Produkt innerhalb einer festgelegten Anzahl von Sprints. Das Team bildet
sich aus den Akteuren, die zur Erreichung und Fertigstellung des Produktes notwendig sind. Somit ist auch eine
Maximalgröße nicht festgelegt. Das Entwicklungsteam agiert stets nach den Standards und Prozessen eines Scrum
Entwicklungsprozesses. Auch die Organisation und das Arbeitsvolumen wird von dem Entwicklungsteam selbst
bestimmt[12].
3.2.3 Scrum Master
Die Rolle des Scrum Masters ist vielschichtig. Der Scrum Master ist zum einen Vermittler zwischen Product
Owner und Entwicklungsteam. Einträge des Product Backlog's werden durch den Scrum Master an das Team
kommuniziert[13].
Neben der Tätigkeit als Vermittler, fungiert der Scrum Master aber auch als Problemlöser. Droht die Arbeit des
Teams in einem Entwicklungsschritt (Sprint) zu stagnieren, hilft der Scrum Master dieses Problem, durch
Einhaltung des geltenden Scrum Techniken, zu lösen. Der Scrum Master ist zu dem nicht weisungsbefugt, d.h. die
Akteure des Entwicklungsteams handeln stets eigenständig[14].
Ein weiteres Tätigkeitsfeld des Scrum Masters ist zudem die Schulung und Führung des Teams zum
selbstorganisierten Handeln[14] [15].
3.2.4 Customer
Der Customer stellt neben den drei Hauptrollen eine Nebenrolle dar. Hierunter werden alle Stakeholder des
Projektes verstanden, wie das Unternehmen als Auftraggeber oder der Endanwender des Produktes. In der Regel
hat der Customer als seinen Ansprechpartner den Product Owner. Für das Verständnis einzelner Anforderungen
kann es aber durchaus sinnvoll sein, dass das Team mit dem Customer in Kontakt tritt[16].
3.2.5 Management
Die Ressourcen für ein Projekt werden vom Management bereitgestellt. In diesem geschaffenen Rahmen bewegen
sich das Team, der Product Owner und der Scrum Master. In einigen Fällen wird das Management benötigt, um
die vom Scrum Master erkannten Probleme zu lösen[17].
3.2.1 Product Owner
5
3.3 Scrum - Meetings
3.3.1 Sprint Planning Meeting
Das Sprint Planning Meeting bildet die Grundlage eines Sprints und ist somit unabdingbarer Bestandteil für die
erfolgreiche Durchführung eines Sprint. Das Sprint Planning Meeting unterteilt sich dabei in zwei Einheiten mit
unterschiedlichem Schwerpunkt[18].
3.3.1.1 Sprint Planning Meeting 1
Die erste Einheit, das Sprint Planning Meeting 1, wird zur Analyse und Zielfindung genutzt. Teilnehmer dieser
ersten Einheit sind neben dem Product Owner und dem Team, auch der Scrum Master und das Management[18].
Der Product Owner definiert mit den anderen Teilnehmern nun das Ziel für den bevorstehenden Sprint, anhand
des Product Backlog. Hierzu wählt das Team einzelne Backlog Items aus und fasst diese in einer gesonderten
Liste, dem Selected Product Backlog, zusammen. Ein wichtiges Kriterium ist die Selektion durch das Team. Das
Team allein bestimmt die Menge an Backlog Items, die es zur Erfüllung des definierten Ziels benötigt, um dieses
letztendlich auch erfüllen zu können[19].
3.3.1.2 Sprint Planning Meeting 2
In der zweiten Einheit, dem Sprint Planning Meeting 2 wird nun die Durchführung für das aus der ersten Einheit
definierte Ziel, geplant. Teilnehmer sind der Product Owner, der Scrum Master und das Team. Product Owner
und Scrum Master nehmen in der zweiten Einheit jedoch nur die Rolle eines Beobachters ein. Die zweite Einheit
wird ausschließlich durch das Team genutzt[20].
Architektur, Spezifikation und alle anderen, essentiell notwendigen Dinge zur Erarbeitung eines Designs werden
im Sprint Planning Meeting 2, diskutiert. Die Umsetzungsvorstellungen der einzelnen Teammitglieder fließen in
dieser Einheit zusammen und werden detailliert zu Teilaufgaben ausgearbeitet[20].
Die Ausarbeitung der Teilaufgaben wird wiederum in einer Liste, dem Sprint Backlog, festgehalten. Nach
Beendigung des Sprint Planning Meeting 2 ist somit jedes Teammitglied anhand des Sprint Backlog in der Lage
die festgelegten Ziele für den bevorstehenden Sprint einzusehen und sich ein klares Bild über den Umfang zu
bilden[20].
3.3.2 Daily Standup Meeting
Das Daily Standup Meeting findet in einem bereits laufenden Sprint statt. Teilnehmende sind der Scrum Master
sowie das Team. Der Scrum Master moderiert dabei lediglich das Meeting, übernimmt jedoch nicht die Führung.
Die maximale Dauer des Daily Standup Meetings sollte nicht mehr als 15 Minuten beanspruchen[21].
Um dieses Meeting erfolgreich durchführen zu können, sollte sich jedes Teammitglied, welches aktiv am Sprint
beteiligt ist, daher die folgenden drei Fragen stellen:
"1. Was habe ist seit dem letzten Meeting erreicht?
2. Was will ich bis zum nächsten Meeting erreichen?
3. Was steht mir dabei im Weg?"[22]
3.3 Scrum - Meetings
6
Ein wichtiger Aspekt dieses Meetings ist somit die Abstimmung und der Informationsaustausch der
Teammitglieder untereinander. Der Scrum Master achtet zudem darauf, dass dieses Meeting nicht zu einem
Statusmeeting mutiert, in welchem der Ist-Zustand eines Projektes diskutiert wird[23].
Auch inhaltliche Fragen, welche nicht innerhalb der 15 Minuten des Daily Standup Meetings geklärt werden
können, werden durch den Scrum Master notiert und anschließend mit den Betroffenen Teammitgliedern
erörtert[24].
3.3.3 Sprint Review Meeting
Das Sprint Review Meeting wird am Ende eines Sprints durchgeführt und präsentiert die erarbeiteten
Funktionalitäten des Teams. Diese Funktionalitäten bilden somit einen Zustand ab, der es erlauben würde, diese
Produktiv einzusetzen. Nicht getestete oder gar instabile Funktionalitäten werden zu diesem Meeting
ausgeschlossen und nicht präsentiert[25]. Es handelt sich bei der Präsentation jedoch nicht um einen
PowerPoint-Vortrag, sondern es wird ausschließlich die laufende Software gezeigt[26].
Durch das Sprint Review Meeting lassen sich zudem drei Fragen beantworten, die gewissermaßen auf den Status
des Projektes schließen lassen[27].
1. Hat das Team geliefert was es versprochen hat?
2. Ist das Projekt da, wo es sein sollte?
3. Wurde ein neuer Stand erreicht, von dem aus weitergearbeitet werden kann?
Teilnehmende Rollen an diesem Meeting sind alle, an dem Projekt interessierten Personen. Neben dem Scrum
Master teilt auch das Team den anderen Teilnehmern mit, welches Ziel für den beendeten Sprint definiert, und
welche Backlog Items hierfür gewählt wurden[28].
Auch dieses Meeting ist zeitlich auf 90 Minuten begrenzt. Auftretende Probleme oder neue Ideen für das Produkt
werden ebenfalls nicht im Sprint Review Meeting diskutiert. Diese werden nach Abschluss des Meetings, oder zu
einem anderen Termin, genauer diskutiert[29].
3.3.4 Sprint Retrospektive Meeting
Das eigentliche Herzstück eines Scrum Entwicklungsprozesses ist das Sprint Retrospektive Meeting. Die
Retrospektive versetzt das Team in die Lage sich ständig selbst zu verbessern. Durch Analyse der eigenen
Arbeitsprozesse kann die Optimierung einzelner Arbeitsabläufe bereits die Effektivität des folgenden Sprints
steigern[30]. Das Meeting wird vom Scrum Master vorbereitet und moderiert. Die Teammitglieder sammeln Daten
über den Ablauf des vergangenen Sprints. Diese werden analysiert und anschließend Ziele formuliert, wie eine
Verbesserung erreicht werden kann. Dieses Vorgehen führt zu einer Steigerung der Produktivität des Teams[31]
3.4 Scrum - Artefakte
3.4.1 Product Backlog
Das Product Backlog enthält eine strukturierte und priorisierte Liste aller Punkte, die der Product Owner für den
Projekterfolg festgelegt hat[32]. Es ist die Dokumentation der Funktionalitäten des zu entwickelnden Produktes in
3.3.2 Daily Standup Meeting
7
der Reihenfolge ihrer Bedeutung für den Projekterfolg. Es werden nicht Anforderungen notiert, sondern die
Eigenschaften und Merkmale des Produktes auf grober Ebene formuliert. Es beinhaltet ebenfalls eine
Aufwandsschätzung in Tagen. Der Product Owner ist für die Einträge und deren laufende Aktualisierung
verantwortlich[33]. In großen Projekten wird er hierbei vom Team unterstützt.
Aus dem Product Backlog, das die Gesamtzahl der Anforderungen enthält, werden vom Product Owner die
Anforderungen für den nächsten Sprint ausgewählt und zusammengestellt[34].
3.4.2 User Story
Ein Product Backlog Item ist die Beschreibung einer zu liefernden Funktionalität. Diese Items werden auch User
Story genannt und bilden die Steuerung für agile Projekte. Der Verfasser ist hierbei Customer, der Product Owner
legt jedoch die Umsetzungsreihenfolge fest.
Beispiele sind:
• Administratoren können die angemeldeten Benutzer sehen
• Anwender können den Status der einzelnen Buchungen abrufen
• Schnittstelle für XML-Export
• Druckvorschau
User Stories sollten dabei gem. den INVEST-Kriterien folgende Eigenschaften haben[35]:
Quelle: http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
Abbildung 1: INVEST-Kriterien
3.4.3 Selected Product Backlog / Sprint Backlog
Das Selected Product Backlog entsteht im ersten Sprint Planning Meeting und besteht aus den Items, die im
Sprint umgesetzt werden sollen. Hieraus leitet sich das Sprint Backlog ab. Dieses beschreibt konkrete Aufgaben,
die das Entwicklungsteam in einem Sprint erledigen wird.
3.4.1 Product Backlog
8
In Anlehnung an: Henning Wolf / Wolf-Gideon Bleek (2011)
Abbildung 2: Vom Product Backlog zum Sprint Backlog
Ein Sprint Backlog wird im Gegensatz zu einem Product Backlog täglich aktualisiert. Das Sprint Backlog zeigt
zudem welcher Akteur des Entwicklungsteams gerade an welcher Aufgabe arbeitet und wie weit diese bereits
erfüllt wurde[32].
Ein Sprint Backlog kann unterschiedliche Formen haben. Eine Möglichkeit wäre z.B. ein großes Whiteboard. Die
User Story bilden die Zeilen und die Spalten werden nach dem jeweiligen Status unterteilt:
• Offen
• in Arbeit
• Fertig
Diese Möglichkeit bietet sich an, wenn sich alle Teammitglieder zentral an einem Standtort aufhalten. Bei
standortübergreifenden Projekten bieten sich hier elektronischen Lösungen eines Product Backlogs an[36].
3.4.4 Burn Down Chart
Der Burndown Chart zeigt übersichtlich wieweit ein laufender Sprint bereits fortgeschritten und die gesteckten
Ziele erfüllt worden sind[37]. Diese Grafik kann für unterschiedliche Visualisierungen genutzt werden und soll
dazu dienen, die Erreichung des Sprint-Ziels besser abschätzen zu können. Folgende Charts können unterschieden
werden:
• Sprint-Burndown-Chart
• Product-Burndown-Chart
• Release-Burndown-Chart
3.4.3 Selected Product Backlog / Sprint Backlog
9
In Anlehnung an: Boris Gloger (2011), S. In Anlehnung an: Boris Gloger (2011), S. In Anlehnung an: Boris Gloger
210
212
(2011), S. 213
Abbildung 3: Sprint-Burndown-Chart Abbildung 4: Product-Burndown-Chart Abbildung 5:
Release-Burndown-Chart
Bei dem Sprint-Burndown-Chart wird auf der x-Achse der Zeitverlauf in Tagen und auf der y-Achse der
geschätzte Gesamtaufwand in Stunden eingetragen. So entsteht ein Übersicht über die täglich abnehmende Zahl
der noch zu leistenden Stunden.
Beim Product-Burndown-Chart werden dagegen die noch nicht erledigten User Stories eines Sprints angezeigt.
Diese werden in Form von unterschielich großen Story Points dargestellt. Auf der x-Achse ist die Dauer des
Sprints und auf der y-Achse die noch offenen Story Points erfasst. Der treppenförmige Kurvenverlauf entsteht, da
immer wenn eine User Story erledigt wurde, eine Absenkung verzeichnet wird. Ziel ist es, dass das Team auf
einen Blick ablesen kann, ob alle Stories in der vorgegebenen Zeit fertig gestellt wurden, oder sich noch Stories in
Bearbeitung befinden.
Um den Verlauf des Gesamtprojektes anzuzeigen, eignet sich der Release-Burndown-Chart. Es basiert auf den
noch offenen User Stories aus dem Product Backlog und geht somit über die Betrachtung des einzelnen Sprints
hinaus. Die Stories werden auf der y-Achse erfasst. Auf diese Weise wird angezeigt, wie viel noch bis zum Ende
des Projektes zu liefern ist[38].
3.5 Scrum - Sprint
Quelle: https://www.3m5.de/scrum/
Abbildung 6: Scrum
Der Sprint ist das wichtigste Element eines Scrum Prozesses. Ein Sprint ist ein terminiertes Zeitfenster in
welchem definierte Ziele des Product Backlogs entwickelt und fertiggestellt werden. Nach einer bestimmten
Anzahl von Sprints entsteht so ein lieferbares Produkt[39] [40]. Der Sprint selbst findet zwischen den beschriebenen
3.4.4 Burn Down Chart
10
Meetings statt.
Zu Beginn des Sprints findet das Sprint Planning Meeting statt. Dabei legen die Teammitglieder zusammen mit
dem Product Owner das Sprint Ziel fest. Das Sprint Ziel stellt das Leitmotiv für alle Beteiligten dar und fast
knapp und präzise den inhaltlichen Kern zusammen[41].
Das Ergebnis ist das Selected Product Backlog, worin festgelegt ist, wer welche Aufgabe zu welchem Zeitpunkt
übernehmen wird. Während der Dauer des Sprint folgt das Team einem gemeinsamen Fokus nach dem Prinzip,
dass immer nur eine Sache zur gleichen Zeit bearbeitet wird. Dies hat zur Folge, dass die Backlog Items nach
ihrer Priorität abgearbeitet werden und dabei immer alle Teammitglieder am gleichen Backlog Item arbeiten. So
wird sichergestellt, das immer alle Teammitglieder wissen worum es gerade geht. Alle haben den gleichen
Wissensstand und bekommen die Entwicklung der einzelnen Funktionalitäten mit. Durch dieses Vorgehen wird
verhindert, dass am Ende des Sprints alle Backlog Items angefangen, aber keins fertig gestellt worden ist[42]. Bei
einem sehr umfangreichen Entwicklungsprojekt und einer entsprechenden Teamgröße kann jedoch durch
Aufteilung eine Parallelisierung in der Abarbeitung der Backlog Items erfolgen. Das Ergebnis des Sprints ist eine
verwendbare Software, die ausgeliefert werden könnte[43].
In Anlehnung an Ralf Wirdemann (2011) S. 131
Abbildung 7: Scrum-Zeit
Der Scrum Master stimmt die Länge des Sprints mit dem Team und dem Product Owner ab. Um einen
gemeinsamen und konstanten Rhythmus zu erhalten ist die Länge der Sprints für ein Projekt in der Regel immer
gleich. Sie sollten so lang gewählt werden, dass sinnvolle Teilstücke entwickelt werden können. In der Praxis hat
sich eine Dauer von drei Wochen bewährt[44].
Ein Sprint besteht aus vier zentralen Variablen:
• Zeit
• Kosten
• Qualität
• Funktionalität
Zeit steht für die Länge des Sprints. Die Kosten bestehen im Wesentlichen aus den Gehältern der Teammitglieder
und die Qualität bezieht sich auf das Ergebnis der umzusetzenden Software. Während diese zu Beginn des Sprints
festgelegt werden und nicht mehr verhandelbar sind, ist die Funktionalität die einzige Größe, die variieren kann.
Dies geschied zum Beispiel, wenn nicht alle eingeplanten Stories fertiggestellt werden[43].
Das Team arbeitet während des Sprints selbstständig und übernimmt somit die Aufgaben des klassischen
Projektmanagers. Auftretende Problem werden an den Scrum Master berichtet und fallen in dessen
Verantwortungsbereich. Das Team arbeitet das Selected Product Backlog ab und entwickelt so die einzelnen
Stories. Der Funktionstest und die Dokumentation fallen ebenfalls in den Verantwortungsbereich des Teams.
Genauso wie die Bearbeitung von notwendigen Bugfixes. Ein häufig auftretendes Problem ist, dass viele
Teammitgliedern diese selbstständige Arbeitsweise erst erlernen müssen. Hier steht aber der Scrum Master
helfend zur Seite[45].
3.5 Scrum - Sprint
11
Der Scrum Master unterstützt das Team, damit das Ziel so schnell wie möglich erreicht werden kann. Er stellt
sicher, dass alle Teammitglieder ihre Aufgaben erledigen und sorgt dafür das, das Team zusammenwächst[46].
Der Product Owner sollte während der gesamten Laufzeit immer zur Verfügung stehen. Er ist der
Ansprechpartner wenn es um Fragen der Umsetzung der User Stories geht. Er bestimmt wann eine User Story
fertig ist und ist verantwortlich für die Durchführung von Akzeptanztests, in denen eine Story hinsichtlich ihres
Funktionsumfanges überprüft wird. Der Product Owner bestimmt in Release Sprints des Weiteren, ob ein fertiges
Release an den Kunden ausgeliefert wird und produktiv geht[47]. Es gibt keine feste einheitliche Definition, wann
eine User Story vollständig fertig gestellt ist. Diese Definition erstellt jedes Team am Anfang eines Projektes
selbst. Häufig werden zum Beispiel folgende Kriterien herangezogen:
• Die User Story ist programmiert und erfüllt die festgelegten Anforderungen
• Die User Story ist erfolgreich in das Gesamtsystem integriert wurden
• Der Akzeptanztest wurde erfolgreich durchgeführt[48]
3.6 Scrum - Prozess
Jedes Scrum Projekt beginnt mit einer Vision, einer zentralen Idee für ein Vorhaben. Der erste Schritt besteht
darin, dass der Product Owner diese Kernidee und die Basisfunktionalität auf einem Konzeptpapier
zusammenfasst. Anschließend entsteht das Product Backlog, der zentrale Anforderungskatalog, bei dem jeder
Listeneintrag eine User Story ist[49].
Die priorisierte Liste von Einträgen wird nun auf den jeweiligen Aufwand geschätzt. Bei der Schätzung der
benötigten Personentage ist das Team beteiligt. Dies hat zur Folge, dass an dieser Stelle im Projekt alle Beteiligen
genau wissen, wie das gewünschte Produkt auszusehen hat. Das Projekt wird in einer festen Anzahl von Sprints
abgeschlossen. Am Ende eines jeden dieser zeitlich begrenzten Intervalle, ist ein Stück funktionierende Software
fertiggestellt. Die Planungsphase am Anfang eines jeden Sprints wird in zwei Teile auf gesplittet. Im Sprint
Planning Meeting I ist vergleichbar mit einem Briefing und Anforderungsworkshop. Alle Softwareanforderungen
werden detailiert besprochen und das Selected Product Backlog entsteht. Es ist das Ergebnis des Planning
Meeting I und beinhaltet alle Product Backlog Items die im anstehenden Sprint bearbeitet werden sollen. Im
Sprint Planning Meeting 2 wird bereits besprochen wie die Anforderungen konkret umgesetzt werden sollen.
Diese Aufgabenliste ist das Sprint Backlog[50].
Das Team erarbeitet und entwickelt während des Sprint völlig selbständig die geforderten Funktionalitäten. Es
finden täglich kurze Statusmeeting, die sogenannten Daily Scrum, statt. Am Ende des Sprints findet das Sprint
Review Meeting statt. Hier wird der Fortschritt des Projektes demonstriert und das bis hierhin entstandene
Produkt begutachtet[51]. Während des Sprints erarbeiten die Teammitglieder gemeinsam mit dem Product Owner
bereits die Aufgabenliste für den nächsten Sprint. Am Ende des Sprints erfolgt im Sprint Review Meeting die
Präsentation der funktionierenden Software.
Nach dem Sprint Review führen die Teamitglieder selbstständig eine Analyse der eigenen Arbeitsprozesse durch.
Diese Sprint Retrospektive soll zur ständigen Prozessoptimierung beitragen[52].
3.6 Scrum - Prozess
12
4 Bewertung des Projekts
Die Fallstudie hat gezeigt, dass sich die Lernmethode Blended Learning mit dem Konzept eines eBooks für die
Vermittlung der Inhalte der Softwareentwicklungsmethode Scrum im Rahmen agiler Projektmethoden eignet.
Im Hauptteil des eBooks können die Grundlagen von Scrum und dessen Ablauf ausführlich beschrieben werden.
Im Anhang befinden sich die Kontrollfragen, die das selbstgesteuerte Lernen fördern und einen hohen Lernerfolg
sicherstellen.
Die Technologie für eBooks ist weit entwickelt und weit verbreitet. Das Lesen ist nicht nur auf dem heimischen
Computer, sondern auch unterwegs mit Hilfe von Tablets und Smartphones jederzeit möglich. Somit ist der Leser
sehr flexible beim Zugriff auf die Inhalte und kann sich ganz nach seinem persönlichen Tagesablauf flexible mit
dem Thema Scrum befassen.
5 Schlussbetrachtung
Es wurden im Verlauf der Fallstudie vier zentrale Punkte für die Bewertung erkennbar:
• Personal
• Kommunikationsaufwand
• Regelwerk
• Erfolgschancen
Ein Unterschied in der Personalstruktur entsteht durch die in Scrum klar definierten Rollen. Während es in
klassischen Projektstrukturen nur einen Projektmanager und ein Team gibt, existieren hier drei Hauptrollen. Die
Aufgaben von ProductOwner, Scrum Master und dem Team sind klar vorgegeben. Für den Projekterfolg ist es
zwingend, dass die Rollen mit den richtigen Personen besetzt werden und diese somit gemäß den Vorgaben gelebt
werden. Wenn dies der Fall ist, wird ein qualitativ hochwertiges Ergebnis erzielt.
Die Kommunikation ist ein zentraler Baustein von Scrum. Es gibt definierte Meetings, die durchlaufen werden.
Ebenso ist die Kommunikation ein wesentlicher Punkt innerhalb des Teams während des Sprints. Der
Mehraufwand im Vergleich zu klassischen Methoden wird jedoch durch das Ergebnis gerechtfertigt. Durch die
stetige Kommunikation kann das Team schneller Probleme erkennen und beseitigen. Des Weiteren hat jedes
Teammitglied den gleichen Wissenstands und es wird eine hohe Qualität beim Endprodukt erreicht. Die
Kommunikation in Richtung Customer ist ebenfalls sehr stark ausgeprägt. Er erhält dadurch viel Transparenz
während der Entwicklungsphase und dann schnell Änderungen durchbringen.
Das Regelwerk von Scrum ist nicht sehr komplex. Es gibt nur wenige einfache Rahmenbedingungen vor. Es stellt
den Beteiligen kein starres Umfeld zur Verfügung, sondern einen flexiblen Prozess, der durch seine verwendeten
Mittel die Kreativität fördert und bei Veränderungen im Prozess ohne Probleme angepasst werden kann.
4 Bewertung des Projekts
13
In Anlehnung an Boris Gloger (2011), Seite 44
Abbildung 8: PDCA-Zyklus
Für den Erfolg von Scrum ist es wichtig, dass das kleine Regelwerk eingehalten und die definierten Rollen
entsprechend gelebt werden. Ist dies der Fall erhält man ein hochwertiges Endprodukt und eine hohe
Kundenzufriedenheit. Eine Studie der Otto-von-Gueriche-Universität in Magdeburg zeigt jedoch, dass 32% der
Projekte nicht erfolgreich waren. Einer der Hauptgründe wurde in der Größe des Teams identifiziert[53].
Scrum setzt dabei den PDCA-Zyklus aus dem Qualitätsmanagement um.
• Plan (Planen): Die Zielsetzung und Planung erfolgt in den Sprint Planning Meetings
• Do (Ausführen): Im Sprint werden die Funktionalitäten entwickelt und somit die Ziele erreicht
• Check (Kontrlollieren): Im Sprint Review Meeting wird die Zielerreichung überprüft
• Act (Verbessern): Im Sprint Retrospektive Meeting erfolgt eine Analyse der Prozesse und Abläufe und
die erarbeiteten Optimierungen werden für den nächsten Durchlauf berücksichtigt[54].
6 Kontrollfragen
6.1 Fragen
Frage 1: Welche der folgenden Aussagen über die beteiligten Rollen sind korrekt?
1. Das Team arbeitet selbstständig und legt auch das Arbeitsvolumen selbst fest.
2. Der Product Owner übernimmt sowohl die fachliche als auch disziplinarische Führung des Teams.
3. Der Scrum Master ist der Vermittler zwischen Product Owner und Team.
4. Der Scrum Master entscheidet, ob eine Funktionalität fertig entwickelt ist.
5. Der Product Owner vertritt während des Scrum Prozessen die Kundenwünsche.
Frage 2: Wer ist für die Erstellung und Pflege des Product Backlog verantwortlich?
1. Das Team
2. Der Product Owner
3. Der Scrum Master
4. Der Customer
5. Das Management
5 Schlussbetrachtung
14
Frage 3: Welche der folgenden Aussagen über die Meetings sind korrekt?
1. Beim Sprint Planning Meeting nimmt das Team teil, hat aber kein Mitspracherecht.
2. Im Sprint Planning Meeting 2 wird die Durchführung der im ersten Meeting festgelegten Ziele
besprochen.
3. Das Daily Standup Meeting dient hauptsächlich dem Informationsaustausch für das Team und wird vom
Scrum Master moderiert.
4. Das Sprint Review Meeting ist eine Präsentation der bis dahin erfolgreich entwickelten Software.
5. Beim Sprint Retrospektive Meeting werden die Arbeitsabläufe vom Scrum Master analysiert und
optimiert.
Frage 4: In welchem Meeting entsteht das Sprint Backlog?
1. Daily Standup Meeting
2. Sprint Planning Meeting I
3. Sprint Planning Meeting II
4. Sprint Review Meeting
5. Sprint Retrospektive Meeting
Frage 5: Welche der folgenden Aussagen über die Artefakte sind korrekt?
1. Das Product Backlog wird täglich aktualisiert.
2. Das Product Backlog ist eine Liste von zu entwickelnden Funktionalitäten geordnet nach ihrer Priorität.
3. Die einzelnen User Stories sind sehr detailliert beschrieben und enthalten technische
Umsetzungsmöglichkeiten.
4. Das Sprint Backlog enthält alle Aufgaben für das Team für die Gesamtlaufzeit des Projektes.
5. Burn Down Charts dienen der Kontrolle und dem Reporting und können verschiedene Projektthemen
grafisch darstellen.
Frage 6: In welchem Artefakt dienen die User Stories in ihrer ursprünglichen Fassung als Datenbasis?
1. Product Backlog
2. Selected Product Backlog
3. Sprint Backlog
4. Sprint Burndown Chart
5. Release Burndown Chart
Frage 7: Welche der folgenden Aussagen über den Sprint sind korrekt?
1. Das Ergebnis eines Sprint ist eine fertig entwickelte Funktionalität.
2. Die Länge der unterschiedlichen Sprints in einem Projekt ist i.d.R. gleich um einen Rhythmus
einzuhalten.
3. Der Scrum Master stimmt die Länge des Sprints mit dem Team und dem Product Owner ab.
4. Das Team arbeitet selbständig die vereinbarte Aufgabenliste des Sprint Backlogs ab.
5. Der Product Owner ist nur am Ende des Sprints beteiligt um die Fertigstellung zu prüfen.
Frage 8: Was sind zentrale Bausteine von Scrum?
1. Kommunikation
2. ein sehr aufwendiges und komplexes Regelwerk
3. klar definierte Rollen
6.1 Fragen
15
4. eigenständige und eigenverantwortliche Teamarbeit
5. Flexibilität
6.2 Lösungen
Frage 1:
• Antwort 1: richtig
• Antwort 2: falsch, der Product Owner ist lediglich der fachliche Projektleiter. Das Team arbeitet
selbstständig.
• Antwort 4: falsch, dies fällt in die Verantwortung des Product Owners
Frage 2:
• Antwort 2: Der Product Owner ist korrekt
Frage 3:
• Antwort 1: falsch, es bestimmt aktiv welche Menge an User Stories im nächsten Sprint bearbeitet wird
• Antwort 5: falsch, diese Aufgabe findet teamintern statt
Frage 4:
• Antwort 3: Sprint Planning Meeting II ist korrekt
Frage 5:
• Antwort 1: falsch, das Sprint Backlog wird täglich aktualisiert
• Antwort 3: falsch, User Stories beschreiben die gewünschte Funktion aus Sicht des Customers und sind
nicht technisch formuliert
• Antwort 4: falsch, es sind nur die Aufgaben für jeweils einen Sprint erfasst
Frage 6:
• Antwort 3: falsch, hier handelt es sich bereits um konkrete Aufgabenformulierungen
• Antwort 4: falsch, hier geht es um den Gesamtaufwand in Stunden
Frage 7:
6.2 Lösungen
16
• Antwort 5: falsch, er steht während des gesamten Sprints für Fragen bei der Umsetzung bereit
Frage 8:
• Antwort 2: falsch, es handelt sich hier um ein einfaches und kurzes Regelwerk
7 Abbildungsverzeichnis
Abbildung
Beschreibung
1
INVEST-Kriterien
2
Vom Product Backlog zum Sprint Backlog
3
Sprint-Burndown-Chart
4
Product-Burndown-Chart
5
Release-Burndown-Chart
6
Scrum
7
Scrum-Zeit
8
PDCA-Zyklus
8 Fußnoten
1. ? vgl. http://www.scrum-kompakt.de/ Zugriff 03.06.2012
2. ? vgl. http://www.blended-learning-network.eu/index_de.php Zugriff 03.06.2012
3. ? vgl. http://www.it-agile.de/wasistagilesoftwareentwicklung.html Zugriff 29.05.2012
4. ? vgl. Henning Wolf / Wolf-Gideon Bleek (2011), S. 10-11
5. ? http://www.agilemanifesto.org/iso/de/ Zugriff 29.05.2012
6. ? vgl. http://scrum-kompakt.de/ Zugriff 20.05.2012
7. ? 7,0 7,1 vgl. Boris Gloger (2011), S. 10
8. ? vgl. http://scrum-fibel.de/ Zugriff 20.05.2012
9. ? Ralf Wirdemann (2011), S. 10
10. ? vgl. Boris Gloger (2011) S. 78-87
11. ? Boris Gloger (2011), S. 14
12. ? vgl. Boris Gloger (2008), S. 14
13. ? vgl. Ken Schwaber, Jeff Sutherland (2011), S. 7
7 Abbildungsverzeichnis
17
14. ? 14,0 14,1 vgl. Boris Gloger (2008), S. 15
16. ? vgl. Ralf Wirdemann (2011), S. 45
17. ? vgl. Boris Gloger (2011), Seite 15
18. ? 18,0 18,1 vgl. Boris Gloger (2008), S. 15-16, 191-197
19. ? vgl. Boris Gloger (2008), S. 15, 193
20. ? 20,0 20,1 20,2 vgl. Boris Gloger (2008), S. 15-16, 193-194
21. ? vgl. Boris Gloger (2008), S. 16, 200-205
22. ? Boris Gloger (2008), S. 200
23. ? vgl. Boris Gloger (2008), S. 200-201
25. ? vgl. Boris Gloger (2008), S. 16, 208
26. ? vgl. Ralf Wirdemann (2011), Seite 31
31. ? vgl. Ralf Wirdemann (2011), Seite 198ff
32. ? 32,0 32,1 Boris Gloger (2008), S. 17
34. ? vgl. Henning Wolf / Wolf-Gideon Bleek (2011), S. 162
35. ? vgl. http://www.mountaingoatsoftware.com/system/presentation/file/35/UserStoriesXPAtlanta.pdf,
Seite 28
36. ? vgl. Ralf Wirdemann (2011), S. 144f
37. ? vgl. Andrew Pham, Phuong-Van Pham (2011), S. 9-10
38. ? vgl. Boris Gloger (2011), S. 207-213.
39. ? vgl. Boris Gloger (2008), S. 12-14, 181-183
43. ? 43,0 43,1 vgl. Ralf Wirdemann (2011); S. 150
45. ? Boris Gloger (2011), S. 193f
48. ? vgl. Ralf Wirdemann (2011), S.155
49. ? vgl. Ralf Wirdemann (2011), Seite 9
50. ? vgl. Boris Gloger (2011), Seite 12f
51. ? vgl. Ken Schwaber / Mike Beedle (2002),Seite 10
53. ? vgl.
http://www.pentaeder.de/wp-content/uploads/Einfluss_agiler_Praktiken_auf_Teammerkmale_und_Erfolg_von_So
9 Literatur- und Quellenverzeichnis
Literaturquellen
8 Fußnoten
18
Boris Gloger (2011)
Boris Gloger (2008)
Ralf Wirdemann (2011)
Ken Schwaber / Mike Beedle
(2002)
Henning Wolf / Wolf-Gideon
Bleek (2011)
Andrew Pham / Phuong-Van
Pham (2011)
Boris Gloger: Scrum: Produkte zuverlässig und schnell entwickeln; 3. Auflage;
Carl Hanser Verlag; München
Boris Gloger: Scrum: Produkte zuverlässig und schnell entwickeln; 1. Auflage;
Carl Hanser Verlag; München
Ralf Wirdemann: Scrum mit User Stories; 2. Auflage; Carl Hanser Verlag;
München
Ken Schwaber / Mike Beedle: Agile Software Development with Scrum;
Prentice Hall Verlag; New Jersey
Henning Wolf / Wolf-Gideon Bleek: Agile Softwareentwicklung; 2.aktualisierte
Auflage; dpunkt Verlag; Heidelberg
Andrew Pham / Phuong-Van Pham: Scrum in Action; Delmar Cengage
Learning Verlag; Clifton Park
Internetquellen
• http://borisgloger.com/scrum/
• http://scrum-master.de/
• http://www.scrum-kompakt.de/
• http://scrum-fibel.de/
• http://www.agilemanifesto.org/iso/de/
• http://www.it-agile.de/
• http://www.pentaeder.de/wp-content/uploads/Einfluss_agiler_Praktiken_auf_Teammerkmale_und_Erfolg_von_So
• http://www.mountaingoatsoftware.com/system/presentation/file/35/UserStoriesXPAtlanta.pdf
9 Literatur- und Quellenverzeichnis
19

Inhaltsverzeichnis

Transcription

Similar documents

Automodell Rennsport Automodell Rennsport

Der fröhliche Kreis - Bundesarbeitsgemeinschaft

Inhaltsverzeichnis

Organisationsuntersuchung - Management consult GmbH

MANAGE AGILE 2014

Product Canvas

4 Die Bedienkonzepte von Windows 8

Für Alle Erfolg in Intranetprojekten dank User

Mediale Lernwerkzeuge nutzen