Ich bin seit fast drei Jahren für die Entwicklungsabteilung einer großen deutschen Ernährungs- und Rezeptseite verantwortlich und nutze dort Kanban in der Software-Entwicklung. Wir haben die Webseite damals mit Typo3 übernommen und nach kurzer Zeit auf Drupal 7 migriert. In diesem Prozess hat sich in der agilen Software-Entwicklung bei uns im Team Kanban bewährt.
Raus dem eigenen Büro, rein in die Agentur
Für die Migration bin ich mit der Entwicklungsabteilung und dem Produktverantwortlichen Martin Kaltwasser für vier Monate in die Räume der Drupal-Agentur comm-press.de in Hamburg eingezogen. Nach fünf Monaten intensiver Entwicklung, gab es auf diesem Wege einen optimalen Wissenstransfer, um nachher die Plattform ohne die Agentur weiterentwickeln zu können. Und ganz nebenbei haben wir nicht nur den Code auf GitHub und das Wissen über Drupal 7, sondern auch die Arbeitsabläufe übernommen.
Was ist Kanban?
Kanban ist eine Möglichkeit, die Arbeit an komplexen Aufgaben in kleinere Tasks aufzuteilen und zu visualisieren. Die größte Neuerung in unserem Büro nach dem Relaunch, war das riesige (120×240cm), magnetische Kanbanboard. „Kanban“ ist japanisch und bedeutet so viel wie „Karte“. Die Gelben Karten spielen eine große Rolle bei uns, denn auf ihnen steht jeweils ein Task in kurzen Worten zusammengefasst.
Agile Entwicklung
Besonders gut funktioniert das in der agilen Entwicklung. Dabei geht man erstmal davon aus, dass alle beteiligten Personen im Team motiviert sind und Lust auf die vor ihnen liegende Aufgabe haben. Die Verteilung der Tickets passiert also nicht durch einen Teamleiter, sondern das Board und die Tickets werden vom Team als gemeinsames Werkzeug angesehen, die Arbeit übersichtlicher zu machen.
Die Kanban Tickets
Ähnlich wie im Journalismus, muss man erstmal mit den W-Fragen beginnen, wenn man ein Ticket schreibt: Was?, Wo?, Wie?. Dafür hat man nur wenige Zeilen und im Notfall die Rückseite zur Verfügung. In die obere Zeile wird das aktuelle Datum und in N1 die Initialen des Ticket-Erstellers geschrieben. N2 sind die Initialen des Bearbeiters, wenn er es sich vom Board geholt und N3 die des Testers, der das Ticket final abgenommen hat.
Ein Task wird von uns meistens in Form eines git branches mit den Codeänderungen gelöst. Dieser wird hinter B: geschrieben. Wir haben im Gegensatz zur ursprünglichen Vorlage eine fortlaufende ID vor den Branch-Namen fest auf das Ticket geschrieben. Die Kanban Ticket Vorlage als Google Spreadsheet stelle ich natürlich gerne öffentlich zur Verfügung. Damit ist das Arbeiten auf der Shell viel schneller und Branches können eindeutig identifiziert werden.
Diese Karten wandern je nach Status auf dem Kanbanboard von links nach rechts. Die Status dabei sind:
backlog
Mehr oder weniger eine Merkliste für „someday maybe“ Tickets.
features
Neue Features werden bei uns nachrangig nach systemkritischen oder anderen wichtigen Aufgaben bearbeitet. Zuerst kümmern wir uns um immanent wichtige Tickets, die echte Blocker sind, den Datenbestand gefährden oder für die User die Seite nicht benutzbar machen. Aus diesem Bereich übertragen wir dann die Tickets in den nächsten Bereich: to-do.
to-do
Hier warten alle Tickets darauf, so schnell es geht erledigt zu werden. Je weiter oben die Tickets am Board sind, desto wichtiger sind sie.
work-in-progress
Hier hängen alle Tickets, die aktuell bearbeitet werden. Jeder Kollege hat seinen persönlichen Magnetbutton, damit man sofort sieht, wer was macht.
unit test
Das hat nichts mit Unit Tests aus der Entwicklung zu tun. Hier hängen fertige Tickets mit dem git branch darauf. Das Ticket ist erst freigegeben, wenn ein anderer Kollege den branch ausgecheckt, getestet und abgenommen hat. Wir nennen es das „Vier-Augen-Prinzip“.
Das Testing kann unter Umständen aufwendiger sein als die Bearbeitung. Dies ist die wichtigste Methode, um Fehler vorzubeugen. Da der branch auf einem anderen System ausgecheckt und getestet wird als er bearbeitet wurde, beugen wir einer Vielzahl von Fehlern vor.
integration mit git rebase
Hier warten Tickets auf ihre Integration in den stable branch. Um sogenannte merge commits wie merged ‘321-crystal-ball-seo-task’ into stable zu vermeiden, benutzen wir den Befehl `git rebase´.
In der Kurzform machen wir das beim Integrieren der branches in den stable so:
git checkout 123-branch-workingcopy git rebase stable
Wenn es einen merge Konflikt gibt, nach dem Auflösen des Konfliktes NICHT commiten, sondern mit
git rebase --continue
weitermachen.
git checkout stable git merge 123-branch-workingcopy
ready to rollout (ready 2 rollout)
Nachdem die fertigen branches integriert worden sind, warten sie hier auf den rollout des stable branches. Wenn wir entscheiden, dass wir deployen möchten, dann taggen wir den Release und pushen auf das Repository auf dem Live-Server. (Diesen Satz hätte man besser komplett auf Englisch geschrieben, sagt meine Freundin…).
Damit man schon im Nachbarbüro weiß, dass wir gerade am Ausrollen sind, spielen wir dabei ein Lied aus unserer git push origin master Playliste auf Spotify. Darin sind passende Songs wie Push it von Salt’n’Pepa oder Rollin‘ von Limp Bizkit enthalten.
done
Sobald der rollout eingeleitet worden ist, alle Features zurückgesetzt wurden und der Cache gelöscht ist, sind die Tickets fertig. Nun werden sie von der Produktleitung eingesammelt und nochmals überprüft.
Was passiert mit den erledigten Tickets?
Da wir durch git rebase leider nicht per git branch -a –merged sehen können, ob der branch komplett integriert worden ist, löschen wir die branches von origin, sobald wir die Tickets von der Produktleitung wiederbekommen haben. Sollten dabei noch Fehler entdeckt worden sein, schreiben wir neue Tickets. Die fertigen Tickets landen in einem großen Glas bei uns im Büro.
Boardmeetings
Es hat sich eingependelt, dass wir einmal in der Woche zu einem festen Zeitpunkt zusammen alle Tickets am Board durchsprechen. Das führt dazu, dass wir uns alle bewusst sind, was gerade anliegt und wo vielleicht etwas anbrennt.
Vorteile von Kanban
Ein massiver Vorteil liegt in der direkten Visualisierung. Quillt der to-do Bereich über mit Tickets, dann haben wir zu viel zu tun. Staut sich alles beim unit test, müssen wir wohl mehr Tickets testen. Und wieso hängt seit gestern so viel in „Integration“? Dann müssen wir wohl schnell ausrollen. Da das Board omnipräsent mit seinen 3qm im Büro hängt, kontrollieren wir uns damit jeden Tag selber.
Nächster Punkt ist, dass die Tickets nicht viele Zeile haben. Man ist also gezwungen auf wenig Raum ziemlich konkret zu beschreiben, was genau gemacht werden muss. So bleiben die Tasks wirklich kleine Aufgaben und mutieren nicht zu Projekten.
Das Pull-Prinzip
Die Teammitglieder holen sich ihre Aufgaben in gemeinsamer Absprache von Board und schätzen dabei wie lange sie dafür benötigen. Mehr Eigenverantwortung im Team bedeutet, dass die Motivation steigt und Aufgaben besser und schneller erledigt werden.
Das funktioniert natürlich nur mit den richtigen Mitarbeitern. Manche Menschen wollen genau gesagt bekommen, was sie zu tun haben. Für solche Teams bietet sich Kanban oder generell agile Entwicklung nicht an.
Marc, Tickets aus Papier?!
Ich bin nun wirklich kein Freund davon, Informationen auf Papier zu speichern. Ich lebe ansonsten den Traum vom papierlosen Büro. Aber in diesem speziellen Fall sind die unfassbaren Zettel wirklich eine Bereicherung für den Workflow. Der Work-in-Progress Bereich wird durch die physikalisch vorhandene Fläche beschränkt und verhindert, dass zu viele Tasks angefangen werden. Jeder weiß was der Andere gerade macht.
Nachteile von Kanban
Wenn man nicht an einem Ort sitzt, sondern viel mit externen Mitarbeitern arbeitet, dann ist diese Art der Arbeitsorganisation natürlich extrem ungeeignet. Unsere externen Aufträge halten sich in Grenzen und es reicht absolut, diesen Tickets einen speziellen Magnetbutton zu spendieren, um die Übersicht zu behalten. Wir sitzen alle vier in einem Raum und arbeiten nur ein paar Meter weiter von allen anderen Abteilungen, mit denen wir Berührungspunkte haben.
Fehlende Suche
Die fehlende Suche über alle aktuellen Vorgänge ist nervig. Wir kompensieren das nur, indem wir immer alle wissen, was gerade am Board hängt. Wenn wir doppelt so viele Mitarbeiter wären, dann würden wir es sicherlich noch mehr vermissen.
Noch schlimmer ist allerdings das fehlende Archiv. Wir werfen am Ende des Prozesses, direkt nach dem Löschen des branches auf origin, die Tickets in ein großes Glasgefäß im Büro. Um so wichtiger ist das vernünftige Tagging auf GitHub, um eine Übersicht der Änderungen zu behalten.
Genau aus dem Grund haben wir ein Backup der Tickets. Wenn jemand die Tickets vom Board entfernen würde, dann hätten wir ein Problem. Genauso wie die Tickets natürlich auch mal verloren gehen können, weil man sie tatsächlich im Büro des Kollegen vergessen kann.
Fazit
Für unser vierköpfiges fünfköpfiges Team ist Kanban im Zusammenspiel mit github und der lokalen Entwicklungsumgebung wirklich hilfreich. Solange wir selten mit externen Entwicklern zusammenarbeiten, brauchen wir das Board meiner Ansicht nach nicht zu digitalisieren. Zu groß sind die Vorteile der schnellen Übersicht. Aber auch der Aspekt, dass wir aufstehen müssen und das Pull-Prinzip wirklich haptisch durchgeführt wird, sorgt für eine besondere Atmosphäre im Büro. Und der Einstieg ist einfach und relativ günstig. Ein Magnetboard gibt es günstig bei Amazon in diversen Größen. Ein paar Marker und Magnete sind dort ebenfalls schnell gekauft.
Eine diskutierte Alternative wäre, dass wir alles komplett in github umsetzen. Das hätte den Vorteil, dass wir Tickets und branches noch enger verzahnen. Ich habe aber schlechte Erfahrungen damit gemacht, wenn ein Ticket so schnell geschrieben werden kann wie eine E-Mail: Die Qualität lässt nach.
Schreibe einen Kommentar