Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
2 Scrum als agiles Managementframework
2.1 Agiles Managementframework
2.2 Agile Prinzipien
2.3 Gründe für Scrum
3 Rollen und Artefakte im Scrum
3.1 Rollen im Scrum
3.1.1 Product Owner
3.1.2 Team
3.1.3 Scrum Master
3.1.4 Andere Rollen und Projektmanagementaufgaben
3.2 Produkt-Backlog
3.2.1 Inhalt eines Produkt-Backlog
3.2.2 Struktur und Anforderungsbeschreibung
3.3 Sprints
3.3.1 Eigenschaften von Sprints
3.3.2 Scrum-Meetings
3.3.3 Sprint Backlog
3.4 Releaseplanung
3.4.1 Transparenz
3.4.2 Beziehung zum Sprint Backlog
4 Fazit
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: Scrum Prozess
Abbildung 2: Übersicht – Scrum Team
Abbildung 3: Sprint-Ablauf (Eigene Darstellung)
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Die Geschichte des Projektmanagements reicht weit in die Vergangenheit zurück. Bereits das Errichten der Pyramiden und des Kölner Doms waren komplizierte Herausforderungen, die nur durch gutes Planen und Organisieren umgesetzt werden konnten. Während des 2. Weltkrieges wurde das Projektmanagement durch Methoden des amerikanischen Militärs, zur Lenkung von Menschen- und Material-Massen, gegründet. Des Weiteren wurden die Methoden in der Raumfahrt weiterentwickelt, bis sie in den 60er Jahren in die Industrie übergingen. Heutzutage findet Projektmanagement auf allen Ebenen, in kleinen sowie in großen Unternehmen Anwendung. Häufig werden Aufgaben in Organisationen durch die Ausübung von Projekten realisiert. So finden sich heute im Projektmanagement viele Methoden und Werkzeuge, die die Durchführung von Projekten vereinfachen und bessere Ergebnisse liefern.1
Agiles Projektmanagement bietet dabei viele Vorteile, wie z.B. Transparenz während des Projektlaufs, ein hohes Maß an Flexibilität bei unerwarteten Änderungen und verkürzte Produkteinführungszeiten. Scrum zählt zu dem bekanntesten Prozess bei agilen Vorgehensweisen. Es ist sehr einfach, hat wenige und klar definierte Rollen, eine geringe Anzahl an Meeting-Formen sowie eine geringe Anzahl an Werkzeugen.2
In dieser Arbeit soll Scrum näher erläutert werden. Dazu werden in Kapitel 2 das agile Managementframework sowie die agilen Prinzipien und das Scrum näher dargestellt.
In Kapitel 3 werden die Rollen und Artefakte vorgestellt und anschließend erfolgt in Kapitel 4 ein Fazit.
2 Scrum als agiles Managementframework
Agile Softwareentwicklung ist seit vielen Jahren eine erfolgreiche Vorgehensweise um Software zu erstellen. Des Weiteren werden agile Entwicklungsmethoden, insbesondere Scrum, in einem großen Teil der Unternehmen genutzt. Scrum zählt dabei zu der Erfolgreichsten unter den agilen Methoden.3
2.1 Agiles Managementframework
Bei der agilen Softwareentwicklung können aufgrund fertig umgesetzter Teillieferungen, frühzeitig Rückmeldungen erfolgen. Allerdings müssen die Teillieferungen der Software fehlerfrei funktionieren, um qualitativ hochwertige und realistische Rückmeldungen erhalten zu können.
Bei agilen Methoden stehen Iterationen, die einen zeitlich festen Zyklus abbilden, im Zentrum. Dabei werden in den Iterationen Aktivitäten aus dem klassischen Modell wie Analyse, Design, Implementierung, Testen etc. mehrmals in Zyklen ausgeführt. Im Fokus steht das entwickelte Softwareprodukt, welches durch das iterative Vorgehen verbessert werden soll.
Bei dem inkrementellen Vorgehen wird die iterative Vorgehensweise angewendet, aber nicht auf das bestehende Produkt, sondern auf neue oder andere Systemteile. Am Ende einer Iteration steht ein Produktinkrement, welches im weiteren Verlauf weiter ergänzt wird, aber funktional erhalten bleibt. Der Fokus beim inkrementellen Vorgehen liegt also auf Produktteile, die frühzeitig Tests durchlaufen können. Zeitgleich können alle weiteren erwähnten Aktivitäten in einer Iteration erfolgen. Eine Detailplanung über den gesamten Entwicklungszeitraum sowie dessen Umfang ist dadurch nicht notwendig und erfolgt nur für die kommende Iteration.
Vorteile von agilen Methoden sind die schnelle Lieferung von Ergebnissen und die Fokussierung auf die frühe Auslieferung an den Kunden. Nach jeweils einem Inkrement liegt, nach kurzer Zeit, ein Produktteil vor, welches im besten Fall lauffähig ist und an den Kunden übergeben werden kann.4
2.2 Agile Prinzipien
Scrum repräsentiert als agiles Framework die Werte des agilen Programmes, welches den Menschen in den Fokus der Softwareentwicklung stellt. Ohne die gegenseitige Kommunikation und die Kooperation von Menschen kann keine Software entwickelt werden. Scrum fordert und unterstützt dabei die enge Zusammenarbeit aller Mitglieder und orientiert sich nicht an die Technologie. Des Weiteren sind die Verbesserung der Kundenzufriedenheit sowie die Wertschöpfung Teil des agilen Manifests.5
Insgesamt gibt es zwölf Prinzipien im agilen Manifest, die nur als Einheit funktionieren. Diese werden im Folgenden stichpunktartig erläutert:
1. Die höchste Priorität ist die Kundenzufriedenheut, die durch schnelle, ständige und qualitative Softwarelieferungen erreicht werden soll.
2. Veränderungen bei Anforderungen werden auch in späteren Entwicklungsphasen akzeptiert und führen eher zu Wettbewerbsvorteilen.
3. Lauffähige Software soll häufig und in kleinen Intervallen ausgeliefert werden.
4. Softwareentwickler und –Benutzer arbeiten jeden Tag zusammen.
5. Projekte müssen mit motivierten Mitgliedern entwickelt werden. Dabei muss die Umgebung und Unterstützung geschaffen werden.
6. Face-to-Face ist die effektivste und effizienteste Kommunikationsmethode, um Informationen innerhalb eines Teams zu verteilen.
7. Um Projektfortschritt zu messen wird primär die Lauffähigkeit einer Software genutzt.
8. Anhaltende Entwicklung wird durch agile Prozesse unterstützt. Dabei sollen die Teilnehmer, wie Entwickler und Anwender, über einen unbegrenzten Zeitraum ein stabiles Entwicklungstempo ausüben können.
9. Klares Design und ständige Aufmerksamkeit für technische Perfektion fördert Agilität.
10. Essentiell ist die Vermeidung nicht notwendiger Tätigkeiten.
11. Selbstorganisation in Teams schafft hervorragende Architekturen, Umsetzungen und Designs.
12. Zyklische Überprüfung der Arbeitsweise erfolgt durch das Team mit anschließender Verbesserung und Anpassung.
Das agile Manifest mit den beschriebenen Werten und Prinzipien wurde im Jahr 2001 durch bekannte Persönlichkeiten, wie Ken Schwaber und Jeff Sutherland, formuliert.6
2.3 Gründe für Scrum
Scrum ist in dem Jahr 1993 durch Ken Schwaber und Jeff Sutherland entwickelt worden.7 8 Im selben Jahr wurde das erste Projekt mit Scrum realisiert. Dabei wurde Scrum bereits am Anfang durch fortschrittliche Maßnahmen, die in japanischen Unternehmen zur Entwicklung von Produkten genutzt wurden, beeinflusst. Scrum gehört zu der schlanken Prozessentwicklung und verhindert Überlastungen mit System.
Häufig laufen Projekte zur Softwareentwicklung in Organisationen schief, da Resultate geliefert werden, die nicht der Kundenzufriedenheit entsprechen. Projekte laufen so oft in einen Teufelskreis, wenn die Projektziele in Gefahr sind. So werden neue Mitarbeiter den Projekten zugeordnet und Projektmitglieder verlängern ihre Arbeitszeiten. Dies führt zu Stress, welches dann zu schlechter Softwareentwicklung führt. Eine schlechte Softwarequalität und Mitarbeitermoral führt zu mehr Kontrollen, die das Management einführt. Dies wiederum führt zu einer langsameren Softwareentwicklung.
Das Hauptproblem klassischer Methoden ist der Versuch alle möglichen Eventualitäten im Projektplan zu berücksichtigen. Zeitgleich erfolgt allerdings das Feedback zur Projektentwicklung sehr spät, zumeist erst wenn das Produkt das Testen durchläuft.
Da im Scrum alle Aktivitäten zur Produktentwicklung innerhalb eines kurzen Zyklus (Sprint) erfolgen, können die ersten Fortschrittsrückmeldungen nach kurzer Zeit erfolgen. So werden Schwierigkeiten sowie Störungen frühzeitig erkannt, Lösungen entwickelt und Gegenmaßnahmen ergriffen.9
Ein wichtiger Aspekt ist, dass Scrum den Schwerpunkt auf die strukturierte Zusammenarbeit in selbstständig organisierten Teams legt. Hierzu werden drei Rollen, vier Meeting-Formen sowie drei Artefakte (Werkzeuge) definiert. Der Scrum Prozess wird in der folgenden Abbildung dargestellt.
Abbildung 1: Scrum Prozess
Abbildung in dieser Leseprobe nicht enthalten
10
3 Rollen und Artefakte im Scrum
Scrum kann aus dem englischen mit „Gedränge“ übersetzt werden und stammt aus dem Rugby-Sport. Beim Scrum geht es, wie beim Rugby, um die Bewegung eines gesamten Teams als eine Einheit. Das ganze Team übernimmt dabei die Verantwortung.11 Auf die verschiedenen Rollen wird in Kapitel 3.1 eingegangen.
Im weiteren Verlauf werden die Artefakte, wie das Produkt-Backlog, die Sprints und die Releaseplanung, näher erläutert.
3.1 Rollen im Scrum
Beim Scrum werden drei Rollen unterschieden, der Product Owner, das Team und der Scrum Master. Alle drei Rollen zusammen bilden das Scrum Team. Gemeinsam ist das Scrum Team verantwortlich für die Lieferung eines Produktes an die Stakeholder, wie z.B. an Fachbereichen oder Managern.12
Üblicherweise erfolgt die Arbeit eines Product Owner mit einem Team und jedem Team steht ein eigener Scrum Master zur Verfügung. Damit betreut jeder Scrum Master ein Team.13
Abbildung 2: Übersicht – Scrum Team
Abbildung in dieser Leseprobe nicht enthalten
14
Im weiteren Verlauf werden die drei Scrum Rollen näher vorgestellt.
3.1.1 Product Owner
Der Product Owner ist für Aufgaben im Produkt- und Projektmanagement sowie gleichzeitig für die Softwareentwicklung zuständig. In der Regel ist der Produc Owner mit der Aufgabe Vollzeit beschäftigt. Er repräsentiert die Bedürfnisse der Endkunden, arbeitet über den gesamten Projektverlauf eng mit dem Team zusammen und ist für die Steuerung der Softwareentwicklung zuständig. Durch diese Aufgaben wird der Erfolg eines Projekts stark geprägt Der Product Owner trägt damit die Verantwortung über das Projekt und bildet damit eine zentrale Rolle im Scrum.15
Durch die Zusammenarbeit mit Endkunden, Anwender und Stakeholdern ermittelt der Product Owner die Umsetzungswünsche, den Umfang der Anforderungen und bestimmt die Reihenfolge zur Softwareumsetzung. Diese Anforderungen werden, je nach ihrem Erfolg (Potenzieller Umsatz oder Kosteneinsparungen), in einem sog. Produkt-Backlog aufgenommen. Der Product Owner trägt die Verantwortung über das Produkt-Backlog und bestimmt die Umsetzungsreihenfolge.16 Des Weiteren ist er für die ständige Bearbeitung des Product-Backlog zuständig. Dabei werden neue Anforderungen hinzugefügt, existierende rausgenommen und die Priorisierungen angepasst.
Der Product Owner muss das Product-Backlog kennen und sich regelmäßig mit den Kunden, Anwendern und Stakeholdern, z.B. in Workshops, abstimmen.17
Ein wesentlicher Aspekt ist, dass beim Scrum eine persönliche Kommunikation favorisiert wird. Schriftliche Dokumente werden ebenso genutzt, allerdings fordert das Scrum Face-to-Face zur Kommunikation zwischen Product Owner, Team oder Kunden.18 Dadurch erfolgt während des gesamten Projektverlaufs eine enge Zusammenarbeit zwischen den einzelnen Parteien. Der Product Owner unterstützt dabei das Team beim Verstehen der Bedürfnisse, stellt Anforderungen der Kunden auf, beliefert das Team mit detaillierten Anforderungen und prüft die daraus resultierenden Ergebnisse. Er schafft dadurch eine direkte Verbindung zwischen der Softwareentwicklung und den Kunden.19
Die aufgezeigten Aufgaben eines Produc Owners ähneln der eines Projektleiters. Allerdings gibt es den typischen Projektleiter im Scrum nicht, so dass einige Aufgaben aus dem klassischen Projektmanagement nicht beim Procuvt Owner liegen, sondern beim Team und dem Scrum Master. Um die aufgeführten Aufgaben zu erfüllen muss der Product Ownder über umfassendes und fachliches Wissen verfügen sowie die notwendigen Entscheidungskompetenzen verfügen.20
[...]
1 Vgl. Zell (2013), S.1-2.
2 Vgl. Wintersteiger (2013), S.18-20.
3 Vgl. Wintersteiger (2013), S.17.
4 Vgl. Wintersteiger (2013), S.18-20.
5 Vgl. Pilcher (2008), S.1.
6 Vgl. Wintersteiger (2013), S.20-22.
7 Vgl. Pilcher (2008), S.3.
8 Vgl. Wintersteiger (2013), S.20.
9 Vgl. Pilcher (2008), S.3-4.
10 Vgl. http://www.mcpa.biz/wp-content/uploads/2014/02/Scrum-Framework.png, Abruf: 18.07.2014.
11 Vgl. Wintersteiger (2013), S.47.
12 Vgl. Wintersteiger (2013), S.47.
13 Vgl. Pilcher (2008), S.9.
14 Vgl. http://kept.co.za/group/images/stories/a468-f1-scrum-team.png, Abruf : 20.07.2014.
15 Vgl. Pilcher (2008), S.9-10.
16 Vgl. Wintersteiger (2013), S.48.
17 Vgl. Pilcher (2008), S.10.
18 Vgl. Wintersteiger (2013), S.49.
19 Vgl. Pilcher (2008), S.11.
20 Vgl. Wintersteiger (2013), S.51.