Technische Schulden verfolgen mit NDepend 2017.2

NDepend nutzte ich mittlerweile häufig zur Analyse meiner Anwendungen. Die statische Codeanalyse liefert zwar kein vollständiges Bild zum Zustand einer Anwendung, aber man erhält genügend Informationen um Probleme frühzeitig zu erkennen. Die früheren Versionen hatte ich bereits hier und hier beschrieben.
Technische Schulden verfolgen mit NDepend 2017.2 weiterlesen

Advertisements

Erfahrungen mit Kanban

Ich nutze Kanban nun bald 2 Jahre. Neben Personal Kanban nutzte ich diese Methode um Präsentationen vorzubereiten, Software zu entwickeln, Reisen zu planen und noch vieles mehr. Dabei konnte ich zahlreiche Erfahrungen sammeln von denen ich hier die wichtigsten vorstellen möchte.

 

Kanban lässt sich beliebig einsetzen

Kanban ist sehr einfach, flexibel und lässt sich schnell erklären. Damit ist es sehr gut geeignet um überall dort zum Einsatz zu kommen wo man eine Verbesserung herbeiführen will. Damit zeigt sich aber auch gleich die Grenze von Kanban. Wenn alles optimal läuft oder man keine Verbesserung erzielen will sollte man auf Kanban verzichten. In diesen Situationen ist es nur ein Zusatzaufwand der in keinem Verhältnis zum möglichen Ertrag steht.

 

Kanban profitiert von einer Definition of Done

Auch wenn Kanban nirgends von einer Definition of Done spricht, so ist eine gemeinsam definierte Minimalanforderung an jeden Task eine hilfreiche Sache. Dabei müssen die Anforderungen aber zum Inhalt passen. „Ist in der Versionsverwaltung eingecheckt“ funktioniert nicht für den Task „Kaffeemaschine entkalken“.

 

Kanban erzwingt Transparenz

Das erste heikle Problem kann bei Kanban bereits beim Visualisieren der Arbeitsabläufe auftreten. Was soll man dort modellieren? Der Ablauf nach Prozess X oder das was gelebt wird? Richtig funktionieren wird Kanban nur wenn man die gelebte Realität abbildet. Man kommt nicht umher die Diskrepanzen zwischen Soll und Ist anzugehen und zu schliessen. Kann oder will man dies nicht machen sollte man gleich ganz auf Kanban verzichten. Man erspart sich so endlose Diskussionen.

Arbeitet man im Team warten die nächsten Herausforderungen: Was macht man wenn sich die Tickets immer am gleichen Ort stauen? Wie geht man damit um das sich einzelne Mitglieder nicht beteiligen wollen?

Auch wenn dies nicht ein Kanban spezifisches Problem ist, so wird es hier doch ins Scheinwerferlicht gerückt. Die dadurch erzwungene Transparenz ist eine grosse Chance für Verbesserungen an den Stellen die wirklich einen Einfluss haben. Aber auch dies muss man wollen.

 

WIP-Limits helfen beim fokussieren

Die bewusste Einschränkung auf einige wenige (gleichzeitige) Arbeiten finde ich äusserst hilfreich. Macht man zu viele Dinge nebeneinander kommen zwar immer viele Tasks ein klein wenig voran – aber viel zu oft wird nichts davon wirklich fertig. Investiert man Wochen für Dinge die dann doch alle nur 90% fertig sind ist dies demotivierend.

Kanban zwingt einem mit den WIP-Limits dazu die angefangenen Arbeiten zu vollenden bevor man hinter die nächste Aufgabe geht. Natürlich kann man hier viel tricksen und hohe WIP-Limits setzen.
Nur dadurch bleibt alles wie gehabt und die ganzen Arbeiten sind dann nur teure Mehrarbeit. Aus meiner Erfahrung ist es daher umso wichtiger den Fortschritt regelmässig zu prüfen und stetig an einer Verbesserung zu arbeiten – denn nur so geht es mit den wenigen Regeln von Kanban wirklich vorwärts.

 

Neben den WIP-Limits auch den Prozess optimieren

Für mein Personal-Kanban Board experimentiere neben den WIP-Limits auch mit dem Pro-zess. Da nur ich davon betroffen bin geht dies sehr einfach und ich habe den nötigen Spiel-raum für Veränderungen. Ich kann dies sehr empfehlen, vor allem wenn man ein nicht genauer definierbares Gefühl hat das irgendetwas an den Abläufen noch nicht so ganz passt.

Nach einigem hin und her bin ich nun wieder auf der Startversion von Leankit angekommen, allerdings mit einer zusätzlichen Spalte „this week“. Darin stehen alle Arbeiten die in dieser Woche erledigt werden müssen. Für mich ist die Unterteilung in Wochen hilfreich da ich so einen guten Kompromiss von Freiraum und Einschränkungen habe. Eine Unterteilung nach aktuellem Tag war für mich viel zu eng und bei einem Monat fehlte mir die Fokussierung.

 

Aufwandschätzung minimieren

Ich schätze alle Aufgaben die auf mein Kanban-Board sollen nur minimal ab und nutze dafür diese 3 Grössen:

  • 1 für ganz kleine und schnell zu erledigende Aufgaben
  • 2 für Aufgaben die zwischen 1-2 Stunden brauchen
  • 3 für abendfüllende Aufgaben

Grössere Aufgaben unterteile ich bis diese in eine dieser 3 Schubladen passen. Die Idee dazu kommt vom Messen mit T-Shirt Grössen (S, M, L). Statt 1, 2 oder 3 könnte die Unterteilung auch S, M oder L sein. Da die von mir verwendete Software von Leankit allerdings nur Zah-len als Grösse unterstützt wurde es halt 1, 2 und 3.

Obwohl diese Unterteilung nur sehr Oberflächlich ist kann ich damit recht gut (oder genauer gesagt genügend genau) abschätzen bis wann meine Aufgabenliste abgearbeitet sein wird. Wie ich durch das Messen der erledigten Aufgaben herausfand ist die Schwankung der erledigten Arbeiten von Woche zu Woche deutlich grösser als die Schätzungenauigkeit. Möchte ich eine genauere Vorhersage über den Abschluss eines grösseren Arbeitspaketes haben müsste ich dementsprechend nicht bei den Schätzungen sondern am gleichmässigeren abarbeiten ansetzen.

 

Karten schieben alleine genügt nicht

Obwohl man bei Kanban Karten herum schiebt geht es dabei um weit mehr als nur das schie-ben dieser Karten. Die Karten repräsentieren eine Aufgabe und das herumschieben deren Be-arbeitung. Wenn die Aufgabe keinen Wert hat und nur gemacht wird damit man etwas schie-ben kann hat man das Ziel verfehlt. So ist man zwar beschäftigt, erzielt aber keinen Fortschritt und verschwendet damit nur seine Zeit.

Daher sollte man unbedingt regelmässig überprüfen ob die vorhandenen Karten wirklich noch benötigt werden. Das Backlog muss wie bei Scrum gepflegt werden. Aufgaben die sich erle-digt haben oder nicht mehr benötigt werden sind zu löschen. Also nicht einfach auf die Seite legen oder in einer anderen Liste führen, sondern wirklich unrückholbar löschen. Sollte wirk-lich einmal etwas zu früh gelöscht werden wird diese Aufgabe wieder verlangt werden.

 

Kanban macht die Arbeit nicht alleine

Auch wenn man Kanban einsetzt muss die Arbeit immer noch gemacht werden. Man kommt nicht daran vorbei die Tasks auch wirklich zu bearbeiten. Kanban hilft einem beim Visualisieren der Arbeitsschritte und beim fokussieren – es nimmt einem die Arbeit aber nicht ab.

 

Fazit

Kanban ist kein Allerheilmittel und es gibt Situationen wo der Einsatz kontraproduktiv ist. Will man aber eine Veränderung herbeiführen und glaubt an die schrittweise, inkrementelle Verbesserung ist Kanban ein sehr guter Ansatz.

Um zu starten braucht es wenig und wenn es für einen nicht stimmt kann man ohne grossen Verlust weiter machen wie bisher. Wer eine Verbesserung seiner Arbeitsorganisation möchte soll nicht zögern: Ein Blatt Papier und Post-It Zettel genügen für den Start…

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Buch-Rezension zu „Kanban and Scrum“

Kanban and ScrumKanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin erschien Ende 2009 bei InfoQ. Kanban und Scrum sind 2 Begriffe die im Zusammenhang mit agiler Softwareentwicklung immer häufiger fallen. Aber was ist nun Kanban? Und wie verhält sich dies zu Scrum? Auf diese und noch viele weitere Fragen liefert das Buch auf rund 100 Seiten eine Antwort.

Bei dieser Seitenanzahl darf es einem nicht verwundern wenn man keine umfassende Erklärung in alle Details rund um Kanban und Scrum bekommt. Den Autoren gelingt es aber dennoch alles Wesentliche auf den Punkt zu bringen. Man kann so in kurzer Zeit abschätzen ob Kanban oder Scrum etwas ist was man vertiefter anschauen will.

 

Teil 1: Vergleich von Scrum und Kanban

Im ersten Teil macht Henrik Kniberg einen Vergleich zwischen diesen beiden Ansätzen. Er zeigt objektiv auf was die beiden Modelle für Gemeinsamkeiten haben und wo die Unterschiede liegen. Man merkt schnell das Scrum mehr Regeln mitbringt als Kanban und so viel mehr Einfluss auf den Arbeitsablauf ausübt. Kanban erlaubt einem aber durchaus die Teile von Scrum zu übernehmen die einem dort besonders gefallen.

Dieses Fallweise übernehmen von Vorgaben und Empfehlungen bietet einem eine sehr flexible Lösung. Wem Scrum zu fix ist sollte einen Blick auf Kanban werfen. Und wem Kanban zu wenig konkret ist kann sich bei Scrum umschauen.

 

Teil 2: Detailliertes Fallbeispiel

Mattias Skarin beschreibt im zweiten Teil was für Erfahrungen er machte bei der Einführung von Kanban in einer skandinavischen Firma. Die Entwickler die nach Scrum arbeiten treffen auf den technischen Betrieb, der sowohl die Entwickler unterstützen wie auch den Betrieb aufrecht erhalten soll. Ein sofortiges lösen von Betriebsproblemen lässt sich nur schwer mit den Iterationen von Scrum in Einklang bringen. Kanban dagegen ist flexibel genug um auch solche Dinge zu ermöglichen.

Wo fängt man aber mit Kanban an und wie integriert man es mit Scrum? Skarin beschreibt dies meiner Meinung nach sehr gut: Egal wo wir anfangen, wir werden es ändern müssen. Also beginnen wir einfach und machen Änderungen sobald diese nötig werden.

Ein tägliches Stand-up Meeting, eine Retrospektive am Iterationsende und das Führen eines Impediment Backlog sind Aktivitäten mit denen Kanban in diesem Fallbeispiel angereichert wurde.

 

WIP Limits für schnelles Angehen eines Problems

Unter dem Titel „One day in Kanban-land“ gibt es ein sehr gutes Beispiel zum Wert von WIP Limits (also einer maximal erlaubten Menge von Arbeit die in einem Verarbeitungsschritt gleichzeitig in Bearbeitung sein darf).

Kanban-Board mit WIP

Für die Tätigkeit Entwicklung wurde ein WIP Limit von 2 vorgegeben. Diese Grenze gilt dabei sowohl für das was gerade entwickelt wird wie auch für die Pakete die aufs testen warten. Gibt es im Test (wo das WIP Limit 1 ist) ein Problem staut sich die Arbeit in der Entwicklung. In kurzer Zeit erreichen die Entwickler ihre Grenze und können keine neue Arbeit beginnen. Die so vorhandene Kapazität kann man nun nutzen um die Probleme im Test anzugehen.

Kanban-Board: WIP erreicht

Wird in der Entwicklung nicht die geforderte Qualität erreicht merkt man dies in diesem Beispiel nach dem 3. Arbeitspaket. Man kann so mit einer Verbesserung in der Entwicklung starten wenn der Schaden noch klein ist. Dies ist deutlich billiger und schneller als wenn man dies erst am Ende beim Abnahmetest bemerkt…

 

Download

Das Buch gibt es sowohl als Paperback wie auch als E-Book zum kostenlosen Download. Vom E-Book gibt es mittlerweile zahlreiche Übersetzungen, die leider nicht alle an die Qualität des Originals heran kommen.

 

Fazit

Wer einen Einblick in Kanban haben möchte oder wissen will wo die Unterschiede zu Scrum sind ist mit diesem kleinen Buch sehr gut bedient. Man bekommt in sehr kurzer Zeit alles Wesentliche mit und hat eine gute Grundlage um sich vertieft mit Kanban oder Scrum zu beschäftigen.

 

Zum Buch

Kanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin, 2009 InfoQ, ISBN: 978-0-557-13832-6, 120 Seiten, Englisch

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Werkzeuge für Kanban

Auch bei den Werkzeugen ist Kanban sehr flexibel. Um den Arbeitsablauf (oder Prozess) zu visualisieren benötigt man ein Kanban-Board. Wie dies auszusehen hat und wie man dies organisiert bleibt jedem selber überlassen.
Was für erfahrene Anwender von Kanban sehr praktisch ist stellt Neulinge vor eine Herausforderung. Zu nutzen was für einen am besten passt ist ein gut gemeinter Ratschlag – zu Beginn fehlt einem aber die Erfahrung um damit auch etwas anfangen zu können.

Aus diesem Grund stelle ich heute 4 verschiedene Möglichkeiten für ein Kanban-Board vor, denn es muss nicht immer ein Whiteboard sein. Arbeitet man an verschiedenen Orten oder in Teams ist eine elektronische Lösung oft praktischer. Die Liste hier ist nicht abschliessend und ich würde mich über Kommentare freuen bei denen zusätzliche Möglichkeiten vorgestellt werden. Gleiches gilt für andere Werkzeuge, die einem bei den Arbeitsabläufen unterstützen können.

 

Minimal

Macht man Kanban nur für sich alleine und hat keine grosse Infrastruktur zur Verfügung kann man mit einer ganz minimalistischen Umgebung arbeiten. Im Grunde genügen Post-it Zettel und der eigene Schreibtisch.

So lange man nur wenige Tätigkeiten verwalten will kann man jeden Task einzeln auf einen Post-it Zettel schreiben. Was links von einem auf dem Schreibtisch klebt ist zu tun, das was man direkt vor sich hat ist in Arbeit und was rechts klebt ist erledigt. Die gleichzeitig bearbeiteten Aufgaben minimiert man in dem man bewusst nur dann eine zusätzliche Aufgabe startet wenn das gesetzte WIP-Limit noch nicht erreicht ist.

Nutzt man verschiedene Farben für unterschiedliche Prioritäten kann man recht einfach seine Arbeiten auswerten. Waren die meisten Arbeiten ganz dringende ungeplante Tätigkeiten kann man für die nächste Woche seine Erwartungen hinsichtlich dem Fortschritt der Taskliste entsprechen anpassen.

Mit dieser Minimalversion kann man einen Prozess beschreiben (bereit, in Arbeit, erledigt), eine WIP-Limite setzen und bekommt Feedback für Verbesserungen. Auswertungen müssen hier alle von Hand gemacht werden, dafür benötigt man fast keine Infrastruktur.

 

Whiteboard

Der Klassiker für Kanban ist ein Whiteboard und Post-it Zettel. Gibt es einen zentralen Ort der für alle Kanban-Teilnehmer gut zu erreichen ist empfiehlt sich dieser Ansatz. Die Post-it-Zettel kommen auch hier zum Einsatz, da sie sehr flexibel sind und beliebig beschrieben werden können.

Gegenüber der Minimalversion ist ein Whiteboard übersichtlicher und bietet mehr Platz. Dies ist gerade für komplexere Abläufe sehr hilfreich. WIP-Limits lassen sich für alle sichtbar oberhalb der einzelnen Spalten aufschreiben.

So lange man keinen Permanent-Marker verwendet lassen sich die Unterteilungen schnell an die neuen Gegebenheiten anpassen.

Der Arbeitsablauf ist hier wie auch bei den anderen Ansätzen immer gleich: Tasks werden am linken Rand eingefügt, schrittweise nach rechts über das Board gezogen und sind am Ende bereit für eine Archivierung.

 

LeanKit Kanban

Bei grösseren Teams oder wenn man immer und von überall her zugreifen will sind elektronische Kanban-Boards eine gute Wahl. LeanKit bietet eine webbasierte Lösung die für bis zu 3 Benutzer kostenlos ist.

Lean ist dabei nicht nur Teil des Herstellernamens, sondern findet sich auch im Produkt wieder. Mit sehr wenig vorarbeiten (Seite aufrufen und registrieren) ist man gleich soweit um mit Kanban zu beginnen. Standardmässig besteht das Board aus den Spalten „TODO„, „DOING“ und „DONE“ sowie dem Backlog und dem Archiv. Neue Karten kann man über den Knopf „New Card“ erzeugen und schon ist man bereit um die Karte mit der Maus über das Board zu bewegen.

Leankit

Mit gefallen an diesem Dienst die vielen einfachen Anpassungsmöglichkeiten. Die Spalten mit ihren WIP-Limits lassen sich sehr einfach verändern und neue Kategorien sind schnell erzeugt. Bei all dieser Personalisierung darf natürlich eine Auswertung nicht fehlen. Bei allen Aktionen durch die Benutzer werden im Hintergrund die Kennzahlen nachgetragen. Egal ob WIP-Limit Verstösse, Lead-Time Veränderungen oder der Arbeitsfortschritt – alles lässt sich einfach auswerten und in einem Report darstellen.

Leankit_Stats

 

Flexilio

Wie LeanKit Kanban ist Flexilio eine Webapplikation. Obwohl beide Anwendungen ein Kanban-Board implementieren haben sie diese Aufgabe ganz unterschiedlich umgesetzt.

Bei Flexilio dreht sich alles um Projekte und (User-) Stories. Eine Story gehört zu einem Projekt und wandert vom Backlog aufs Board und nach der Bearbeitung ins Archiv. Auf dem Board kann man für jede Story beliebig viele Tasks erzeugen diese dann einzeln durchs Board bewegen.

Flexilio

Flexilio zeigt einem immer direkt an zu welcher Story ein Task gehört. Wenn man Story-orientiert arbeitet ist es so viel einfacher die Übersicht zu behalten als bei LeanKit. Dafür muss man bei Flexilio aber immer zuerst eine Story haben bevor man einen Task erzeugen kann.

 

Fazit

Bei Kanban kann man die Werkzeuge einsetzen die am besten zu den eigenen Anforderungen passen. Ob dies eine ganz minimale Implementierung, ein Whiteboard oder eine elektronische Lösung wie LeanKit oder Flexilo ist – wenn es passt soll man es verwenden.

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Buch-Rezension zu „Kanban“

Kanban: Successfull Evolutionary Change for your Technology Business“ von David J. Anderson gilt als Standardwerk zu Kanban. Anderson gelang es als einem der ersten das in der Produktion beheimatete Kanban auf die Softwareentwicklung zu übertragen.

 

Einführung & Nutzen von Kanban

Im ersten Teil zeigt Anderson was er alles für Methoden versuchte bevor er bei Kanban angelangt ist. Diese Einführung hilft einem den Kontext zu sehen und festzustellen ob man die gleichen Probleme zu lösen versucht. Sollte dies nicht der Fall sein ist Kanban wohl nicht die passende Lösung.

Im zweiten Teil wird erklärt was Kanban ist und auf was man bei der Implementierung achten soll. Anderson erklärt sehr verständlich wieso man die WIP-Limits (Work in Progress) tief setzen soll und wie man dadurch den Durchsatz erhöhen kann.

Das Kaizen (die kontinuierliche Verbesserung) nicht nur eine Worthülse sein muss wird an mehreren Beispielen aufgezeigt. Gerade wenn das gegenseitige Vertrauen fehlt kann durch eine stetige Lieferung und Verbesserung der Abläufe gezeigt werden dass man es ernst meint mit der Zusammenarbeit.

 

Kanban implementieren und verbessern

Nach dem das Wieso geklärt wurde geht es im dritten Teil ums Wie. Dies beginnt ganz simpel mit dem Aufbau des Kanban-Boards und wie man seinen Prozess darauf abbilden kann. Die Hinweise zum Setzen von Grenzen sollte man unbedingt beachten, da man sich so viel unnötigen Aufwand ersparen kann. Es folgt eine Erklärung zum Aufbau der einzelnen Karten und wie man diese durchs Board bewegt.

Obwohl Kanban nicht festlegt wie man das Board befüllen soll stellt Anderson einige praxisgetestete Ansätze vor. In einem seiner Beispiele konnte auf die aufwändige Schätzung der einzelnen Tasks verzichtet werden und hatte so mehr Zeit zum Erledigen der nötigen Arbeiten.

Ein ganzes Kapitel widmet sich den Kennzahlen die man bei Kanban messen kann. Dies umfasst das überwachen der WIP-Limiten, der Lead Time und geht bis zum messen des Durchsatzes. Die so gewonnenen Werte sollen wiederum mittels Kaizen stetig verbessert werden. Wie man dies genau angehen kann zeigt der vierte und letzte Teil.

 

Takeaways & Beispiele

Ich fand die Auflistung der wichtigsten Punkte am Ende jedes Kapitels äusserst praktisch. Die Zusammenfassung ist eine gute Erinnerung an das was man gerade alles gelesen hat und hilft einem auch später wenn man etwas Bestimmtes finden will.

Anderson hat einige sehr passende Beispiele gefunden um seine Ideen zu erklären. Das Kanban nicht nur mit Produktionssystemen benutzt werden kann zeigt er am Einlasssystem des Imperial East Gardens in Tokyo. Dort werden Kanban-Karten als Limitierung der Besucher verwendet. So lange es Karten hat können Besucher den Park betreten. Sind die Karten weg muss gewartet werden bis andere Besucher den Park verlassen haben. Ein ganz simples System das Kanban nutzt und mit wenig Verwaltungsaufwand auskommt.

Ein anderes Beispiel das mir besonders in Erinnerung blieb zeigt den Unterschied von Durchsatz und Kapazität anhand einer Autobahn. Die maximale Anzahl von Autos die auf einem Strassenstück stehen können erreicht man wenn man ein Auto hinter das andere stellt. Nur hat man so einen Parkplatz und der Durchsatz ist entsprechend gering.

 

Was fehlt

Anderson ist von Kanban überzeugt und hat damit mehrmals erfolgreich Teams neu organisiert. Ich hätte es begrüsst wenn auch ein Beispiel gezeigt würde wo Kanban nicht funktionierte. Kanban ist schliesslich keine Allzwecklösung und durch entsprechende Beispiele könnte man besser abklären ob Kanban für die eigene Situation wirklich passt.

Was leider auch fehlt ist der Hinweis dass man mit Kanban nicht gleich im ganzen Team starten muss. Dies macht vor allem dort Sinn wo es grosse Wiederstände gegen alternative Ansätze gibt und man mit dem eigenen Projekt die Machbarkeit „beweisen“ soll.

 

Fazit

Die vielen praktischen Beispiele und ausführlichen Erklärungen helfen einem die simplen Regeln von Kanban mit den komplexen Vorgängen der Softwareentwicklung zu verbinden. Die Tipps aus der Praxis helfen einem dabei mit Kanban zu starten und schrittweise die eigenen Abläufe zu verbessern.

Für mich ist dieses Buch ein Must-Read wenn man sich mit Kanban in der Softwareentwicklung beschäftigen will.

 

Zum Buch

Kanban: Successfull Evolutionary Change for your Technology Business“ von David J. Anderson, 2012 Blue Hole Press, ISBN 978-0984-5214-01, 278 Seiten, Englisch

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Durchstarten mit Kanban

Kanban ist eine Methode zur Arbeitsorganisation. Dies tönt erst einmal langweilig und formal. Zu viele Methoden haben uns erzählt dass wir alles falsch machen und unsere lieb gewonnenen Eigenheiten aufzugeben haben.

Kanban ist anders: Es gibt fast keine Regeln, Flexibilität ist nicht nur ein Stichwort und man kann ohne grossen Bruch mit dem Status Quo an einer Verbesserung arbeiten. Und will man schneller und aggressiver eine Veränderung herbeiführen ist auch dies machbar – aber man wird für einmal nicht dazu gezwungen.

In dieser Serie will ich Kanban näher bringen und zeigen was mir daran so gefällt. In den folgenden Beiträgen werde ich Werkzeuge vorstellen und Tipps für den Start mit Kanban geben. Aber beginnen wir erst einmal mit dem Grund wieso man Kanban anschauen soll und überprüfen wir meine Aussage von den wenigen Regeln.

 

Weil ToDo-Listen nicht genug sind

ToDo-Listen haben für mich nie wirklich funktioniert. Kaum hatte ich die Liste geschrieben gab es neue Dinge die noch hinein mussten. War im ersten Durchgang alles schön nach Priorität sortiert hatte ich so gleich das erste Durcheinander. Weder immer wieder die Liste neu zu erstellen noch eine Vergabe von Prioritäten hat für mich funktioniert. Nach kurzer Zeit habe ich aufs führen einer Liste verzichtet. Es ging ja auch ohne und war erst noch viel besser.

Schreibt man die Arbeiten nirgends auf hat man das nächste Problem: Entweder gehen sie vergessen oder man muss ständig daran denken. Beides ist nicht wirklich angenehm. Nach etlichen Versuchen mit alternativen Methoden landete ich schliesslich bei Kanban.

 

Regeln

Kanban verfügt über sehr wenig Regeln. Genau genommen sind es sogar nur 2:

  1. Visualisiere den Workflow
  2. Limitiere die gleichzeitige Arbeit

Durch die Visualisierung des Arbeitsflusses sieht man auf einen Blick wo die Arbeit liegt. Limitiert man die Arbeit an der man gleichzeitig ist kann man sich auf die wichtigen Tätigkeiten fokussieren. Für mich gibt es noch eine weitere Regel die ich für einen erfolgreichen Einsatz von Kanban als nötig erachte:

  1. Überprüfe den Fortschritt

Ohne diesen Zusatz fehlt einem die Motivation für eine Verbesserung. Der dafür häufig verwendete japanische Begriff ist Kaizen und meint die stetige Verbesserung (auch in ganz kleinen Schritten).

 

Mit Kanban starten

Für den Start in Kanban empfiehlt es sich die eigenen Arbeiten zu verwalten. So kann man die ersten Erfahrungen sammeln ohne gleich die ganze Umwelt mit einem halb verstandenen Konzept zu überrennen.

Zu Beginn genügen kleine Post-It Zettel und ein Blatt Papier. Das Papier dient als Kanban-Board und wird in 3 Bereiche unterteilt:

Initiales Kanban-Board

Nach der Visualisierung geht es nun an die Limitierung der gleichzeitigen Arbeit. Dies wird als WIP-Limit bezeichnet, wobei WIP für Work in Progress steht. Man sollte sich für den ersten Versuch nicht zu viele Gedanken über die Limiten machen. Diese kann man gleich wie die Spalten später immer noch anpassen. Um zu beginnen kann das Limit für die Spalte in Arbeit auf 3 gesetzt werden.

Kanban-Board mit WIP-Limite

Als nächstes werden alle Arbeiten die anstehen auf die Post-It Zettel geschrieben – pro Zettel nur 1 Aufgabe. All diese Zettel landen in der Spalte Bereit. Fürs erste kann man sowohl auf eine Aufwandsschätzung wie auch auf eine Priorisierung verzichten. Es geht vorerst einmal darum zu sammeln. Durch die Regel 3 kann man später immer noch darauf zurückkommen – falls man dies noch als wichtig erachtet.

Kanban Tasks erfassen

Mit allen offenen Arbeiten vor sich wählt man nun die Arbeit aus, die man jetzt beginnen kann und die am wichtigsten ist. Diesen Zettel zieht man in die Spalte in Arbeit und beginnt mit der Arbeit. Ist man damit fertig zieht man den Zettel in die Spalte Erledigt. Diesen Ablauf wiederholt man bis alle Arbeiten durchs Board gezogen wurden und erledigt sind.

Mit der Arbeit beginnen

Dieses ziehen macht das Pull-Prinzip aus. Wenn ich über freie Kapazität verfüge hole ich mir eine neue Arbeit. Im Gegensatz zum Push-Prinzip wo mir von aussen Arbeiten zugeschoben werden – unabhängig davon ob ich überhaupt Zeit dafür habe.

 

Blockierte Arbeiten

So einfach wie gerade beschrieben wird man wohl nicht arbeiten können. Oft geht es nicht lange und man ist blockiert. In dem Fall prüft man ob das WIP-Limit erreicht ist. Hat man noch freie Kapazität holt man die nächste Aufgabe in die Spalte in Arbeit und beginnt mit dieser. Wird man auch bei dieser Arbeit blockiert wiederholt man diesen Ablauf so lange das WIP-Limit nicht erreicht ist. Bevor man zusätzliche Arbeiten beginnt sollte man aber überprüfen ob sich eine Blockade mittlerweile aufgelöst hat.

Ist das WIP-Limit erreicht muss man die Ursachen der Blockaden angehen. Erhöht man einfach das WIP-Limit hat man in kürzester Zeit nicht nur 3 blockierte Aufgaben, sondern 10 oder 20.

Kanban-Board blokiert

Die Ursache hinter den Blockaden herauszufinden ist oft nicht einfach. Vorgehensweisen wie die 5-Whys können einem mit überschaubarem Aufwand an die Quelle der Probleme führen. Bleibt auch dies ohne Erfolg hat man immer noch die Möglichkeit das WIP-Limit zu erhöhen.

 

Wie Priorisieren und Aufwand schätzen?

An der Art wie man die Aufgaben priorisiert oder auch den Aufwand schätzt ändert sich mit Kanban nichts. Man kann genau so weiter machen wie man es sich gewohnt ist. Erst beim abarbeiten sollen nur noch so viele Aufgabenangegangen werden wie es das WIP-Limit erlaubt.

Nutzt man die Anzahl Karten als WIP-Limit braucht man die Aufwände der einzelnen Arbei-ten nicht extra zu schätzen. Bei der Priorisierung kann man es sich ebenfalls einfach machen und die Arbeiten in der Reihenfolge angehen, wie diese in der Spalte Bereit aufgelistet sind. Eine Repriorisierung der Aufgaben beschränkt sich so auf das Verschieben der Karten an die passende Stelle.

All dies ist nicht nur erlaubt sondern man soll auch explizit alles nutzen, was einem bei der Produktivitätssteigerung hilft. Ein anpassen und erweitern ist keine Verletzung der Prinzipen von Kanban sondern explizit gewünscht.

 

Zusätzliche Arbeit

Sobald man mit der einen Aufgabe begonnen hat taucht schon bald die nächste noch wichtigere Arbeit auf. Im Gegensatz zu Scrum kann jederzeit eine neue Aufgabe aufgenommen werden. Ist das WIP-Limit noch nicht erreicht könnte man gleich mit der neuen Aufgabe beginnen, andernfalls landet diese in der Spalte Bereit.

Diese Flexibilität ist besonders für Software-Projekte hilfreich bei denen sich das gleiche Team um die Entwicklung und den Betrieb kümmert. Kanban geht auf diese Bedürfnisse ein und ermöglicht eine komplette Rundumsicht auf alle gemachten arbeiten.
So zeigt das Kanban-Board auf den ersten Blick wie viele Supportfälle angefallen sind und wie viel Zeit die Entwickler mit dem Lösen von Produktionsproblemen verbringen.

 

Wo anfangen?

Wie bereits erwähnt fängt man am besten mit seinen eigenen Tätigkeiten an. Dazu braucht man nicht mit den bestehenden (teamweit) verwendeten Werkzeugen zu brechen. Es genügt vollends die Aufgaben die einem zugewiesen wurden auf dem eigenen Kanban-Board unter Bereit aufzulisten, bei in Arbeit ein passendes WIP-Limit zu setzen und mit der Abarbeitung zu beginnen.

Dieser kleine Schritt ermöglicht einem Kanban ohne grossen Aufwand auszuprobieren. Selbst mit so einer kleinen Anwendung kann man von der Fokussierung auf die wichtigen Tätigkeiten profitieren. Wenn Kanban einem gefällt ist es ein kleiner Schritt all seine Aufgaben zu erfassen. Und wenn nicht kann man das Experiment beenden ohne viel zu verlieren.

Kanban-Board: Arbeiten erledigt

 

Ausblick

In der nächsten Folge werde ich das Buch „Kanban“ vorstellen. Darin wird von David J. Anderson gezeigt dass Kanban nicht nur in der Produktion von Fahrzeugen sondern auch für die Software-Entwicklung sehr gut geeignet ist.

 

Kanban Serie

Falls dieser Beitrag ihr Interesse geweckt hat sollten Sie einen Blick auf die übrigen Folgen dieser Kanban Serie werfen:

  1. Durchstarten mit Kanban
  2. Buch-Rezension zu “Kanban”
  3. Werkzeuge für Kanban
  4. Buch-Rezension zu “Kanban and Scrum”
  5. Erfahrungen mit Kanban

 

Die Testpyramide

Seit einigen Monaten stosse ich immer wieder auf das Konzept der Testpyramide. Ich finde dieses Bild sehr passen, da es die wesentlichen Aspekte auf den Punkt bringt. Um ein System wirklich zu testen gilt es mehrere Ebenen anzuschauen. Die Testpyramide zeigt diese auf und vermittelt auf eine leicht verständliche Weise wie sich die Anzahl der Testfälle staffeln soll:

Die Testpyramide

 

Unit-Tests als Grundlage

Unit-Tests bilden die Basis der Testpyramide. Die kleinstmöglichen Tests sollten sicherstellen dass das System im Kern funktioniert. Eine wichtige Eigenschaft von Unit-Tests: Sie sind Schnell. In wenigen Sekunden sollte man wissen ob es überhaupt Sinn macht die länger laufenden Tests zu starten. Diese Sekunden sind wohlgemerkt nicht für einen einzigen Tests gedacht, sondern für alle Unit-Tests zusammen – womit ein Unit-Test der länger als 1/100 Sekunde dauert schon als langsam gelten muss.

Damit Tests so schnell sind dürfen sie nur wenig testen. Weder eine Verbindung zur Datenbank noch ein Zugriff aufs Dateisystem oder Aufruf eines Webservices ist erlaubt. All diese Abhängigkeiten müssen entfernt werden. Ob dies mittels Konfiguration oder mit Mocks gemacht wird spielt dabei keine Rolle.

Die Geschwindigkeit alleine kann aber nicht das einzige Kriterium für einen Unit-Test sein. Sonst besteht die Testsuite am Ende nur aus leeren Methoden. Das was man testet soll auch noch Sinn machen. Und einem in die richtige Richtung weisen wenn einmal ein Test fehlschlägt. So ist man schnell einmal bei mehreren Kriterien die von Ben Rady und Rod Coffin in „Continuous Testing“ mit dieser Abkürzung zusammengefasst werden:

FIRE: Fast, Informative, Reliable and Exhaustive

 

Integrationstests

Zu wissen dass der eigene Code für sich alleine funktioniert ist ein Anfang. Damit weiss man aber noch nicht ob der Code auch mit anderen Teilen funktioniert. Hier kommen die Integrationstests ins Spiel.

Auf dieser Ebene werden all die Abhängigkeiten angeschaut die man bei den Unit-Tests entfernt hat. Was zuerst nach vermeidbarem Zusatzaufwand aussieht hat sehr wohl seine Berechtigung. Es genügt wenn man das Erzeugen, Speichern, Aktualisieren und Löschen eines Objekts in der Datenbank ein Mal pro Klasse testet. Dies hat die gleiche Aussagekraft (ist aber deutlich schneller) wie wenn man in allen Unit-Tests immer mit den Objekten aus der Datenbank arbeiten würde.

Da weniger Tests mit den Umsystemen nötig sind wirkt sich deren Ausführungsdauer nicht so stark auf die Länge des gesamten Testlaufs aus.

 

Akzeptanztests

Die Akzeptanztests bilden die Spitze der Testpyramide. Hier gilt es die Anwendung aus Sicht des Benutzers zu testen. Vom GUI durch die Geschäftslogik hin zur Datenbank und den externen Webservices soll hier alles geprüft werden.

Da man bereits weis das sowohl der Kern der Anwendung funktioniert und der auch mit den Umsystemen korrekt zusammenarbeitet benötigt man nur noch wenige Akzeptanztests. Diese dürfen noch einmal langsamer sein als die Integrationstests und sollen als letzte Stufe die Korrektheit der gesamten Anwendung belegen.

Und da es so wenige Tests sind kann man diese auch mit dem Kunden/Endbenutzer besprechen. Müssen wirklich nur die wichtigsten Tests angeschaut werden hat man gute Chancen dass dies auch wirklich gemacht wird.

 

Reihenfolge & Einschränkungen

Die Testpyramide gibt keine Reihenfolge für die Erstellung der Testfälle vor. Wenn es bei der Ausführung auch am meisten Sinn macht mit den Unit Tests zu beginnen so ist man beim Erstellen frei.

Hat man Glück und der Kunde will an Akzeptanztests mitarbeiten kann man einen Top-Down Ansatz wählen. Man beginnt mit einem fehlgeschlagenen Akzeptanztest und schreibt so lange Integrations- und Unit-Tests bis dieser erfüllt wird. Alternativ kann man aber auch mit den Unit-Tests beginnen und sich nach oben arbeiten.

Die Testpyramide ist aber nicht perfekt. Es gibt etliche Testarten die darin keinen Platz finden. Wo platziert man beispielsweise die Explorationstests? Oder die Performancetests? Trotz dieser Einschränkungen finde ich das Bild der Testpyramide sehr gelungen.