Lade Inhalt...

Agile Softwareentwicklung mit Scrum und Kanban

von Stephan Röß (Autor) Manuel Guttenberger (Autor)

Hausarbeit 2017 36 Seiten

BWL - Informationswissenschaften, Informationsmanagement

Leseprobe

Gliederung

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einführung
1.1 Motivation
1.2 Zielsetzung der Arbeit und Forschungsfragen

2 Theoretische Grundlagen
2.1 Begriffe
2.1.1 Agilität
2.1.2 Softwareentwicklung
2.1.3 Projektmanagement
2.2 Scrum
2.2.1 Prinzipien
2.2.2 Die Rollen
2.2.3 Meetings
2.2.4 Artefakte
2.2.5 Vorteile und Nachteile
2.3 Kanban
2.3.1 Prinzipien
2.3.2 Visualisierung die Arbeit
2.3.3 Limitierter Work in Progress
2.3.4 Messen und managen des Arbeitsflusses
2.3.5 Prozessregeln
2.3.6 Erkennen von Verbesserungsmöglichkeiten
2.3.7 Rollen
2.3.8 Vor- und Nachteile

3 Scrumban - Das Beste aus Scrum und Kanban
3.1 Gemeinsamkeiten der Methoden
3.2 Unterschiede der Methoden

4 Situationsstudie
4.1 Situationsstudie „kleines Team, parallele Projekte“
4.2 Situationsstudie „großes Team, internaltionale Projekte“

5 Analyse und Vergleich der agilen Methoden

6 Ergebnisse

7 Fazit uns Ausblick

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Agiles Manifest

Abbildung 2: Komplexität in Projekten

Abbildung 3: Der Scrum Prozess

Abbildung 4: Kanban Board

Abbildung 5: Limitierung des WiP

Abbildung 6: Messgrößen von Kanban

Abbildung 7: Benchmarking der Methoden

Abbildung 8: Kanban Board am Beispiel der Grasenhiller GmbH

Abbildung 9: Teammanagement mit Scrumban und Kanban-Board

Abbildung 10: Praktiken zur Koordination von Teams

Abbildung 11: Einsatzszenarien für Scrum, Kanban und Scrumban

Abbildung 12: Scrum und Kanban Bierdeckel

1 Einführung

Die digitale Transformation hält Einzug in alle Wirtschaftsbereiche und verändert die Wirtschaftsstrukturen und Wertschöpfungsketten nachhaltig. Nach Meinung vieler Experten sind Flexibilität, Diversität und Agilität die Schlüsselkompetenzen, um in diesem dynamischen Umfeld zu bestehen.[1] Zur Bewältigung der flexiblen und unspezifizierten Herausforderungen sind speziell in der Softwareentwicklung agile Methoden entstanden, die in anderen Wirtschaftsbereichen adaptiert werden können.[2]

1.1 Motivation

In der Softwareentwicklung haben sich die agilen Entwicklungsmethoden wie Scrum und Kanban fest etabiliert und sind aus dem beruflichen Alltag nicht mehr wegzudenken. Durch einen besser gelebten Einsatz der Methoden werden Teams fokussierter arbeiten, sich gegenseitig besser unterstützen und motivierter das Projekt umsetzten.[3]

1.2 Zielsetzung der Arbeit und Forschungsfragen

Ziel dieser Hausarrbeit ist es, Scrum und Kanban als agile Projektmanagement Frameworks für die Softwareentwicklung vorzustellen und die Möglichkeiten und Grenzen dieser Arbeitsweisen herauszuarbeiten. Dazu werden in den ersten Kapiteln die Methoden und Werte der Frameworks beschrieben und miteinander verglichen. In diesen Bereichen soll der spezifische Methodeneinsatz von Scrum und Kanban analysiert werden, um dessen Besonderheiten herauszuleiten.

Im Folgenden werden zwei fiktive Teamkonstellationen aus unterschiedlichen Wirtschaftsbereichen vorgestellt. Die beiden Situationen werden am beruflichen Umfeld der beiden Autoren angelehnt, wodurch sich eine Situation im national und eine weitere im internationalen Umfeld, mit unterschiedlichsten Größen und Aufgaben ergibt. Am Beispiel dieser differenzierten Beispiele lassen sich spezifische Vor- und Nachteile der Methoden ableiten. Der Abgleich zwischen Theorie und Praxiseinsatz ermöglicht es Optimierungspotenziale aufzudecken und diese in den Unternehemen einzuführen.[4]

2 Theoretische Grundlagen

In diesem Kapitel sollen zunächst grundlegende Begriffe und im Folgenden die beiden Methoden Scrum und Kanban vorgestellt werden.

2.1 Begriffe

2.1.1 Agilität

Der Begriff der Agilität geht auf Kanter und Peters zurück. Beide grenzen Agilität von der Starrheit bürokratischer Organisationen ab.[5] Gemäß Kanter ist es für erfolgreiche Unternehmen elementar, flexibel auf zukünftige und sich verändernde Anforderungen agieren zu können.[6] Hofert liefert eine ähnliche Definition und beschreibt mit Agilität die „Fähigkeit von Teams und Organisationen, in einem unsicheren, sich veränderndem und dynamischen Umfeld flexibel, anpassungsfähig und schnell zu agieren“.[7] Im Allgemeinen herrscht Konsens über die Definition des Begriffs der Agilität. Hofert lehnt sich an die Interpretation von Kanter an, erweitert diese jedoch um die Reaktionsgeschwindigkeit. Im Kontext der Softwareentwicklung und einem schnelllebigen Markt erscheint diese Fähigkeit als elementar, so dass für diese Arbeit der Begriff Agilität nach Hofert definiert werden soll.

Eng mit dem Begriff der Agilität in Verbindung gebracht werden die Eigenschaften adaptiv, iterativ und menschenorientiert.[8] Besonderer Bedeutung kommt hierbei der Fokussierung auf den Menschen und einem gemeinsamen Werteverständnis zu, welche Basis für alle Handlungen im Unternehmen darstellt.[9]

Im Kontext der Softwareentwicklung wird ein gemeinsames Werteverständnis durch das agile Manifest geschaffen. Im Kern legt das Manifest den Fokus auf Individuen und Interaktionen anstatt Prozessen und Werkzeugen. Einer funktionsfähigen Software wird einer höheren Bedeutung zugeordnet als einer umfassenden Dokumentation. Anstelle langwieriger Vertragsverhandlungen wird die Kooperation zwischen den Projektbeteiligten in den Vordergrund gestellt. Zudem soll von einem vordefinierten Plan abgewichen werden können, insofern sich die Anforderungen ändern.[10] Die Kernelemente des Agilen Manifests werden in Abbildung 1 visualisiert zusammengefasst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Agiles Manifest.
Quelle: Eigene Darstellung in Anlehnung an: Beck u.a., 2001, Manifest, S. 1.

Agile Vorgehensweisen werden im Rahmen dieser Arbeit im Kontext der Softwareentwicklung betrachtet. Dies wirft die Frage auf, wie Softwareentwicklung interpretiert werden kann.

2.1.2 Softwareentwicklung

Die Softwareentwicklung ist weit mehr als die ausschließliche Aufgabe der Programmierung von Software. Kollmeier beschreibt die Aufgaben in einem Spannungsbogen, welcher von der initialen Idee hin zur Konzeption, der Entwicklung sowie der Inbetriebnahme der Software reicht.[11]

Gemäß Summerville umfasst die Softwareentwicklung neben dem eigentlichen Quellcode die Dokumentation als auch entsprechende Konfigurationsdateien.[12]

Für die Softwareentwicklung gibt es unterschiedliche Vorgehensmodelle. Ein Vorgehensmodell legt fest, wie gleichartige Projekte ablaufen, benennt Projektbeteiligte sowie deren Aufgaben. Weiter stellt ein Vorgehensmodell Methoden zur Bewältigung der Aufgaben zur Verfügung.11

Beispiele für agile Vorgehensmodelle in der Softwareentwicklung sind neben Scrum und Kanban auch Extreme Programming (XP), Crystal, Adaptive Software Development und Rational Unified Process (RUP).[13]

Für die vorliegende Arbeit soll Softwareentwicklung nach Kollmeier definiert werden, da diese Definition den Fokus auf die gesamte Wertschöpfungskette legt, welche im Kontext von agilen Vorgehensweisen eine elementare Rolle spielt.[14]

Eng verwandt mit Vorgehensmodellen in der Softwareentwicklung ist das Projektmanagement. Dieses soll im folgenden Kapitel definiert werden.

2.1.3 Projektmanagement

Projektmanagement ist nach DIN 69901 als die Gesamtheit von Führungsaufgaben, -organisationen, -techniken und -mittel für die Abwicklung von Projekten definiert. In heutzutage vorherrschend sozio-technischen Systemen ist Projektmanagement eine der wichtigsten Funktionen um den wirtschaftlichen Erfolg eines Entwicklungsprojektes zu gewährleisten.[15]

Speziell die nötigen Techniken und Mittel für die Abwicklung von Projektaufgaben stehen in Interaktion mit agilen Projektmanagementmethoden, wie Scrum oder Kanban. In den vielseitigen Methoden des Projektmanagements wird ebenfalls immer das Ziel angestrebt die Projektoutputs wie beispielweise Funktionsmenge, Verfügbarkeit und Durchsatz, auch als Leistungsgrößen zu maximieren. Chaotische Projektsituationen müssen durch die richtige Priorisierung der Aufgaben vermieden werden.[16]

Stacey veröffentlichte 2002 hierzu eine Matrix, in der ersichtlich ist, welche Maßnahmen getroffen werden können, um chaotische Projektkonstellationen zu vermeiden. Anforderungen müssen aus dem unbekannten Zustand in verständliche Aufgaben übersetzt werden, indem Experten oder Stakeholder befragt werden. Bei dem Einsatz von Technologien ist darauf zu achten, dass diese bereits beherrscht oder kurzfristig entwickelt werden können.[17]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Komplexität in Projekten.
Quelle: Maximini, D., Scrum – Einführung in der Unternehmenspraxis, 2013, S. 17.

Scrum und Kanban können hier einen positiven Beitrag leisten, indem Technologieoptionen gegeneinander abgewägt werden und bei Anforderungen frühzeitige Zielkonflikte bereinigten werden. Hierdurch werden bessere Resultate erlangt. Softwareprojekte verbessern sich positiv auf einer der vier Stufen in Richtung einfaches Projekt. Eine bewältigbare Aufgabe entsteht, die zu einer besseren Produktivität führt.

Der Methodeneinsatz von Scrum und Kanban kann speziell in den Bereichen der komplizierten und komplexen Softwareentwicklung sinnvoll eingebunden werden.[18] Bei einfachen Projekten sollten hingegen Best Practice Lösungen zur Anwendung kommen, die ebenfalls aus vergangenen Scrum oder Kanban Projekten abgeleitet werden können. Der somit verbundene positive Beitrag zum Wissensmanagement, durch die Methoden, ist somit ebenfalls hervorgehoben.[19]

2.2 Scrum

Hirotaka Takeuchi veröffentlichte 1986 einen Artikel im Harvard Business Review mit dem Titel „The New New Product Development Game“, in diesen schnelle und innovative Entwicklungsprozesse dargestellt wurden.[20] Als einer der Schlüsselindikatoren wurden hier die Scrum-Teams das erste Mal wissenschaftlich erwähnt. In den darauffolgenden Jahren entwickelte sich der Scrum Prozess zu einem der meist gelebten agilen Projekt- und Softwareentwicklungsmethoden, die stark überlappende Entwicklungsphasen nutzen, Ansatz der klassischen sequenziellen Phasen. Transparenz, Überprüfbarkeit und Anpassung sind die Hauptaspekte, die im Scrum Prozess verfolgt werden.[21]

Das Scrum Framework definiert kleine Arbeitspakete, die in parallelen Entwicklungsphasen abgearbeitet werden, sodass kürzere Entwicklungszeiten realisiert werden können und ein höherer Fokus auf den Return on Investment gelegt werden kann. Der Scrum Prozess ist aus einem Minimalgerüst aus Rollen, Meetings und Artefakten bestehend, die in der folgenden Abbildung dargestellt werden.[22]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Der Scrum Prozess.
Quelle: Eigene Darstellung in Anlehnung an: Roock S., Scrum verstehen und erfolgreich einsetzten, 2016, S 18.

Am Anfang steht immer die Vision bzw. Mission, was für ein Produkt entwickelt oder im Änderungsmanagement angepasst werden soll. Aus der Vision werden konkrete Eigenschaften abgeleitet, die von dem Product Owner priorisiert werden und ein Sprit Backlog entsteht. Die Entwicklung erfolgt in festen und immer gleichen Interationen, die Sprints genannt werden. Die Sprints des Entwicklungsteams sind maximal 30 Tage lang und das Produkt Backlog wird hier umgesetzt. Der Scrum Master supportet das Entwicklungsteam, indem er u.a. eine störungsfreie Umgebung schafft. In den Daily Scrums die max. 15 Minuten dauern, wird nochmals eine Feinabstimmung für den Arbeitstag geschaffen. Zum Ende des Sprints liefert das Entwicklungsteam ein Produktinkrement ab, das auslieferbar sein sollte. Das Produktinkrement wird im Sprint Review präsentiert und schafft Transparenz über den Entwicklungsfortschritt. Danach wird die Sprint-Retrospektive durchgeführt, wobei neuen Aufgaben definiert werden und der Prozess kontinuierlich verbessert wird. Das Resultat des Meetings wird in dem nächsten Sprint umgesetzt.[23]

Im Gegensatz zu komplexen Entwicklungsmethoden kann der Scrum Prozess auf einem Bierdeckel dargestellt werden. Dieser als Beweis im Anhang abgebildet ist.

2.2.1 Prinzipien

Die Prinzipien von Scrum bilden einen wesentlichen Anteil an Verhaltungsregeln und Arbeitsweisen ab, die im Scrum Rahmenwerk kontinuierlich gelebt werden. Es ist wichtiger die Scrum Prinzipien umzusetzen, als eine stringente Verfolgung des Prozesses sicherzustellen. Sie bilden das agile Manifest ab und tragen am meisten dazu bei, Vorteile, wie höhere Qualität, schnellerer Time to Market und Effektivität umzusetzen.[24]

Die Prinzipien setzten sich aus sieben Grundeinstellungen zusammen, die im Folgenden kurz erläutert werden.

Das autonome und cross-funktionale Team muss interdisziplinär besetzt sein. Das Team darf wenige Verpflichtungen nach außen aufweisen und muss selbstgesteuert agieren können.[25]

Inspect und Adapt verinnerlicht das empirische Management. Ein kontinuierlicher Lessons Learned Prozess vermittelt hier, dass negative und positive Erfahrungen in der Zukunft verbessert oder identisch gelebt werden.

Timeboxing sind die fest definierten Zeiträume für die Sprints und Meetings. Sie werden verwendet um den Fokus auf die Arbeit zu konzentrieren. Das Timeboxing ist hilfreich um in der definierten Zeit auch schwierige Entscheidungen manchmal zu erzwingen und sich wieder auf die Arbeit konzentrieren zu können.

Der Return on Investment umschreibt, dass immer Arbeitspakte priorisiert werden, die diesen am meisten positiv beeinflussen. Nur so erzeugt das Entwicklungsteam den höchsten Wert mit der verfügbaren Kapazität.

Das Prinzip „Qualität einbauen“, beinhaltet die inkrementelle Entwicklung und legt somit eine kontinuierliche Überwachung der Qualität in der Softwareentwicklung dar. Scrum macht hierzu keine detaillierten Vorgaben. Die aufeinander aufbauende Qualitätsüberwachung muss an die Programmiersprache und an das Projekt angepasst werden.

Aus dem Lean Management kommt das Pull-Prinzip hinzu. Aufgaben müssen somit angenommen werden, wenn die Teammitglieder ihre definierten Aufgaben abgearbeitet haben und freie Kapazitäten aufweisen. Durch die hohe Varianz in der Softwareentwicklung entstehen somit ein kontinuierlicher Flow und eine homogene Auslastung des Teams.

Scrum kann missbilligt angerechnet werden, dass es chronisch unterspezifiziert ist und viele Details nicht geregelt sind. Dies ist jedoch als Stärke umzusetzen, da dem Entwicklungsteam viele Freiheiten ermöglicht werden und eine hohe Eigenverantwortung auch zu höherem Engagement führt.[26]

2.2.2 Die Rollen

Die wirtschaftliche Verantwortung unterliegt dem Product Owner. Er verfolgt das Ziel, das Produkt zu definieren und seinen Nutzen zu maximieren. Die Erstellung, Priorisierung und Erläuterung der Entwicklungsaufgaben zählen hierbei zu den Hauptaufgaben, des Product Owners. Nur er kann darüber urteilen, welche Eigenschaften am Ende eines Sprints wirklich fertiggestellt sind und welche ggf. eine Überarbeitung benötigen. So koordiniert er hauptsächlich das Zeit-, Kosten- und Qualitätsparadigma.[27]

Das Entwicklungsteam ist für die Ausarbeitung der Produkteigenschaften verantwortlich, die von dem Product Owner vorgegeben werden. Es besteht aus drei bis neun Mitgliedern. Wie in den Prinzipien beschrieben, ist je nach Projektaufgabe ein cross-funktionales Team zu definieren. Das ideale Team ist sowohl mit unterschiedlichen Spezialisten als auch Generalisten zu besetzen um alle anfallenden Aufgaben in der Softwareentwicklung zu meisten und ggf. in anderen Teambereich unterstützen zu können.

Der Scrum Master sorgt für eine erfolgreiche Anwendung von Scrum. Er gehört nicht selbst zum Entwicklungsteam, koordiniert jedoch die Meetings und behebt Störungen und Hindernisse im Projekt. Hierzu zählt die Optimierung der Kommunikation und Zusammenarbeit im Team und auch gegenüber den Stakeholdern. Er ist als Coach zu verstehen und muss das Projekt und Team je nach Anforderung situationsbedingt führen.[28]

2.2.3 Meetings

Wie im Scrum Prozess dargestellt ist, beginnt der Sprint mit der Sprint Planung und endet mit dem Sprint Review sowie der Sprint-Retrospektive. Im Sprint selbst ist nur der Daily Scrum als Meeting vorgesehen.

Die Sprint Planung orientiert sich an zwei grundlegenden Fragen. Was kann im kommenden Sprint inhaltlich entwickelt werden? Und wie wird die Arbeit im kommenden Sprint erledigt? Die erste Frage ist meist durch den vom Product Owner priorisierten Produkt Backlog schon beantwortet. Um eine Überbelastung im Entwicklerteam zu vermeiden, entscheidet jedoch das Team, wie viele Arbeitspakete in den Sprint gezogen werden. Hierzu wird meist das Planing Poker verwendet, um mit Spielkarten eine Aufwandsabschätzung für die Produkt Backlog Items abzugeben. Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen werden geklärt und der Sprint Backlog wird dadurch definiert.[29]

Der Daily Scrum findet täglich, meist zur identischen Zeit, am identischen Ort, statt. Das 15-minütige Meeting wird stehend abgehalten und durch den Scrum Master moderiert. Im Entwicklungsteam werden die Ergebnisse des Vortages diskutiert, die zu erreichen des Sprint Ziels notwendig waren und jeder erläutert, was er heute von seinen Aufgaben zu erledigen versucht. Weiterhin werden mögliche Hindernisse, die zum Erreichen des Sprint Ziels vorhanden sind, besprochen und hierzu Maßnahmen definiert.[30]

Am Ende des 1-4-wöchigen Sprint steht das Sprint Review. Das Entwicklerteam legt die Ergebnisse des Sprints dar und es wird überprüft welche Ziele aus dem Product Backlog erreicht wurden. Hieraus ergeben sich mögliche Anpassungen an den Produktfeatures.

Das Sprint Review dient zur Optimierung der Zusammenarbeit im Team und der Verbessrung des Entwicklungsprozesses. Neben den möglichen Optimierungen werden auch Best Practice Ansätze eruiert, die im kommenden Sprint gelebt werden können.[31]

2.2.4 Artefakte

Der Scrum Prozess beinhaltet die drei Artefakte; Product Backlog, Sprint Backlog und Product Increment.

Das Product Backlog ist das zentrale Artefakt und beinhaltet eine strukturierte Auflistung der Anforderungen an das Produkt. Die Priorisierung und Anpassung erfolgt durch den Product Owner. Für die Auslegung der Abarbeitungsreihenfolge sind die Interaktionen der einzelnen Aufgaben zu bestimmen. Meist werden User Stories verwendet um die Formulierung der Produkteigenschaften anwenderorientiert auszulegen und die Priorisierung zu definieren.[32]

Aus dem Product Backlog werden die Arbeitsaufgaben ausgewählt, die im nächsten Sprint erledigt werden können und in den Sprint Backlog übertragen. Eine kontinuierliche Aktualisierung erfolgt im Sprint selbst und Anpassungen werden im Daily Scrum ausgelegt.

Das Product Increment selbst ist die Summe aller nutzbaren Inkremente, die in das Produkt implementiert werden können. In jedem Sprint wird somit das Produkt optimiert und der Wert kontinuierlich erhöht.[33]

2.2.5 Vorteile und Nachteile

Der stark verbreitete Einsatz von Scrum deutet bereits darauf hin, dass die Methode funktioniert und viele Absichten zur Zufriedenheit der Stakeholder erfüllt werden können.

Zu den Vorteilen von Scrum, ist die Schaffung einer Transparenz für alle Beteiligten zu zählen, sodass unkalkulierte Aufwände zum Ende des Projektes vermieden werden können. Scrum fördert den Teamgedanken, die Eigenverantwortung und Eigeninitiative im Team. Dies wiederum führt zu einer Entlastung des Projektmanagements und der Projektleitung da kleinere Hindernisse von dem Team selbst beseitigt werden. Durch die Retrospektiven hält ein kontinuierlicher Verbesserungsprozess Einzug. Dabei können ebenfalls Best Practice Ansätze in Lessons Learned Datenbanken geteilt werden. Durch die Implementierung der Scrum Prinzipien kann weiterhin ein Kulturwandel im Unternehmen entstehen. Abschließend ist zu den Vorteilen noch die gute Skalierbarkeit auf große Projekte zu nennen, auf diese im Situationsbeispiel noch tiefer eingegangen wird.[34]

Neben den Vorteilen sind jedoch auch Nachteile der Methode zu erwähnen. Unter anderem kann sich die stringente Struktur des Ablaufs der Meetings im Verlauf der Zeit als Nachteil herausstellen. Ein hoher Zeitbedarf für die regelmäßigen Meetings entsteht. Die Sprint Abstände sind fix definiert, sodass Änderungen von Anforderungen nur von Sprint zu Sprint diskutiert werden können. Hierzu ist eventuell ein ausgeweitetes Daily Scrum Meeting zu empfehlen um den bis zu zweimonatigen Verzug nicht zu erlangen. Da zu Projektstart kaum spezifizierte Aussagen zum Aufwand möglich sind, ist die zeitliche Planbarkeit der Projekte schwer. Die Arbeit während der Sprintphasen ist nicht strukturiert und gegen Ende des Sprints ist die Belastung für die Entwicklerteams sehr hoch, da versucht wird, alle liegengebliebenen Themen termingerecht abzuschließen. Der Support innerhalb des Teams kann hierdurch sehr leiden.

2.3 Kanban

Die Ursprünge von Kanban liegen bei Toyota und der Fertigung für die Automobilindustrie. Es wurde erkannt, dass 94 % der Unternehmensleistung vom System und sechs Prozent der Leistung vom Mitarbeiter abhängen. Das Toyota Prodution System (TPS) ist ein Bespiel für die ständige Verbesserung des Systems – Kaizen. Die Geisteshaltung Kaizen beschreibt die „Veränderung zum Besseren“. Es soll nur erledigt werden, was gebraucht wird und das in der Menge und zu dem Zeitpunkt, zu dem es gebraucht wird. Aufgaben, welche keinen Wert liefern und zu hohe Variabilität im Produktionsprozess aufweisen, werden als Verschwendung angesehen und sind zu vermeiden.[35]

Kernelement des TPS ist die kanban. Ein kanban ist sinngemäß eine „Signalkarte“. "kan" steht im japanischen für "Signal" und "ban" für Karte. Mittels dieser Signalkarten wird die Zeit- und Aufgabenplanung in der Just-in-Time Produktion vorgenommen und nachgelagerten Produktionsstufen visualisiert, dass eine Aufgabe fertiggestellt wurde. Während in der Automobilproduktion Prozesse größtenteils einheitlich ablaufen und standardisiert werden können, ist in der Softwareentwicklung Kreativität und Problemlösung gefordert, so dass die Prinzipien von Kanban nicht eins zu eins in die Softwareentwicklung übertragen werden können. Kanban in der IT vereint deshalb unterschiedliche Denkansätze zu einem adaptiven System, in welchem Prozesse sukzessive optimiert werden.[36]

Entwickler von Kanban für die Softwareentwicklung ist Anderson.[37] Anderson beschreibt das System mit: “Kanban is giving people permission to think for themselves. It is giving people permission to be different: different from the team across the floor, on the next floor, in the next building, and at a neighboring firm. It is giving people permission to deviate from the textbook.“ [38]

Kanban ist damit eine adaptive Methode, welche an die Anforderungen unterschiedlicher Teams und Prozesse angepasst werden kann. Zu den Zielen von Kanban in der Softwareentwicklung gehört insbesondere die schnelle und regelmäßige Auslieferung von qualitativ hochwertiger Software.[39]

Um die Durchlaufzeit von Aufgaben entlang der Wertschöpfungskette zu minimieren und die Qualität zu erhöhen, bedarf es verschiedener Prinzipien und Kernpraktiken. Diese sollen in den nachfolgenden Kapiteln beschrieben werden.

2.3.1 Prinzipien

Im Allgemeinen macht Kanban wenige Vorschriften, wie etwas gemacht werden soll, sondern fokussiert sich darauf, dass etwas gemacht werden soll. Grundprinzip von Kanban ist es, mit dem zu starten, was bereits vorhanden ist. Dieser Zustand soll durch inkrementelle, evolutionäre Veränderungen verbessert werden.[40]

Für das Funktionieren des adaptiven Kanban Systems sind gemäß Anderson die Visualisierung der Arbeit, der Limitierung des Work in Progress (WiP), das Messen und Managen des Flows, explizite Prozessregeln und das Erkennen von Verbesserungsmöglichkeiten elementar.39 Diese Kernpraktiken werden in den folgenden Kapiteln näher ausgeführt.

2.3.2 Visualisierung die Arbeit

Kanban hilft, die Abläufe der Wissensarbeit entlang der Wertschöpfungskette zu visualisieren und dadurch Probleme, welche den Arbeitsfluss behindern, sichtbar zu machen. Die Visualisierung der Arbeit erfolgt mittels eines Kanban Boards. Abbildung 4 zeigt ein exemplarisches Kanban Board mit Prozessschritten wie beispielsweise Entwicklung und Auslieferung. Die einzelnen Prozessschritte sollen hierbei den tatsächlich in der Praxis gelebten entsprechen. Aufgaben fließen auf dem Kanban Board entlang der Wertschöpfungskette. Grundsätzlich kann Kanban so weit skaliert werden, dass die Gesamte Wertschöpfungskette eines Unternehmens abgebildet wird.[41]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Kanban Board. Quelle: Eigene Abbildung nach: Epping, 2011, S. 3.

Die Organisation erfolgt nach dem Pull Prinzip. Fertiggestellte Aufgaben der vorherigen Arbeitsschritte werden von Personen geholt, sobald entsprechende Kapazitäten dafür zur Verfügung stehen. Um Engpässe zu erkennen und zukünftig vermeiden zu können, werden die parallel auszuführenden Aufgaben innerhalb eines Prozessschrittes limitiert.[42]

[...]


[1] Vgl. Finckler, D., Transformationale Führung Wegweiser für nachhaltig, 2016, S. 46 – 48.

[2] Vgl. Reddy, A., The Scrumban [R]Evolution, 2016, S. 1 – 9.

[3] Vgl. Reddy, A., The Scrumban [R]Evolution, 2016, S. 5 – 9.

[4] Vgl. Bea, F., Strategisches Management, 2015, S. 134 – 137.

[5] Vgl. Hofert, S., 2016, Agil, S. 6.

[6] Vgl. Kanter, R, 1984, Agil, S. 41.

[7] Hofert, S., 2016, Agil, S. 5.

[8] Vgl. Abrahamsson, P. u. a., Agil, 2008, S. 95.

[9] Vgl. Schein, E., 2010, Unternehmenskultur, S. 23 f.

[10] Vgl. Beck, K. u.a., 2001, Manifest, S. 1.

[11] Vgl. Brandt-Pook, H., Softwareentwicklung, 2016, S. 2 f.

[12] Vgl. Summerville, I., Softwareentwicklung, 2012, S. 31.

[13] Vgl. Summerville, I., Softwareentwicklung, 2012, S. 89.

[14] Vgl. Leopold, K., 2013, Kanban, S. 26 f.

[15] Vgl. Litke, H., Projektmanagement, 2007, S. 20.

[16] Vgl. Burghardt, M., Einführung in Projektmanagement, 2007, S. 23 – 26.

[17] Vgl. Maximini, D., Scrum – Einführung in der Unternehmenspraxis, 2013, S. 17 - 19.

[18] Vgl. Maximini, D., Scrum – Einführung in der Unternehmenspraxis, 2013, S. 17 - 19.

[19] Vgl. Laudon, K., Wirtschaftsinformatik, 2010, S. 393 - 397.

[20] Vgl. Roock, S., Scrum, 2016, S. 1.

[21] Vgl. Roock, S., Scrum, 2016, S. 17 - 18.

[22] Vgl. Roock, S., Scrum, 2016, S. 18.

[23] Vgl. McKenna, D., The Art of Scrum, 2016, S. 27 - 34.

[24] Vgl. Roock, S., Scrum, 2016, S. 7.

[25] Vgl. Roock, S., Scrum, 2016, S. 27 - 28.

[26] Vgl. Roock, S., Scrum, 2016, S. 27 - 32.

[27] Vgl. Maximini, D., Scrum – Einführung in der Unternehmenspraxis, 2016, S. 157.

[28] Vgl. Maximini, D., Scrum – Einführung in der Unternehmenspraxis, 2016, S. 157 - 172.

[29] Vgl. Roock, S., Scrum, 2016, S. 22 - 23.

[30] Vgl. Roock, S., Scrum, 2016, S. 23.

[31] Vgl. Roock, S., Scrum, 2016, S. 24.

[32] Vgl. McKenna, D., The Art of Scrum, 2016, S. 63 - 88.

[33] Vgl. Roock, S., Scrum, 2016, S. 26.

[34] Vgl. Roock, S., Scrum, 2016, S. 2 - 160.

[35] Vgl. Leopold, K., Kaizen, 2013, S. 11 f.

[36] Vgl. Leopold, K., Kaizen, 2013, S. 12.

[37] Vgl. Epping, T., Kanban, 2011, S. 10 f.

[38] Anderson, D., Kanban, 2010, S. 17.

[39] Vgl. Anderson, D., Kanban, 2010, S. 14 f.

[40] Vgl. Leopold, K., Kanban, 2013, S. 15.

[41] Vgl. Leopold, K., Kanban, 2013, S. 26 f.

[42] Vgl. Epping, T., Kanban, 2011, S. 54f.

Details

Seiten
36
Jahr
2017
ISBN (eBook)
9783668807839
ISBN (Buch)
9783668807846
Sprache
Deutsch
Katalognummer
v442556
Institution / Hochschule
FOM Essen, Hochschule für Oekonomie & Management gemeinnützige GmbH, Hochschulleitung Essen früher Fachhochschule
Note
1,0
Schlagworte
agile softwareentwicklung scrum kanban

Autoren

Teilen

Zurück

Titel: Agile Softwareentwicklung mit Scrum und Kanban