Kanban in der Software-Entwicklung


Kanban Board für Agile Softwareentwicklung

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.

Eines unserer Kanban-Tickets aus dem Unit Test
Eines unserer Kanban-Tickets aus dem Unit Test

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.

Der „Team Awesome“-Shrine im Büro
Der „Team Awesome“-Shrine im Büro

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.

Kanbanboard und Magnete bei uns im Büro
Kanbanboard und Magnete bei uns im Büro

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.


Beitrag veröffentlicht

in

, ,

von

Kommentare

11 Antworten zu „Kanban in der Software-Entwicklung“

  1. Avatar von Stefan
    Stefan

    Sehr schöner Artikel! Ich habe es selber nicht getestet, aber Jimflow ist ein ziemliches cooles Add-on und kann ein paar der Nachteile aufheben. Irgendwie aber auch ein unnötiger Schritt „zurück“ in die digitale Welt.

    1. Avatar von Marc
      Marc

      Jimflow ist immer das Erste was kommt, wenn man sich darüber unterhält, wie man das „anders“ machen kann. Den Overhead, den wir damit generieren würden, ist in meinen Augen für vier Leute zu hoch. Aber das Backup, Statistiken und vor allem die Suche wären schon hilfreich. Vielleicht wenn wir das Team ausbauen und über zehn Leute groß werden in der Entwicklung.

      Wie macht ihr das denn?

      Und zum Thema „Schöner Artikel“. Es ist wirklich schade, dass Artikel und Themen, die ich persönlich super finde, wenig Aufmerksamkeit bekommen.

    2. Avatar von Stefan
      Stefan

      Ich finde Jimflow auch eher technisch cool, als wirklich alltagstauglich. Wir nutzen auch Kanban, aber in etwas einfacherer Form. Für meine persönliche Aufgabenorganisation nutze ich für alle Lebenslagen gerne Things.

      Um die Aussage „schöner Artikel“ etwas zu präzisieren: Ich finde es immer super, Einblicke in andere Arbeitsabläufe zu bekommen. Besonders eure git Integration klingt sehr sinnvoll.

    3. Avatar von JTRch
      JTRch

      Ähnliches Konzept wie das was wir bei den vorherigen Arbeitgeber für die Abwicklung von Aufträgen in sog. „just do it“ Räumen hatten. Jeder Auftrag wurde aufgehängt, stand das wichtigste drauf und wurde der Wand nach nach Meilensteinen verschoben. Kein Wunder, der Herr den es eingeführt hat war ein japanischer Consulter der vorher schon Autokonzerne auf Vordermann gebracht hat.

    4. Avatar von Marc
      Marc

      Entwickelt ihr auch Software? Oder was macht ihr genau? Mich wundert es nämlich, dass dies etwas ist, was scheinbar nur im weitesten Sinne „Ingenieur“ nutzen.

    5. Avatar von JTR
      JTR

      Ich bin nicht mehr in der Firma, aber es war ein Maschinenbauer, sprich Ingenieurtechnik ja. Ich fand die Methode praktisch. Man hatte mit einem Blick einen Überblick über die Dinge die aktuell wichtig sind. Gut bei uns war es nicht ein Whiteboard sondern ein ganzer Meetingroom dessen Wände mit A4 Zettel behangen waren. Aber bei der Menge an Maschinen, alle an Kundenwünsche angepasst, war das kein Wunder.

  2. Avatar von func0der
    func0der

    Also der Grundansatz ist ja gut, allerdings in Zeiten der digitalen Medien ist das alles ein wenig suboptimal.

    Die meisten Nachteile sind ja bereits aufgezählt worden.
    Zusätzliche Vorteile böten natürlich auch noch die Verlinkung von Tickets in git commit messages, die Github dann automatisch verlinken würde. Außerdem könnte man relativ einfach Tags für Tickets setzen und sie so leichter einordnen.

    Zudem ist das „Einbinden“ neuer Mitarbeiter in das analoge Vorgehen recht teuer und langwierig. Neue Buttons müssen bezahlt und bestellt werden etc. Nervig und bei spontanem Ausscheiden eines Mitarbeiters hat man das Zeug rumliegen.
    Zusätzlich kostet ein Whiteboard in der oben genannten Größe ca 190,00 € (exkl. MwSt.), was nicht unbedingt so günstig ist.
    Bei GitHub sind das nur zwei Klicks.
    In Verbindung mit , dem OpenSource-Tool, das im Prinzip die ganze Tafel als visuelles Mittel obsolet macht, kann das System auch komplett digital funktionieren.

    Dem generellen „Verschmutzen“ des Ticketsystem durch ewig lange Tickets kann ich nicht beipflichten. Ich empfinde es sogar als besser, wenn man ein Problem präzise beschreibt, Handlungsszenarien aufzeigt, die dazu geführt haben, Screenshots anhängt, sofern nötig und zu dem ganzen einfach einen präzisen Titel wählt.
    Als zusätzliche Maßnahme gegen das „E-Mail-Schreiben“-Verhalten gibt es halt Berechtigungen nur für solche Leute, die wissen, wie man ordentliche Tickets schreibt.

    Zu der JimFlow-Sache: Ist eine schicke Idee, allerdings nur technisch. Ansonsten macht es null Sinn, da man zu viel Software hat, die Fehler produzieren kann. Dann lieber einen Fernseher kaufen oder einen ausrangierten Beamer benutzen, um die Tickets visuell an die Wand zu „hängen“.
    Und wenn eine richtig krasse Technikkette aufbauen, dann doch bitte mit digitalem Whiteboard und Schriftenerkennung.

    Rechtschreib- und Flüchtigkeitsfehler dürft ihr aus gegebenem Anlass behalten.

    Gruß
    Lars

    1. Avatar von Marc
      Marc

      Ja, github ist super. Die Branches hängen dann direkt an den Tickets. Alles fein. Das würde ich als Agentur, die mit vielen Kunden und Mitarbeitern an verschiedenen Orten zusammenarbeitet, auch so machen.

      Aber für uns, die wir hier alle an einem Ort sitzen und nur eine Tür weiter gehen müssen für die Stakeholder, überwiegen meiner Ansicht nach die Vorteile.

      Aber es könnte ja rein theoretisch sein, dass wir bald mit einem externen Diensleister genau das mal zusammen testen, lieber Lars. ;-)

  3. Avatar von ben_
    ben_

    Ich hab ja immer ein bisken ein Problem damit, sowas zu sagen wie „Wir machen Xyz“. Da ist man schnell dabei Dinge des reinen Formalissmusses oder der reinen Lehre wegen zu machen. Ich halte mir mit der konkreten Verweigerung die Option offen, zu jedem nötigen Zeitpunkt sagen zu können „Ok, wir machen das und das ab jetzt anders.“

    Davon abgesehen gibt es ja zwei zentrale Voraussetzungen, unter denen eure Lösung funktioniert:

    1. Alle Entwickler arbeiten fast ausschließlich in einem Raum
    2. Die Menge und Komplexität der Arbeit läßt sich auf einem Board abbilden.

    Beide ist bei uns im Palasthotel leider nicht gegeben. Wir arbeiten an 4 unterschiedlichen Standorten, oft auch mehr und unsere Auftraggeber sind sowieso über die Republik verteilt. Da ist der Vorteil, dass alle Tasks an EINER Stelle diskutiert werden vital. Außerdem haben wir Stand jetzt 515 Task in Github. Dazu kommen noch die Tasks, die in anderen Ticket-Systemen verwaltet werden. Da bräuchte man schon eine ziemlich große Tafel.

    Nebenbei: Wie macht ihr das, wenn ihr mit jemandem zusammenarbeitet, der nicht bei euch im Büro sitzt?

    1. Avatar von Marc
      Marc

      Hi Ben,

      Erstes sehe ich genau so. Ich bzw. wir haben keine Prinzipen. Wir nehmen einfach das, was am besten funktioniert. Und das findet man nur durch ausprobieren heraus.

      1. Alle Entwickler arbeiten fast ausschließlich in einem Raum

      Das erfüllen wir. Außerdem sind wie geschrieben auch alle anderen Leute, die das Board indirekt beeinflussen nicht weit weg.

      2. Die Menge und Komplexität der Arbeit läßt sich auf einem Board abbilden.

      Mehr noch: Wir halten die Komplexität klein. Bei vier Leuten in der Entwicklung ist das sprichwörtliche Ende der Fahnenstange erreicht, wenn nichts mehr ans Board passt. Dann können wir

      a) … Leute einstellen und größeres Board kaufen.
      b) … uns fragen, ob diese Tasks wirklich in der Form (noch) sinnvoll sind

      Das war besonders schön zu sehen, als wir noch für die andere Firma nebenan komplett zuständig waren. Da hatten wir das Board horizontal geteilt. Unsere Arbeitskraft musste ja auch geteilt werden.

      Natürlich ist das Kanbanboard nur ein Modell und das sind nur grobe Abschätzungen. Besonders wenn wir uns externe Hilfe holen. ;-) Denn dann – um auf den Punkt von dir zu kommen – haben wir kleine, goldene Magnete sogenannte – Wolfgang-Petry-Gedenk-Ohrstecker) – für Tickets, die wir rausgeben.

      Nun könnte es ja passieren, dass wir mit einer Agentur zusammenarbeiten, wo ein Projektname auf dem Ticket stehen müsste, weil die Aufgabe so aufwendig ist. Das ist natürlich nicht im Sinne des Modells bzw. des Boards. Wir würden das pragmatisch angehen. Wenn die Agentur github nutzt, dann probieren wir das aus und gliedern das Projekt aus dem Board aus.

      Und wir evaluieren nebenbei ob wir nicht nächste Woche das Board mit Benzin überschütten und anzünden und mich mein Geschwätz von gestern nicht mehr interessiert. ;-) Unter den gegebenen Umständen hilft uns das Board aktuell aber sehr die Übersicht zu behalten.

  4. Avatar von Ron
    Ron

    uh uh. Beim benzin überschütten bin ich dann dabei! Super Dekonstruktivismus. Ansonsten: Schöner Artikel. Wir haben in letzter Zeit auch das ein oder andere mehr formalisiert. Und ich muss schon sagen, dass ich das sehr schätze. Man betrachtet das Zeug einfach als Framework und hat dann gleich zu Beginn ein gemeinsames Vokabular und die Gewissheit, dass man nicht der einzige ist der so arbeitet. Prinzipiell also nicht so weit weg von OpenSource. Doch, das hilft schon!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert