"Java by Comparison" von Simon Harrer, Jörg Lenhard und Linus Dietz erschien 2018 bei The Pragmatic Programmers. Dieses Buch wagt sich an eine grosse Herausforderung: Wie kann man das über Jahre angeeignete Expertenwissen in einfacher Form Programmier-Anfängern zugänglich machen?
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. In der neusten Version kommt nun das Thema der technischen Schulden grosse Beachtung. Ein leicht zu verstehender Indikator liefert einem schnell einen Wert um Projekte untereinander zu vergleichen. Genau so etwas hatte ich bereits in meinem ersten Beitrag dazu gewünscht.
Mit dem neuen Jahr wird es auch wieder Zeit für eine Aktualisierung meines Technologieradars. Nach den Ausgaben für 2014 und 2015 verzichtete ich auf eine Ausgabe für 2016. Die grossen Ankündigungen von Microsoft (wie ASP.Net vNext) verzögerten sich und nur die Jahreszahl anzupassen war mir zu wenig.
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 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.
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.
"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.
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.
Ein gutes Buch über objektorientiertes Design (OOD) zu finden ist nicht einfach. Obwohl sich viele Bücher diesem Thema widmen fehlt doch immer wieder etwas: Entweder ist das Buch so theoretisch das es keinen Bezug zur Praxis hat oder die notwendige Theorie fehlt.
"Practical Object-Oriented Design in Ruby" (kurz POODR) von Sandi Metz findet den Mittelweg zwischen Theorie und Praxis. In einer direkten Sprache wird man Schritt für Schritt an die Thematik OOD herangeführt. Auch wenn die Beispiele in Ruby sind so ist dieses Buch auch für andere Sprachen sehr zu empfehlen – das benötigte Wissen über Ruby ist minimal und schnell erklärt.
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:
