Leseprobe
Inhaltsverzeichnis
I Tabellenverzeichnis
II Abkürzungsverzeichnis
1. Einleitung
1.1 Ausgangssituation undZielsetzung
1.2 Vorgehensweise
2. Projektbericht
2.1 Vorbereitungenfür Projektdurchführung
2.1.1 User Story und Anwendung der Serum-Methode
2.1.2Projektqualität
2.1.3AgilerFestpreis
2.2 Projektierung mittels Serum
2.2.1 ProduktBacklog
2.2.2 Backlog Meeting und Planning Poker
2.2.3 Sprint Planning Meeting
2.2.4 Daily Serum und Sprint Backlog
2.2.5 Sprint Review
2.2.6 Sprint Retrospektive
3. Fazit
III.Literaturverzeichnis
I Tabellenverzeichnis
Tab. 1: Ablaufplan Projektbeginn und ersterSprint
Tab. 2: Product Backlog
Tab. 3: Planning Poker: kritische Items
Tab. 4: Sprint Backlog User Story #1
II Abkürzungsverzeichnis
CFD: Cumulative Flow Diagram
Die folgenden Abkürzungen werden nur in den Tabellen verwendet.
D: Designer, HM: Hotelmanagement; M: Master; PO: Product Owner; P: Programmierer; P1: Programmierer 1; P2: Programmiere^.1
1. Einleitung
1.1 Ausgangssituation und Zielsetzung
Ein mittelständisches Hotel mit 80 Zimmern hatte eine wachsende Anzahl an negativen Bewertungen und einem Rückgang an Buchungen zu verzeichnen. Zur Verbesserung seiner Marktfähigkeit wurden vom Hotelmanagement das Personal und Gäste als Stakeholder befragt. Als besonders gravierend kritisierten die Gäste die langen Wartezeiten beim Check-in und Check-out für Reisegruppen, obwohl die Rezeption mit zwei bis drei Beschäftigten besetzt war. Einzelreisende, die in die Ankunft einer Reisegruppe gerieten, fühlten sich unnötig aufgehalten. Gegenwärtig werden im Hotel Türschlösser mit Zifferneingabe verwendet. Den Tür-Code erhalten die Gäste von der Rezeption nach erfolgreichem Einchecken per Hand in den Hotelausweis eingetragen. Das Hotelmanagement leitete daraus die Idee der Entwicklung einer App für Mobilfunkgeräte als Kundensystems zum selbsttätigen Check-in/Check-out durch die Gäste ab. Mit diesem personenkontaktfreien Verfahren wird zusätzlich den Erfahrungen der Corona-Pandemie Rechnung getragen. Diese App soll das bestehende Hotelverwaltungssystem nutzen. Die Verwaltungsprozesse sollen automatisiert, zeitlich entzerrt und die bisher manuellen Tätigkeiten in der Rezeption besonders beim Check-in weitgehend entfallen. Eine Stelle und die zugehörigen Personalkosten sollen eingespart werden.
1.2 Vorgehensweise
Nachdem das Hotel die Leistung ausgeschrieben hatte, wurde von unserem Start-upUnternehmen in einem Workshop der Projektinhalt geklärt. Serum empfahl sich als agile Managementmethode, da die Vorstellungen des Hotels als Auftraggeber noch nicht ausgereift waren und, wie es sich während der Projektierung zeigen sollte, noch überarbeitet und ausgeweitet wurden. Für die Realisierung wurden ein agiler Festpreis und die Serum-Methodik vereinbart. In den folgenden Kapiteln werden die Vorarbeiten bis zum Vertragsabschluss für das Projekt aufgezeigt. Die Empfehlungen des Scrum Guide bilden die Grundlage für die Projektierung. Im chronologischen Ablauf werden die Arbeiten von der Vorplanung mit Schwerpunkt auf dem agilen Festpreis als Grundlage für den Vertragsabschluss dargelegt. Es wird aufgezeigt, wie der agile Festpreis die Vorteile der Serum-Methode für die Vertragsgestaltung übernimmt und wie sich beide im Vertrag ergänzen. Die eigentliche Projektierung mittels Serum-Methode, der Workflow vom Product Backlog und Planning Poker über Sprints mit ihren Wechselbeziehungen bis zu abschließenden Projekttests und Auslieferung der Inkremente (Gloger/Margetich 2018, S. 59) wird nachfolgend dargestellt. Probleme, die während der Arbeit mit den agilen Methoden erkannt wurden und die in der Zusammenarbeit mit dem Auftraggeber, dem eigenen Personal, dem Einsatz von Tools und der Nutzung der Serum-Methodik erkannt wurden, werden abschließend erläutert. Wege und Maßnahmen zu ihrer Lösung werden aufgezeigt.
2. Projektbericht
2.1 Vorbereitungen fürdie Projektdurchführung
2.1.1 User Story und Anwendung der Serum-Methode
In einem ersten Workshop mit dem Start-up, vertreten durch den künftigen Product Owner, formulierte das Hotelmanagement seine Vorstellungen und Funktionswünsche als User Story: „Als Hotelleitung möchte ich eine mobile App, mittels derer die Hotelgäste einchecken können und auschecken können, um Personal an der Rezeption zu sparen und für den Gast die Prozesse zu beschleunigen.“ Da diese User Story sehr komplex ist und zahlreiche nicht eindeutig definierte Features umfasst, wurde sie vom Product Owner als Epic eingestuft und die Anwendung der agilen Projektmanagement-Methode Serum vorgeschlagen. Der Product Owner erläuterte, dass Serum davon ausgehe, dass im Projektanfang noch nicht alle Features, nicht alle Anforderungen bekannt sind und diese erst in gemeinsamer Arbeit entwickelt und iterativ verfeinert werden (Maximi 2013, S. 16). Permanente Qualitätsprüfung hält das Projekt flexibel und transparent. Auf Fehlentwicklungen kann frühzeitig reagiert werden. Zeitaufwand sowie finanzielle Risiken werden minimiert. Der Nutzen der künftigen User steht im Mittelpunkt (Gloger/Margetich 2018, S. 52; 88). Das SerumModell basiert auf gegenseitigem Vertrauen und Transparenz.
Gemeinsam wurden für die Epic zwei User Storys als selbstständig verwertbare Projektteile, die Produktinkremente, erarbeitet. In diesen definierte das Hotelmanagement seine Anforderungen an Funktionen und Nutzen in quantitativer oder qualitativer Hinsicht. Die neu formulierten User Storys lauteten: #1: „Als Hotelleitung möchte ich, dass die Hotelgäste über eine App für Mobiltelefone selbstständig einchecken können, um den Personalbedarf und die damit verbundenen Kosten der Rezeption zu halbieren sowie die Wartezeiten für die Gäste zu minimieren. #2: „Als Hotelleitung möchte ich, dass die Gäste per App die während des Aufenthalts gebuchten Zusatzleistungen bezahlen können, um den Check-out zu beschleunigen.“
2.1.2 Projektqualität
Der Product Owner ist für die inhaltliche Analyse von Projektidee und Aufgabenstellung zuständig. Er verantwortet die zu lösenden Aufgaben gegenüber dem Entwicklungsteam, deren Erfüllung den Nutzen gegenüber dem Auftraggeber. Die Qualität der User Storys wurde durch den Produkt Owner anhand der Invest-Methode2 überprüft (Schaaf o.J.). Er klassifizierte Projekt und User Storys als qualitativ durchschnittliche App. Diese kommuniziert mit einer Backend-Lösung, hat mehrere Menüpunkte, eine umfangreiche Konfiguration und verwendet Standardkomponenten (Haalck o.J.).3 Für die Preisbildung schlug der Product Owner einen agilen Festpreis vor.
2.1.3 Agiler Festpreis
Das Vertragskonstrukt des agilen Festpreises kombiniert Elemente aus Dienst-und Werkvertrag (Keller o.J./ Tuholjakovic 2020, S. 72). Angewendet wird der agile Festpreis bei komplexen Projekten, wo die Vielzahl der Aufgaben, Ergebnisse und der zu erwartenden Änderungen eine vollständige Planung mit festem Preisgefüge schwer bis unmöglich machen. Bevorzugte Anwendungsgebiete sind große IT-Projekte und Organisationsprojekte. Er vereint die Vorteile des agilen Projektmanagements mittels Serum mit denen eines Festpreises.
Der agile Festpreis ist ein initialer Preis für das Projekt, der im Verlauf der Arbeit angepasst werden kann. Die Regelungen dazu umfassen u.a. die Definition der Risk-Shares, d.h. die anteilige Übernahme der Mehrkosten durch Auftraggeber und Auftragnehmer bei höherem Ressourcenbedarf. Ein Bonus-System, z.B. für vorzeitige Projekterfüllung, kann vereinbart werden. Die Abrechnung der Leistungen kann aufwandsbezogen für eine abgenommene Teilleistung, eine Sprint oder ein Inkrement, erfolgen (Tuholjakovic 2020, S. 76). Durch dieses Vertragskonstrukt ist es den Beteiligten möglich, flexibel auf Veränderungen aufgrund neuer Funktionalitäten oder auftretender Probleme zu reagieren, ohne den Vertrag ändern zu müssen. Gleichzeitig werden die Kosten transparent (Riedel o.J.). Ausgangspunkt ist eine „vollständige, aber noch nicht detaillierte Beschreibung des Vertragsgegenstandes“ (Opelt/Gloger/Pfarl/Mittermayr 2017, S. 43). Die Erarbeitung eines agilen Festpreises basiert auf der Verringerung der Komplexität des Projektes auf plan- und kalkulierbare Elemente. Im Workshop definierte der Product Owner die Features für die erste User Story in einer noch geringen Detaillierungstiefe.
Wegen der unterschiedlichen Leistungsarten zog er zur Bewertung der Features das vorgesehene Entwicklerteam hinzu. Gemeinsam vergaben sie Story Points. Mit Story Points wird nicht der Aufwand, sondern die Komplexität bewertet. Als Referenz für einen Story Point wurde ein unkomplizierte, einfaches Teilaufgabe, das Item #1-7, festgelegt, das auch im späteren Product Backlog (Tab. 3) verwendet wird und das keine Verbindungen zu anderen Teilaufgaben oder zum Hotelsystem hat. Der Aufwand dafür wurde mit zwei Arbeitsstunden festgelegt. Je komplizierter ein Feature und die daraus hervorgehenden Items sind, desto mehr Story Points wurden vergeben. Story Points geben ein Abbild der relativen Größe. Nach der Bewertung der Kompliziertheit der Features wurde ein vorläufiger Sprint gebildet. Ein Sprint ist eine Menge von Items, welche die Teammitglieder innerhalb eines definierten Zeitraumes für realisierbar halten (Schwaber/Southerland 2020, S.8)4. Dieser Zeitraum wurde wegen der noch geringen Erfahrungen des Teams mit Serum auf zwei Wochen festgelegt. Story Points dieses Sprints wurden im folgenden Schritt mittels der festgelegten Arbeitsstunden mit personellem Aufwand und Kosten von 100 €/Stunde bewertet. Diese Festlegungen zu Story Points und Aufwand wurden als Kalkulationsbasis in den späteren Vertrag übernommen (Mustervertrag: Denovo GmbH, .o. J). Aus dem Aufwand des Sprints wurde der finanzielle und zeitliche Gesamtrahmen von max. vier Wochen für das Projekt abgeleitet. Für die User Story #1 ermittelte der Product Owner einen Preis von ca. 20.000 €, für die User Story #2 wurde der Leistungsumfang auf ca. 12.000 € geschätzt5, da hierfür die App in Struktur und Design bereits vorliegt und nur noch die inhaltlichen Features zu berücksichtigen sind. Der Gesamtpreis von ca. 32.000 € wurde dem Hotelmanagement als agiler Festpreis angeboten. Das Hotelmanagement hatte selbst mittels eines im Internet verfügbaren Kalkulators den Preis der ersten Story auf ca. 20.000 - 30.000 € grob geschätzt (Portal24 GmbH 24, o. J) und nahm das Angebot an. Der Vertrag wurde abgeschlossen.
Während der Gespräche hatte der Product Owner als Alternative zur Vorgehensweise vorgeschlagen, das Projekt und den agilen Festpreis vertraglich auf eine User Story zu begrenzen. Diese wird als Minimum Viable Product (MVP) definiert. Das ist der Leistungsumfang, den das Projekt mindestens haben muss, um selbstständig verwendbar zu sein. Die User Story wird in mehreren Schritten bis zur Projektierungsreife in einem oder mehreren Sprints kalkuliert. Nach Fertigstellung werden anhand des tatsächlichen Aufwandes die übrigen Scope-Teile bewertet. In dieser Phase kann über Fortsetzung oder Einstellung des Projektes entschieden werden. Vom Hotelmanagement wurde die Möglichkeit der Beendigung des Projekts nach dem ersten Sprint in den Vertrag aufgenommen. Generell wies das Hotelmanagement auf die Notwendigkeit schnellstmöglicher Fertigstellung.
2.2 Projektierung mittels Serum
Pandemie bedingt wurden die internen und externen Besprechungen per Videokonferenz durchgeführt. Für die Videokonferenzen wurden Excel-Tabellen statt der sonst für die einzelnen Scrum- Schritte üblichen Karten und Whiteboards verwendet.
Nach Auftragserteilung wurde das Scrum Team gemäß Scrum Guide aus Master, Product Owner und Entwicklerteam, bestehend aus Designer und zwei Programmieren, gebildet (Schwaber, K., Sutherland, J. (2020) S.5).6 Das Scrum Team arbeitet ohne Hierarchie selbstmanagend, es
wählt, wer die Arbeit erledigt, wie und woran gearbeitet wird.“ (Schwaber/Sutherland 2020, S. 15). Bei Scrum-Teams ist besonders auf die Teamfähigkeit der Mitglieder zu achten. Aufgaben des Serum Master sind Scrum-Schulung, Koordinierung der Arbeiten und Klärung auftretender Probleme mit der Geschäftsleitung. Er ist „ergebnisverantwortlich für die Effektivität des Serum Teams“ (Schwaber/Sutherland 2020, S. 7). Als ersten Schritt erstellte der Master einen prinzipiellen Ablaufplan für den Backlog und einen Sprint von zwei Wochen, der sich in der gesamten Projektierung bewährte.
Tab. 1: Ablaufplan Projektbeginn und ersterSprint
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Erstellung
Einen Strukturplan zu erstellen hielt der Product Owner für unnötig, da es seitens des Hotelmanagement keine unterschiedlichen Zuständigkeiten gibt. Für größere Projekte ist jedoch ein Strukturplan unumgänglich.
2.2.1 Produkt Backlog
Der Product Backlog wird vom Product Owner als Liste aller anstehenden Aufgaben in detaillierter Form als Items erarbeitet und dieser verantwortet ihn gegenüber dem Hotelmanagement und den Teammitgliedern. Der Product Backlog ist nicht starr, sondern kann bei sich ändernden Anforderungen des Hotelmanagements angepasst werden. Zur Sicherung der Transparenz wurden alle Entscheidungen dokumentiert.
Der Product Owner erstellte den Product Backlog für beide die User Storys. Für die User Story #1 konnten die Vorarbeiten zum agilen Festpreis genutzt werden. Im Produkt-Backlog werden für die Items vom Product Owner die jeweiligen Akzeptanzkriterien festgelegt. Diese bestimmen, welche Anforderungen das einzelne Item erfüllen muss und wie diese getestet werden, um den Ansprüchen des Product Owners an die Funktionalität zu genügen (Scrum Events, 2021). Für die weitere Bearbeitung wurden die Items vom Product Owner mit der MosCoW-Methode7 (T2lnformatik (o.J.) priorisiert.
Die Priorisierung soll festlegen, inwieweit die Erfüllung des Items zur Erfüllung der vom Hotelmanagement formulierten Anforderungen beiträgt. Je detaillierter die Anforderungen sind, desto präziser wird die Schätzung. Sie bestimmen den Rang im Produkt-Backlog. Die MoSCoW-Methode lässt nur vier Priorisierungsstufen von „unbedingt notwendig“ bis „überflüssig“ zu. Der Product Owner stellte fest, dass aufgrund der minimalistischen Ausstattung der App mit Features fast alle Items die höchste Priorisierungsstufe erhalten mussten.
[...]
1 Zur Vereinfachung der Lesbarkeit wird im gesamten Projektbericht das generische Maskulinum verwendet. Darunter sind alle Geschlechter einbegriffen.
2 Die User Story ist independent, negotiable, valuable, estimatable, small, testable.
3 Kriterien für einfache Apps: Wenig Logik, kein Backend-Zugriff, Standardkomponenten und Layout. Komplexe Apps: Eigenes Backend notwendig, aufwendige Logik, viele Menüs, zahlreiche Optionen für eigene Konfiguration, Maßnahmen für Sicherheit und Stabilität erforderlich, Designs nach individuellen Wünschen.
4 Maximal ein Monat.
5 Basis Item #1-7: ein Storypoint = zwei Stunden a 100€. Story #1: 100 Points, User Story #2: 50 Points.
6 Empfehlung: Scrum Team: Master, Product Owner, Entwicklungsteam, insgesamt max. zehn Personen.
7 MosCow: Priorisierungsverfahren für Reihenfolge von User Storys, Aufgaben, Items: Must have: unbedingt notwendig; Should have: nützlich, kann in auch in zweiter Ausbaustufe umgesetzt werden; Could have: für Funktionieren des Projekts nicht zwingend notwendig, kann verschoben werden oder entfallen; Won't have: nicht umzusetzende Anforderungen. Abstimmung mit Product Owner oder Auftraggeber notwendig.