ISSE01 - Projektbericht PDF

Preview

Summary

ProjektberichtVergleich der agilen Methoden Kanban,Extreme Programming und ScrumHolger Lapenat Mai 2 020 Matrik elnr.: 3191237 Studiengang: Bachelor of Science Wirtschaftsinformatik Kurs: ISSE01 – Seminar Software Engineering Kursbetreuer: Hr. Thomas ZöllerSeite IInhaltsverzeichnisI. Abkürzungsverze...

Description

Projektbericht

Vergleich der agilen Methoden Kanban, Extreme Programming und Scrum

Holger Lapenat 31. Mai 2020

Matrikelnr.:

3191237

Studiengang: Bachelor of Science Wirtschaftsinformatik Kurs:

ISSE01 – Seminar Software Engineering

Kursbetreuer: Hr. Thomas Zöller

Inhaltsv Inhaltsverzeichni erzeichni erzeichniss I. Abkürzungsverzeichnis .................................................................................................................. II II. Abbildungsverzeichnis .................................................................................................................. II III. Tabellenverzeichnis ..................................................................................................................... II 1. Einleitung ...................................................................................................................................... 1 1.1 Ziel ......................................................................................................................................... 1 1.2. Methoden ............................................................................................................................... 1 2. Kanban Methode........................................................................................................................... 1 2.1 Kanban Werte ......................................................................................................................... 2 2.2 Kanban Praktiken .................................................................................................................... 2 2.3 Kanban Prinzipien ................................................................................................................... 3 3. Scrum Methode............................................................................................................................. 4 3.1 Scrum Rollen ........................................................................................................................... 4 3.2 Scrum Artefakte....................................................................................................................... 5 3.3 Scrum Ereignisse .................................................................................................................... 6 4. Extreme Programming (XP) Methode ........................................................................................... 7 4.1 XP Rollen ................................................................................................................................ 7 4.2 XP Werte ................................................................................................................................. 8 4.3 XP Prinzipien ........................................................................................................................... 9 4.4 XP Management Techniken .................................................................................................. 10 4.5 XP Team Techniken .............................................................................................................. 11 4.6 XP Techniken für Programmierung ....................................................................................... 11 5. Möglichkeiten der Kombinationen ............................................................................................... 11 5.1 Gemeinsame Schnittpunkte .................................................................................................. 12 5.2 Übersicht Schnittpunkte ........................................................................................................ 12 6. Resümee..................................................................................................................................... 13 IIII. Literaturverzeichnis ................................................................................................................... 14

Seite I

I. Abkürzungsverzeichnis PDCA

Plan Do Check Act

XP

Extreme Programming

II. Abbildungsverzeichnis Abbildung 1 Darstellung Kanban Board ........................................................................................... 3 Abbildung 2 Ablauf Scrum Prozess ................................................................................................. 4 Abbildung 3 Schaubild Grundwerte von Extreme Programming....................................................... 8

III. Tabellenverzeichnis Tabelle 1 Zuordnung Werte zu Praktiken ......................................................................................... 2 Tabelle 2 Zuordnung Werte zu Prinzipien......................................................................................... 2 Tabelle 3 Schnittpunkte der Modelle............................................................................................... 12

Seite II

1. Einleitung 17 renommierte Softwareexperten haben 2001 das agile Manifest (Originaltitel: Agile Manifesto bzw. Manifesto for Agile Software Development) veröffentlicht. Darunter waren z. B. Ken Schwaber und Jeff Sutherland, die Gründer von Scrum Frameworks oder Ken Beck, der die agile Methode Extreme Programming erschaffen hat. Das Manifest ist ein wesentlicher Meilenstein der agilen Bewegung. Im klassischen Projektmanagement stehen organisatorische Vorgaben und Regeln an erster Stelle. Dies beeinträchtigt die Reaktionsmöglichkeit bei Problemen in einem Projekt. Das agile Manifest gibt den Teams vier Leitsätze an die Hand: • • • •

Individuen und Interaktionen > Prozessen und Werkzeugen Funktionierende Software > Umfassende Dokumentation Kunden-Zusammenarbeit > Vertragsverhandlung Reaktion auf Veränderung > Befolgen von einem Plan

Im Laufe der Zeit sind mehrere Methoden entwickelt worden. Zu den bekanntesten Beispielen zählen Kanban, Scrum und Extreme Programming. Diese Methoden bauen grundsätzlich auf den Leitsätzen auf und werden mit Praktiken erweitert, damit agiles Projektmanagement in die Praxis verwandelt werden kann.

1.1 Ziel Im Rahmen dieser Arbeit werden die drei Modelle vorgestellt und mögliche Gemeinsamkeiten ermittelt und näher erläutert.

1.2. Methoden Scrum, Extreme Programming und Kanban haben als Grundlage die Grundsätze des agilen Manifests. Diese Methoden sind allerdings in der Umsetzung sehr unterschiedlich. Extreme Programming bezieht sich auf die technische Ebene der Softwareentwicklung und verzichtet auf die Management-Sicht. Scrum bezieht sich auf die Management-Sicht und gibt dafür definierte Abläufe und Regeln vor. Diese sind für die problemlose Kommunikation zwischen Entwicklern, Management und der Kundenseite einzuhalten. Kanban setzt auf Empfehlungen und Vorschläge. Damit soll der Prozess kontinuierlich besser werden (vgl. Epping, 2011, S. 34).

2. Kanban Methode Kanban kommt ursprünglich aus der japanischen Sprache. Kan bedeutet übersetzt Signal und ban steht für Karte. Die Übersetzungen erklären auch schon den Mittelpunkt hinter dieser Idee. Kanban möchte mit sehr einfachen Mitteln aufmerksam machen, wenn der weitere Projekt Fortschritt in Seite 1

Gefahr ist. Dies kann z. B. durch Karten erfolgen (vgl. Epping, 2011, S. 33). Diese Karten können z. B. an einem Kanban Board als Hilfsmittel genutzt werden. Der Gründer David Anderson hat 2007 erstmals Kanban in der Öffentlichkeit vorgestellt.

2.1 Kanban Werte Kanban hat das Ziel der permanenten Verbesserung (japanische Übersetzung Kaizen). Damit dieses Ziel erreicht werden kann hat Kanban eine Basis von 9 Werten (vgl. Anderson + Carmichael, 2017, S. 3). 1. 2. 3. 4. 5. 6. 7. 8. 9.

Respekt Verständnis Arbeitsfluss Kundenfokus Vereinbarung Kollaboration Balance Transparenz Führung

Diese Werte werden in Praktiken und Prinzipien aufgeteilt. Wert / Werte

Praktik / Praktiken

Arbeitsfluss Kundenfokus

Manage den Arbeitsfluss

Kollaboration

Verbessere gemeinsam – entwickle weiter

Balance

Limitiere die parallele Arbeit

Transparenz

Visualisiere Mache Prozessregeln explizit Implementiere Feedback Zyklen

Tabelle 1 Zuordnung Werte zu Praktiken

Wert / Werte

Prinzip

Führung Respekt

Respektiere Prozesse und Verantwortlichkeiten

Verständnis

Beginne mit dem was du hast

Vereinbarung

Verfolge die Änderungen

Tabelle 2 Zuordnung Werte zu Prinzipien

2.2 Kanban Praktiken Visualisiere: Die transparente Visualisierung erfolgt mittels eines Kanban Boards. Damit erfolgt ein Überblick über den kompletten Arbeitsprozess. Mache Prozessregeln explizit: Prozessregeln halten Mitarbeiter dazu an, das System nach einem gemeinsamen Verständnis zu betreiben. Seite 2

Implementiere Feedback Zyklen (Feedback Loops): Feedback wird für Erkennung und Beseitigung von Problemen benötigt. Limitiere die parallele Arbeit (WIP Limit): Die Projektarbeit soll gleichmäßig auf die Mitarbeiter aufgeteilt werden, damit die Arbeitsmenge die Kapazität nicht überschreitet. Verbessere gemeinsam, entwickle weiter: Mittels PDCA Zyklus wird die Veränderung weiterentwickelt. PDCA steht für: Plan-Do-Check-Act (Übersetzung: Planen-Umsetzen-Prüfen-Handeln). Mit dieser Methode kann das Team Prozesse fortlaufend verbessern. Manage den Arbeitsfluss (Manage Flow): Die Projektmitarbeiter sollen nicht komplett ausgelastet werden. Im Fokus steht hierbei die Prozessoptimierung.

Abbildung 1 Darstellung Kanban Board

1

2.3 Kanban Prinzipien Beginne mit dem was du hast: Das Modell Kanban startet nah am vorhandenen Prozess und möchte ihn dauerhaft in kleinen Schritten besser machen.

1

Quelle: https://www.wrike.com/de/blog/scrum-vs-kanban-board-projektplan/ [Zugriff: 15.05.2020] Seite 3

Verfolge die Änderungen: Der Prozess soll optimiert werden. Die Verbesserung erfolgt fortlaufend in vielen kleinen Schritten. Respektiere Prozesse und Verantwortlichkeiten: Eine Kanban Einführung muss zwingend mit allen Verantwortlichkeiten eingeführt und erarbeitet werden. Die Mitarbeiter sollen den Mut haben mit Problemen an die Prozess-Verantwortlichen heranzutreten. Das Ziel ist immer die Verbesserung vom Prozess.

3. Scrum Methode Scrum kommt ursprünglich aus der Sportart Rugby und bedeutet übersetzt Gedränge. Scrum ist für die Softwareentwicklung ein Management-Framework mit wenigen Regeln (vgl. Pichler, 2008, S. 1). Jeff Sutherland und Ken Schwaber haben in den 1990er Jahren Scrum an die Öffentlichkeit gebracht. Seit der Veröffentlichung findet es als Prozessrahmenwerk Verwendung. Es muss kein Prozess eingehalten werden. Scrum bietet mehrere Praktiken an, damit der Stand und Ablauf des Projektes für alle Personen transparent ist. Scrum kann für komplexe Projekte genutzt werden.

Abbildung 2 Ablauf Scrum Prozess

2

3.1 Scrum Rollen In Scrum gibt es drei Managerrollen mit differenzierten Aufgabenbereichen (vgl. Glogler, 2013, S. 61). Scrum Master und Product Owner bestehen aus jeweils einer Person. Das Entwickler Team kann aus drei bis neun Personen bestehen. Rolle Scrum Master: Der Scrum Master erklärt dem Product Owner und den anderen Team Mitgliedern die Bedeutung von Scrum und wie man mittels Scrum Arbeitsprozesse überwachen kann. Ebenfalls wird er mögli2

Quelle: https://erfolgreich-projekte-leiten.de/scrum-prozess/ [Zugriff: 29.04.20] Seite 4

che Blockaden beheben damit sein Team produktiv arbeiten kann. Am Sprintende erfolgt eine Team Präsentation mit den Stakeholdern des Kunden über die umgesetzten Anforderungen. Die empfohlene Teamgröße beträgt mindestens 5 bis maximal 9 Personen und soll aus allen Spezialgebieten mindestens eine Person enthalten. Rolle Entwickler Team: Das Entwickler Team kümmert sich um die Auslieferung des fertigen Produktes. Es werden Wünsche und Anforderungen mit den Anwendern und dem Kunden herausgearbeitet. Danach erfolgt die Analyse, Implementierung und die Testphase. Rolle Product Owner: Der Product Owner ist die Schnittstelle zwischen dem Team und dem Kunden. Er ist der HauptAnsprechspartner für den Kunden. Der Kunde teilt ihm seine Wünsche mit. Der Product Owner kann durch die Priorisierung des Product Backlog sicherstellen, dass das Team an den wichtigsten Produkt Aspekten des Kunden arbeitet. Bei Beginn eines Projektes wird eine Vision des Produktes entwickelt und das Backlog mit den Anforderungen des Kunden erstellt. Hierbei werden die gewünschten Anforderungen nach Priorität sortiert, die Kriterien der Abnahme und der Zeitpunkt für die Auslieferung des fertigen Produktes bestimmt.

3.2 Scrum Artefakte Scrum beinhaltet mehrere Dokumente und diese zählen zu den Scrum Artefakten. Die Dokumente dienen zur Planung, zur Überwachung und für die Bereitstellung von Informationen. Impediment Backlog: Diese Liste wird vom ScrumMaster geführt und bearbeitet. Sie enthält Probleme / Hindernisse (engl. Impediments) die das Team an effektiver Arbeit hindern und blockieren. (vgl. Glogler, 2013, S. 89) Productvision: Die Hauptaufgabe der Productvision ist das Ziel aufzuzeigen. Die Erstellung wird vom Product Owner durchgeführt. Dieser lenkt das Projekt in die richtige Richtung (vgl. Glogler, 2013, S. 119). In der Vision werden keine Vorgaben oder Spezifikationen erstellt. Die Vision zeigt dem Scrum Team wie das fertige Produkt (Ziel) aussehen soll. Product Backlog: Das Product Backlog enthält Anforderungen und Ergebnisse. Das Backlog wird vom Product Owner in Zusammenarbeit mit dem Kunden entwickelt. Sprint Backlog: In diesem Backlog sind alle Anforderungen definiert, die in der nächsten Sprint Phase erledigt werden müssen. In der Planungssitzung teilt das Team die Anforderungen in kleine Arbeitspakete.

Seite 5

Release Plan: Um den Fortschritt des Projektes zu überwachen, kann man Burndown Charts nehmen. Die Charts zeigen einen visuellen Verlauf der restlichen Aufwände. Der Product Owner kann dieses Diagramm einsetzen.

3.3 Scrum Ereignisse Scrum beinhaltet mehrere Ereignisse. Dazu zählen Sprint Plannings, Daily Scrums, Sprint Reviews und die Sprint Retrospektive. Alle Aktivitäten die als Umsetzung der Produkt Anforderungen dienen, werden in einem Sprint erledigt. Nach einem Sprint Ende sind die Anforderungen in eine Software umgewandelt worden. Während dieser Umwandlung wird die Software getestet, dokumentiert und lauffähig gemacht (vgl. Pichler, 2008, S. 82). Ziel der Sprint Plannings ist die Identifikation der Anforderungen, die bis Sprint Ende in ein funktionsfähiges Produktinkrement umgesetzt werden können. In der Vorplanung wird der Product Owner die Wünsche des Kunden priorisieren. Dieses Ergebnis ist das Backlog. Sprint Retrospektive: Das Ziel der Retrospektive ist die Zusammenarbeit des Scrum Teams und die Verbesserung der Prozess-Anwendung (vgl. Pichler, 2008, S. 111). Es wird eine Art Rückblick vom letzten Sprint durchgeführt und findet nach dem Review statt. Teilnehmer ist der Scrum Master und das Team. Als optionaler Teilnehmer kann der Product Owner dabei sein. Sprint Review: Der Review wird am Sprintende durchgeführt und es werden die Ergebnisse der durchgeführten Arbeiten vorgestellt. Sprint Plannings: Bei den Sprint Plannings erfolgt die komplette Planung für einen Sprint. Nach der erfolgten Planung weiß das Team, was sie im nächsten Zeitraum entwickeln müssen. Daily Scrum: Während eines Sprints erfolgt ein kurzes tägliches Meeting des Entwickerteams. Das Meeting hat eine (empfohlene) maximale Zeitdauer von 15 Minuten. Im Meeting werden aktuelle (vorhandene) Probleme, die Fortschrittskontrolle und eine kurze Planung des heutigen Tages besprochen. Diese oder ähnliche Fragen sollen von jedem Einzelnen beantwortet werden: 1. Habe ich aktuelle Probleme um meine Arbeit durchzuführen? 2. Was habe ich gestern gemacht? 3. Was möchte ich bis zum nächsten Arbeitstag erledigen?

Seite 6

4. Extreme Programming (XP) Methode Die Methode Extreme Programming ist bei einem Projekt der Firma Chrysler entstanden. Das Projekt Chrysler Comprehensive Compensation ist in den 90iger Jahren durchgeführt worden. Das Projekt stand kurzzeitig vor dem Aus – Kent Beck erhielt die Möglichkeit für einen Projekt-Neustart (vgl. Hanser 2010 S. 13). Er hat seine informellen Praktiken in ein neues Projektmodell formuliert. Dabei hat er bestehende unterschiedliche Softwarepraktiken genutzt und bis ins Extreme ausgereizt. Das Projektergebnis war der endgültige Durchbruch und somit wurde es als Extreme Programming bezeichnet.

4.1 XP Rollen In XP gibt es sieben unterschiedliche Rollen. Die Kernrollen sind Coach, Kunde und Programmierer. In einem größeren Team können die passiven Rollen Terminmanager, Berater und Big Boss besetzt werden (vgl. Beck 2003 S. 139-140). Kernrolle Coach: Der Coach ist für den kompletten Prozess Extreme Programming verantwortlich. Er ist zuständig, dass sein Team die Prinzipien und Werte verstehen und benutzen können. Kernrolle Kunde: Der Kunde repräsentiert den Arbeitgeber / Kunden, ist meistens Endanwender des Produktes und arbeitet mit den Testern und den Programmierern zusammen. Er übermittelt und priorisiert die Anforderungen an das Team. Dies kann z. B. in User-Stories erfolgen. Bei Rückfragen des Teams steht er als Ansprechpartner bereit. Kernrolle Programmierer: Die Programmierer sind für die Realisierung und die Umsetzung der Kunden-Anforderungen zuständig. Sie übernehmen die Design Erstellung, implementieren Funktionen, schreiben den Programmcode und erarbeiten Versionen und Iterationen. Zum Abschluss wird das fertige Produkt an den Kunden übergeben. Rolle Terminmanager: Der Terminmanager übernimmt den Zeitplan. Er überwacht die Termine der Programmierer und interveniert bei Abweichungen. Rolle Berater: Der Berater ist eine externe Person die dem Team Spezialwissen vermitteln kann. Der Berater steht nur während einer kurzen Zeit im Projekt zur Verfügung. Rolle Big Boss: Big Boss ist der direkte Vorgesetzte vom Coach und hilft dem Coach bei der Projektdurchführung.

Seite 7

4.2 XP Werte Bei Extreme Programming (XP) wird die Vorgehensweise für das Projekt genau vorgegeben. Es werden Rules and Practices (übersetzt: Regeln und Praktiken) definiert, diese sind für Kodierung, Testen, Design und Planung vorgesehen und diese Vorgaben sollen eingehalten werden. Über den Rules and Practices stehen 5 Werte. Diese lauten: Respekt, Mut, Einfachheit, Feedback und Kommunikation. Mit den Werten und weiteren 15 Prinzipien können die Praktiken und Regeln umgesetzt werden (vgl. Hanser 2010 S. 13).

Abbildung 3 Schaubild Grundwerte von Extreme Programming

Wert Kommunikation: Ein sehr entscheidender Erfolgsfaktor ist die Kommunikation. Hierbei gibt es die interne und externe Kommunikation. Die interne Kommunikation erfolgt zwischen den Teammitgliedern. Als externe Kommunikation wird die Absprache mit dem Kunden bezeichnet. Im Rahmen der Kommunikation können Fragen und Probleme schnell gelöst werden. Wert Mut: Dauernde neue Kunden Anforderungen können mit XP umgesetzt werden. Dafür ist eine permanente Design- und Code-Anpassung notwendig. In manchen Fällen ist es eventuell sinnvoll eine Neuentwicklung vom Code und Design durchzuführen, wenn das Team feststellt das die fortlaufende Entwicklung die Kosten in die Höhe treibt und die Code-Weiterentwicklung erschwert wird. Die Entscheidung einer möglichen Neuentwicklung erfordert großen Mut und lässt sich mit dem „Wert“ Mut des Kunden und vom ganzen Team bewerkstelligen.

Seite 8

Wert Einfachheit: Bei XP steht die einfache Lösung im Vordergrund. Der entwickelte Code soll möglichst einfach sein. Im besten Falle ist keine Kommentierung im Code notwendig. Einfache Lösungen sind günstig und schnell zu realisieren. Wert Feedback: Das Team erhält Feedback mittels erfolgreicher Tests und Kunden Feedback über das ausgelieferte Produkt. Dadurch kri...