Agiles IT-Projektmanagement mit Scrum


Bachelorarbeit, 2011

73 Seiten, Note: 1,7


Leseprobe


Inhaltsverzeichnis

Bilderverzeichnis

1. Einleitung und Motivation
1.1 Motivation
1.2 Ziel
1.3 Vorgehensweise

2. Projektmanagement
2.1 Grundlagen
2.2 Methodiken im IT-Projektmanagement
2.2.1 Wasserfall-Modell
2.2.2 V-Modell XT
2.2.3 Extreme Programming
2.3 Agiles Projektmanagement
2.3.1 Einführung
2.3.2 Das Agile Manifest
2.3.3 Prinzipien des agilen Manifest

3. Scrum
3.1 Grundlagen und Geschichte
3.2 Rollen
3.2.1 Scrum Master
3.2.2 Product Owner
3.2.3 Team
3.2.4 Weitere Rollen
3.3 Anforderungsmanagement in Scrum
3.3.1 Product Backlog
3.3.2 Sprint Backlog
3.3.3 Burn Down Chart
3.4 Sprints
3.5 Meetings
3.5.1 Release-Planung
3.5.2 Sprint Planning Meeting
3.5.3 Daily Scrum
3.5.4 Scrum of Scrums
3.5.5 Sprint Review
3.5.6 Retrospektive

4. Einführung und Praxis
4.1 Einführung von Scrum
4.1.1 Motivatoren
4.1.2 Vorgehensweisen
4.1.3 Gefahren
4.2 Praxisbeispiel: telegate Media AG
4.2.1 telegate Media vor der Einführung von Scrum
4.2.2 Idee, Einführung und Umsetzung
4.2.2.2 Einführung und Umsetzung
4.2.3 Wirkungen der Einführung

5. Bewertung
5.1 Kriterien eines geeigneten IT-Projektmanagements
5.2 Eignung von Scrum für das Management von IT‑Projekten
5.3 Weitere Einsatzmöglichkeiten
5.4 Grenzen der Analyse

6. Fazit

Literaturverzeichnis

Bilderverzeichnis

Bild 1 Wasserfall-Modell

Bild 2 V-Modell XT

Bild 3 Manifesto for Agile Software Development

Bild 4 Grafische Darstellung der Scrum Prozesse

Bild 5 Sprint Backlog

Bild 6 Burn Down Charts

Bild 7 Sprint Typen

Bild 8 Zeitversetzte und Synchronisierte Sprints

1. Einleitung und Motivation

1.1 Motivation

Projekte gibt es schon seit Jahrtausenden. Bereits vor 4500 Jahren erbauten die Ägypter Pyramiden, Projekte von beachtlicher Größe und enormem Aufwand (Litke 2007, S. 7). Auch heute gibt es Projekte mit enormen Ausmaßen wie z. B. das 2005 in Deutschland eingeführte LKW-Mautsystem. Es gibt aber auch zahlreiche kleinere Projekte, deren Ergebnisse sich z. B. als Software in Motorsteuergeräten moderner Autos, DVD-Player, Handys, Digitalkameras, Kassensysteme im Supermarkt, gmx.de, google.com, facebook.com und vielen weiteren Produkten wiederfinden, die für unser alltägliches Leben von Bedeutung sind.

Für die erfolgreiche und effiziente Abwicklung solcher und anderer Projekte bedarf es einer klaren und systematischen Vorgehensweise (Bea et al. 2008, S. 30). In der Literatur und in der Praxis finden sich hierfür eine Reihe von Methodiken und Vorgehensweisen. Eine davon ist Scrum, das als De-Facto-Standard für agiles Projektmanagement gilt (Gloger 2010, S. 195). Aber was genau ist Scrum, wie funktioniert es, worin unterscheidet es sich von anderen Methodiken und macht der Einsatz überhaupt Sinn? Zur Beantwortung dieser Fragen sind eine umfassende Vorstellung und eine Bewertung von Scrum notwendig. Hilfreich ist auch ein Blick über den Tellerrand der wissenschaftlichen Theorie hinaus in die Praxis, was diese Arbeit leisten wird.

1.2 Ziel

Ziel dieser Arbeit ist es, Scrum umfassend zu beschreiben und anschließend, anhand zuvor diskutierter Kriterien, zu bewerten. Beim Leser soll also ein umfassendes Verständnis für diese agile Projektmanagementmethodik geschaffen werden. Daneben soll es dem Leser ermöglicht werden, Scrum im Kontext seines Arbeitsumfelds bzw. für künftige Projekte kritisch zu bewerten und eine fundierte Entscheidung bezüglich einer Einführung von Scrum zu treffen.

1.3 Vorgehensweise

Zu Beginn wird sich die Arbeit, mithilfe vorhandener Literatur, mit Projekten, Projektmanagement und Projektmanagementmethodiken beschäftigen. Die Einführung in agiles Projektmanagement und dessen Differenzierung zu anderen Methodiken und Vorgehensweisen bildet dann den Übergang zu einer umfassenden Auseinandersetzung mit Scrum. An dieser Stelle wird Scrum detailliert erläutert und es wird beschrieben, wie eine mögliche Einführung praktisch umgesetzt werden kann. Anschließend wird auf Schwierigkeiten und Probleme, die dabei auftreten können, eingegangen. Wie das praktisch aussehen kann, wird mithilfe eines Beispiels aus der Praxis illustriert. Dies bildet dann die Grundlage zu einer abschließenden Bewertung bezüglich der Einsatzmöglichkeiten sowie der Stärken und Schwächen von Scrum.

2. Projektmanagement

2.1 Grundlagen

Um ein gemeinsames Verständnis für die Begriffe Projekt und Projektmanagement zu haben, werden diese hier definiert.

Kessler und Winkelhofer (2004, S. 9–10) beschreiben ein Projekt in Anlehnung an DIN 69 901 als ein Vorhaben, das im Wesentlichen durch die Einmaligkeit seiner Bedingungen in ihrer Gesamtheit gekennzeichnet ist. Als Beispiele zählen sie Zielvorgabe, Abgrenzung von anderen Vorhaben, begrenzte Ressourcen und eine projektspezifische Organisation auf. Als weitere Eigenschaften eines Projekts nennen sie unter anderem Neuartigkeit, Komplexität, klare Zielsetzung und zeitliche Begrenzung. Ferner definieren sie Projektmanagement als das erforderliche Management, um ein Projekt in einer bestimmten Art, zu einer bestimmten Zeit mit einem bestimmten Einsatz von Ressourcen zu einem bestimmten Ergebnis zu bringen. Basierend auf der DIN 69 901 beschreiben sie Projektmanagement auch als Gesamtheit von Führungsaufgaben, -organisationen, -techniken und -mitteln für die Abwicklung eines Projekts.

Bea, et al. (2008, S. 31) definieren ein Projekt ähnlich als ein zeitlich befristetes Vorhaben, das sich neben seiner Neuartigkeit und Einmaligkeit auch durch seine Größe und Komplexität auszeichnet. Ohne den Begriff Unternehmenswert explizit zu definieren, identifizieren Bea, et al. (2008, S. 36) dessen Steigerung als die wichtigste Zielsetzung des Projektmanagements. Dazu trage das Projektmanagement mit einer effizienten Planung, Umsetzung und Kontrolle einzelner Projekte bei. Realisiert wird der Wertbeitrag eines Projekts durch ein systematisches Vorgehen.

Versteegen, et al. (Versteegen et al. 2001, S. 209–210) liefern keine vollständige Definition für das Projektmanagement, identifizieren aber aus Unternehmenssicht Termin- und Budgeteinhaltung und aus Kundensicht die Erfüllung seiner Anforderungen zum vereinbarten Zeitpunkt als wesentliche Kriterien.

Auch wenn es, wie Versteegen et al. (Versteegen et al. 2001, S. 209) anmerken, keine einheitliche Definition für das Projektmanagement in der Softwareentwicklung gibt, findet sich im intendierten Ziel, ein Projekt erfolgreich abzuschließen, eine wesentliche Gemeinsamkeit. Diese Arbeit orientiert sich bezüglich der Betrachtung des Projektmanagements ebenfalls an dieser Sichtweise und den von Versteegen et al. genannten Kriterien Termineinhaltung, Budgeteinhaltung und Anforderungserfüllung.

2.2 Methodiken im IT-Projektmanagement

Aufbauend auf das vorige Kapitel, werden hier einige Methodiken für das Management von IT-Projekten exemplarisch vorgestellt. Damit soll eine Grundlage geschaffen werden, mit der später Scrum verglichen werden kann. Als IT-Projekte werden in dieser Arbeit solche verstanden, deren Ziel die Entwicklung von Produkten aus dem Bereich Informationstechnik ist.

2.2.1 Wasserfall-Modell

Das Wasserfall-Modell ist das älteste im Software-Engineering bekannte Vorgehensmodell. Kennzeichnend für das Wasserfall-Modell ist das sequentielle Abarbeiten der einzelnen Phasen. In jeder Phase wird ein Ergebnis produziert, das einer Qualitätskontrolle unterzogen und als Input der nächsten Phase bereitgestellt wird. Alternativ ist auch ein Rücksprung in die vorangegangene Phase möglich. (Ruf und Fittkau 2008, S. 31; Versteegen 2002, S. 30–31)

Die Stärke des Wasserfall-Modells ist gleichzeitig auch seine Schwäche. Da die Projektdetails bereits zu Beginn festgelegt und vom Kunden abgenommen werden, können spätere Änderungen gering gehalten werden. Dadurch lässt sich eine bessere Steuerbarkeit und Berechenbarkeit des Projekts bezüglich Zeit und Kosten erreichen. Der Versuch, Änderungen möglichst gering zu halten, macht es aber auch schwierig, während des Projekts erzielte Lerneffekte in das Projekt mit einfließen zu lassen. (Poppendieck und Poppendieck 2003, S. 25)

Abbildung in dieser Leseprobe nicht enthalten

Bild 1 Wasserfall-Modell

Quelle: in Anlehnung an Ruf und Fittkau (2008, S. 31)

Alternative Darstellungen des Wasserfall-Modells, die sich primär in der Auswahl der verwendeten Phasen unterscheiden, finden sich unter anderem bei Madachy (2008, S. 31), Schönsleben (2001, S. 107) und Stobbs (2000, S. 56).

2.2.2 V-Modell XT

Der Standard für die Entwicklung und Wartung von Software aller deutschen Bundesministerien ist das V-Modell, welches 1992 erstmals veröffentlicht wurde und seitdem ständig weiter entwickelt wird (Bernhard et al. 2003, S. 289). Die derzeit aktuelle Version ist das 2005 veröffentlichte V-Modell XT. Dieses deckt eine ganze Reihe von Projekttypen und Disziplinen wie beispielsweise Projektmanagement, Qualitätssicherung, Konfigurationsmanagement oder Ausschreibung und Vergabe ab. (Kirk 2010, S. 26–27) Ein durch das Suffix XT im Namen dargestellter Unterschied und wesentlicher Bestandteil des V-Modell XT gegenüber den vorherigen Versionen, ist das eXtreme Tailoring, womit gemeint ist, dass sich das Modell an die gegebenen Erfordernisse des Unternehmens und des Projekts anpassen lässt. (Faerber 2010, S. 17)

Das zentrale Element des Tailoring sind Vorgehensbausteine, die jeweils eine eigenständige Einheit darstellen und die wesentlichen Inhalte des V-Modell XT enthalten. Diese können verändert und erweitert werden, und beinhalten alle notwendigen Aktivitäten und zu erstellenden Produkte, einschließlich der mitwirkenden Rollen, die zur Erfüllung von Aufgabenstellungen im Rahmen eines V-Modell-Projekts relevant sind. Einige dieser Vorgehensbausteine werden zusammen als der V-Modell-Kern bezeichnet, der ein Mindestmaß an Qualität in der Projektdurchführung garantieren soll und für jedes Projekt obligatorisch ist. Zu diesem V-Modell-Kern gehören die Vorgehensbausteine Projektmanagement, Qualitätssicherung, Konfigurationsmanagement und Problem- und Änderungsmanagement.

In welcher Reihenfolge die Vorgehensbausteine angewendet werden, ist nicht vorgegeben, sondern hängt von der Projektdurchführungsstrategie ab, die festlegt, wann welches Produkt zu erstellen ist. Als Produkt werden alle zentralen Zwischen- und Endergebnisse des Projekts verstanden. Die Projektdurchführungsstrategie wird auf Basis des Projekttyps (unterstützt werden die Typen Systementwicklungsprojekt als Auftraggeber, als Auftragnehmer, Systementwicklungsprojekt innerhalb der Organisation und Einführung und Pflege eines organisationsspezifischen Vorgehensmodells) und der Projektvariante, die den Projekttyp näher charakterisiert, entwickelt. Neben der Projektdurchführungsstrategie werden auch sogenannte Entscheidungspunkte definiert, die einen Meilenstein darstellen, an dem der Projektfortschritt geprüft und gegebenenfalls das weitere Vorgehen freigegeben wird. In Bild 2 finden sich alle vorgesehenen Entscheidungspunkte, die entsprechend der in der Legende dargestellten Aufteilung in vier Bereiche farblich markiert sind.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2 V-Modell XT

Quelle: V-Modell XT (2002, S. 22)

Die grundlegende Struktur des Projektverlaufs ergibt sich damit durch die Projektdurchführungsstrategie und die Entscheidungspunkte. (Abrahamsson 2002, S. 15–22)

2.2.3 Extreme Programming

Das von Kent Beck, Howard Cunningham und Ron Jeffries entwickelte Extreme Programming zählt zu den bekanntesten Vertretern der agilen Methodiken und Modellen. Extreme Programming kennzeichnet sich durch die fünf grundlegenden Werte Kommunikation (zwischen allen Beteiligten), Einfachheit (von Lösungen), (frühes und ständiges) Feedback, Mut (zum Handeln), Respekt (gegenüber Anderen und dem Projekt) und Andere (vom Team gewählte Werte). (Beck 2003, S. 18–22)

Aus diesen Werten leiten sich eine Reihe von Handlungspraktiken ab, die sich vereinzelt bereits bewährt haben und eine Verbesserung bringen können, aber erst in der den Werten entsprechenden und den vorherrschenden Erfordernissen ausgerichteten Kombination sich gegenseitig verstärken und einen deutlich spürbaren Nutzen bringen. (Beck 2003, S. 35–36; Litke 2007, S. 276) Im Folgenden sind einige dieser Handlungspraktiken exemplarisch beschrieben:

- Pair Programming: An einem Arbeitsplatz sitzen zwei Entwickler, von denen einer aktiv programmiert und vom zweiten unterstützt wird.
- Test-First-Programming: Bevor Code geschrieben oder geändert wird, werden für das gewünschte Resultat Testfälle geschrieben.
- Ständige Integration: Die Integration und der Test von Änderungen erfolgt alle paar Stunden oder häufiger.
- Geteilter Code: Jeder Entwickler kann zu jedem Zeitpunkt an jeder beliebigen Stelle im System am Code arbeiten und diesen verbessern.
- Ursachenanalyse: Bei jedem gefundenen Fehler wird neben dessen Behebung auch nach der Ursache geforscht und diese beseitigt.
- Echte Kundeneinbindung: Diejenigen, die das Produkt später nutzen, werden direkt in das Team eingebunden.

(Beck 2003, S. 37–70)

Wie aufgrund der Bezeichnung Extreme Programming schon vermutet werden kann, legt diese Methodik den Fokus auf die Softwareentwicklung, insbesondere das Programmieren. Bereiche wie Marketing, Vertrieb oder Management liegen außerhalb der Betrachtung. Genauso wenig kennt Extreme Programming feste Rollen. Stattdessen wird von jedem Teammitglied erwartet, sein bestmöglichstes zu tun, um zum Projekterfolg beizutragen. (Beck 2003, S. 82–85)

Anzumerken ist noch, dass während Litke (2007, S. 273) und Hoffmann (2008, S. 507) die Eignung von Extreme Programming nur für kleine bis mittelgroße Teams als gegeben sehen, ist diese Beck und Andres (2003, S. 3) zufolge auch für große Projekte und Teams geeignet, wenn entsprechend angepasst und skaliert wird.

2.3 Agiles Projektmanagement

Einige Projektmanagementmethodiken wurden bereits vorgestellt. Eine weitere ist das agile Projektmanagement, welches mehr ist als nur eine Methodik. Was das bedeutet, wird im Folgenden beantwortet.

2.3.1 Einführung

In den letzten rund 40 Jahren, in denen Vorgehensmodelle und Methodiken erschienen sind, lässt sich ein klarer Trend hin zu einem immer größeren Umfang und Komplexität erkennen. Während das Wasserfall-Modell ( 2.2.1) noch relativ leicht zu Beschreiben ist, erfordert das V-Modell XT (2002) eine umfassende Einarbeitung. Daneben werden traditionellen Vorgehensmodellen und Methodiken eine durch zu starre Strukturen bedingte Inflexibilität, eine mangelnde Einbeziehung des Kunden in die Entwicklungsprozesse und ein hoher Dokumentationsaufwand vorgeworfen. Als Gegengewicht dazu erschienen in den 1990er Jahren die ersten agilen Methodiken, die das Ziel hatten, Software-Entwicklungsprozesse zu verschlanken und deren Komplexität zu reduzieren. (Hoffmann 2008, S. 506–507; Vigenschow 2008) Zu diesen zählt Gloger (2010, S. 195) neben Scrum das Extreme Programming (Beck 2003) von Kent Beck und Ward Cunningham, Crystal Clear von Alistair Cockburn (Cockburn 2005) und Feature Driven Development von Jeff DeLuca und Peter Coad (De Luca o. J.). Als weitere bekannte Vertreter nennt Seibert (2007, S. 42–43) auch Adaptive Software Development von James Highsmith (Highsmith 2000) und Lean Software Development von Mary und Tom Poppendieck (Poppendieck und Poppendieck 2003).

Im Februar 2001 trafen sich 17 Leute in Utah, darunter einige der eben genannten Vertreter agiler Methodiken sowie Softwarespezialisten aus unterschiedlichen Bereichen, die eines gemeinsam hatten: Sie sahen die Notwendigkeit für eine Alternative zu schwergewichtigen Software-Entwicklungsmethodiken. In den drei Tagen, die sie gemeinsam verbrachten, gründeten sie die „Agile Alliance“ und entwickelten das „Manifesto for Agile Software Development“ auch bekannt als das Agile Manifest. (Highsmith 2001)

2.3.2 Das Agile Manifest

Agile Entwicklung ist nicht einfach eine Methodik, ein Modell oder ein Prozess. Es ist eine Philosophie. Es ist die Denkweise wie sie vom agilen Manifest vorgesehen und durch vier Bewertungen und zwölf Prinzipien beschrieben ist. (Shore und Warden 2008, S. 9)

Das Agile Manifest ( Bild 3) beginnt mit der Aussage, dass dessen Verfasser durch ihre Praxis bessere Wege der Softwareentwicklung finden und anderen dabei helfen. Daraus lässt sich schließen, dass das agile Manifest nicht nur theoretischer Natur ist, sondern aus der praktischen Erfahrung vieler Spezialisten der Softwareentwicklung resultiert. Durch diese Arbeit, so die Verfasser, kommen sie zu den folgenden Bewertungen:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

Im Vordergrund stehen die einzelnen Menschen, die zusammen entwickeln und miteinander sowie mit ihrer Umwelt interagieren. Auch wenn Werkzeuge und Prozesse durchaus wichtig sind, dürfen sie die Arbeit der Menschen nicht einschränken. Während es die Menschen sind, die ein Projekt voranbringen, sollen ihnen Prozesse und Werkzeuge lediglich als Hilfsmittel dienen, um das Projektziel zu erreichen. (Bleek und Wolf 2008, S. 14–15)

2. Lauffähige Software ist wichtiger als umfassende Dokumentation

Lucius Annaeus Seneca schrieb einst: „Longum iter est per praecepta, breve et efficax per exempla“, was etwa so viel bedeutet wie: Lang ist der Weg durch Lehren, kurz und wirkungsvoll durch Beispiele. (Lautenbach 2002, S. 375) Während die Dokumentation von Funktionalität als Lehre bezüglich der Software betrachtet werden kann, ist lauffähige Software zur Präsentation der Funktionalität wirkungsvoller. Hinzu kommt, dass lauffähige Software der Maßstab ist, mit dem der Projektfortschritt nachgewiesen wird. Daher steht lauffähige Software im Vordergrund und sollte möglichst früh und oft präsentiert werden können. Dokumentation sollte zugunsten lauffähiger Software eingespart werden und nur in dem Umfang erstellt werden, der für die Erreichung des Projektziels erforderlich ist und dabei einfach, präzise, klar, widerspruchsfrei und angemessen bezüglich des Verhältnisses von Aufwand und Nutzen sein. Der Transfer von Wissen sollte weniger durch Dokumentation und mehr durch Interaktion und Kommunikation erfolgen. (Bleek und Wolf 2008, S. 14–15; Koch 2008, S. 74–75)

3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen

Insbesondere bei innovativen Produkten unterliegen Anforderungen einer hohen Unsicherheit, so dass es selten möglich ist, diese und andere Details wie Budget oder Entwicklungsdauer im Rahmen von Vertragsverhandlungen bereits zu Beginn des Projekts präzise festzulegen und auch einzuhalten. Dies wird auch vom jährlich erscheinenden Chaos Report der Standish Group (2009) bestätigt, der besagt, dass nur in etwa einem Drittel aller IT-Projekte innerhalb der vorgegebenen Zeit mit dem geplanten Budget die gewünschten Anforderungen realisiert werden. Die Entwicklung einer brauchbaren und dem Kundenwunsch gerecht werdenden Software ist nur dann möglich, wenn mit dem Kunden und den Anwendern zusammengearbeitet wird. Auch wenn Vertragsverhandlungen vor Projektbeginn erforderlich sind, dürfen sie die spätere Zusammenarbeit nicht behindern. In den Vertragsverhandlungen sollten lediglich grobe Rahmenbedingungen festgelegt werden, die nach und nach zusammen mit dem Kunden präzisiert werden. Dies und die ständige Möglichkeit des Teams, vom Kunden Feedback zu erhalten bzw. zu erfragen, erhöht die Wahrscheinlichkeit, dass Anforderungen richtig verstanden und durch eventuelle Spekulationen bezüglich der Kundenwünsche entstandene falsche Annahmen für die Entwicklung vermieden werden. Auch die Wahrscheinlichkeit, dass zu einem späten Zeitpunkt beim Kunden Änderungswünsche auftreten, reduziert sich damit. (Dubinsky und Hazzan 2008, S. 10; Koch 2008, S. 76)

4. Die Reaktion auf Veränderungen ist wichtiger als das Befolgen der Planung

Während eines Projekts können ständig neue Erkenntnisse und Lerneffekte auftreten. So kann für das geplante Produkt die Notwendigkeit weiterer oder die Zwecklosigkeit geplanter Funktionen erkannt werden. Effizienzhemmer in bestimmten Vorgehensweisen können durch Lerneffekte vermieden werden. Es gibt viele unterschiedliche Veränderungsmaßnahmen, die erkannt werden und eine Verbesserung für den Projektablauf bedeuten können. Daher wird die Reaktion auf Veränderungen als wichtiger bewertet als das sture Befolgen von Plänen. (Bleek und Wolf 2008, S. 15)

Im Anschluss an diese vier Bewertungen folgt die Aussage, dass die Autoren zwar den Werten auf der rechten Seite einen Wert beimessen, denen auf der linken Seite jedoch einen höheren Wert zuschreiben.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Workings software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the item on the left more.

© 2001, the above authors: This declaration may be freely copied in any form, but only in its entirety through this notice.

Abbildung in dieser Leseprobe nicht enthalten

Bild 3 Manifesto for Agile Software Development

Quelle: Beck et al. (2001)

2.3.3 Prinzipien des agilen Manifest

Hinter den oben genannten Werten des agilen Manifests stehen die folgenden zwölf Prinzipien[1]:

1. Die höchste Priorität hat die schnelle und stetige Zufriedenstellung des Kunden mit brauchbarer Software.
2. Selbst in späten Entwicklungsstadien sind Änderungswünsche stets willkommen. Agile Prozesse nutzen diese zur Schaffung von Wettbewerbsvorteilen für den Kunden.
3. Liefere häufig lauffähige Software, sei es alle paar Wochen oder alle paar Monate. Bevorzuge dabei kürzere Zeitabstände.
4. Entwickler und Geschäftsleute müssen über die gesamte Laufzeit des Projekts Tag für Tag zusammen arbeiten.
5. Setze für Projekte motivierte Leute ein und gib ihnen die Umgebung und Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe meistern.
6. Die Wirksamste und effizienteste Art der Kommunikation mit und in einem Entwicklerteam ist die direkte Besprechung von Angesicht zu Angesicht.
7. Lauffähige Software ist der Hauptmaßstab des Entwicklungsfortschritts.
8. Agile Prozesse fördern eine nachhaltige Entwicklung. Die Geldgeber, die Entwickler und die Benutzer sollten im Stande, sein ein dauerhaft gleichmäßiges Tempo beizubehalten.
9. Die ständige Beachtung technischer Feinheiten und guten Designs fördert Agilität.
10. Einfachheit, die Kunst der Maximierung nicht zu erledigender Arbeit, ist essentiell.
11. Die besten Architekturen, Anforderungen und Designs kommen von sich selbst organisierenden Teams.
12. Das Team reflektiert regelmäßig darüber, wie es sich selbst in Bezug auf seine Wirksamkeit verbessern kann und passt sein Verhalten dementsprechend an.

(The Agile Alliance)

Auf dem agilen Manifest basieren viele agile Methodiken, die aus einer Kombination verschiedener Praktiken, wie z. B. Pair Programming, regelmäßige Retrospektiven etc., bestehen. Auch wenn der Anschein entstehen kann, dass man durch eine Kombination diverser Praktiken einfach eine völlig neue, an die eigenen Bedürfnisse angepasste, agile Entwicklungsmethodik konstruieren kann, sollte man dies vermeiden. Eine agile Methodik ist mehr als nur die Summe seiner Praktiken. Die Kombination der Praktiken einer agilen Methodik ist ein Ausdruck der ihr zugrunde liegenden Prinzipien und um eine agile Methodik zu beherrschen ist es notwendig, diese Prinzipien verstanden zu haben. (Shore und Warden 2008, S. 10-11, 357)

3. Scrum

3.1 Grundlagen und Geschichte

Dieses Kapitel führt in die laut Hammerstein (Hammerstein 2009, S. 29) am weitesten verbreitete agile Methodik Scrum ein und beantwortet die Frage nach dessen Herkunft.

Der Begriff Scrum ist weder eine Abkürzung, noch ist es ein Akronym, sondern stammt aus dem Sport Rugby und betitelt eine Standardsituation zur Wiederaufnahme des Spiels, in der sich eine bestimmte Anzahl an Mitspielern beider Mannschaften in einer Art Gedränge dicht gegenübersteht, um durch wegschieben der jeweils anderen Mannschaft in den Ballbesitz zu kommen. In dieser Situation kann sich eine Mannschaft nur dann den Ballbesitz erkämpfen, wenn sie erfolgreich zusammenarbeitet. (Mitchell et al. 2006, S. 190; Schwaber und Beedle 2002, S. 121–122)

Auch wenn zunächst Extreme Programming ein gewisse Verbreitung fand, sieht Seibert (2007, S. 41–42) Scrum als repräsentatives Beispiel für agile Methodiken. Gloger (2010, S. 195) geht noch einen Schritt weiter und bezeichnet Scrum als De-Facto-Standard der agilen Softwareentwicklung. Den Grund dafür sehen beide darin, dass, während Extreme Programming klare Vorgaben zur Entwicklung macht, Scrum eher auf das Management ausgerichtet ist. Bestätigt wird dies auch durch das Ergebnis einer Studie (Wolf und Roock 2008, S. 10), wonach zwar Extreme Programming unter den Befragten mit 93 Prozent eine höhere Bekanntheit genießt als Scrum mit 74 Prozent, was aber den erfolgreichen Einsatz betrifft mit 14 Prozent deutlich hinter Scrum liegt, das mit 21 Prozent die am häufigsten erfolgreich eingesetzte agile Methodik unter den Befragten ist.

Das erste Mal wurde Scrum 1993 unter Anleitung von Ken Schwaber eingesetzt, nachdem dieser den CEO der Easel Corporation von den Vorteilen dieser Methodik überzeugte. Das Resultat war nicht nur ein Produkt mit allen zum Schluss gewollten (und nicht ursprünglich gedachten) Funktionalitäten, sondern auch, dass ein von diesem CEO verantworteten Projekt termingerecht zum erfolgreichen Abschluss gebracht werden konnte. (Sutherland 2004, S. 1–3)

Abbildung in dieser Leseprobe nicht enthalten

Bild 4 Grafische Darstellung der Scrum Prozesse

Quelle: In Anlehnung an Cohn (2010b, S. 167)

In Scrum werden die Anforderungen und Eigenschaften, die für das zu entwickelnde Produkt realisiert werden sollen, vom Product Owner im Product Backlog ( 3.3.1) gesammelt und verwaltet. Die wichtigsten daraus legt er im Sprint Planning Meeting ( 3.5.2) vor, von denen das Team diejenigen auswählt, die es in der nächsten Iteration realisieren kann. Aus diesen leitet sich das Team Aufgaben ab und hält sie im Sprint Backlog ( 3.3.2) fest. Während der Iteration, die in Scrum als Sprint ( 3.4) bezeichnet wird, arbeitet das Team den Sprint Backlog eigenverantwortlich ab und validiert dabei im 24-Stunden- Rhythmus seinen Fortschritt im Daily Scrum ( 3.5.3). Das Ziel jeder Iteration ist es, ein potentiell auslieferbares Produkt fertig zu stellen. Bild 4 veranschaulicht grob diese Vorgänge.

Durch das Sprint Planning Meeting, dem Daily Scrum sowie dem Sprint Review ( 3.5.5) und der Retrospektive ( 3.5.6) findet in Scrum eine empirische Prozesssteuerung statt, mit welcher die Produktivität und die Entwicklungsrichtung in Bezug auf das Ziel ständig überwacht und angepasst sowie die gemeinsame Arbeit reflektiert und entsprechend verbessert werden. (Hammerstein 2009, S. 30; Schwaber und Sutherland 2010, S. 4)

Scrum gibt, wie bei agilen Methodiken üblich, nicht viele Regeln vor. (Coldeway 2003, S. 52) Um aber die Einhaltung der vorhandenen Regeln und das Funktionieren von Scrum sicherzustellen, gibt es den Scrum Master ( 3.2.2), der neben dem Product Owner und dem Team die dritte Rolle in Scrum darstellt.

3.2 Rollen

In Scrum gibt es die drei Rollen Scrum Master, Product Owner und Team, die in den nächsten Abschnitten beschrieben und in ihrer Gesamtheit als Scrum-Team bezeichnet werden.

3.2.1 Scrum Master

Die erste hier vorgestellte Rolle ist der Scrum Master, deren Zweck es ist, das Funktionieren von Scrum sicherzustellen. Welche Aufgaben und Verantwortlichkeiten damit verbunden sind, folgt in diesem Abschnitt.

Zunächst sei angemerkt, dass es sich beim Scrum Master nicht um einen Projektleiter oder Teamleiter handelt. Sollte er eine solche Rolle einnehmen, wäre das keine korrekte Umsetzung von Scrum, da z. B. dem Product Owner ( 3.2.2) die Möglichkeit genommen würde, das Team direkt zu steuern. Um ein nachhaltiges Funktionieren von Scrum sicherzustellen, müssen die Inhaber der Rollen diese richtig verstanden haben und sie entsprechend leben. (Pichler 2009, S. 24)

Einen wesentlichen Punkt, der einen Scrum Master von einem Projektleiter oder Teamleiter unterscheidet, sehen Wieczorrek und Mertens (2010, S. 127) darin, dass sich der Scrum Master zurücknehmen muss und auf keinen Fall in die Arbeit des Teams eingreifen darf. Tim Lister (2007) veranschaulicht dies mit einem Bild von marschierenden Küken. Der Scrum Master, oder von Lister allgemeiner als agile leader bezeichnet, entspricht in diesem Bild nicht dem vordersten Küken, das den Weg vorgibt. Dieses bezeichnet er lediglich als Scout, während er das hinterste Küken, welches stets das Ziel und die Gruppe im Auge hat, als tatsächlichen Leader betrachtet. Von dieser Position aus, so Eickmann (2009a, S. 122–123), ist es dem Scrum Master möglich, sicherzustellen, dass sich das Team an die Scrum Regeln hält und keine Gefahren die Arbeit des Teams bedrohen.

Damit das Team sich an die Regeln hält und mit seiner Arbeit möglichst effizient das Ziel verfolgt, agiert er ähnlich wie ein Coach von Sportteams. Er bereitet das Team vor, erklärt die Regeln und beantwortet aufkommende Fragen. Während das Team dann auf dem Feld eigenverantwortlich agiert, steht er selbst nur am Spielfeldrand, ohne aktiv am Spiel teilzunehmen und beobachtet stattdessen die Spielweise (Arbeitsweise) des Teams, deckt Schwachstellen oder Potentiale auf und gibt dem Team Hinweise, wie es sich verbessern kann.

Daneben wacht er über mögliche Gefahren, die auf sehr unterschiedliche Weise in Erscheinung treten können. Beispielsweise können dem Team notwendige Ressourcen fehlen, weil z. B. Testhardware fehlt oder die IT-Abteilung keinen Bugtracker bereit stellt. Dem Team oder einzelnen Teammitgliedern können zusätzliche Aufgaben zugeteilt werden oder Teammitglieder werden ganz abgezogen. Es können durch die Organisation bedingte Probleme auftreten, wie z. B. ungeeignete Arbeitsräume, Besprechungsräume oder fehlende Medien. Ein falsches Rollenverständnis, Interessenskonflikte und Differenzen zwischen den Beteiligten stellen ebenso Gefahren dar wie private und fachliche Probleme der einzelnen Teammitglieder. Nicht alle dieser oder anderer auftretenden Probleme oder Hindernisse können vom Scrum Master selbst beseitigt werden. In solchen Fällen ist er trotzdem für deren Beseitigung verantwortlich, was Eickmann zufolge oft mit einem hohen Aufwand an Zeit und einem guten Durchsetzungsvermögen verbunden ist.

[...]


[1] Die Nummerierung soll hier keine Rangfolge oder Gewichtung suggerieren, sondern nur einen Bezug zu den einzelnen Punkten erlauben.

Ende der Leseprobe aus 73 Seiten

Details

Titel
Agiles IT-Projektmanagement mit Scrum
Hochschule
Universität Duisburg-Essen
Note
1,7
Autor
Jahr
2011
Seiten
73
Katalognummer
V183805
ISBN (eBook)
9783656086185
ISBN (Buch)
9783656086444
Dateigröße
701 KB
Sprache
Deutsch
Schlagworte
Scrum, agile Softwareentwicklung, agiles Projektmanagement, agile Prozesssteuerung, agil, Managementframework, Projektmanagement, Softwareentwicklung, Daily Scrum, Sprint, Product Owner, Scrum Master, Product Backlog, Burn Down Chart, User Story, telegate, telegate Media, Vorgehensmodell, agiles Manifest
Arbeit zitieren
Jonas Tewolde (Autor:in), 2011, Agiles IT-Projektmanagement mit Scrum, München, GRIN Verlag, https://www.grin.com/document/183805

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Agiles IT-Projektmanagement mit Scrum



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden