=Paper=
{{Paper
|id=None
|storemode=property
|title=Kanban im Universitätspraktikum - Ein Erfahrungsbericht
|pdfUrl=https://ceur-ws.org/Vol-956/S3_Paper3.pdf
|volume=Vol-956
|dblpUrl=https://dblp.org/rec/conf/seuh/NonnenIS13
}}
==Kanban im Universitätspraktikum - Ein Erfahrungsbericht==
https://ceur-ws.org/Vol-956/S3_Paper3.pdf
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