SEMINARARBEIT. Kanban in der Softwareentwicklung. im Studiengang Informationsmanagement und Computersicherheit Lehrveranstaltung Projektmanagement 1

Transkript

1 SEMINARARBEIT im Studiengang Informationsmanagement und Computersicherheit Lehrveranstaltung Projektmanagement 1 Kanban in der Softwareentwicklung Ausgeführt von: Hermann Wagner, BSc ( ) Jovica Zuljic-Suljuzovic, BSc ( ) Lukas Schweitzer, BSc ( ) Begutachter: Dipl.-Ing. Mag. Dr. Michael Tesar Wien,

2 Inhaltsverzeichnis 1 Wurzeln und Geschichte Ursprung Übernahme in die IT Kanban als Vorgehensmodell Die 7 Werte der schlanken Softwareentwicklung Eliminate Waste Amplify Learning Decide as Late as Possible Deliver as Fast as Possible Empower the Team Build Integrity in See the Whole Charakteristische Elemente Regeln Kaizen Tracking Priorisierung Anwendungsbereiche Vergleich mit anderen Vorgehensmodellen Kanban vs. Wasserfallmodell Kanban vs. Scrum Kanban in Aktion Techniken Das Kanban Board Erstellung Arbeiten Beispiele Kanban Tools Zusammenfassung Literaturverzeichnis

3 Abbildungsverzeichnis...24 Tabellenverzeichnis...24 Aufteilung der Inhalte Kapitel 1 Wurzeln und Geschichte Jovica Zuljic-Suljuzovic Kapitel 2 Kanban als Vorgehensmodell Jovica Zuljic-Suljuzovic Kapitel 2.1 Die 7 Werte der schlanken Softwareentwicklung Lukas Schweitzer Kapitel 2.2 Charakteristische Elemente Jovica Zuljic-Suljuzovic Kapitel 2.3 Anwendungsbereiche Lukas Schweitzer Kapitel 2.4 Vergleich mit anderen Vorgehensmodellen Lukas Schweitzer Kapitel 3 Kanban in Aktion Hermann Wagner Kapitel 4 Zusammenfassung Hermann Wagner 3

4 1 Wurzeln und Geschichte 1.1 Ursprung Das Wort Kanban stammt aus dem Japanischen und setzt sich aus den beiden Wörtern kan (Signal) und ban (Karte) zusammen. Kanban bedeutet also übersetzt Signalkarte. Im Verlauf dieser Arbeit wird noch genauer erklärt werden, was es mit den Signalkarten auf sich hat. Mitte des 20. Jahrhunderts entwickelte der Japaner Taiichi Ohno eine neue Produktionsmethode beim Automobilhersteller Toyota. Ziel der neuen Methode war es, den Anteil an Ballast in der Produktion zu minimieren. Ganz besonders wurde darauf geachtet, dass man keinen unnötigen Materialvorrat lagert. Stattdessen kamen Signalkarten ins Spiel welche den Materialbedarf erst dann anzeigten, wenn Material tatsächlich benötigt wurde. So stellte man sicher, dass sich niemals zu viel Ware in den Lagern befand. Durch diese und weitere Techniken entwickelte sich das sogenannte Toyota Production System. Aus der Verallgemeinerung dessen, ging in den 1980er Jahren die schlanke Produktion (Lean Manufacturing) hervor, die sich nicht nur in der Automobilindustrie sondern auch mittlerweile in anderen produzierenden Unternehmen etabliert hat [1, p. 34]. 1.2 Übernahme in die IT Die Ideen der schlanken Produktion wurden dann Anfang des 21. Jahrhunderts von Mary und Tom Poppendieck sowie David J. Anderson auf den Bereich der Softwareentwicklung übertragen [1, p. 34]. Allerdings wurde es erst 2004 das erste Mal auch tatsächlich angewendet. Dragos Dumitriu setzte dieses Verfahren als erstes für Microsoft ein. Seit damals findet dieses Modell immer mehr Verbreitung in der Softwareentwicklung. Es dauerte weitere drei Jahre, bis David J. Anderson dieses Modell auch öffentlich vorstellte. Seit dem Zeitpunkt gilt er als Vater von Kanban in der Softwareentwicklung [1, pp ]. Den Erfolg des ersten Einsatzes von Kanban, beschreibt Anderson in seinem Buch Kanban: Successful Evolutionary Change for Your Technology Business (2010) anhand eines Microsoft Teams welches für etwa 80 Anwendungen zuständig war. Vor dem Einsatz von Kanban betrug die Durchlaufzeit für Fehlerbehebungen und Erweiterungen zwischen 125 und 155 Tage. Dadurch hatte das Team den Ruf der schlechtesten Kundenbetreuung. Nachdem Kanban eingeführt wurde, sank die Durchlaufzeit um fast 90% auf nur mehr 14 Tage und die Fälligkeitstermine konnten zu 98% eingehalten werden. Dies brachte dem Team die Auszeichnung Engineering Excellence Award ein. Das Vorgehensmodell des Teams wurde durch Kanban nicht wesentlich geändert, jedoch trug ein Faktor wesentlich zum Erfolg bei. Dieser Faktor war die Limitierung der Erweiterungen und Fehlerbehebungen die das Team zur selben Zeit (Work in progress) betreuen musste. 4

5 2 Kanban als Vorgehensmodell Wie schon im vorherigen Abschnitt angedeutet ist Kanban also ein noch sehr junges Vorgehensmodell der schlanken Softwareentwicklung (Lean Software Development). Kanban als Vorgehensmodell ist ein System mit dem gestiegene Erwartungen von Kunden in Bezug auf Produktionsgeschwindigkeit und Lieferbereitschaft erfüllt werden können. Es bietet ein hohes Anpassungspotenzial, da die Informationen immer aktuell sind und somit an Bedarfssituationen von Verbraucher, Produzent und Lieferant angepasst werden kann. Durch diese Tatsache haben Unternehmen die Möglichkeit, komplexe Produktionsprozesse in selbstständige Regelkreise umzuwandeln, was zu einer Reduktion des Steuerungsaufwandes führt [2]. Da diese Erklärung etwas kompliziert scheint, wird nun im Detail auf die Charakteristika und Regeln von Kanban eingegangen. 2.1 Die 7 Werte der schlanken Softwareentwicklung Der Begriff Lean Software Development (dt. schlanke Softwareentwicklung) stammt von Mary und Tom Poppendieck. Sie beschreiben in ihrem Buch, das denselben Titel trägt, folgende 7 Werte auf denen die schlanke Softwareentwicklung beruht: Eliminate Waste Ist ein zentraler Wert in der schlanken Softwareentwicklung. Er betrachtet alles, das keinen Mehrwert für das Produkt liefert als Müll, den es zu vermeiden gilt. Er nimmt eine ähnlich wichtige Stellung ein, wie in der agilen Softwareentwicklung der Wert Respond to Change. [1, p. 40] Es gibt sieben Formen für Ballast: [1, p. 48] Partially Done Work Teilweise erledigte Arbeit hat oft die Tendenz obsolet zu werden. Zusätzlich weiß man nicht sicher ob dieser unerledigte Teil der Software auch wirklich funktioniert. Extra Processes Zuviel Bürokratie gilt es zu vermeiden. Es verlangsamt die Arbeit und erhöht nicht den Mehrwert des Produkts für den Kunden. Extra Features Jegliche zusätzlich eingebaute, nicht erforderte Funktionalität macht den Code unnötig komplex und erhöht so die Chance auf Fehler. Task Switching Personen sollen nur einem Projekt zugewiesen werden. Denn beim Wechseln zwischen verschiedenen Projekten geht viel Zeit für die Umstellung verloren. 5

6 Waiting Verzögerungen sollten vermieden werden, da dadurch auch die Reaktionszeit gegenüber neuen Kundenwünschen länger dauert. In diese Kategorie fallen auch Puffer in der Wertschöpfungskette. Trotzdem werden oft Puffer eingesetzt, da ein gleichmäßiger Arbeitsfortschritt wichtiger ist als die Beseitigung dieses Ballasts. [1, p. 50] Motion Das Teilen von Artefakten respektive Gegenständen mit mehreren Projekten ist auch eine Verschwendung. Defects Fehler beziehungsweise Defekte sollten so schnell wie möglich behoben werden. Um das zu gewährleisten ist es notwendig, ständig sofort zu testen, oft zu integrieren und so schnell wie möglich zur Produktion freigeben Amplify Learning Bedeutet, dass den, in einem Projekt beteiligten, Personen ein kontinuierliches Lernen ermöglicht wird. Darunter versteht man einerseits das Lernen aus Fehlern, aber auch das Erlernen von neuen Fachgebieten. Drei Faktoren begünstigen diesen Wert: Fehler sind als unvermeidbarer Bestandteil akzeptiert, sollen aber reduziert werden, Zeit zum Lernen ist vorhanden und es gibt eine Atmosphäre, die das Lernen ermöglicht. [1, p. 42] Decide as Late as Possible Entscheidungen werden so spät wie möglich getroffen um zu vermeiden dass diese auf Basis von zu wenigen Informationen entschieden werden. Vor allem in der Softwareentwicklung können sich Faktoren schnell ändern. Trifft man eine Entscheidung zu früh, kann es passieren, dass sie dann aufgrund der geänderten Faktoren doch falsch ist. [1, p. 43] Deliver as Fast as Possible Schnelle Entwicklung hat viele Vorteile. Denn desto schneller das Endprodukt fertig ist, desto früher erhält man Feedback und kann das in der nächsten Iteration einfließen lassen. Desto kürzer die Iterationen, desto mehr kann gelernt werden. Zusätzlich verringert die geringe Durchlaufzeit den Anteil an paralleler Arbeit. [1, p. 44] 6

7 2.1.5 Empower the Team Ein Softwareentwicklungsprojekt kann in seiner Gesamtheit nicht von nur einer Person gesteuert werden. Verbesserung funktioniert am besten, wenn sich alle daran beteiligen. Zusätzlich steigert das Involvieren der Mitarbeiter deren Motivation. Vor allem Entwickler oder andere Mitarbeiter, können bei Detail-Entscheidungen in ihrem Metier sehr hilfreich mit ihrem Spezialwissen sein. Auch beinhaltet dieser Wert eine gewisse Risikominimierung, da das Projekt nicht von einer Person komplett abhängt. Würde nur eine Person das ganze Projekt steuern und diese unvorhergesehen ausfallen, würde das ganze Projekt auf der Kippe stehen. [1, p. 45] Build Integrity in Die Anwendung funktioniert genau den Vorstellungen des Kunden entsprechend. Dies ist aber auch eine Gratwanderung zwischen einer funktionierenden und faszinierenden Anwendung. Obwohl prinzipiell Ballast (siehe 2.1.1) vermieden werden muss, kann es durchaus sein, einen solchen in Kauf zu nehmen um die Akzeptanz der Anwendung beim Kunden zu erhöhen. [1, p. 46] See the Whole Software ist heutzutage sehr komplex. Deshalb kommt es auch auf ein gutes Zusammenspiel der einzelnen Teile an. Aus diesem Grund darf das Gesamtbild der Anwendung nicht verloren gehen. Bei einer Anwendung kann es deshalb durchaus Sinn machen auf einzelne Bestandteile zu verzichten, wenn dafür die Abstimmung der Teile zueinander besser funktioniert. [1, p. 47] 2.2 Charakteristische Elemente Folgende vier Punkte charakterisieren Kanban: Arbeit wird genommen, nicht gegeben (Pull) Mengen werden limitiert (Limitierte Mengen) Informationen werden veröffentlicht (Transparente Information) Arbeitsabläufe werden kontinuierlich verbessert (Kontinuierliche Verbesserung) Pull: Das Element pull besagt, dass Arbeitspakete nicht von einer Phase in die andere geschoben werden sondern dass sie von der darauffolgenden Phase erst dann genommen werden, wenn diese auch bereit dazu ist. Damit wird vermieden, dass Teams überlastet werden da sie nicht mit mehreren Arbeiten gleichzeitig beschäftigt sind. 7

8 Limitierte Mengen: Dieses Element sorgt dafür dass der Work in progress gesenkt wird indem die Anzahl der Aufgaben die sich gleichzeitig in der Wertschöpfungskette befinden dürfen, limitiert wird. Darüber hinaus vermeidet die Limitierung eine Überlastung der Personen und unterstützt gleichzeitig die durchschnittliche Fertigstellungsgeschwindigkeit (Average Completion Rate). Somit ergibt sich automatisch eine geringere Durchlaufzeit von Aufgaben. Und genau hier liegt der Fokus von Kanban [1, p. 57]. Transparente Information: Transparenz ist notwendig damit Aufgaben selbstorganisiert und eigenverantwortlich bearbeitet werden können. Sehr wichtig ist, dass diese Transparenz konsequent für alle Aufgaben herrscht und dass alle Personen von dieser Transparenz profitieren. Die wichtigsten transparenten Informationen sind: Phasen der Wertschöpfungskette Aufgaben die sich in den Phasen der Wertschöpfungskette befinden Personen die die Aufgaben erledigen Limitierung der Anzahl der Aufgaben für jede Phase Projektkennzahlen die den Projektfortschritt illustrieren Kontinuierliche Verbesserung: Dieses Element ist grundlegend für das Kanban Modell. Dieses strebt nämlich nach kontinuierlicher Verbesserung. Die Verbesserungen bestehen aus Anpassungen an projektindividuelle Rahmenbedingungen die sich in einem Softwareentwicklungsprojekt laufend ergeben können. Weiters finden Verbesserungen unter Anteilnahme aller Personen im Team statt mit dem Ziel neue Werte, Elemente oder Techniken einzuführen, alte zu verbessern und nicht mehr gebrauchte aufzugeben. Durch das Element der kontinuierlichen Verbesserung wird Kanban zu einem empirischen Modell, das konsequent aus seiner Vergangenheit lernt [1, p. 63]. Verbesserungen laufen immer in fünf Schritten ab: Größte Schwachstelle identifizieren Maßnahmen beschließen um die Leistung der Schwachstelle zu maximieren Maßnahmen aus dem vorherigen Schritt mit höchster Priorität ausführen Prüfen ob die Schwachstelle immer noch die größte ist, wenn ja, Schritt 2 und 3 nochmal ausführen Nicht ausruhen, mit Schritt 1 fortfahren Regeln Es gibt natürlich auch einige Regeln beziehungsweise Prinzipien die man befolgen sollte, wenn man erfolgreich das Vorgehensmodell Kanban anwenden möchte. Die fünf Regeln werden nun kurz erörtert (Quelle: [2]). 8

9 Visualisierung: Der Arbeitsprozess wird auf einem Kanban Board visualisiert. Die verschiedenen Phasen (Stationen) werden als Spalten dargestellt. Sämtliche Aufgaben welche erledigt gehören, werden auf Karteikarten geschrieben und wandern im Laufe des Prozesses auf dem Board von links nach rechts. Begrenzung der Tickets: Jede Phase muss die Anzahl der zu gleichzeitig bearbeitenden Aufgaben streng limitieren. Auch wenn es mehr Aufgaben zum Bearbeiten geben würde, darf dieses Limit nicht überschritten werden. Dadurch wird das Element Pull realisiert bei dem sich Phasen die Aufgaben von der davor gehenden Phase selber abholen sobald Kapazität frei wird anstatt sie von ihr zu bekommen. Messung und Optimierung: Durch die Messung von Größen wie der Länge von Warteschlangen, der Zykluszeit oder des Durchsatzes kann ermittelt werden, wie gut der Arbeitsprozess organisiert ist. Dies erlaubt es den Prozess laufend weiter zu verbessern. Messung und Optimierung findet während des ganzen Prozesses statt. Explizite Regelungen: Alle Regeln müssen explizit sein. Das heißt, alle Beteiligten wissen zu jedem Zeitpunkt unter welchen Annahmen und Gesetzmäßigkeiten gearbeitet wird. Dazu gehört zum Beispiel die Definition fertig, Regeln wie die nächste Aufgabe gewählt werden soll und auch die Bedeutung der einzelnen Spalten. Verwenden von Modellen: Damit der Prozess vereinfacht werden kann und verständlicher wird, werden Modelle verwendet. Diese können zum Beispiel auf den Modellen der Engpasstheorie, dem systematischen Denken oder dem Modell von Wert, Fluss und Verschwendung basieren. Diese Modelle sollen dabei helfen, Methoden zu finden um den Prozessablauf zu verbessern Kaizen Das Wort Kaizen stammt aus dem Japanischen und setzt sich aus den Worten kai (Wandel) und zen (zum Besseren) zusammen. Am besten lässt sich das Wort folgendermaßen zusammenfassen: Es ist eine Arbeitsphilosophie, deren Motor das Streben nach ständiger Verbesserung ist. Im ökonomischen Bereich wird das Wort oft als Synonym für den Kontinuierlichen Verbesserungsprozess (KVP) verwendet. Kaizen basiert auf der Annahme, dass nicht sprunghafte Innovation, sondern schrittweise erfolgende Verbesserung eines Produkts zu wirtschaftlichem Erfolg führt. Es kommt zu einer Abkehr von der reinen Ergebnisorientierung hin zur Prozessorientierung. Durch Kaizen wird eine höhere Identifikation der Mitarbeiter mit dem Unternehmen erreicht. (Quelle: [2]) Detailreichere Erklärungen lassen sich unter [3] oder zum Beispiel unter [4] finden. 9

10 2.2.3 Tracking Um empirische Daten für die kontinuierliche Verbesserung zu sammeln, werden bei Kanban verschiedene Maße aufgezeichnet. Die üblichsten Arten des Tracking stellen folgende dar: Cumulative Flow Diagram (CFD): Dieses Diagramm stellt eine Zusammenfassung der Abbildungen auf dem Kanban Board dar. Es zeig an, wie lange es dauert Arbeiten fertigzustellen und wie viele Arbeiten insgesamt fertiggestellt wurden. Dieses Diagramm eignet sich hervorragend dazu mögliche Bottlenecks zu finden. Bottlenecks sind Phasen im Kanban System an denen sich viele Arbeiten stauen. Sie entstehen wenn die Bearbeitungszeiten der verschiedenen Arbeiten zwischen den Phasen zu stark voneinander differieren [2]. Work in Progress: Die Anzahl der aktuell im System befindlichen Arbeiten wird gemessen und in einem Diagramm festgehalten. Daran lässt sich ablesen, wie effektiv das System arbeitet. Weiters kann man mithilfe dieses Diagramms Probleme im System feststellen. Dies wird dadurch ersichtlich, dass die Anzahl der Arbeiten im System steigt. Dies könnte zum Beispiel auf eine blockierte Arbeit hindeuten [2]. Durchsatz: Dieses Diagramm ist ein sehr einfaches und zeigt lediglich an, wie viele Arbeiten pro Woche erledigt werden. Fehlerquote: Die Messung der Fehlerquoten ist in Kanban Systemen unabdingbar. Da dieses Modell auf kurze Durchlaufzeiten abzielt und diese nur durch eine hohe Qualität erreicht werden kann, sollte man die Qualität der Arbeit laufend durch die Fehlerquotenmessung überprüfen Priorisierung Beim Entscheiden, welche Aufgabe wann in das Kanban System gegeben wird, muss man Prioritäten setzen. Durch die Limitierung des Work in progress ist es natürlich nicht möglich, sämtliche Aufgaben in die erste Phase des Kanban Systems einzugeben. Eine der Möglichkeiten, auch diejenige die am häufigsten genutzt wird, um zu priorisieren ist das Schema der Verzögerungskosten. Dieses ist unter dem Namen Cost of Delay besser bekannt. Die Idee dahinter ist, dass nicht nur das Entwickeln neuer Features Ressourcen kostet, sondern auch das Nichtentwickeln jener zu Ressourcenkosten führen kann. Streng genommen wären das keine Kosten im herkömmlichen Sinne, vielmehr sind das dann Verzichtskosten, also zum Beispiel Geld welches man verdient hätte, wäre das Feature entwickelt worden. 10

11 2.3 Anwendungsbereiche Prinzipiell kann Kanban nicht auf bestimmte Branchen reduziert werden. Wichtig für den Einsatz sind nur die Gestaltung der Prozesse und die Beschaffenheit der Materialien. [5] So wird es unter anderem bei industriellen Fertigungen (Massen- bzw. Serienfertigung) oft eingesetzt, wenn eine möglichst gleichmäßige Produktion vorliegt. Zusätzlich darf der Produktionsprozess nicht sehr störanfällig sein, bzw. auch nicht zu hohen Abrufschwankungen ausgesetzt sein. Denn dann würde das Kanban-System nicht funktionieren. [5] [6, p. 380] Auch bei Logistikprozessen findet Kanban Verwendung. [7] Ein weiteres Beispiel außerhalb der IT-Welt ist das Unternehmen McDonalds. Dieses setzt Kanban ein, um eine bedarfsgerechte Produktion bei kurzen Wartezeiten in den Filialen zu gewährleisten. [5] In der IT-Welt selbst wird es auch in sehr vielen Bereichen eingesetzt: Um einem bestehendem, schon agil tätigen, Team noch bessere respektive kürzere Durchlaufzeiten zu verschaffen, wird manchmal Kanban eingeführt. Bei Unternehmen, die vom Wasserfallmodell auf ein agiles Modell umsteigen wollen. Hierbei eignet sich Kanban deshalb sehr gut, da es dem Wasserfallmodell in den einzelnen Schritten ähnlich ist. Außerdem ist es einfacher umzusetzen, als ein anderes agiles Vorgehen, wie zum Beispiel Scrum. [8] Bei Projekte, bei denen umfangreiches Spezialwissen erforderlich ist, eignet sich Kanban auch sehr gut. Da bei anderen Methoden (zum Beispiel Scrum) die Teams zum Großteil aus Generalisten bestehen, während es bei Kanban unerheblich ist ob Spezialisten oder Generalisten beteiligt sind. [1, p. 45], [1, p. 75] Bei der Wartung von Software kommt es nur noch bei Bedarf zur Weiterentwicklung. Hierbei sind andere agilen Methoden, die feste Iterationen verwenden ungeeignet, da es nicht wirklich möglich ist, einen beständigen Fluss an Tasks zu kreiren. [9], [8] Bei zu komplexen Projekten eignet sich Kanban hingegen nicht so gut, denn desto komplexer das Projekt ist, desto mehr verhelfen feste Spielregeln, wie bei Scrum, zu einem geordneten Projekt- bzw. Prozessablauf. [9] 2.4 Vergleich mit anderen Vorgehensmodellen Kanban vs. Wasserfallmodell Der größte Unterschied zwischen den beiden Modellen ist, dass Kanban ein iteratives und das Wasserfallmodell ein lineares Vorgehensmodell ist. Trotzdem ist Kanban dem Wasserfallmodell vom Aufbau her sehr ähnlich. Beide schließen sich auch nicht gegenseitig aus. Kanban kann auch in Wasserfall-Projekten eingesetzt 11

12 werden, um das Projekt schneller beziehungsweise flexibler zu gestalten. Es kann aber auch langfristig das Wasserfall-Modell ersetzen. [8] Aber im Gegensatz zum Wasserfallmodell zielt Kanban darauf ab die batch size möglichst gering zu halten, während beim Wasserfallmodell das Produkt parallel durch die Phasen der Produktion läuft. [10] Kanban vs. Scrum Kanban und Scrum haben einige Ähnlichkeiten. Beide orientieren sich an den Lean- Prinzipien, aber auch an der agilen Entwicklung. [9] Kanban kann vor allem für kleinere Projekte viel bewirken. Auch bei Wartungsprojekten ist Kanban besser geeignet als Scrum, da die Geschwindigkeit keine Rolle spielt und Scrum zu überdimensioniert dafür ist. Für Projekte höher Komplexität eignet sich hingegen Scrum besser als Kanban. [9] Im Folgenden werden die Ähnlichkeiten und Unterschiede der beiden Modelle näher erläutert. Ähnlichkeiten Beide sind dem Lean aber auch dem agilen Development zuzuordnen Benutzung eines Pull-Systems Setzen auf Transparenz Fokussieren sich darauf, häufig und früh releasbare Software zu liefern selbst-organisierende Teams der Release-Plan wird immer wieder, basierend auf den empirischen Daten, optimiert. [11], [8] 12

13 Tabelle 1 listet relevante Unterschiede zwischen Scrum und Kanban auf. Aus der Tabelle ist sehr gut ersichtlich, dass Kanban weniger vorschreibt, und in manchen Belangen flexibler ist, als Scrum. [11] Unterschiede Kanban Scrum Priorisierung Priorisierung ist optional. Alle Einträge im Backlog müssen priorisiert werden. Board Das Kanban-board ist persistent. Das Scrum-board wird nach jedem Sprint zurückgesetzt. Rollen Gibt überhaupt keine Rollen vor. Schreibt drei Rollen vor (PO, SM, Team) Anforderungen Neue Anforderungen können, wenn Kapazität verfügbar ist, jederzeit hinzugefügt werden. In einer laufenden Iteration können keine neuen Anforderungen hinzugefügt werden. Planungs- und Prozessverbesserungen Benutzt Lead time als Maßstab für Planung und Prozessverbesserungen. Scrum benutzt hingegen Geschwindigkeit (Velocity) dafür. Timeboxes Iterationen sind optional. Es können auch Unterschiede zwischen der Planung, dem Bei Scrum sind Iterationen in Zeitboxen vorgeschrieben. Release und der Prozessverbesserung existieren. Zusätzlich kann es auch eventbasiert sein, anstatt in Zeitboxen stattzufinden. Tabelle 1 Kanban vs Scrum 13

14 3 Kanban in Aktion 3.1 Techniken Auf der nachfolgenden Abbildung sind links die sieben Werte der schlanken Softwareentwicklung zu sehen, in der Mitte dann die vier charakteristischen Elemente von Kanban und ganz rechts neun individuelle Techniken für Kanban, die abhängig vom Projekt eingesetzt werden können oder auch nicht. Abbildung 1: Lean Development Werte, Kanban-Elemente & -Techniken (Quelle: [1, p. 87]) Daraus geht wiederum eindeutig hervor, dass Kanban ein Vorgehensmodell der schlanken Softwareentwicklung ist, da zwischen den Werten, Elementen und Techniken folgender Zusammenhang besteht: Werte werden durch verschiedene Elemente umgesetzt, während Elemente wiederum durch Techniken realisiert werden. Ein Beispiel aus der Abbildung oberhalb: Der Wert Amplify Learning aus dem Lean Development wird in Kanban unter anderem durch das Element Transparente Information abgedeckt, das zum Beispiel technisch durch ein Kanban-Board oder auch Daily Standups realisiert sein kann. Das Vorgehensmodell ist eine Zusammenstellung von Elementen und zeigt sich durch eine Menge von unterschiedlichen Techniken, wobei nicht immer alle Techniken angewandt werden müssen. 14

15 Sowohl die Werte des Lean Development als auch die vier grundlegenden Kanban-Elemente wurden in dieser Arbeit bereits erklärt. Nachfolgend werden nun auch die verschiedenen Kanban-Techniken kurz erklärt. Näher eingegangen wird nur auf das Kanban-Board, da diese Technik zum einen essentiell bei Kanban ist und Kanban auch meist mit der Visualisierung auf dem Board (fälschlicherweise) gleichgesetzt wird. Kanban-Technik Beschreibung Verwendet für User Stories Planungspoker Code Reviews Continous Integration sicherung Testautomatisierung Formulierung der Anforderungen aus Sicht des Kunden. Die Story beschreibt dabei eine Funktionalität, die Wert für den Benutzer oder Käufer des Systems hat. Die Story selbst zerfällt dann für die Entwickler in eine oder mehrere Anforderungen. Typische Formulierung: Als {Rolle} möchte ich {werttragender Wunsch}, weil {Begründung des Wertes}. Aufwandsschätzung und Diskussion der User Stories durch das ganze Team. Mögliches Vorgehen: (1) Jeder Entwickler bekommt ein Kartendeck mit möglichen Werten für den Aufwand (2) Der Product Owner liest die User Story vor und beantwortet alle möglichen Fragen die das Entwicklerteam hat (3) Jeder Entwickler wählt einen Wert aus dem Kartendeck. Die Karten werden gleichzeitig aufgedeckt. (4) Unterscheiden sich die Schätzungen signifikant, so erklären die Ausreißer ihre Beweggründe und die Gruppe diskutiert kurz darüber (5) Danach wird nochmal (jeder für sich) geschätzt und anschließend verglichen (6) Der Vorgang wiederholt sich bis sich die Schätzwerte aneinander angenähert haben Diskussion und Informationsaustausch bezüglich der Umsetzungen der Anforderungen. Themen: Alles was für die Entwicklung von Bedeutung ist (nicht nur Code) Teilnehmer: Entwickler Ergebnisse: Technische Änderungen für die ein Refactoring (Code-Restrukturierung ohne Änderung des Verhaltens der Anwendung) notwendig ist. Daraus müssen dann wieder User Stories (vom Team) geschrieben werden, die dem Kunden zur Priorisierung vorgelegt wird. Entwickler integrieren ihre Änderungen kontinuierlich (mindestens 1x/Tag). Jede Integration wird durch einen automatischen SW-Build inkl. Test verifiziert um Fehler so schnell wie möglich zu erkennen. Dies führt zu einer erheblichen Reduktion von Integrationsproblemen und zu einer schnellen Auslieferung der Features an den Kunden. Dienen zur Entscheidung darüber, wann die Qualitätssicherung von Anforderungen abschlossen ist und die Anforderung dem Kunden zur Verfügung gestellt werden kann. Der Kunde trifft die Entscheidung ob er die Kriterien selbst formuliert (als Teil der User Story), die Kriterien nur kontrolliert (Abnahmetests) oder gar nichts dergleichen tut. Letzteres birgt natürlich das Risiko, dass bei einer falsch verstandenen Anforderung, dieser Mangel erst sehr spät entdeckt werden kann. Ermöglicht eine hochfrequente Verifikation und Validierung von Anwendungen und unterstützt dadurch die Entwicklung in keinen Arbeitsschritten. Weiters wird dadurch sichergestellt, dass die Entwicklung der aktuellen Anforderungen keine ungewollten Requirements Engineering Entwicklung Abnahmekriterien Qualitäts- 15

16 Kanban-Board Stand-Ups Retrospektiven Nebenwirkung auf andere bereits umgesetzte Anforderungen hat (Regressionstests). Visualisierung aller Phasen der Wertschöpfungskette der Limitierungen pro Phase (WIP) der Anforderung Charakterisiert die Kanban-Elemente Pull, Limitierte Mengen und Transparente Informationen gleichzeitig. Auf das Kanban-Board wird weiter unten noch genauer eingegangen. Kurzes Meeting aller Teammitglieder zur rollenübergreifenden und inhaltlichen Abstimmung des Teams. Eigenschaften eines Stand-Ups: Wird im Stehen durchgeführt um die Konzentration zu erhöhen Dient nicht zur Berichterstattung Täglich am gleichen Ort zur gleichen Zeit Maximal 15 Minuten Länge ( Timebox) Beiträge sind für die Mehrheit relevant Beiträge jedes Teammitglieds liefern Antworten auf die folgenden 3 Fragen: (1) Was habe ich seit dem letzten Meeting getan? (2) Was werde ich bis zum nächsten Meeting tun? (3) Welche Hindernisse treten gibt es bei meiner aktuellen Arbeit? Kann Auslöser für neue Anforderungen sein Beschreiben ein Treffen aller Personen eines Teams um Ballast in der Wertschöpfungskette zu identifizieren. Auch der Auftraggeber kann beteiligt werden. Die Retrospektiven werden regelmäßig (jede Woche, Monat, SW-Ablieferung) durchgeführt und haben je nach Häufigkeitsintervall eine Dauer von x Stunden. Für ausgewählte Themen werden Maßnahmen getroffen. Alle Phasen, alle Rollen Tabelle 2: Zusammenfassung der verschiedenen Kanban-Techniken (Quelle: [1, p. 85ff] 3.2 Das Kanban Board Das sogenannte Kanban Board dient der Visualisierung des Entwicklungsvorgangs, also der Wertschöpfungskette. Das Board ist die zentrale Technik von Kanban und sieht von Projekt zu Projekt verschieden aus, da es sich zum einen von den individuellen Bedürfnissen des Projekts abhängt und zum anderen sich ständig weiterentwickelt Erstellung (1) Als erstes wird die Kanban-Tafel benötigt. Das kann zum Beispiel eine Whiteboard, Magnettafel oder Pinnwand sein. Diese Tafel wird so aufgehängt, dass sie möglichst gut zugänglich oder eventuell sogar von jedem Teammitglied einsehbar ist. (2) Anschließend wird die Tafel unterteilt in die Phasen der jeweiligen Wertschöpfungskette bzw. des Entwicklungsvorgangs. Ein mögliches Beispiel wäre z.b. die Unterteilung in die Phasen Backlog Neue Kundenanforderungen, die noch nicht bearbeitet wurden Analyse Anforderung befindet sich in Analyse. 16

17 Spezifikation Anforderung wird spezifiziert. Umsetzung Anforderung wird umgesetzt. Testen Anforderung wird getestet. Integration & Ablieferung Anforderung wird integriert und abgeliefert. Archiv Anforderung wurde erfolgreich abgeliefert. (3) Nachdem die Phasen definiert wurden, muss nun das Kanban-Element Limitierte Mengen in Form von WIP-Limits angewendet werden. Das heißt, für jede Phase wird eine Obergrenze an möglichen Elementen definiert werden, die sich gleichzeigt in dieser Phase befinden dürfen. Die Limits können auch über mehrere Phasen hinweg definiert werden. Eine Limit-Überschreitung ist prinzipiell nicht erlaubt. (4) Die Anforderungen müssen nun die definierten Phasen, also die Wertschätzungskette durchlaufen, beginnend bei der Phase Backlog. Dazu werden aber erst einmal Repräsentanten für die Anforderungen benötigt. Diese Repräsentanten sind in Form einer Signalkarte (Ticket) realisiert. Auf der Signalkarte können nun verschiedene Informationen vermerkt sein. Hier ein paar Beispiele: Eindeutige ID Anwendungen, auf die sich die Anforderung bezieht Kurzbeschreibung Priorität Geschätzter Aufwand Erstellungsdatum Fertigstellungsdatum Aktueller Bearbeiter Vorangegangene Bearbeiter Für die Bearbeiter kann zum Beispiel ein Avatar, in Form eines Stickers, eingesetzt werden. Je nach Art des Tickets können verschiedene Farben verwendet werden (zb. Anforderung blau, Bug rot, interner Punkt gelb) (5) Tafel in den aktuellen Ist-Zustand versetzen. Dazu werden für jede aktuelle Aufgabe eine Signalkarte (mit allen Attributen) erstellt und auf die entsprechende Phase am Board geheftet/geklebt/gepinnt Arbeiten Zum Arbeiten mit dem Board sind folgende Regeln zu beachten: Pull-Prinzip: die Tickets werden nicht in die nächste Phase verschoben, sondern der Bearbeiter der nächsten Phase holt sich das Ticket ab Ist das Ticket also in der aktuellen Phase abgeschlossen, so wird es entsprechend markiert (zb. grüner Sticker) 17

18 Ist eine weitere Bearbeitung einer Anforderung aus irgendwelchen Gründen nicht möglich, so kann es als on-hold markiert werden oder in eine on-hold Sektion verschoben werden bis eine Weiterbearbeitung wieder möglich ist. Die Archiv-Phase dient als Motivator um zu zeigen wie viele Tickets schon erfolgreich umgesetzt wurden Beispiele Es folgen nun zwei Beispiele für physische Kanban-Tafeln: Abbildung 2: Beispiel Kanban-Board 1 (Quelle: help.targetprocess.com) Abbildung 3: Beispiel Kanban-Board 2 (Quelle: galleryhip.com) 18

19 3.2.4 Kanban Tools Bis jetzt stand der Fokus auf der Erstellung eines physischen Kanban-Boards. Dieses Kapitel widmet sich den elektronischen Kanban Tools. Elektronische Tools haben mitunter folgende Vorteile: Bessere Unterstützung bei geografisch verteilter Entwicklung An verschiedenen Orten verfügbar (bei Meetings, in der U-Bahn, Zuhause) Einheitliches Aussehen der Board-Elemente bzw. verwenden von vorhandenen Vorlagen möglich Verschiedene graphische Darstellungsmöglichkeiten Automatische Analysen und Auswertungen sind möglich Leider bringen elektronische Tools nicht nur Vorteile mit sich, sondern haben auch folgende Nachteile: Änderungen an den aktuell vereinbarten Phasen und Abläufen sind eventuell schwieriger durchzuführen. Am physischen Board nimmt man im Gegensatz dazu einfach eine Nadel und ein Kärtchen und positioniert es anders. Es ist noch ein Programm mehr, das der Entwickler ständig offen hat. Das physische Board hängt einfach an der Wand und ist für jedes Teammitglied jederzeit ersichtlich. Daily-Standups sind bei vielen Personen bzw. großen Kanban-Boards nicht so einfach möglich. Abhilfe können große TV-Bildschirme bzw. Beamer bringen. Auf Grund dieser Nachteile empfehlen viele Kanban-Experten (z.b. Marcus Hammarberg und Joakim Sundèn in [12, p. 316]), dass Kanban-fremde Teams besser mit einem physischen Board starten sollten bevor sie zu einem elektronischen wechseln. Beginnt man gleich mit einem elektronischen Tool, so ist es sehr wahrscheinlich, dass am Tool selbst wenig konfiguriert und verändert wird und das Tool bestimmt wie das Team arbeitet. Damit dies nicht der Fall ist, sollte zuerst jedes Teammitglied die Prinzipien und die Vorgehensweise von Kanban verstanden haben, damit dann mit dem Tool auch entsprechend umgegangen werden kann und es auf die eigenen Bedürfnisse angepasst wird. Eine weitere gute Möglichkeit ist die Verwendung eines physischen als auch eines elektronischen Tools. Dies ist zum Beispiel sinnvoll, wenn das Team geografisch verteilt arbeitet. Jeder Standort mit mehreren involvierten Personen hat bei diesem Ansatz ein physisches Board und arbeitet mit diesem. Wenn sich Änderungen ergeben, so werden diese auch ins elektronische Tool eingetragen, damit auch die Teammitglieder an anderen Standorten die Änderungen mitbekommen und in ihr Board übernehmen können. Natürlich generiert diese Vorgehensweise einen gewissen Verwaltungs-Overhead. Jedoch ist dieser (wenn das Board einmal erstellt wurde) überraschend gering und kann gegebenenfalls auch gleich beim Daily-Standup erfolgen. 19

20 Manche Teams kommen auch auf die Idee sich den Verwaltungsaufwand zu sparen, indem sie eine Kamera auf das Board ausrichten und einen Online Live-Stream einrichten. So hat jedes Teammitglied, egal an welchem Ort, immer einen Blick auf das Board. Diese Vorgehensweise kann dann sinnvoll sein, wenn es zum Beispiel einen Hauptstandort gibt und vereinzelt Teammitglieder an anderen Standorten tätig sind. Obwohl Kanban in der Softwareentwicklung noch nicht sehr lange etabliert ist gibt es inzwischen eine Vielzahl an Tools. Nachfolgend werden ein paar Beispiele gegeben: Leankit ( Abbildung 4: Leankit Beispiel (Quelle: AgileZen ( Abbildung 5: AgileZen Beispiel (Quelle: 20

21 Trello ( Abbildung 6: Trello Beispiel (Quelle: Kanbanize ( Abbildung 7: Kanbanize Beispiel (Quelle: 21

22 4 Zusammenfassung "People ask me: What is the difference between lean and kanban? Answer: lean is a destination; kanban is means to get there." David J. Anderson Bei Kanban geht es um die evolutionäre, inkrementelle Veränderung (evolutionäres Change Management). Das bedeutet, dass durch die Einführung von Kanban nicht alle bisherigen Prozesse, Vorgehensweisen und Rollen verworfen werden. Ganz im Gegenteil: Team, Projekt, Organisation, Rollen, Verantwortlichkeiten usw. bleibt alles beim Alten. Die einzige Vereinbarung ist, dass man permanent kleine Verbesserungen an der bestehenden Arbeitsweise vornimmt. Um diese ständigen Verbesserungen durchführen zu können halten sich Kanban-Teams an folgende Grundprinzipien: Visualisierung Sichtbar machen der laufenden Arbeiten Limitierung Laufende Arbeiten werden durch WIP-Limits begrenzt Arbeitsflusses steuern und Messung durchführen Explizite Prozessregeln aufstellen Kontinuierliche Verbesserung mittels bewährter Modelle Um diese Grundprinzipien oder auch Regeln umzusetzen wurden in dieser Seminararbeit 9 Kanban-Techniken beschrieben, wobei das wichtigste und bekannteste das Kanban-Board ist. Es genügt jedoch nicht in einem Team einfach ein Kanban-Board zu erstellen und zu hoffen, dass es dadurch automatisch zu Veränderung bzw. Verbesserung kommt. Das Team muss den Kanban-Gedanken verstehen und sich mehrere der Kanban-Techniken zu Nutze machen um sich kontinuierlich verbessern zu können. Wurde Kanban erst einmal erfolgreich ins Team integriert und schon viele Verbesserungen und Optimierungen gefunden und durchgeführt, gilt dennoch folgende Grundgedanke: Es gibt kein Team, das perfekt arbeitet, daher bleibt immer Platz für Verbesserung. 22

23 5 Literaturverzeichnis [1] T. Epping, Informatik im Fokus - Kanban für die Softwareentwicklung, Berlin: Springer- Verlag, 2011, pp [2] Unbekannt, Kanban, InterFace AG, [Online]. Available: [Zugriff am ]. [3] Unbekannt, Kaizen, business-wissen.de, [Online]. Available: [Zugriff am ]. [4] S. Stephenson, What is Kaizen?, graphicproducts.com, [Online]. Available: [Zugriff am ]. [5] H. Wildemann, Produktionssteuerung mit KANBAN, [Online]. Available: [Zugriff am ]. [6] K.-W. Hansmann, Industrielles Management, Oldenbourg: Oldenbourg Wissenschaftsverlag, [7] P. Loos, Kanban - Enzyklopädie der Wirtschaftsinformatik, [Online]. Available: enzyklopaedie/lexikon/informationssysteme/sektorspezifische- Anwendungssysteme/Produktionsplanungs--und-- steuerungssystem/fertigungssteuerung/kanban. [Zugriff am ]. [8] S. Roock, Kanban in der Softwareentwicklung, [Online]. Available: [Zugriff am ]. [9] J. P. Berchez und U. Kapp, Kriterien für eine Entscheidung für Scrum oder Kanban, [Online]. Available: Entscheidung-fuer-Scrum-oder-Kanban html?artikelseite=2. [Zugriff am ]. [10] M. Cottmeyer, What is Kanban : Is Kanban just Waterfall with small batches?, [Online]. Available: [Zugriff am ]. [11] H. Kniberg und M. Skarin, Kanban und Scrum, [Online]. Available: 23

24 [Zugriff am ]. [12] M. Hammarberg und J. Sundén, Kanban in Action, Shelter Island, NY: Manning Publications Co, Abbildungsverzeichnis Abbildung 1: Lean Development Werte, Kanban-Elemente & -Techniken (Quelle: [1, p. 87])...14 Abbildung 2: Beispiel Kanban-Board 1 (Quelle: help.targetprocess.com)...18 Abbildung 3: Beispiel Kanban-Board 2 (Quelle: galleryhip.com)...18 Abbildung 4: Leankit Beispiel (Quelle: Abbildung 5: AgileZen Beispiel (Quelle: Abbildung 6: Trello Beispiel (Quelle: Abbildung 7: Kanbanize Beispiel (Quelle: Tabellenverzeichnis Tabelle 1 Kanban vs Scrum...13 Tabelle 2: Zusammenfassung der verschiedenen Kanban-Techniken (Quelle: [1, p. 85ff]