Anwendung agiler Methoden. Aufbau eines Einsatzmonitorsystems mit dem agilen Managementframework Scrum

I. Inhaltsverzeichnis

I. Inhaltsverzeichnis

II. Abbildungsverzeichnis

III. Abkürzungsverzeichnis

1. Einleitung
1.1. Produktvision
1.2. Projektrahmendefinition
1.3. Projektressourcen und Rollenverteilung
1.4. Projektplanung

2. Projektdurchführung
2.1. Aufbau der Iterationen
2.2. Verwalten von Anforderungen
2.2.1. Product Backlog und User-Sories
2.2.2. Sprint Backlog
2.2.3. TASK-Board und Daily Scrum
2.2.4. Burndownchart
2.3. Projekt Meetings und Absprachen
2.3.1. Sprint Planning Meeting 1
2.3.2. Sprint Planning Meeting 2
2.3.3. Sprint Review
2.3.4. Sprint Retrospektive

3. Zielerreichung und Reflexion der Projektarbeit

V Glossar

VI. Literaturverzeichnis

VII. Anhang

II. Abbildungsverzeichnis

Abbildung 1: Übersicht über die Aktivitäten und Artefakte in Scrum (Timinger, Holger 2017, S.166)

Abbildung 2: Aufbau einer User Story (Timinger, Holger 2017, S. 166)

Abbildung 3: Ausschnitt aus dem Product Backlog (eigene Darstellung)

Abbildung 4: Ausschnitt aus dem Sprint Backlog (eigene Darstellung)

Abbildung 5: Arbeiten mit dem Taskboard (Gloger, B., & Margetich, J. 2018, S. 168)

Abbildung 6: Burndownchart aus diesem Projekt (eigene Darstellung)

Abbildung 7: Screenshot Produkt Einsatzmonitor

III. Abkürzungsverzeichnis

OCR: optical character recognition

MS: Microsoft

1. Einleitung

Dieser Projektbericht wird im Rahmen des Studienganges „Bachelor of Science Wirtschaftsinfor­matik“ an der IUBH Internationale Hochschule GmbH im Kurs „Agiles Software Engineering“ (IWNF02) verfasst. Er bildet die Durchführung eines Projektes, unter Anwendung agiler Methoden, als Projektdokumentation ab. Im Vordergrund stehen nicht die Programmierung bzw. Implementie­rung an sich, sondern die Anwendung der Agilen Methode und deren Artefakte. Für die Realisie­rung des Projekts habe ich das Vorgehensmodell Scrum gewählt. Dieses Vorgehensmodell kann zusammengefasst wie folgt beschrieben werden: „Scrum [skr A m] ist ein agiles Management­framework zur Entwicklung von Software, das aus wenigen klaren Regeln besteht. Diese beinhal­ten die Anwendung der drei Rollen Product Owner, Team und ScrumMaster, die Verwendung ei­nes priorisierten Product Backlog sowie das Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, die Sprints genannt werden“ (Pichler, Roman 2013, S. 1). Die Umsetzung des Ma­nagementframeworks und der sich daraus ergebenden Rollen und Managementartefakte wird im Berichtsverlauf erläutert.

1.1. Produktvision

Ziel bzw. Vision der Projektarbeit ist es, einen lauffähigen Einsatzmonitor für eine Freiwillige Feuer­wehr zu installieren, zu konfigurieren und an das Alarmsystem anzubinden. Dieser soll nach einer Alarmierung alle relevanten Daten zum vorliegenden Einsatz auf einem Bildschirm im Gerätehaus darstellen. Dazu gehört mindestens eine Adresse, ein Alarmstichwort und eine Visualisierung des kürzesten Weges zum Einsatzort. Der Einsatzmonitor soll die Einsatzkräfte schneller und übersicht­licher mit Informationen versorgen und zusätzlich die Anfahrt zum Schadensereignis erleichtern. Dies hilft dabei Zeit zu sparen und somit Menschenleben zu retten.

1.2. Projektrahmendefinition

Das Projekt wird unter den folgenden Rahmenbedingungen durchgeführt:

- Durchführung im Ehrenamt, nach der regulären Arbeitszeit
- Ressourcen: zwei Entwickler, ein Softwarearchitekt
- Ein Sprint dauert 14 Tage
- Iterative Regressionstests soweit als möglich
- Auf Grund der Durchführung im Ehrenamt, sitzt das Team räumlich getrennt
- Kommunikation über Telefon oder Skype
- Besonderheit: ein Entwickler nimmt gleichzeitig die Rolle des Scrum Masters wahr
- Projektkosten nach Minimalprinzip, da Produkt für eine Hilfsorganisation
- Beginn 02.01.2020
- Ende 06.06.2020
- Ausfallzeiten und Puffer werden mit 25 % der Verfügbaren Ressourcen festgesetzt (z.B. Ur­laub, Krankheit, etc.)

1.3. Projektressourcen und Rollenverteilung

„Scrum kennt drei Rollen: Product Owner, Team und ScrumMaster. Alle drei Rollen müssen adäquat besetzt sein und eng zusammenarbeiten, um ein Scrum Projekt zum Erfolg zu führen“ (Pichler, Roman 2013, S. 9).

Im Folgenden wird die Rollenbesetzung und deren jeweilige Verfügbarkeit mit Aufgabenbereich be­schrieben.

- Die Rolle des Product Owners wurde durch Herrn G. wahrgenommen. Herr G. ist 14 Stunden in der Woche für das Projekt verfügbar. In der Ausfüllung seiner Rollen nimmt er folgende Aufgaben war: „Der Product Owner in Scrum repräsentiert die Endkundenbedürfnisse, steuert die Softwareentwicklung und arbeitet mit dem Team über den gesamten Projektverlauf eng zusammen“ (Pichler, Roman 2013, S. 9).

Der Product Owner generiert somit hauptsächlich die Anforderungen in einem Softwarepro­jekt.

- Das Team wird von den Herren K., M. und Kaiser besetzt. Herr K. und Herr M. können ihre Rolle mit jeweils 14 Stunden pro Woche ausfüllen, Herr Kaiser mit 9 Stunden. Die Aufgaben des Teams können wie folgt beschrieben werden: „Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare Produktinkremente notwendig sind“ (Pichler, Roman 2013, S. 13). „Das Team entscheidet allein, wie viele Anforderungen es innerhalb des nächsten Sprints in ein Produktinkrement umwandeln kann“ (Pichler, Roman 2013, S. 14).

- Die Rolle Scrum Master wird von Herrn Kaiser besetzt. Für diese Funktion steht er 5 Stunden pro Woche zur Verfügung. Der Scrum Master erfüllt hauptsächlich die folgenden Funktionen: „Als Scrum Master unterstützen Sie beispielsweise den Product Owner beim Erstellen des Product Backlog oder stellen sicher, dass das Team die notwendige Testumgebung erhält. Anders gesagt: Als ScrumMaster helfen Sie den Projektmitarbeitern, ihre Aufgaben effektiv zu erledigen. Er schützt das Team vor externen Einflüssen“ (Pichler, Roman 2013, S. 20).

Aus den Rollenbeschreibungen ergibt sich die Besonderheit, dass Herr Kaiser sowohl die Rolle als Scrum Master wahrnimmt und aber auch aktiv im Team mitarbeitet. Dies ist normalerweise nicht vorgesehen, lies sich allerdings auf Grund der fehlenden weiteren Ressourcen nicht anders reali-sieren.

1.4. Projektplanung

Die Projektplanung im agilen Umfeld lässt sich in einem kurzen Satz wie folgt beschreiben: „Wir verzichten auf die Gesamtprojekt-Planung und planen, das was wir überschauen, und das ist die Iteration“ (Hans W. Wieczorrek 2010, S. 170). Daraus wird bereits ersichtlich, dass es keine detail­lierte Projektplanung von Projektbeginn bis Projektende gibt.

Um jedoch dem Projekt eine Struktur zu geben, wird zum Projektstart eine Projektgrobplanung mit den bekannten Rahmenbedingungen durchgeführt. Dies ergibt zumindest einen Anhaltspunkt über die theoretisch zur Verfügung stehenden Iterationen und macht es möglich theoretische Meilen­steine auf bestimmte Iterationen zu setzen.

Das Projekt beginnt am 06.01.2020 und endet nach Plan am 06.06.2020. Somit stehen 22 Kalen­derwochen eingeteilt in 11 Iterationen zur Verfügung. Eine Iteration (=Sprint) besteht aus jeweils 14 Tagen, wobei das Team variabel von Montag bis Sonntag die unter 1.3 beschriebenen Stunden erbringen kann. Somit entfallen auf einen Sprint 74 Stunden. Pro Sprint werden 10 % der Zeit für Meetings und 25 % für Ausfallzeiten und Puffer abgezogen. Somit stehen pro Sprint noch 48,1 Stun­den kalkulierbare Arbeitszeit zur Verfügung. Insgesamt stehen dem Projekt somit 529,1 Stunden zur Verfügung. Die benötigten Pufferzeiten können sich im Laufe des Projektes verändern. Die darge­stellten Zahlen sollten an dieser Stelle für eine Grobkalkulation ausreichen.

2. Projektdurchführung

Das Projekt wurde mittels des Managementframeworks Scrum umgesetzt. Die Umsetzung der sich daraus ergebenden Regularien, durchzuführende Meetings und zu erstellende Managementarte­fakte sollen im Folgenden erläutert werden. Durch Beispiele und Abbildungen wird die Anwendung der agilen Methode im durchgeführten Projekt weiter verdeutlicht.

2.1. Aufbau der Iterationen

Die Iteration wird im Vorgehensmodell Scrum als Sprint bezeichnet und stellt damit einen kurzen Arbeitszyklus dar. Jeder Sprint setzt in diesem Projekt Anforderungen aus dem Product Backlog in eine lauffähiges, auslieferbares Produktinkrement um. Die im Sprint umzusetzenden Anforderungen werden dazu im Sprint Backlog verwaltet. Zu Beginn eines Sprints wurde jeweils ein Sprint Planning Meeting 1 und ein Sprint Planning Meeting 2 durchgeführt. Täglich Abstimmungen, also das Daily Scrum, finden von Montag bis Freitag per Telefon statt. „Die Dauer eines Sprints beträgt maximal 30 Tage“ (Pichler, Roman 2013, S. 7). In diesem Projekt wurde die abweichende Dauer eines Sprints auf 14 Tage festgesetzt. Am Ende jeder Iteration wird schließlich noch das Sprint Review und eine Sprint Retrospektive durchgeführt. Inhalt und Umsetzung sind im Kapitel 2.3.3 und 2.3.4 beschrieben.

Abbildung 1: Übersicht über die Aktivitäten (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektiv) und Artefakte (u.A. Product Backlog, Sprint Backlog, Produktinkrement) von Scrum (Timinger, Holger 2017, S. 166)

Abbildung in dieser Leseprobe nicht enthalten

2.2. Verwalten von Anforderungen

2.2.1. Product Backlog und User-Sories

„Das zentrale Mittel zum Erfassen und Managen von Anforderungen in Scrum ist das Product Back­log. Es enthält alle bekannten Anforderungen und Arbeitsergebnisse, die zur Erreichung des Pro­jektziels umgesetzt oder erbracht werden müssen. Hierzu zählen funktionale und nicht funktionale Anforderungen sowie Anforderungen an die Benutzerschnittstelle. Außerdem kann das Product Backlog Arbeitsergebnisse wie das Aufsetzen der Test und Entwicklungsumgebung oder das Be­seitigen von Defekten (Bugs) enthalten. Der Product Owner erstellt und verfeinert das Product Back- log“ (Pichler, Roman 2013, S. 27).

Als Bezeichnung für die Pflege des Product Backlogs wird in der Fachsprache auch häufig der Ang­lizismus „Grooming“ verwendet. Defekte bzw. Bugs werden auch unter dem Begriff technische Schulden verstanden. Hierzu können auch Anforderungen zählen, die zur Qualitätsverbesserung führen. Technische Schulden werden in der Regel während eines Sprints festgestellt und werden daher im anschließenden Sprint Review als mögliches Element im Product Backlog eingestellt Das Product-Backlog wird aus Kostengründen und der weiten Verbreitung des MS Office Pakets, als Exceltabelle geführt. Der Product Owner formuliert seine Anforderungen und trägt diese mit den erforderlichen Attributen in die Exceltabelle ein. Für das umgesetzte Projekt werden die Anforderungen in Form von User-Storys im Product Backlog abgelegt. „Eine User Story ist eine Anforderung, die aus Sicht einer bestimmten Rolle, häufig der des Anwen­ders, geschrieben wird“(vgl. Timinger, Holger 2017, S. 169).

Die User Storys wurden in diesem Projekt nach dem folgenden Schema formuliert:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufbau einer User Story (Timinger, Holger 2017, S. 170)

Beispiel:

„Als Feuerwehrmann will ich auf dem Einsatzmonitor die Navigation vom Gerätehaus zur Einsatz­stelle angezeigt bekommen, damit ich den Weg zur Einsatzstelle schneller finde“

Zur weiteren Spezifizierung und zur besseren Verwaltung, werden den User-Stories bzw. Backlog Elementen, neben der eigentlichen fachlichen Beschreibung, zusätzlich folgende Attribute zugewie­sen:

- ID: Laufende, eindeutige Nummer zur Identifizierung des Elements
- Autor: Autor der User Story (Anforderer)
- Inhalt: Inhalt der User Story (nach Schema Abbildung 2)
- Priorität: Priorität der User Story (festgelegt vom Product Owner)
- Definition of Done: Beschreibung, wann eine Anforderung final umgesetzt ist
- Story Points: Geschätzter Aufwand einer User Story
- Status: In welchem Status befindet sich die User Story (in Redaktion, in Umsetzung, )
- Sprint: Angabe, in welchem Sprint die User Story realisiert wird/wurde

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Ausschnitt aus dem Product Backlog

Für gewöhnlich werden Anforderungen durch den Product Owner in das Product Backlog eingestellt. In diesem Projekt kann das Product Backlog jedoch auch von weiteren Stakeholdern befüllt werden. Ist dies der Fall, müssen diese jedoch Ihre Anforderungen zwingend mit dem Product Owner ab­stimmen, da dieser letztendlich entscheidet, was umgesetzt wird und was nicht.

2.2.2. Sprint Backlog

Im Sprint Backlog werden die User Storys verwaltet, die im jeweils aktuellen Sprint realisiert werden sollen. Das Team übernimmt im Rahmen des Sprint Plannig Meetings, welches immer am Anfang eines Sprints stattfindet, die Anforderungen in Absprache mit dem Product Owner vom Product Backlog in das Sprint Backlog. Der Product Owner darf das Sprint Backlog weder befüllen, noch verändern. Es liegt rein in der Verantwortung des Teams.

Auch dieses wurde aus den gleichen Gründen wie das Product Backlog, jeweils für jeden Sprint als Exceltabelle geführt. Mittels der Attribute „ID“ und „Sprint“ jeder User Story, sind zwischen Product Backlog und dem jeweiligen Sprint Backlog eindeutige Referenzen vorhanden.

Zur Übernahme eines Elements vom Product Backlog in das Sprint Backlog ist dies lediglich zu kopieren und in der Excel Tabelle für den jeweiligen Sprint wieder einzufügen. Im weiteren Verlauf des Sprints, muss für jede User Story der Status gepflegt und aktuell gehalten werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Ausschnitt aus einem Sprint Backlog

Detaillierter werden der Status und der Umfang einer User-Story am TASK-Board sichtbar, dessen Anwendung folgend beschrieben wird.

2.2.3. TASK-Board und Daily Scrum

Das Arbeiten mit dem TASK-Board funktioniert vereinfacht nach dem folgenden Grundsatz: „Die Methode ist einfach: Aufschreiben aller anstehenden Aufgaben oder Anforderungen“ (Gloger, B., & Margetich, J. 2018, S. 167).

Da sich eine User Story in den meisten Fällen in mehrere Unteraufgaben gliedert, die so genannten Tasks, werden diese auf kleine Kärtchen geschrieben und der User Story und dem aktuellen Status zugeordnet, an das Task Board gehängt oder geklebt. Die Tasks können drei Zustände annehmen: „Geplant“, „in Arbeit“ und „Erledigt“. Da es im Projekt nur drei Entwickler gibt, gilt die Festlegung, dass lediglich drei Tasks gleichzeitig im Status „in Arbeit“ stehen dürfen. Dies soll sicherstellen, dass jeder Mitarbeiter nur einen Task gleichzeitig bearbeitet und nicht mit vielen parallelen Aufgaben überlastet wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Arbeiten mit dem Taskboard (Gloger, B, & Margetich, J. 2018, S. 168)

Auf Grund der räumlichen Trennung des Teams, trifft sich dieses nur in Ausnahmefällen direkt am Taskboard vor Ort. Trotzdem findet ein täglicher, maximal 15-minütiger telefonischer Austausch als Daily Scrum statt (Time Boxing durch den Scrum Master). Teilnehmer sind hierbei der Scrum Master und das Team. Auf Basis des Task Boards wird die Qualität des Produkts, der Fortschritt und die auftretende Impediments besprochen. Impediments stellen Hindernisse dar, die gemeinsam mit o­der vom Scrum Master gelöst werden müssen. Zudem werden in dem Meeting der Status der Tasks überprüft und diese ggf. richtig zugeordnet (z.B. vom Status „in Arbeit“ nach „Erledigt“ verschoben). Im Prinzip werden von jedem Teammitglied die folgenden drei Fragen beantwortet:

„1. Was habe ich gestern fertigbekommen?
2. Was nehme ich mir für heute vor?
3. Wo benötige ich Hilfestellung, wo kann ich unterstützend wirken?“(Gloger, B., & Margetich, J. 2018, S. 71)

Auf Grund des unregelmäßigen „vor Ort“ Termins am Taskboard, wird dieses zentral vom Scrum Master gepflegt und die jeweils neueste Version den Teammitgliedern zur Verfügung gestellt. Hierfür verschickt der Scrum-Master den täglich aktualisierten Stand des Task Boards nach dem Daily Scrum an das Team.

Nimmt ein Entwickler im weiteren Tagesverlauf einen neuen Task „in Arbeit“, so muss dies im Vorfeld mit dem Scrum Master abgestimmt werden, damit doppelte Bearbeitungen von Tasks vermieden werden.

2.2.4. Burndownchart

Auf dem Burndownchart wird dargestellt zu welchem Zeitpunkt User Storys, also geplante Aufwände („Story Points“), „verbrannt“ wurden oder Aufwände dazugekommen sind. Verbrannt ist der Aufwand einer User Story dann, wenn diese geliefert ist und durch den Product Owner abgenommen wurde. Letztendlich wird also ersichtlich wie viele „Story Points“ abgearbeitet wurden und wie viele noch abzuarbeiten sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Burn Down Chart des Projektes

Im Idealfall werden bis zum Projektende alle Story Points verbrannt und die blaue Linie erreicht somit den Wert von 0. In dem hier abgebildeten Burndownchart ist zu erkennen, dass zu Beginn des Projektes auf Grund von laufendem Requirements Engineering mehr Story Points dazu gekommen sind, als abgearbeitet werden konnten. Ab dem Wert von 526 Story Points, wechselt dies in das Gegenteil. Im Laufe des Sprints 10 kamen auf Grund von Impediments und neuen Erkenntnissen weiter Story Points hinzu.

2.3. Projekt Meetings und Absprachen

Aus dem Aufbau der Sprints geht unter anderem hervor, dass diverse Meetings im Sprintverlauf durchgeführt werden. Diese unterstützen die Kommunikation und Organisation im Projekt und sor­gen unmittelbar für das Management der umzusetzenden Anforderungen. Grundsätzlich werden Meetings nur von Montag bis Freitag und nur in Ausnahmefällen „vor Ort“ durchgeführt. Die Kom­munikation wird durch Telefonkonferenzen und bei Bedarf über Videokonferenzen mittels Skype sichergestellt.

2.3.1. Sprint Planning Meeting 1

„Jeder Sprint beginnt mit einem Abgleich zwischen dem Entwicklungsteam und dem Product Owner. Die Basis dafür bilden die im Product Backlog durch den Product Owner priorisierten User Storys“(Gloger, B., & Margetich, J. 2018, S. 68).

Die allgemeine Dauer des Meetings wird in jedem Sprint auf maximal zwei Stunden festgelegt. Hier bewusst „maximal“, da das Meeting nach Möglichkeit auf Grund der knappen Ressourcen auch kür­zer ausgeführt werden kann. Im Allgemeinen kommt jedoch das übliche Vorgehen zur Anwendung welches folgend beschrieben wird.

Im Sprint Planning Meeting 1 übernimmt das Team die priorisierten User Strorys vom Product Back­log in das Sprint Backlog. Diese werden zuvor gemeinsam mit dem Product Owner abgestimmt und deren Umsetzung und Lieferung als Produktinkrement als Ziel für den Sprint festgelegt. Im gleichen Zuge findet eine Aufwandsschätzung statt. Den User Storys werden Aufwände in Form von „Story Points“ zugeordnet, wobei die Festlegung gilt, dass ein „Story Point“ einer Stunde Arbeitszeit ent­spricht. Die Schätzung der Aufwände findet mittels der agilen Technik „Planning Poker“ statt. Hierbei schreiben alle Entwickler ihren geschätzten Aufwand (Expertenschätzung) auf eine Karte und de­cken diese auf Kommando des Scrum Masters auf. Die höchste und niedrigste Schätzung muss anschließend vom jeweiligen Entwickler erläutert bzw. begründet werden. Dieser Vorgang wird nun so lange wiederholt, bis Einigkeit über einen Aufwand besteht, oder die geschätzten Aufwände nur noch geringe Abweichungen aufweisen. Wird keine Einigung erzielt, so wird der höchste Aufwand gewählt. Wird eine User Story mit mehr als 14 Stunden Aufwand geschätzt, so muss diese weiter unterteilt werden, da ein Entwickler sonst eine ganze Woche nur eine Aufgabe implementieren würde.

Die Team-Velocity liegt bei maximal 48 Story Points pro Sprint (siehe Kapitel 1.4). Der Begriff Team­Velocity wird unter anderem wie folgt interpretiert: „Bei der Team Velocity geht es um die Arbeitsge­schwindigkeit eines Teams“ (Preußig, J. 2018, S. 138). Diese stellt somit die Anzahl der Story Points dar, die das Team während eines Sprints schafft abzuarbeiten.

2.3.2. Sprint Planning Meeting 2

Im Anschluss an das Sprint Planning Meeting 1, wird bei Bedarf das Sprint Planning Meeting 2 durchgeführt. Hier nimmt ebenfalls das Team und der Scrum Master teil. Die Time-Box des Meetings wird aus den gleichen Gründen wie beim Sprint Planning Meeting 1 (Ressourcenknappheit) auf eine Stunde festgelegt. Folgende Aspekte wurden durch das Sprint Planning Meeting 2 beleuchtet:

„Im Fokus steht das gemeinsame Verständnis über die Herangehensweise, die Risiken sowie Un- wegbarkeiten und auch darüber, welche Kompetenzen an welcher Stelle gebraucht werden. Mög­licherweise werden schon in diesem Meeting externe Zulieferer eingebunden, um sicherzustellen, dass das im Sprint Planning 1 gegebene Commitment auch wirklich gehalten werden kann“ (Gloger, B., & Margetich, J. 2018, S. 70).

[...]