Agiles Projektmanagement - Kanban und Scrum


Seminararbeit, 2011

46 Seiten, Note: 1,0


Leseprobe


INHALT

BILDERVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGS- UND AKRONYMVERZEICHNIS

1. EINLEITUNG
1.1 Thema
1.2 Zielsetzung
1.3 Vorgehensweise

2. KLASSISCHES PROJEKTMANAGEMENT
2.1 Erfolge von IT-Projekten
2.2 Probleme der klassischen Softwareentwicklung
2.3 Das Wasserfallmodell

3. AGILITÄT IN DER SOFTWAREENTWICKLUNG
3.1 Begriffsdefinition
3.2 Werte des Agilen Manifests
3.3 Prinzipien des Agilen Manifests
3.4 Zusammenfassung der Bewertungskriterien

4. KANBAN IN DER IT
4.1 Visualisierung der Wertschöpfungskette
4.2 WIP-Begrenzung
4.3 Das Pull-Prinzip
4.4 Die Kaizen-Kultur

5. SCRUM
5.1 Rollen
5.2 Scrum Ereignisse
5.3 Scrum Artefakte

6. BEWERTUNG
6.1 Nutzwerte
6.1.1 UnvorhergeseheneAnderungen
6.1.2 Akzeptanz, Forderung und Förderung von Wandel
6.1.3 Projekterfolg und Kundenzufriedenheit
6.1.4 Direkte Kommunikation
6.1.5 Nutzereinbindung
6.1.6 Kurze Release Zyklen
6.1.7 Freiheit und Vertrauen
6.1.8 Reflektionsphasen
6.1.9 Nutzwert Ergebnisse

7. FAZIT UNDWEITERFÜHRENDE FRAGEN

LITERATURVERZEICHNIS

BILDERVERZEICHNIS

Abbildung 1: Projektabschlüsse im Zeitverlauf

Abbildung 2: Comic eines IT-Projektes

Abbildung 3: Wasserfallmodell

Abbildung 4: Änderungskostenkurve

Abbildung 5: Werte des Agilen Manifests

Abbildung 6: Kanban-Regelkreis

Abbildung 7: Ein Kanban-Board

Abbildung 8: Ein Aufgabenticket

Abbildung 9: Pull-prinzip anhand der Tickets C und K

Abbildung 10: Scrum überblick

Abbildung 11: Ein Sprintablauf

Abbildung 12: Ein Burndownchart

TABELLENVERZEICHNIS

Tabelle 1: Arbeitspaket Grundlagen

Tabelle 2: Arbeitspaket Agilität in der Softwareentwicklung

Tabelle 3: Arbeitspaket Kanban

Tabelle 4: Arbeitspaket Scrum

Tabelle 5: Arbeitspaket Bewertung von Kanban und Scrum

Tabelle 6: Arbeitspaket Fazit

Tabelle 7: Zusammenfassung der Kriterien zur Bewertung von agilen Methoden

Tabelle 8: Punkteskala

Tabelle 9: Nutzwert Ergebnisse

ABKÜRZUNGS- UND AKRONYMVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

In dieser Arbeit werden die beiden Frameworks Kanban und Scrum als agile Entwicklungsmethoden vorgestellt und anhand von zuvor ausgearbeiteten Kriterien im Hinblick auf Ihre Agilität bewertet.

1.1 Thema

Das Projektmanagement ist eine Thematik die jedes Unternehmen beschäftigt. Immer komplexere Aufgaben lassen sich von einzelnen Individuen nicht mehr kontrollieren und bewältigen, sodass es nötig ist, diese Aufgaben im Kollektiv zu meistern. Die Entwicklung des Projektmanagements führte dazu, dass immer weniger Projekte scheiterten. Ein Grund für dieses Phänomen ist die Einführung von Standards wie beispielsweise ITIL. Doch solche Standards sind recht umfangreich, sodass auf einem, von konstantem Wechsel durchzogenen Markt wie der IT-Markt einer ist, das klassische Projektmanagement zu starr und unflexibel ist, um dieser Schnelllebigkeit Stand zu halten (Munz und Soergel 2007, S.73). Der Ansatz von Kanban in der IT leitet sich aus einer Technik ab, die Ursprünglich aus dem Toyota-Produktionssystem stammt (Glaser et al. 1992, S. 256). Mit diesem in der Öffentlichkeit erstmals 2007 vorgestellten Ansatz, versucht man das Projektmanagement deutlich schlanker zu gestalten, um so die Wahrscheinlichkeit eines erfolgreichen Projektverlaufs drastisch zu erhöhen. Die Motivation dieser Arbeit liegt nun darin, sich mit den Paradigmen des Projektmanagements auseinanderzusetzen und anhand des Agilitätsbegriffs der Vorgehensmodelle Scrum und Kanban, neue Wege in der Softwareentwicklung aufzuzeigen.

Zielgruppe dieser Arbeit sind zum einen das akademische Publikum mit dem Schwerpunkt des Projektmanagements und zum anderen Unternehmen und Mitarbeiter, die am agilen Projektmanagement interessiert sind.

1.2 Zielsetzung

Die Erkenntnisziele dieser Seminararbeit setzen sich aus einer Beschreibung und Erläuterung der Methoden, sowie der anhand von Kriterien abgeleiteten Bewertung dieser Methoden bezüglich ihrer Agilität und Eignung für die IT zusammen. Ziel dieser Arbeit ist es, anhand von agilen Methoden die entscheidenden Charakteristika für erfolgreiche IT-Projekte auszuarbeiten.

1.3 Vorgehensweise

Zunächst wird das von agilen Methoden adressierte Problem beschrieben. Dazu werden die Erfolgsaussichten von klassischen IT-Projekten vorgestellt und im Anschluss wird auf die Probleme von nicht agilen Vorgehensweisen eingegangen. Im weiteren Verlauf wird die Begrifflichkeit der Agilität näher definiert und anhand diesem sowie des Agilen Manifests, Kriterien zur Bewertung agiler Methoden abgeleitet.

Im Anschluss wird in einem ersten Schritt Kanban und Scrum vorgestellt und erläutert, um in einem zweiten Schritt die Frameworks auf Basis der zuvor abgeleiteten Kriterien, zu bewerten. In einem Fazit wird auf die die Auswertung der Bewertung eingegangen und mögliche Schlussfolgerungen gezogen.

Im Folgenden wird die Vorgehensweise anhand von Arbeitspaketen in den Tabellen 1-6 verdeutlicht.

Tabelle 1: Arbeitspaket Grundlagen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Arbeitspaket Agilität in der Softwareentwieklung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Arbeitspaket Kanban

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Arbeitspaket Serum

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Arbeitspaket Bewertung von Kanban und Serum

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Arbeitspaket Fazit

Abbildung in dieser Leseprobe nicht enthalten

2. Klassisches Projektmanagement

In diesem Kapitel werden zum einen die Erfolgsaussichten von IT-Projekten untersucht und zum anderen auf Probleme klassischer Vorgehensmodelle zur Softwareentwicklung eingegangen.

2.1 Erfolge von IT-Projekten

Der seit 1994 in regelmäßigen Abständen erscheinende CHAOS Report der Standish Group untersucht die Erfolgsquote von Softwareentwicklungsprojekten (Stan-dish Group 1994).

Die Studien zeigen, dass zwischen 1994 und 2009, die Summe der gescheiterten und nur teilweise erfolgreichen Projekte1 stetig gesunken sind.

Im Jahr 1994 waren 31% der Projekte gescheitert und 53% verspätet, oder mit einer Budgetüberschreitung verbunden (Standish Group 1994).

2009 lagen die Zahlen bei 24% für gescheiterte Projekte und 53% für teilweise erfolgreiche Projekte. Die Summe an erfolgreichen Projekten lag bei 16 % (1994), 28 % (2001) und 32 % (2009) (Standish Group 1994/2001/2009).

Berücksichtigt man jedoch das Zeitfenster von über 15 Jahren, ist die Verbesserung nicht signifikant ausgefallen. Abbildung 1 zeigt die obigen Aussagen bezüglich des Projektausgangs.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Projektabschlüsse im Zeitverlauf

Quelle: Eigene Darstellung in Anlehnung an Standish Group

Der CHAOS Report wird in der Literatur kontrovers diskutiert, sodass sich Zweifel gegenüber der Erhebungsmethode und den Ergebnissen nicht ausräumen lassen und somit kritisch zu hinterfragen sind (Eveleens und Verhoef 2010, S.30-36; Jorgensen und Mol0kken2OO6, S.297-301).

Doch viel entscheidender als die konkrete Ausprägung der Ergebnisse ist die Erkenntnis, dass auch nach über zehn Jahren ein erheblicher Anteil an Projekten, trotz Projektmanagements, nicht erfolgreich abgeschlossen wird. In Anbetracht dessen, dass das Agile Manifest erst 2001 (Götzenauer 2009, 26) und die ersten agilen Verfahren, wie eXtreme Programming oder Crystal 2003 veröffentlicht wurden, liegt die unbestätigte Vermutung nahe, dass die Steigerung des Projekterfolgs sowie die Reduzierung der Summe an überschrittenen Projekten zwischen 2001 und 2009 durch agile Methoden bewirkt wurden. Die Untersuchung dieser Fragestellung wird im Rahmen dieser Seminararbeit nicht weiter betrachtet und stellt mögliche Ansatzpunkte zur Messung der Effektivität von agilen Methoden dar.

2.2 Probleme der klassisehen Softwareentwieklung

Die im Kapitel 2.1 geschilderten Erfolgsquoten werden durch viele Faktoren beeinflusst, welche im Folgenden geschildert werden.

Zu Beginn einer Softwareentwicklung werden Pläne und Architekturen ausgearbeitet, Termine festgelegt, mögliche Probleme antizipiert und alles bis ins Detail dokumentiert. Obwohl eine solche Planung durchaus logisch erscheint, scheitert eine solche Vorgehensweise vor allem an Einem: dem Menschen selber (Sutherland 2011, S.14). Su]therland (2011, S.14) beschreibt einen gewaltigen Unterschied zwischen dem, was explizit zu Papier gebracht wurde und dem was der eigentliche die Idee in Gedanken ist. So wissen die Kunden selber nicht konkret, was ihre eigenen Anforderungen sind und können nicht ihre Vorstellungen explizieren und wenn sie es tun, ist dies oft nur unter Berücksichtigung der zuvor skizzierten Verzerrung der Gedanken möglich (Parnas, Clements 1996,S. 251-252).

Denn Kunden müssen die in Auftrag gestellte Software sehen und fühlen, im Sinne von Ausprobieren können um eine Aussage über ihre Anforderungen treffen zu können. Doch genau das wird bei nicht agilen Ansätzen verhindert, indem Anforderungen zu Beginn expliziert und an die Entwicklung weitergegeben werden (Szalvay 2004, S.3). Weiterhin werden entscheidende Softwaredetails, erst während der Entwicklung bzw. Anwendung deutlich.

Dazu spielen externe Faktoren eine Rolle wie z. B. Markt- oder Technologieänderungen, welche eine Änderung der zur entwickelnden Software benötigen. So berücksichtigen klassische Vorgehensmodelle solche Änderungen nur unzureichend (Parnas, Clements 1996,S. 251-252).

Vor allem schaffen klassische Vorgehensmodelle einen großen Koordinations- und Dokumentationsoverhead welchen Schwaber (2007, S. 56-58) mit folgendem Zitat verdeutlicht: „Aus einer Kommunikation von Angesicht zu Angesicht wurde eine Kommunikation auf Basis von Dokumentationen. Schnelle Richtungsänderungen mutierten zu langwierigen Phasen, in denen Anforderungen zusammengetragen wurden“.

Die Gründe solcher Probleme resultieren dadurch, dass viele Methoden zu starr sind und der Kunde nur zu Beginn für die Anforderungen eingebunden wird (Munz und So-ergel 2007, S.72).

Die obig skizierten Probleme er Softwareentwicklung illustriert die Abbildung 2 sehr gut. Die Abbildung zeigt wie das Verständnis einer Software, durch die Kommunikationsbrüche der agierenden Personen völlig verfremdet wird. Der Kunde wollte eine Schaukel in Form eines Reifens, doch wurde durch die Weitergabe entlang des Prozesses, seine Vorstellung zu einer nicht funktionsfähigen Schaukel verfremdet, für diese er zudem überzogen bezahlt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Comic eines IT-Projektes

Quelle: projectcartoon.com in Anlehnung an Oakland (1989, S. 11)

Der CHAOS Report hat zudem Projektleiter nach Faktoren für das Scheitern eines IT-Projektes befragt. Die meist genannte Antwort war unvollständige Anforderungen mit 13,1%, dicht gefolgt von fehlender Nutzerbeteiligung mit 12,4% (Standish Group 2004).

Diese Antworten decken sich mit den zuvor genannten Gründen von Parnas und Clements. Unvollständige Anforderungen resultieren eben gerade durch die fehlende Möglichkeit des Kunden, seine Vorstellungen, eindeutig zu explizieren. Auch ist die fehlende Nutzerbeteiligung eine Symptomatik der Softwareentwicklung, die durch agile Methoden behoben werden soll (vgl. Kapitel 3.1).

Ein bewährtes Mittel um den Erfolg eines IT-Projektes zu steigern, ist die Nutzung von Standards wie z. B. ITIL oder PRINCE2. Doch besitzen Standards im Allgemeinen eine ganze Reihe von Nachteilen. So sind nach Oestereich und Weiss (2007, S. 14) diese oftmals zu langsam weiterentwickelt, sodass aktuelle Ziele verfehlt werden und nur bereits vergangene Problematiken angesprochen werden. Weiterhin besteht die Gefahr, dass Standards einen solchen bürokratischen Apparat bilden, welcher jeglichen Praxisbezug verliert. Doch der größte Kritikpunkt ist die erhebliche Einschränkung der Verantwortung der einzelnen Projektteilnehmer (Oestereich und Weiss 2007, S. 14). Die Tragweite dieses Kritikpunktes wird in Kapitel 3.1 weiter erläutert.

2.3 Das Wasserfallmodell

Das Wasserfallmodell ist das älteste Vorgehensmodell für die Softwareentwicklung und ein klassischer Vertreter eines nicht agilen Ansatzes (Chughtai et al. 2002, S.30). An diesem Modell werden im Folgenden die aus dem Kapitel 2.2 geschilderten Probleme skizziert.

Das Wasserfallmodell teilt die Entwicklung in einzelne Phasen wie z. B. Anforde- rungsanalyse, Design, Implementierung, Testen und ein . Abbildung 3 veranschaulicht die Iteration des Wasserfallmodells.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Wasserfallmodell

Quelle: Eigene Darstellung in Anlehnung an Ahrendts und Marton (2002, S.159)

Ein solches lineares Vorgehensmodell, welches unidirektionale Beziehungen zwischen den Phasen, sowie eine klare Trennung der einzelnen Phasen suggeriert, ist in der Realität außerhalb von sehr kleinen und simplen Projekten unmöglich. Es ist nur dann Verwendbar wenn es möglich ist, schon früh die Anforderungen mit einer sehr hohen Präzision zu antizipieren. (Fischer und Dangelmaier 2000, S.30).

Die Phasen werden inkrementell und linear durchlaufen, was den großen Nachteil mit sich bringt, dass Änderungen die im zeitlichen Verlauf spät eingebracht werden, deutlich mehr Ressourcen benötigen als es zu Beginn der Fall wäre (Fischer und Dangelmaier 2000, S.30).

3 Weiterführende Literatur zum Wasserfallmodell und anderen Vorgehensmodellen findet sich bei Gre-chenig und Bernhart(2009) Kombiniert man, die im zeitlichen Verlauf ändernden Kundenwünsche, mit der hohen Häufigkeit von zu spät erkannten Fehlern, entstehen dadurch, exponentielle wachsende Änderungskosten welche auch den Projektabbruch als Folge haben können. (Ver-steegen 2000,S.29-31).

Mit dem Zitat „People caught up in heavy process can [...] run the risk of becoming documentation generators instead of software developers“ (Boehm und Turner 2008, S. 13) stellen Boehm und Turner zudem eine Zielverfehlung klassischer Methoden fest, in denen die Dokumentation wichtiger als das eigentliche Ziel, eine funktionierende Software gesehen wird.

Szalvay (2004, S.3) verdeutlicht, die in Kapitel 2.2 beschriebenen Problematiken mit dem folgenden Zitat „Although I’m a terrible artist, when I draw a picture I need to see the drawing as I progress. If I tried to close my eyes and draw the same picture, it would prove far less successful. But this is what waterfall asks customers to do: specify the entire system without having a chance to periodically see the progress and make ad-justments to the requirements as needed“.

Weiterhin hat Szalvay die Darstellungen der Änderungskosten nach Boehm, als Vertreter des Wasserfallmodells und somit des klassischen Projektmanagements, sowie den von Cockburn/Ambler und Becks vertretenen agilen Ansatzes in Abbildung 5 zusammengefasst. Kritisch zu beachten ist, dass das Koordinatenkreuz keine Achsenmetriken besitzen sowie die horizontale Achse nicht beschriftet ist, jedoch einen zeitlichen Verlauf suggeriert. Zu Beginn sind die Kosten agiler Ansätze leicht über dem klassischen Ansatz, doch übersteigt die Kurve von Boehm die agilen Vertreter bereits nach kurzer Zeit. Das lässt sich durch den exponentiellen Wachstums der klassischen Kurve erklären, welche gegen Ende des Projekts überproportional hohe Kosten verursacht gegenüber den agilen Methoden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Änderungskostenkurve

Quelle: Szalvay (2004, S. 6)

Fasst man die Probleme der Softwareentwicklung zusammen, so treffen Munz und So-ergel (2007, S.73) die Annahme, „dass bei der Entwicklung von Software in den meisten Fällen keine frühe abschließende Bestimmung der Anforderungen möglich ist. Ein geeignetes Vorgehensmodell muss demnach ein anpassungsfähigen Entwicklungsprozess beschreiben, der flexibel an alle auftretenden Änderungen adaptiert werden kann“.

Vor dem Hintergrund des in Kapitel 3.1 geschilderten Begriffs der Agilität wird mit der Aussage Munzs und Soergels deutlich, dass die Anforderungen an ein Vorgehensmodell, inhaltsdeckend mit den Elementen der Agilität sind.

Nach Frick adressieren agile Methoden genau diese Probleme der Inflexibilität, indem die Fähigkeit auf Veränderungen, angemessen reagieren zu können, bewahrt wird (2002, S.26).

3. Agilität in der Softwareentwicklung

In diesem Kapitel wird die Agilität in der Softwareentwicklung näher betrachtet. Dabei wird zum einen der Begriff näher eingegrenzt und zum anderen werden Kriterien zur Bewertung agiler Methoden ausgearbeitet.

3.1 Begriffsdefinition

Agilität ist eines der zentralen Begriffe dieser Arbeit und aus diesem Grund wird der Begriff Agilität im Folgenden näher eingegrenzt.

Highsmith definiert Agilität mit dem Zitat: "Agility is the ability to both create and respond to change in order to profit in a turbulent business environment“(Highsmith 2002, S.29).

Goldman et al. (1995 S. 42) haben eine sehr umfassende Definition für Agilität ver-fasst:„Agility is dynamic, context specific, aggressively change-embracing and growth-oriented. It is not about improving efficiency, cutting costs or battening down the business hatches to ride out fearsome competitive ‘storms.’ It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about win-ning profits, market share and customers in the very center of the competitive storms many companies now fear“.

Im Kontext dieser Arbeit besteht Agilität im Kern aus vier Elementen, welche aus den obigen Definitionen abgeleitet und im Folgenden vorgestellt werden. Zudem werden diese Elemente als Kriterien für die Bewertung von agilen Methoden benutzt.

Das erste Element ist die Fähigkeit auf (unvorhergesehene) Änderungen angemessen reagieren zu können. Diese unvorhergesehenen Änderungen sind nicht von Seiten des Projektmanagements bei der Planung berücksichtigt, sodass die Reaktion auf diese Änderungen dynamisch und flexibel erfolgen muss. Wie in Kapitel 2.2 erörtert liegt in es der Natur von IT-Projekten, stark mit Änderungen in Beziehung zu stehen.

Beispiele für Änderungen könnten Fluktuationen des Projektteams aufgrund von Krankheiten oder Änderungen der Marktbedingungen aufgrund von Wirtschaftskrisen oder wie in Kapitel 2.2 beschriebene Änderungswünsche der Kunden sein.

[...]


1 Ein Projekt galt als teilweise erfolgreich, wenn der Budget- oder Zeitumfang des Projektes überschritten wurde.

2 Eine vollständige Auflistung findet sich in Standish Group 2004.

3 Weiterführende Literatur zum Wasserfallmodell und anderen Vorgehensmodellen findet sich bei Gre-chenig und Bernhart(2009)

Ende der Leseprobe aus 46 Seiten

Details

Titel
Agiles Projektmanagement - Kanban und Scrum
Hochschule
Universität Duisburg-Essen
Note
1,0
Autor
Jahr
2011
Seiten
46
Katalognummer
V191527
ISBN (eBook)
9783656164340
ISBN (Buch)
9783656164470
Dateigröße
1069 KB
Sprache
Deutsch
Schlagworte
Kanban, Scrum, Agiles Projektmanagement, APM, PM;, Projektmanagement, Agil, Wirtschaftsinformatik, Softwareentwicklung, IT-Projekte, Projekte
Arbeit zitieren
Fahim Halamzie (Autor:in), 2011, Agiles Projektmanagement - Kanban und Scrum, München, GRIN Verlag, https://www.grin.com/document/191527

Kommentare

  • Gast am 25.11.2012

    Auf der Suche nach einer hilfreichen, praxisnahen Lektüre des modernen Projektmanagements stoßte ich auf dieses Werk.

    Insgesamt ist es sehr gelungen und überzeugt in vielerlei Hinsicht. Der Leser wird gut in die Materie eingeführt, bevor konkrete Handlungsempfehlungen aufgezeigt werden. Vor allem bleibt die Betrachtungsweise dabei stets differenziert und kritisch. Der Autor nutzt einen verständlichen und klaren Wortschatz.

    Insgesamt gebe ich eine klare Empfehlung sowohl für Studenten als auch für Berufstätige ab, die ihr Wissen im Bereich des Projektmanagements erweitern möchten oder auf der Suche nach modernen Initiativen in diesem Bereich sind.

Blick ins Buch
Titel: Agiles Projektmanagement - Kanban und 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