Kanban im Universitätspraktikum Ein Erfahrungsbericht Jan Nonnen, Paul Imhoff und Daniel Speicher, Universität Bonn {nonnen, imhoffj, dsp}@cs.uni-bonn.de Zusammenfassung 1. Visualize Workflow Visualisiere den Fluss der Arbeit Agile Softwareentwicklung praxisnah und erlebbar 2. Limit Work-in-Progress zu lehren ist eine Herausforderung, die einen deut- Begrenze die Menge angefangener Arbeit lichen Einsatz von Zeit und Personal erfordert. Wir 3. Measure and Manage Flow hatten die Möglichkeit, viele gute Erfahrungen in un- Miss und steure den Fluss serer Lehre sammeln zu können. Allerdings hatten wir immer noch einige Schwierigkeiten den Studenten be- 4. Make Process Policies Explicit stimmte Probleme während der Entwicklung bewusst Mache die Regeln für den Prozess explizit und sichtbar zu machen. In dieser Arbeit berichten 5. Use Models to Recognize Improvement wir von unseren Erfahrung mit der Anwendung des Opportunities - Verwende Modelle um Kanban-Entwicklungsprozesses in einem agilen Block- Verbesserungsmöglichkeiten zu identifizieren praktikum an der Universität Bonn. Tatsächlich hat Tabelle 1: Die fünf Kanban-Kerneigenschaften nach dieser einige dieser Schwierigkeiten deutlicher sicht- Anderson (Anderson, 2010, S. 15). bar machen können. Basierend auf unseren Erfolgen, bewältigten Herausforderungen und neu beobachte- ten Schwierigkeiten geben wir abschließend Empfeh- lung eingesetzt haben. Wir berichten von unseren lungen für andere Lehrende. Erfahrungen, positiv und negativ, und präsentieren anderen Lehrenden Empfehlungen aufgrund dieser Einleitung Erfahrungen für ihre Anwendung von Kanban. Agile Softwareentwicklung ist in den letzten Jahren - Wir haben unseren Bericht wie folgt strukturiert: Zu- mehr noch in der Wirtschaft als in der Lehre - beliebt erst geben wir eine allgemeine Einführung in Kanban geworden und hat eine große Verbreitung erfahren und berichten über den Praktikumsaufbau und die His- (Lindvall u. a., 2004). Dem muss auch die universi- torie unserer Praktika. Danach beschreiben wir, wie täre Softwaretechnik-Lehre Rechnung tragen und sei wir unseren Prozess mit Hilfe von Kanban angepasst es nur durch die Befähigung zur kritischen Reflexion. haben. Anschließend berichten wir, was wir während Hier stellt sich aber eine besondere Herausforderung: des Praktikums geändert haben und am Ende ziehen Agilität möchte der oft erfahrenen Wirklichkeit Rech- wir ein Fazit und präsentieren unsere Empfehlungen nung tragen, dass sich Softwareentwicklung nur ein- für Lehrende. geschränkt planen lässt. Diese Erfahrung und wie sie sich durch agile Vorgehensweisen meistern lässt, ist auf theoretischem Weg kaum vermitteln. Daher haben Kanban einige Universitäten spätestens seit 2003 begonnen, Kanban ist ein agiler Software-Entwicklungsprozess, Praktika zu agiler Softwareentwicklung in ihre Lehr- dessen Ursprünge im Toyota Production System liegen. pläne aufzunehmen (Mügge u. a., 2004; Melnik u. Entwickelt wurde das Toyota Production System von Maurer, 2004). In unseren eigenen Praktika haben Taiichi Ōno, der es auch in seinem 1988 auf Englisch wir dabei stets als unerlässlich angesehen, ”weiche” erschienen Buch beschrieb (Ōno, 1988). Das japani- Faktoren mit einzubeziehen. So unterstützen wir die sche Original war bereits 10 Jahre zuvor erschienen. Teambildung durch regelmäßige Reflexion und aus- ”kan” bedeutet wörtlich aus dem Japanischen über- drückliche Retrospektiven, um die Studierenden in setzt ”visuell”, und ”ban” Karte. Toyota nutzte Kanban, die Lage zu versetzen, Kommunikation, Kollaboration um die Lagerbestände zu reduzieren und einen gleich- und den Prozess als Ganzes zu verbessern. mäßigen Fluss (Flow) in der Automobilfertigung zu Ein aktueller Trend der letzten Jahre in der agilen realisieren. David Anderson hat diesen Prozess auf Softwareentwicklung ist Kanban (Anderson, 2010). In Softwareentwicklung übertragen (Anderson, 2010) diesem Beitrag erläutern wir, wie wir Kanban in einem und durch fünf Kerneigenschaften charakterisiert (sie- universitären Praktikum zur agilen Softwareentwick- he Tabelle 1). A. Spillner, H. Lichter (Hrsg.): SEUH 13 91 Für Kanban ist die sichtbare Tafel oder ein White- Kanban basiert auf dem so genannten Pull-Prinzip, board mit einer Übersicht über den Entwicklungszu- d.h. dass die Entwickler ein Ticket selbstständig in stand ein zentrales und wohl auch das offensichtlichs- eine Spalte ziehen, solange die Arbeitslimits in der te Instrument. entsprechenden Phase noch nicht erreicht sind. Sie Zur Illustration gehen wir schon hier kurz unser übernehmen damit die Verantwortung für den der eigenes Kanban Board ein: Bereits in der agilen Ent- Spalte entsprechenden Schritt in Bezug auf das ”gezo- wicklung und in unseren vorherigen Praktika war und gene” Ticket. Des Weiteren werden häufig die einzel- ist es üblich, die sogenannten User Stories auf einem nen Phasen in zwei Spalten unterteilt, um zu visuali- Board zu visualisieren. Dieses Board hatte Spalten sieren was ”In Arbeit” ist und welche Tickets ”Fertig” für die Entwicklungsschritte wie z.B. ”Analyse” oder sind. Dies erlaubt es in den nachfolgenden Phasen zu ”Done”. In Kanban wird diese Praxis weiter verwendet sehen, welche Tickets als nächstes gezogen werden und angereichert durch die in den fünf Kerneigen- dürfen. schaften genannten Imperative. In Abbildung 1 sieht Durch die explizite Visualisierung des Ist-Zustandes man ein Bild von einer Kanban Tafel aus dem hier ist es möglich, den Gesamtprozess zu messen und zu vorgestellten Praktikum. Diese Visualisierung wurde analysieren, wie schnell die einzelnen Tickets durch mit Stickern, Whiteboard-Stiften und Klebeband reali- den Prozess wandern (4. Kerneigenschaft). Ebenso siert. Die Verwendung dieser Materialien erlaubte uns, werden Probleme in der Entwicklung sichtbar, wenn flexibel das Board an das Entwicklerteam und andere man z.B. feststellt, dass die Limits in einer Phase häu- Einflüsse anzupassen, und so die Entwicklungsschritte fig erreicht werden oder die Entwickler in einer Phase für das Team zu individualisieren. Diese Flexibilität ist regelmäßig auf Arbeit warten müssen. wichtig, da Kanban auf die Bedürfnisse zugeschnitten Diese Informationen können mit genutzt werden, werden sollte und sich diese änderen können. Es sollte um den Prozess kontinuierlich und gemeinsam zu daher auch mit dem Team diskutiert werden, was die verbessern (5. Kerneigenschaft). Hier werden häufig Phasen (bisher Entwicklungsschritte) sind, durch die auch mathematische Modelle auf Basis der ”Theory die Tickets (bisher User Stories) bis zur Fertigstellung of Constraints” (Goldratt u. a., 1984) angewandt um wandern. Engpässe (Bottlenecks) in dem Prozess frühzeitig zu erkennen. Diese Modelle geben auch die Möglichkeit, objektiv über den Prozess zu diskutieren. Neben den Limits kann es noch andere Regeln geben die die Bear- beitung von einem Ticket verhindern oder priorisieren (z.B. bestimmte Kartenfarben signalisieren Dringlich- keit). Damit solche Konventionen nicht zu Fehlern durch Vergessen führen, ist es nützlich, alle Konventionen, die sich im Lauf der Entwicklung ergeben, explizit aufzuschreiben und allen Entwicklern bewusst zu ma- chen (3. Kerneigenschaft). Dieses kann zum Beispiel durch ein Poster mit den Konventionen neben dem Whiteboard geschehen. Dieses fördert analog zu der Abbildung 1: Im Praktikum verwendetes Kanban- Verbesserung des Flusses die gemeinsame Diskussion Board. Das weiter unten referenzierte Video bietet und Verbesserung der Konventionen und Regeln. zusätzlich eine dynamische Perspektive auf das Board. Im Folgenden verwenden wir allgemeine Kanban- Aufbau des Praktikums Konventionen und orientieren uns an Kanban-Boards Das dieser Arbeit zugrundeliegende Praktikum fand welche wir selber eingesetzt und entwickelt haben für vier Wochen als Vollzeit-Blockpraktikum im Sep- (siehe Abbildung 2). tember 2011 während der Vorlesungspause zwischen Die Stories oder Tickets laufen in der Regel von Sommer- und Winteresemester statt. Blockpraktika links nach rechts auf dem Kanban Board und durch- dieser Art finden jährlich im Rahmen des Internatio- laufen dabei die Entwicklungsphasen bis sie fertig nal Program of Excellence in Computer Science (IPEC) (”done”) sind. Nachdem durch die 2. Kerneigenschaft am Bonn-Aachen International Center for Informati- die Tickets, die in Arbeit sind, begrenzt werden soll- on Technology (B-IT) statt, und bieten den Studenten ten, werden je Spalte Begrenzungen definiert und auf die Möglichkeit Erfahrungen als Softwareentwickler dem Board notiert. Dies bedeutet, dass sobald das Li- in einem realen Kontext zu sammeln. Seit 2001 wer- mit in einer Phase erreicht ist, nicht neue Tickets in den in den Praktika agile Softwareprozesse gelehrt, diese gezogen werden dürfen sondern die Ressourcen angewandt und in Hinblick auf die Lehre angepasst genutzt werden müssen um die in Arbeit stehenden (Mügge u. a., 2004). In der Vergangenheit haben bis Tickets fertig zu stellen. zu 16 Studenten in einem Team gearbeitet, welches 92 A. Spillner, H. Lichter (Hrsg.): SEUH 13 dazu von bis zu drei Lehrkräften die ganze Zeit betreut technischen Fragen des Teams und hat Wissen in den wird. einzusetzenden Technologien und Projekten. Dem Praktikum unmittelbar vorgelagert ist ein klei- ner Workshop von bis zu drei Tagen. Für diesen vertie- Anwendung von Kanban fen sich die Studenten in die einzelne Technologien, Das Thema des Praktikums in 2011 war die Entwick- die im Praktikum genutzt werden, und arbeiten diese lung von Analysen für Designprobleme von Java Quell- in Form von Seminarvorträgen und Ausarbeitungen code für die Android Plattform. Insgesamt nahmen auf. Neben den Vorträgen wird dieser Workshop vor zehn Studenten an dem Praktikum tatsächlich teil, allem zur Teambildung genutzt. Im Normalfall ha- nachdem ursprünglich 16 Plätze vergeben waren. Als ben die teilnehmenden Studenten vorher noch nicht Basis gab es schon ein selbstentwickeltes Framework zusammengearbeitet. Daher sind teambildende Maß- mit dem statische Codeanalysen für Java geschrie- nahmen in der Regel fest in dem Workshop eingeplant. ben werden konnten. Dieses musste im Rahmen des Dieser Workshop hat sich im Laufe der Jahre als nütz- Praktikums erweitert werden. Ebenso mussten die lich erwiesen, um im Praktikum direkt gemeinsam Studenten erfassen, was hinsichtlich vor allem Per- und produktiv als Team arbeiten zu können. formanz und Speicherbedarf problematischer Code Der Fokus des Blockpraktikums ist es, einen Einblick auf der Android Plattform ist. Dafür wurden im Laufe in die reale Softwareentwicklung zu geben. Dazu ist des Praktikums z.B. die Entwickler-Richtlinien von das Praktikum als Vollzeit-Präsenzpraktikum ausge- Google2 zu Rate gezogen. legt, d.h. dass das Team für vier Wochen mit je acht Zur Vorbereitung und Anwendung von Kanban als Stunden pro Arbeitstag zusammen arbeitet. Dies hat Entwicklungsprozess wurden die früheren Arbeits- für die Studenten den Vorteil, das neben dem norma- schritte in früheren Praktika analysiert und die Erfah- len Arbeitstag keine Überstunden oder Heimarbeiten rungen festgehalten. Zu den Bestandteilen früherer anfallen. Als eine wichtige Arbeitstechnik hat sich in Praktika, die wir für erhaltenswert befunden haben diesen Praktika das Pair-Programming aus dem ”eXtre- gehören (wie bereits beschrieben) das Pair Program- me Programming” (Beck u. Andres, 2004) etabliert. ming, die Rollenverteilung unter den Mitarbeitern, Pair-Programming bedeutet, dass immer zwei Studen- sowie (wie weiter unten beschrieben) die Differenzie- ten ein Ticket gemeinsam an einem Rechner bearbei- rung zwischen Stories und Tasks und ein starker Fokus ten. Damit sich Wissen zwischen möglichst vielen Teil- auf die Selbstorganisation des studentischen Entwick- nehmern gut verteilt, ermutigen wir die Studenten zu lerteams. Letztere haben wir unter anderem durch regelmäßigem Wechsel des Programmierpartners. Wir die Anleitung zu Stand-Up Treffen und Retrospektiven halten dafür in einer Matrix fest, wer schon mit wem unterstützt. zusammen entwickelt hat. Dieses Verfahren wurde Über die Jahre sind wir in den Praktika jedoch auch aus früheren Praktika ohne Änderung übernommen. auf wiederkehrende Schwierigkeiten gestoßen. So ist Allgemein beinhaltet der tägliche Arbeitstag ein es immer wieder vorgekommen, dass fast fertige Sto- Stand-up Treffen am Morgen und am Abend, sowie ries nicht endgültig fertiggestellt wurden. Die letzten ein gemeinsames selbstorganisiertes Teamfrühstück integrierenden Arbeitsschritte wurden von den Stu- vor Beginn der Arbeit. Wöchentlich gibt es eine Re- denten sowohl als unerfreulich als auch als technisch trospektive (Beck u. Andres, 2004) in der reflektiert anspruchsvoll wahrgenommen. Daher wurden andere wird, was in der Woche erreicht wurde und was man Arbeiten der Fertigstellung vorgezogen, auch wenn verbessern könnte. sich das Team bereits dieses Problems bewusst war. Die drei Lehrkräfte üben während des Praktikums Sicherlich hätte sich dieses Problem durch Zuordnung feste aber verschiedene Rollen aus. Wie bereits in einzelner zu diesen Arbeitsschritten lösen lassen, aber (Mügge u. a., 2004) ausgeführt hat sich die Dreitei- das hätte dann unser Bemühen das Team in seiner lung Kunde, Teamleiter und technischer Experte am bes- Selbstorganisation zu unterstützen deutlich konterka- ten bewährt. Der Kunde legt fest, was er als Produkt riert. Mit Kanban erhofften wir uns, dass durch die entwickelt haben möchte und welche Funktionalitä- Kombination des Pull-Prinzips mit strikten Limits für ten er sich wünscht. Das resultierende Produkt kann die einzelnen Phasen, die Sichtbarkeit des Problems so entweder etwas sein, was in der Forschung genutzt deutlich würde, dass sich das Team seiner annehmen wird oder was von der Industrie an uns herangetragen würde. wird1 . Der Kunde ist auch in den täglichen Entwick- Eine weitere Herausforderung, die von den Studen- lungsprozess eingebunden wie im Extreme Program- ten deutlicher wahrgenommen wurde als von uns, ming üblich. Das tägliche Projektmanagement des war den Aufwand für Besprechungen - insbesondere Teams wird von der Rolle des Teamleiters ausgeübt. zum Anfang einer Iteration - zu reduzieren. In nicht Dieser stellt die Brücke zwischen dem Entwicklerteam wenigen Praktika verbrachten die Studenten einen und dem Kunden dar. Die letzte Rolle ist die eines Tag oder sogar etwas mehr damit, in die Produkt- technischen Experten. Dieser ist Ansprechpartner bei wünsche des Kunden eingeführt zu werden. Bei einer 1 Ein Beispiel für ein entwickeltes Produkt: 2 http://developer.android.com/guide/practices/ http://www3.uni-bonn.de/Pressemitteilungen/299-2009 performance.html A. Spillner, H. Lichter (Hrsg.): SEUH 13 93 Abbildung 2: Schematische Darstellung des Kanban-Boards des Praktikums mit den einzelnen Phasen und Limits. Teamgröße von mindestens 10 Studenten führt dies unterschiedliche Entwicklerpaare zu verteilen und an- zumindest vorübergehend zu einiger Passivität. Da dererseits bleibt der angestrebte Fortschritt sichtbar Kanban weniger Wert auf Iterationen legt bzw. sogar und verschwindet nicht hinter technischen Details. ganz ohne diese auskäme, versprachen wir uns, die Die Implementation findet in der Development-Phase initialen Besprechungen etwas entzerren zu können. statt. Anschließend werden sowohl ein Team-interner Das Ende der Iterationen hingegen stellte den Kun- Codereview, als auch ein gemeinsamer Review mit den vor die Herausforderung, Funktionalitäten in ei- dem Kunden durchgeführt. Nach erfolgreichem Ab- nem Umfang überprüfen zu müssen, den er nicht be- schluss der Reviews ist ein Ticket in der Live-Phase wältigen konnte. Daher war das Feedback des Kun- angelangt. den über die Qualität des Geleisteten mitunter eher Zur Visualisierung der Phasen auf einem White- unscharf. Durch einen gleichmäßigeren Fluss fertig- board wurde je Phase eine Spalte verwendet (siehe gestellter Funktionalität hofften wir dieses Problem Abbildung 2). Die Phasen Analyse, Development und entschärfen zu können. Dieses konnten wir schließ- Review wurden noch weiter unterteilt in die Zustände lich durch vorhergehende Reviews durch Team und ”In Progress” sowie ”Done”. Die Arbeitslimits wurden Teamleiter beheben. in einer separaten Zeile je Phase dargestellt. Ab der Basierend auf den Erfahrungen bisheriger Praktika zweiten Praktikumswoche wurde ein Zeitraffervideo wurde der grundsätzliche Arbeitsfluss in einem in- des Kanban-Boards erstellt3 . In diesem sieht man, wie itialen Kanban-Board festgehalten. Das initiale Board einzelne Tickets von links nach rechts durch die ein- enthielt die folgenden sechs Phasen: Backlog, Input zelnen Phasen des Prozesses wandern. Queue, Analysis, Development, Review und Live (Ab- Wie erwähnt unterteilt das Team die anfänglichen bildung 2). Tickets des Kunden (die User Stories) in kleinere Tasks, die von den Studenten jeweils in einem Paar in einer Das Backlog enthält die Ideen des Kunden, die in kurzen Zeit bearbeitet werden können. In der Ent- noch nicht ausreichend genauer Form definiert sind wicklungsphase wandern daher die Task-Karten für oder die (noch) nicht realisierbar sind. Dies entspricht ein Ticket von links nach rechts. Ein Ticket ist dann dem Backlog des Scrum-Prozesses mit dem Unter- fertig implementiert, wenn alle Tasks des Tickets fer- schied, dass die Tickets noch nicht von dem Team tig implementiert wurden. Da es aber Tickets geben geschätzt wurden und sie noch in Bearbeitung sind. kann mit wenigen oder auch welche mit vielen Tasks, Die ”Input Queue” Phase wird von dem Kunden kon- gibt es für diese Tasks keine Beschränkung hinsichtlich trolliert und bestimmt, welches das nächste zu entwi- maximal erlaubter Anzahl an Tasks, die zeitgleich be- ckelnde Feature ist. arbeitet werden dürfen. Hingegen wurde die Anzahl In der Analyse wird mit dem Kunden zusammen an Tickets - also der User Stories zu den Tasks - in der festgelegt, was alles zu der Realisierung des Tickets Development-Phase beschränkt. gehört, d.h. es werden Akzeptanzkriterien festgelegt. Während des Praktikums wurde der aktuelle Zu- Außerdem nimmt das Team in der Analyse eine Zerle- stand zu festen Zeiten von allen Tickets auf dem gung des Tickets in kleinere sogenannte Tasks vor. Die- Kanban Board gemessen und festgehalten. Aus die- se Unterscheidung von Tickets, die einen durch den sen Daten wurde anschließend ein ”Cumulative-Flow” Kunden wahrnehmbaren Funktionalitätsfortschritt ha- Diagramm (Anderson, 2010) (siehe Abbildung 3) ge- ben, (User Stories) und den dazu nötigen Arbeits- neriert. In dem Diagramm wird über die Zeit auf- schritten (Tasks) haben wir aus den vorhergehenden getragen, wieviele Tickets sich zu einem Zeitpunkt Praktika übernommen. Dadurch wird es möglich ei- nerseits die Teilschritte genau zu beschreiben und auf 3 http://www.youtube.com/watch?v=OiPaIefQbgM 94 A. Spillner, H. Lichter (Hrsg.): SEUH 13 im System befinden und welchen Zustand diese ha- rungen aus didaktischen und allgemeinen praktischen ben. Dabei zählen fertig bearbeitete Tickets zu der Gründen vorgenommen. Live-Phase. Eine breite Phase in dem Diagramm kann Das Verebben des Ticketflusses wurde deutlich an- entweder bedeuteten, dass ein Ticket lange in dieser hand der Anzahl der Entwickler die keine Arbeit hat- Phase bearbeitet wird, oder dass die nächste Phase ten. Dies wurde teilweise durch blockierende Tickets nicht verfügbar ist und die Tickets nicht weiterbear- in späteren Phasen erzeugt. Im Kanban-Prozess, soll- beitet werden können. Dieses Diagramm wurde im ten idealerweise die freien Ressourcen mithelfen die Praktikumsraum neben dem Board aufgehangen und Engpässe zu beheben. Dies war aber bei unseren fein- diente als Visualisierung des Fortschritts in täglichen granularen Tasks die schon auf ein Entwickler Paar Stand-Up Besprechungen mit dem Team. geplant waren selten möglich. Ebenso zeigte sich, dass In Kanban-Prozessen findet man häufiger speziali- unsere oben beschriebene anfängliche Priorisierung sierte Entwicklerrollen (z.B. Architekten oder Tester) ungünstig gewählt war. Durch die Engpässe in der die in speziellen Phasen arbeiten. In unseren Prak- Development-Phase, gab es wenige bis keine Tickets tika legen wir Wert darauf, dass die Studenten alle für den Review. Nachdem aber auch der Review prio- Entwicklungsphasen erfahren, so dass wir keine spe- risiert werden sollte, wurde eher der Review gemacht zialisierten Rollen genutzt haben. Als Konsequenz dar- bevor ein neues Ticket in die Analyse-Phase gezogen aus waren die Studenten frei in der Wahl in welchem wurde. Entwicklungsschritt sie arbeiten möchten, solange die Es stellte sich auch heraus, dass ein Ticket in der Kanban-Limits berücksichtigt wurden. Allerdings gab Analyse-Phase nicht von mehreren Paaren effektiv be- es Priorisierungen von zu bearbeitenden Tickets im arbeitet werden konnte. Daraus resultierte ein Stocken System. des Entwicklungsprozesses, in dem keine Tickets in Initial war die einzige Regelung, dass Tickets in der Analyse oder fertig für die Development-Phase späteren Phasen bevorzugt weiterbearbeitet werden waren. Als Lösungsmöglichkeiten hätten wir die Ar- sollten, damit der Kunde zügiger fertige Features be- beitslimits in der Development-Phase anpassen kön- kommt. Auch wenn diese Regel bereits dem Toyota nen um ein Entwicklerpaar frei zu haben für Analyse Production System entstammt, war sie für uns beson- oder Review. Wir passten aber unsere unglücklich ge- ders plausibel, da in früheren Praktika - wie oben wählte Priorisierung an, indem wir die Priorisierung erwähnt - die Integration von Tasks zum Ticket und Analyse -> Review -> Development vorschlugen. Dies der Review unbeliebter waren. In der Konsequenz stellte sich im Laufe des Praktikums als sinnvolle Ent- wurde lieber ein neues Ticket analysiert als ein fast scheidung heraus, da es den Engpass entlastete und fertiges Ticket fertigzustellen und dem Kunden zu die Studenten in der Development-Phase Tickets zum präsentieren. Bearbeiten hatten. Ein weiterer Engpass in dem Prozess war die Rolle Anpassungen während des des Kunden. Dieser wurde in der Analyse-Phase zur Praktikums Akzeptierung der genaueren Anforderungen und in Während des Praktikums wurden einige Anpassungen dem finalen Schritt der Review-Phase benötigt. Da an den Arbeitsfluss und die Visualisierung des Prozes- es nur einen Kunden gab, war dieser eine begrenzte ses vorgenommen. Im Folgenden möchten wir diese Ressource. Ebenso war es aber weder sinnvoll, die An- genauer beschreiben und vorstellen. Der Hauptgrund zahl an Kunden zu erhöhen noch die Einbindung des für die Anpassungen war ein ”verebben” des Ticketflus- Kunden in beide Schritte zu vermeiden, daher wurde ses innerhalb des Prozesses. Ebenso wurden Verände- versucht, durch den Teamleiter in beiden Schritten einen vorgelagerten Kundenrepräsentanten zu spie- len. Dies bewirkte, dass viele Fragen der Studenten in 60 diesen Schritten von dem Teamleiter beantworten wer- Tickets Backlog Items Input Queue 50 Analysis den konnten und der Kunde trotz alledem die fertigen Development Review Dokumente präsentiert bekam und selber entscheiden 40 Live konnte, ob sie fertig sind. 30 Für die meisten Studenten war es das erste Mal, dass sie in einem größeren Entwicklerteam an einem 20 gemeinsamen Projekt arbeiten mussten. Der Kanban- Prozess war keinem der Studenten vor dem Prakti- 10 kum bekannt. Eine Einführung in den Kanban-Prozess 0 und das Kanban-Board war zwar durch in den Work- shop gegeben, aber diese war nach unserer jetzigen Date Erfahrung zu kurz. Aus diesen beiden Tatsachen resul- tierten während des Praktikums Unsicherheiten der Abbildung 3: ”Cumulative-Flow” Diagramm des Prak- Studenten, was zu tun ist oder wo sie helfen konnten. tikums Nachdem die Erfahrung mit dem Prozess und dem A. Spillner, H. Lichter (Hrsg.): SEUH 13 95 Board merklich zunahm, wurden die Zeiten, in denen Entwicklern und der Kommunikation zwischen den die Studenten aufgrund der Limits keine Arbeit am Phasen. Durch die kurze Zeit des Praktikums ist es Projekt leisten konnten, für die Studenten demotivie- darum schwer aus den wenigen Messpunkten herzu- rend. leiten, ob Kanban rein objektiv zur Verbesserung des In der Kanban-Literatur (Anderson, 2010) wird die- Gesamtprozesses beigetragen hat. ser nützliche Spielraum (”Slack”) genutzt, um einer- Als weiterer Kritikpunkt fügt unsere finale Priorisie- seits den Prozess zu optimieren und andererseits den rung von Analyse > Review > Development dem Ge- Entwicklern die Möglichkeit zu bieten, sich selbststän- samtprozess noch eine zusätzliche Komplexität hinzu. dig fortzubilden. Als Fortbildungsmöglichkeit definier- Diese Entscheidung sollte auf der einen Seite bewir- ten wir einige Möglichkeiten in Form von Tutorials ken, dass dem Kunden möglichst zügig Tickets als fer- und Literatur, die sich um die benutzte Technologie tig vorgelegt werden konnten. Auf der anderen Seite oder solche, die später noch genutzt werden sollte, sollte es durch die Priorisierung immer fertig analy- drehten. Diese hatten damit den zusätzlichen Nutzen sierte Tickets geben, die direkt in den Development- für den Kunden, dass das Wissen über die Technologi- Schritt gezogen werden konnten. Diese beiden Schrit- en frühzeitig im Team verteilt werden konnte. Die Stu- te waren gegeben, trotzdem waren wir mit der re- denten hatten bei Leerlauf die freie Wahl aus diesen sultierenden Priorisierung nicht glücklich, da es eine auf Karten beschriebenen Fortbildungen zu wählen. höhere Aufmerksamkeit auf Seiten der Studenten for- Neben diesen Karten konnten die Studenten auch derte. jederzeit Vorschläge oder Ideen einbringen, wie man Durch den ungewohnten Entwicklungsprozess und den Gesamtprozess oder das Board verbessern könnte. das Umfeld waren die Studenten anfangs eher passiv Ein Vorschlag war zum Beispiel, dass nicht immer klar in dem Prozess. Mit steigender Erfahrung mit Kanban war welche Studenten an welchen Tickets arbeiteten. und steigendem Selbstbewusstsein im Team fingen Nachdem die Tickets in der Development-Phase in die Studenten an, Verbesserungsvorschläge zu ma- meist mehrere Tasks unterteilt und mit je einem Paar chen. Durch eine bessere und längere Einführung von weiterentwickelt wurden, war es wichtig, dass sich Kanban in dem Workshop könnte man diese Hemm- diese Studenten über den Zustand austauschen, da schwelle vermutlich verringern und frühere Verbes- es häufig Abhängigkeiten zwischen den Tasks gab. serungsvorschläge erleichtern. Wie so oft in unseren In diesen Schritten ist es daher wichtig, zu wissen, Praktika war das Team in der letzten Woche erst auf wer an welchen Tasks arbeitet um sich z.B. räumlich voller Produktivität. nebeneinander zu setzen. Als Lösung des Problems Eine Schwierigkeit in der Anpassung des Prozesses wurde ein Bild von jedem Entwickler und Dozenten während des Praktikums ist der kurze Zeithorizont. gemacht und auf dem Board befestigt. Jeder hatte Man kann entweder zur Optimierung Arbeitsschritte dann die Aufgabe, sein Bild auf das Ticket oder den und Puffer hinzufügen oder entfernen, oder an den Li- Bereich zu verschieben, an dem er arbeitete. Da es mits in jedem Schritt drehen. Wenn man eines von bei- diese Bilder auch für Teamleiter und Kunden gab, half den anpasst, soll man laut Literatur (Anderson, 2010) diese einfache Idee als Nebeneffekt auch, den Paaren, einige Zeit warten, bis sich der Prozess auf die neu- die in der Analyse oder dem Review arbeiteten, visuell en Rahmenbedingungen eingependelt hat.4 Ebenso zu erfassen ob der Kunde verfügbar war. sollte man nur eine Schraube in jedem Schritt verän- dern. Dies bedeutete aber für unser Praktikum, dass Fazit es schwer war den Effekt abzuschätzen. Wir hatten Um zu bewerten, wie gut unser Prozess im Praktikum uns daher auch entschieden während des Praktikums funktionierte, wurde das Cumulative Flow Diagramm keine Arbeitsschritte anzupassen und nur die Limits (siehe Abbildung 3) herangezogen. Außerdem hatten der Schritte zu justieren. Davon haben wir auch in wir an einem Tag während des Praktikums einen ex- der ersten Woche Gebrauch gemacht, indem wir die ternen Prozess-Reviewer, der Entwickler-Teams in der Limits in der Development-Phase von sechs Tasks auf Industrie bei der Einführung von Kanban professio- zwei Tickets angepasst haben. nell berät. Von ihm erhielten wir hilfreiches Feedback Zur Evaluation des Praktikums haben wir die Stu- und wertvolle Tipps. Schließlich haben wir zudem denten am Ende gebeten, einen Fragebogen auszufül- die Studenten noch mit einem Fragebogen um ihre len. Neben acht offenen Fragen enthielt der Fragebo- Einschätzung gebeten. gen Fragen, die mit Werten auf einer Skala von 0 bis In unserer Nachbereitung stellten wir aber fest, dass 6 zu beantworten waren. Unter anderem baten wir es für uns schwer war zu entscheiden, ob uns das Dia- die Studenten um ihre subjektive Einschätzung ihrer gramm eine Aussage über die Prozessqualität machen Kompetenz vor und nach dem Praktikum. Hier bedeu- kann. Dies hängt vor allem daran, dass selten ein tete 0 ”keinerlei Wissen” und 6 ”exzellentes Wissen”. festes Paar ein Ticket durch den gesamten Prozess In allen abgefragten Kompetenzen verbesserten sich begleitet hat. Daher hängt die Dauer, die ein Ticket in 4 Kanban-Entwickler aus der Wirtschaft berichteten uns im per- einer Phase verbracht hat, nicht nur von den Eigen- sönlichen Gespräch, dass man bis zu einem Monat warten muss, schaften des Tickets selber ab, sondern auch von den um zu sehen ob eine Änderungen positive Auswirkungen hatte 96 A. Spillner, H. Lichter (Hrsg.): SEUH 13 die Studenten im Mittel um mindestens 1,1 Punkte. zu machen, was sie bereits erreicht haben. Nachdem Den größten mittleren Zuwachs gaben die Studenten die Studenten häufig nicht in allen Phasen bei jedem bei den technischen Fertigkeiten an (Verständnis von Ticket involviert waren, erzeugte dieses Zelebrieren Android (+1,7), Prolog (+1,9), Verwendung von Sub- häufig auch das Gefühl, dass jeder seinen Teil dazu version (+2,0) und Eclipse (+2,1)). Aber auch bei beigetragen hat und der Code vom gesamten Team ”weichen” Faktoren war der Zuwachs deutlich (Kom- stammt. Wir haben diese Treffen auch genutzt, um munikation (+1,5), Zusammenarbeit (+2,0)). Auch über die Entwicklung des Tickets selber zu reflektie- im Hinblick auf Kanban äußerten sich die Studen- ren: Was lief gut und was hätte im Prozess besser ten eindeutig positiv. So hat ihrer Meinung nach das laufen können? Kanban Board die Übersicht verbessert (5,0) und den Das Praktikum hat drei Probleme aufgezeigt, denen Arbeitsfluss klar widergespiegelt (5,1). Zudem waren man sich bewusst sein sollte. Erstens, sollte vor einem die Work-in-Progress Limits klar (4,7). Nicht ganz so Praktikum genug Zeit investiert werden um den Pro- zufrieden waren die Studierenden mit der eigenen zess und Kanban zu besprechen und zu diskutieren. Handhabung von ”Staus” (3,0).5 Zusätzlich sollten die Studenten die Möglichkeit be- kommen, den Prozess selber zu erleben, zum Beispiel Empfehlungen für die Lehre in Form eines Spieles. Die Evaluation ergab, dass der Kanban-Entwicklungs- Zweitens waren die unterschiedliche Größen und prozess für die Studenten nützlich war. Außerdem, hat Komplexitäten der Tickets ein Problem. In Kanban soll- der Prozess Probleme verringert, die wir in früheren ten idealerweise alle Tickets ungefähr gleich groß sein Praktika erlebt haben. Zum Beispiel hatten wir erlebt, und lange brauchen. Durch gemeinsame Schätzungen dass blockierende Tickets früher nicht immer allen der Tickets durch das Team konnten im späteren Teil sichtbar und bewusst waren und zusätzlich von dem des Praktikums zu große Tickets identifiziert werden. Prozess nicht explizit behandelt wurden. Zu diesem Zu Anfang des Praktikums fehlen im Normalfall die Er- Zweck hat, das Kanban-Whiteboard in dem Prakti- fahrungen zu präzisen Schätzungen. Dozenten sollten kumsraum eine essentielle Rolle als Mittel für Diskus- in dieser Phase verstärkt dem Team mit ihrer Erfah- sionen geboten. Dieses hat auch den Studenten gehol- rung helfen und Wert darauf legen, ihr Wissen über fen den Gesamtüberblick zu behalten und ihnen die Schätzungen an das Team zu vermitteln. Möglichkeit gegeben selbst ihre eigenen Leistungen zu Drittens war die Anpassung der Arbeitsschritte oder reflektieren. Wir würden daher, trotz digitalen Mög- der Limits eine Herausforderung. Anpassungen sollten lichkeiten, empfehlen, ein physisches Kanban-Board in kleinen Schritten erfolgen und man sollte einige zu nutzen und es zentral in den täglichen Arbeitsalltag Zeit abwarten, ob die Änderungen den gewünschten zu stellen. Effekt haben. In unseren Praktika haben wir aber nur In Scrum (Schwaber u. Beedle, 2001) gibt es feste eine kurze Zeit zur Verfügung, und die Studenten be- Iterationen, die im vorhinein geplant werden. Dem nötigen unserer Erfahrung nach einige Zeit um sich Kunden ist es dabei nicht möglich, den Fokus der an die Rahmenbedingungen des Teamentwicklung Entwicklungs dynamisch während einer Iteration an- und der Technologien zu gewöhnen. Wenn man den zupassen. Durch die flexible Input-Queue in unserem Prozess einsetzen will, sollte man sich als Lehrender Praktikum war es dem Kunden jederzeit möglich den dessen bewusst sein und in der Vorplanung bereits aktuellen Fokus anzupassen. Dies ist in einem For- berücksichtigen. Ebenso empfehlen wir in so einer schungsprojekt wichtig, da auf aktuelle Erkenntnisse kurzen Zeitspanne entweder sich vorher zu überlegen und Entwicklungen reagiert werden kann. ob die Arbeitsschritte verändert werden dürfen, oder Die Fortbildungsmöglichkeiten für Studenten wäh- die Limits in den Arbeitsschritten angepasst werden rend des Lehrlaufes waren unserer Meinung nach sinn- sollen. Wir hatten uns in dem Praktikum entschie- voll, wurden aber nicht gut genug kommuniziert. Die den nur die Limits anzupassen und hatten damit gute Arbeit an diesen Aufgaben entsprach auch nicht dem Erfahrungen gesammelt. allgemeinen Ticketfluss. Wenn man solche Möglich- keiten vorsieht, sollte man diese Aufgaben auch an Praktikum 2012 einem Ort in der Nähe des Whiteboards visualisieren. Aufgrund unserer guten Erfahrungen wurde auch im Der Vorteil davon ist, dass sowohl die Lehrenden als Praktikum im Jahr 2012 der Kanban-Prozess einge- auch die Teilnehmer wissen an welchen Aufgaben die setzt. Als Basis wurde das hier vorgestellte Kanban- Studenten arbeiten. Board genutzt. Dieses musste nicht weiter angepasst Tägliche “feature celebrations” nach der Mittags- werden, so dass die Dozenten eine geringere Vorberei- pause wurden genutzt um im Team kurz vorher fer- tungszeit benötigten. Im Laufe des Praktikums wurden tiggestellte Tickets in einer Livedemonstration zu fei- auch nur wenige und erwartete Anpassungen an den ern. Dies hatte den Zweck, den Studenten bewusst Limits der Prozessschritte vorgenommen. Diese An- 5 Die Fragen und die Verteilung der Antworten können online passungen wurden nötig, da die problematische Prio- nachgelesen werden: http://sewiki.iai.uni-bonn.de/_media/ risierung des vorherigen Praktikums entfernt wurde. teaching/labs/xp/2011b/agile_lab_2011_evaluation.pdf Weiterhin mit Problemen behaftet waren wiederum A. Spillner, H. Lichter (Hrsg.): SEUH 13 97 unterschiedlich komplexe Tickets und ihr Einfluss und [Mügge u. a. 2004] M ÜGGE, H. ; S PEICHER, D ; K NIE - Aussagekraft auf den Gesamtfluss. Durch die Arbeitsli- SEL , G.: Extreme Programming in der Informatik- mits bedingt konnten aber auch schwierige Aufgaben Lehre - Ein Erfahrungsbericht. In: Informatik 2004 - fokussierter bearbeitet werden. Beiträge der 34. Jahrestagung der GI, Lecture Notes in Informatics, 2004 Zusammenfassung [Ōno 1988] Ō NO, T.: Toyota production system: beyond In dieser Arbeit haben wir von unseren Erfahrung mit large-scale production. Productivity Pr, 1988 der Anwendung des Kanban-Entwicklungsprozesses in einem Blockpraktikum an der Universität Bonn be- [Schwaber u. Beedle 2001] S CHWABER, K. ; B EEDLE, richtet. Neben den Vorteilen des Prozesses und den M.: Agile software development with Scrum. Bd. 18. Lösungen früherer Probleme wurden auch neue Pro- Prentice Hall, 2001 bleme aufgezeigt. In einem kürzlich durchgeführten Praktikum konnten diese teilweise auch schon bewäl- tigt werden. Als wichtigste Erkenntnis würden wir jedem Leh- renden, der Kanban einsetzen möchte, empfehlen, zu Anfang den bisher eingesetzten Prozess und dessen Schwierigkeiten schriftlich festzuhalten. Auf Basis des- sen kann man dann überlegen ob Kanban sinnvoll ist und wie man den Prozess anpassen kann. In unserem Fall konnte Kanban die hartnäckigen Schwierigkei- ten aufgeschobener Fertigstellung fast fertiger Stories und ungenügender Reviews aufgrund auf das Iterati- onsende konzentrierter Fertigstellungen aus der Welt schaffen, sowie den Besprechungsaufwand deutlich reduzieren. Danksagung Wir möchten uns bei Matthias Bohlen für seinen exter- nen Review unseres Kanban-Prozesses während des Praktikums bedanken. Wir haben wertvolle Tipps er- halten, die unser Verständnis von Kanban vertieft und unseren Prozess verbessert haben. Literatur [Anderson 2010] A NDERSON, D.: Kanban, Successful Evolutionary Change For Your Technology. Blue Hole Press, 2010 [Beck u. Andres 2004] B ECK, K. ; A NDRES, C.: Extreme programming explained: embrace change. Addison- Wesley Professional, 2004 [Goldratt u. a. 1984] G OLDRATT, E.M. ; C OX, J. ; O UT- PUT , C.: The goal: Excellence in manufacturing. Bd. 262. North River Press New York, 1984 [Lindvall u. a. 2004] L INDVALL, M. ; M UTHIG, D. ; D A - GNINO , A. ; WALLIN , C. ; S TUPPERICH , M. ; K IEFER , D. ; M AY, J. ; K AHKONEN, T.: Agile software deve- lopment in large organizations. In: Computer 37 (2004), dec., Nr. 12, S. 26 – 34 [Melnik u. Maurer 2004] M ELNIK, G. ; M AURER, F.: In- troducing agile methods: three years of experience. In: Euromicro Conference, 2004. Proceedings. 30th, 2004, S. 334 – 341 98 A. Spillner, H. Lichter (Hrsg.): SEUH 13