Das Thema dieser Fallstudie ist die Einführung eines agilen Softwareentwicklungsprozesses nach der Methodik von Scrum in einem Unternehmen, das bisher nach dem Wasserfallmodell gearbeitet hat.
Hierfür werden in dieser Arbeit die notwendigen Artefakte, Rollen, Meetings und Vorlagen erstellt und aus Sicht eines Scrum-Masters beschrieben, die benötigt werden um ein Projekt mit Scrum durchzuführen.
Des Weiteren werden die für diesen Prozess benötigte Teamstruktur entlang der Vorgaben für diese Fallstudie ausgearbeitet und erläutert.
Projektvorgaben:
1 - Das Team besteht aus drei Entwicklern, davon zwei mit 100% Auslastung (Arbeitszeit) und einer mit nur 80%
2 - Ein einzelner Sprint hat eine Dauer von 14 Kalendertagen.
3 - Jeder Release Candidate (RC) wird sofort nach Erstellung getestet.
4 - Jeder Sprint beinhaltet die üblichen (bereits automatisierten) Regressionstests, sowie Last- und Performance (LuP) Tests.
5 - Das Projekt ist laut Planung nach Beenden des zehnten Sprints abgeschlossen.
6 - Das Team sitzt nicht räumlich getrennt und es sind keine Urlaube geplant.
Es werden konkrete Beispiele und Berechnungen zur tatsächlichen Arbeitszeit (inklusive Pufferzeiten), sowie Vorlagen zu den diversen Managementartefakten (Scrum-Board, Burndown-Chart, etc.) gezeigt.
Inhaltsverzeichnis
Tabellenverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Aufgabenstellung, Zielsetzung, Rahmenbedingungen
2 Ressourcenplanung
2.1 Rollenplanung
2.2 Zeitplanung
2.3 Projektplan
3 Managementartefakte
3.1 Product Backlog
3.2 Sprint Backlog
3.3 Burn Down Chart
3.4 Scrum Board
4 Meetings
4.1 Sprint Planung
4.2 Daily Serum
4.3 Sprint Review
4.4 Retrospektive
5 Fazit
Glossar
Literaturverzeichnis
Gender Erklärung
Aus Gründen der leichteren Lesbarkeit wird in der vorliegenden Fallstudie die männliche Sprachform bei personenbezogenen Substantiven und Pronomen verwendet. Dies impliziert jedoch keine Benachteiligung des weiblichen Geschlechts, sondern soll im Sinne der sprachlichen Vereinfachung als geschlechtsneutral zu verstehen sein
Tabellenverzeichnis
Tabelle 1: Rahmenbedingungen / Projektvorgaben
Tabelle 2: Rollenverteilung
Abbildungsverzeichnis
Abbildung 2-1: Darstellung Zeiten (eigene Darstellung)
Abbildung 3-1 Excel-Beispiel UserStorys
Abbildung 3-2: Beispiel für ein Sprint Backlog (kostenlose Testversion von https://de.atlassian.com/software/jira)
Abbildung 3-3: Beispiel für ein Sprint Backlog Element (kostenlose Testversion von https://de.atlassian.com/software/jira)
Abbildung 3-4: Beispiel für ein Burn Down Chart (kostenlose Testversion von https://de.atlassian.com/software/jira)
Abbildung 3-5 Beispiel für ein Serum Board (kostenlose Testversion von https://de.atlassian.com/software/jira)
Abkürzungsverzeichnis LuP-Test: Last- und Performance Tests RC: Release Candidate
1 Einleitung
Diese Fallstudie entsteht im Rahmen des Bachelorstudiengangs Wirtschaftsinformatik im Kurs Agiles Softwareengineering. Das Thema ist die Einführung eines agilen Softwareentwicklungsprozesses nach der Methodik von Serum in einem Unternehmen, das bisher nach dem Wasserfallmodell gearbeitet hat. Hierfür werden in dieser Arbeit die notwendigen Artefakte, Rollen, Meetings und Vorlagen erstellt und aus Sicht eines Serum-Masters beschrieben, die benötigt werden um ein Projekt mit der agilen Vorgehensweise Serum durchzuführen. Des Weiteren werden die für diesen Prozess benötigte Teamstruktur ausgearbeitet und beschrieben.
1.1 Aufgabenstellung, Zielsetzung, Rahmenbedingungen
Zielsetzung der Fallstudie ist es, einen kompletten Serum-Prozess für ein Team zu beschreiben. Der erarbeitete Prozess soll ermöglichen, dass damit unmittelbar anschließend ein Projekt durchgeführt werden könnte, welches die beschriebenen Vorgehensweisen und Vorlagen produktiv einsetzt. Die Aufgabenstellung beinhaltet konkrete Vorgaben hinsichtlich der geplanten Projektdauer, Personalressourcen sowie einzelne Vorgaben für den Entwicklungsprozess.
Abbildung in dieser leseprobe nicht enthalten
Tabelle 1: Rahmenbedingungen / Projektvorgaben
2 Ressourcenplanung
Für die Dauer des Projekts stehen dem Serum-Master folgende drei Entwickler uneingeschränkt mit folgenden Zeiten zur Verfügung:
Herr Müller (40-Std. Woche)
Herr Bauer (40-Std. Woche)
Frau Maier (32-Std. Woche, freitags abwesend)
2.1 Rollenplanung
Ein Scrum-Team besteht aus drei Rollen: ScrumMaster, Product Owner und das Team (Boris Gloger 2010). Diese Rollen werden im Folgenden erläutert und auf die Projektmitglieder der Fallstudie aufgeteilt.
Abbildung in dieser leseprobe nicht enthalten
2.2 Zeitplanung
Die Entwicklung erfolgt in 14-tägigen Entwicklungszyklen (Sprints). Dadurch ergeben sich folgende Kapazitäten:
Pro Sprint: 28 Personentage (2x5 Arbeitstage X zwei Personen, 2x4 Arbeitstage eine Person)
Gesamtprojekt: 280 Personentage (Personentage pro Sprint X Anzahl geplanter Sprints)
Für die Umsetzung aller offenen Anforderungen stehen also planmäßig 280 Personentage Entwicklungskapazität zur Verfügung. Diese Gesamtzeit kann sich jedoch durch ungeplante Tätigkeiten oder äußere Umstände wie beispielsweise Verwaltungstätigkeiten, dringende Supporttätigkeiten oder Krankheiten reduzieren. Außerdem sind gewisse Zeiten für Regelmeetings, die im Abschnitt 4 Meetings näher erklärt werden, vorgesehen.
Für die endgültige Planung wird demnach ein Puffer einbezogen, welcher diese nicht planbaren Zeiten abzubilden versucht und die tatsächlich für das Projekt zur Verfügung stehende Zeit realistischer wiederspiegeln soll. Als Faktor wird zu Beginn des Projekts der Wert 0,7 für den ersten Sprint festgelegt. Hierbei muss beachtet werden, dass am Ende jedes Sprints zu bewerten ist, ob der Puffer angemessen und ausreichend ist, oder ob dieser für zukünftige Planungen angepasst werden muss. Dabei können durchaus individuelle Abweichungen innerhalb des Teams bestehen. Aufgrund dieser Überlegungen ergeben sich folgende voraussichtliche Zeiten:
Pro Sprint: 28 PT X 0.7 (vori. Puffer) = 19,6 PT
Gesamtprojekt: 280 PT X 0.7 (vori. Puffer) = 196 PT
2.3 Projektplan
Zur Visualisierung der im vorherigen Abschnitt ermittelten Zeiten kann folgendes Schaubild helfen:
Abbildung in dieser leseprobe nicht enthalten
Abbildung 2-1: Darstellung Zeiten (eigene Darstellung)
Auf einen klassischen Projektplan sowie eine Meilensteinplanung wird an dieser stelle verzichtet. Die daraus entspringenden Erkenntnisse sollen, durch die im folgenden Abschnitt vorgestellten Managementartefakte geliefert werden.
3 Managementartefakte
Zur Nachverfolgung und Visualisierung des Projektstatus, sowie dem Stand der aktuellen Tätigkeiten, werden die in den nachfolgenden Kapiteln erläuterten und von Serum vorgesehenen Hilfsmittel wie folgt implementiert.
3.1 Product Backlog
Das Product Backlog ist eine priorisierte Liste mit allen gegenwärtig bekannten Anforderungen, die für das zu erstellende Produkt benötigt werden. Es liegt in der Verantwortung des Product Owners und ist unter anderem dadurch gekennzeichnet, dass es niemals vollständig ist. Es ist dynamisch und entwickelt sich mit dem Produkt und der Umgebung, in der es sich befindet. (Schwaber und Sutherland 2018). Dabei ist zu beachten, dass ebenfalls Arbeiten die zur Verbesserung des Prozesses oder zur Vermeidung oder dem Abbau von technischen Schulden notwendig sind, als Product Backlog Elemente aufgenommen werden. Anhand von kontinuierlichem Feedback der Stakeholder im Rahmen der später erläuterten Sprint Reviews, können neue Elemente entstehen, oder verfeinert werden. Ebenso können bereits erfasste Elemente entfernt werden. Diese Tätigkeiten zur Pflege werden häufig auch als ״grooming“ bezeichnet.
Für das umzusetzende Projekt sollen die Anforderungen in User-Storys formuliert werden und anhand einer Risiko-Wert-Matrix priorisiert werden. Die Vorlage zur Formulierung der User-Story gestaltet sich dabei wie folgt:
Abbildung in dieser leseprobe nicht enthalten
Abbildung 3-1 Excel-Beispiel User Storys
Die Erfassung erfolgt vorerst in einer Excel Liste. In Zukunft soll dies jedoch im für das Serum Board verwendete Tool Jira untergebracht werden.
Die Spalten ergeben sich dabei wie folgt:
ID = Eine projektspezifische ID, die es erlaubt die Anforderung eindeutig zu identifizieren.
Als (Rolle) = Die Person bzw. Rolle, für die eine bestimmte Funktionalität geschaffen werden soll. Die Rollen der Anwender sollten dabei vorab identifiziert werden.
Möchte ich (Feature) = Eine kurze Beschreibung der erwarteten Funktionalität bzw. des Features. Diese Spalte ist auf 100 Zeichen begrenzt, um die kurze Darstellung als möglichst granulare UserStory zu fördern.
Um (Ziel) = Der Grund, warum diese Funktionalität benötigt wird. Welcher Zweck wird damit verfolgt? Auch hier besteht eine Begrenzung auf 100 Zeichen um bei der Formulierung schon dazu gezwungen zu werden, sich auf das wesentliche zu konzentrieren.
Akzeptanzkriterien = Wann erachtet der Anwender diese Anforderung als erfüllt, bzw. welche Eigenschaften sind für die Abnahme mindestens notwendig.
Priorität = Wie wichtig ist diese Anforderung? Hier wird der durch die Risiko-Wert-Matrix ermittelte Wert in eine Priorität umgerechnet. Dies ist der wesentliche Indikator wann diese Story umgesetzt werden sollte.
Ersteller = Von wem wurde die Funktionalität gewünscht? In diesem Projekt werden die User Storys ausschließlich vom Product Owner Hr. Mustermann erfasst. Hier sollte die Person vermerkt werden, welche ausschlaggebend für diese Erfassung war, um für ggf. auftretende Rückfragen einen Ansprechpartner benennen zu können.
Story Points = In dieser Spalte kann der Product Owner vorab eine Schätzung eintragen. Die abschließende Anzahl an Story Points wird jedoch von den Entwicklern im Rahmen der Sprint Planung vergeben.
3.2 Sprint Backlog
Das Sprint Backlog beinhaltet diejenigen User Storys, die im Rahmen der Sprint Planung dem jeweiligen Sprint zugewiesen werden um das geplante Sprint Ziel zu erreichen. Dabei wird für jedes übernommene Element eine Zeitschätzung durch die Entwickler durchgeführt. Das Sprint Backlog kann nur durch das Entwicklungsteam verändert werden. Durch die kontinuierliche Aktualisierung der Restarbeitszeiten, liefert es ein gutes Echtzeitbild der im Sprint zu erledigenden Arbeiten. Das Team verfolgt und managt den Fortschritt dabei während den Daily Serum Meetings (Schwaber & Sutherland, J. 2018).
Bei der Übernahme der Product Backlog Elemente in das Sprint Backlog, werden diese in das Tool Jira übernommen. Ein exemplarisches Sprint Backlog sollte wie folgt aussehen:
Abbildung in dieser leseprobe nicht enthalten
Abbildung 3-2: Beispiel für ein Sprint Backlog (kostenlose Testversion von https ://de. atlassi an. com/software/iira )
Ein Sprint Backlog Element wird dabei auf folgende Eingabemaske angelegt:
[...]
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.