Archiv

Posts Tagged ‘Bücher’

Buch-Rezension zu “Training Guide: Programming in HTML5 with JavaScript and CSS3″

21. Mai 2014 Kommentare aus

HTML5 & CSS3 Training GuideWer sich für die Zertifizierung 70-480 “Programming in HTML5 with JavaScript and CSS3″ vorbereitet trifft bald einmal auf den gleichnamigen Training Guide von Glenn Johnson. Dieser ist nicht nur auf der offiziellen Seite zur Prüfung als Vorbereitungsmaterial aufgeführt, sondern folgt auch dem Aufbau der Trainingsbücher von Microsoft Press für die .Net 4 Zertifizierungen.

Diese Bücher waren mal besser und mal schlechter geeignet
um neben der Prüfung auch im Praxisalltag eingesetzt zu werden. Man konnte sich damit aber immer gut auf die Zertifizierung vorbereiten. Mit diesem Training Guide ist dies leider nicht der Fall.

 

Prüfungsumfang nicht abgedeckt

Noch im Intro gibt es einen kleinen und wichtigen Hinweis der gerne überlesen wird:

This book covers some of the topics and skills that are the subject of the Microsoft certification exam 70-480. If you are using this book to complement your study materials, you might find this information useful. Note that this book is designed to help you in the job role; it might not cover all exam topics.

Wie gross die Lücke zwischen Training Guide und Prüfung ist hängt von der Interpretation der bewerteten Fähigkeiten ab. Man wird aber kaum um zusätzliche Bücher und viel eigenen Code herumkommen um sich gut vorzubereiten.

Da das Buch aber dennoch sehr auf die Prüfung fokussiert ist sind in der Praxis zusammenhängende Arbeiten über mehrere Kapitel verstreut. Ein ständiges hin und her ist damit unvermeidlich und schmälert den Nutzen abseits der Zertifizierung erheblich.

 

Zielpublikum?

Bisher ist mir nicht klar an wen sich dieses Buch eigentlich richtet. Als Vorbereitung für die Prüfung fehlt zu viel, für den Praxisalltag passt die Struktur nicht. Da die Grundlagen ebenfalls nur unzureichend behandelt werden ist es auch nicht als Einstiegsbuch in die Themen HTML5 und CSS3 geeignet.

Übrig blieben somit noch die Entwickler die ihre ModernUI-Anwendungen nicht mehr in C# sondern in HTML5 und JavaScript schreiben wollen. Allerdings wird dieses Thema nur im 1. Kapitel behandelt und was dort steht hilft einem auch nur bei der Auswahl der richtigen Visual Studio Version.

 

Alternativen

Als zwingende Ergänzung und je nach Wissensstand auch als Alternative kann ich diese Bücher empfehlen:

In diesen 3 Büchern wird weit mehr behandelt als für die Zertifizierung notwendig ist, allerdings helfen einem diese Konzepte wartbaren Code zu schreiben. Den Zeitaufwand dürfte man so schnell eingespart haben.

 

Fazit

Trotz zahlreicher guter Erklärungen kann ich dieses Buch nicht weiterempfehlen. Der mit dem Titel implizierte Hauptzweck der Prüfungsvorbereitung wird zu wenig umgesetzt und als Praxisbuch sind die behandelten Themen zu verzettelt.

Wer sich weder für die Zertifizierung noch für Windows Store Apps interessiert findet mit “HTML 5 and CSS 3” eine deutlich bessere Alternative.

 

Zum Buch

Training Guide: Programming in HTML5 with JavaScript and CSS3” von Glenn Johnson, 2013 Microsoft Press, ISBN 978-0-7356-7438-7, 682 Seiten, Englisch

Schlagworte: , , ,

Buch-Rezension zu “HTML5 and CSS3 (2nd edition)”

26. März 2014 2 Kommentare

HTML5 and CSS3HTML5 und CSS3 sind in aller Munde. Wo man auch hin sieht findet man schöne Beispiele die mit den neusten Browser-Versionen wunderbare Möglichkeiten bieten. Was aber macht man wenn die eigenen Seitenbesucher noch mit IE 8 unterwegs sind? Verzichtet man auf diese Möglichkeiten? Oder bastelt man eine Umgehungslösung?

Brian Hogan lieferte mit seinem Buch “HTML5 and CSS3” ein praxisbezogenes Handbuch um auch in solchen Situationen zu bestehen. Er beschreibt leicht verständlich den aktuellen Stand der HTML5 Spezifikation und wie man diesen in die eigene Webseite integriert. Dabei legt er sehr grossen Wert auf die Abwärtskompatibilität und erklärt eingehend wie man mittels Modernizr ein vergleichbares Verhalten auch für ältere Browser anbieten kann.

Seine Beispiele haben mir sehr geholfen um mich ins Thema HTML5 einzuarbeiten. Da diese nur genau das jeweils besprochene Feature behandeln musste ich nicht lange den Code nach den richtigen Anweisungen durchsuchen. Dies ist vor allem beim erweitern der eigenen Webanwendung sehr hilfreich. Da hat man meistens nicht Zeit um zahlreiche Beispiele nochmals nachzuvollziehen nur um die 2-3 Zeilen Code zu finden, die einem noch fehlen. Wer sich selber von den Beispielen überzeugen will findet diese bei PragProg.com.

Wer allerdings noch nie etwas mit HTML gemacht hat wird mit diesem Buch nicht glücklich. Dies ist definitiv kein Einsteigerbuch sondern richtet sich an Leute die über Erfahrung mit HTML 4 verfügen und möglichst auch schon jQuery verwendet haben. Erfüllt man diese Voraussetzungen führt aus meiner Sicht kein Weg an diesem Buch vorbei.

 

Fazit

Weder ist HTML5 nur unnötiger Schnickschnack noch braucht man zwingend den neusten Browser. Mit ein wenig Rücksichtnahme kann man sehr wohl die neuen Möglichkeiten von HTML5 und CSS3 auch für “richtige” Web-Anwendungen nutzen.

Das Buch von Brian Hogan liefert einem die nötigen Grundlagen um ohne grosses googeln loszulegen. Da seine Beispiele sehr praxisrelevant sind eignen sie sich auch gut um den eigenen Code darauf aufzubauen. So kann man schnell erste Ergebnisse erzielen und schrittweise die eigenen Anwendungen Richtung HTML5 weiterentwickeln.

 

Zum Buch

HTML5 and CSS3 (2nd edition)” von Brian P. Hogan, 2013 The Pragmatic Programmers, ISBN 978-1-9377-8559-8, 300 Seiten, Englisch

Schlagworte: , ,

Buch-Rezension zu “Code Complete 2nd Edition”

4. März 2014 Kommentare aus

Code Complete 2nd editionCode Complete – A Practical Handbook of Software Construction (2nd edition)” von Steve McConnell gilt als Standardwerk das man unbedingt gelesen haben muss. Es behandelt alle wichtigen Themen der Softwareentwicklung und gewann zahlreiche Preise.

Nach langem fand ich doch noch die Zeit um dieses Buch zu lesen. Allerdings fragte ich mich sehr bald ob die Empfehlungen auf Amazon vom gleichen “Code Complete” handeln. Entgegen der weit verbreiteten Meinung hatte ich kein praktisches Handbuch vor mir, sondern die ausführlichste Auflistungen von Studien die ich je gesehen habe. Nach zahlreichen weiteren Entdeckungen kann ich von diesem Buch nur abraten.

 

Solider 1. Eindruck

Liest man das Inhaltsverzeichnis durch sieht man dass alle wesentlichen Teile der Erstellung von Software in diesem Buch behandelt werden. Wie McConnell im Vorwort schreibt geht es ihm um eine ausgewogene Diskussion und nicht um Hype. Dies tönt vielversprechend und durchs ganze Buch hinweg untermauert er seine Aussagen mit Studien.

Die zahlreichen Diagramme helfen einem beim Verstehen der gerade vorgestellten Ideen und die Checklisten sind ein guter Ausgangspunkt um die gewonnenen Erkenntnisse im eigenen Code umzusetzen.

Versucht man allerdings mit dem Buch zu arbeiten bemerkt man schnell die ersten Probleme.

 

Genauer hingeschaut

Die objektive und ausgewogene Diskussion erreicht McConnell durch das Referenzieren von Studien. Über die ersten Kapitel hinweg erweckt dies einen sehr professionellen Eindruck. Bis man feststellt das McConnell einen Artikel eines gewissen “McConnell, S.” zitiert. Einen eigenen Artikel zu zitieren ist ja kein Problem, doch sollte man auf diesen Punkt hinweisen. Dies wäre besonders wichtig wenn es sich um ein eher kontroverses Thema handelt und der eigene Artikel der einzige Text ist der die eigene These stützt.

Richtig interessant wird es aber erst wenn die einzige Studie zu einem Thema unübersehbar falsch ist. Auf Seite 518 werden die Fehlerarten gemäss der Studie von Boris Beizer von 1990 aufgeführt. Es wurde dabei so genau gearbeitet dass die Prozentwerte auf 2 Nachkommastelen genau ausgewiesen werden. Dies obwohl die Studie nur die Resultate anderer Studien kombinierte und deren Werte mehr als 50% voneinander abweichen. Auf all diese Fehler weist McConnell explizit hin. Seine Schlussfolgerung daraus ist, die Werte mögen so nicht stimmen aber die Richtung ist in Ordnung. Er verwendet diese Werte danach um seinen Punkt zu beweisen – allerdings ohne die Nachkommastellen…

Wenn man so mit Studien arbeitet kann man auch gleich darauf verzichten. Dieses Beispiel ist das offensichtlichste, allerdings gibt es noch zahlreiche weitere Stellen wo die Resultate so lange verdreht werden bis der gewünschten Punkt „bewiesen“ ist.

 

Zu kurz

Obwohl das Buch rund 960 Seiten hat ist es viel zu kurz um die Fülle an Themen auch wirklich zu erklären. Lässt man das Vorwort, den Anhang, die einzelnen Verzeichnisse, die Checklisten und die Zusammenfassungen weg bleiben für jedes der 35 Kapitel nur noch 20 Seiten übrig. Das reicht in der Regel nur um das jeweilige Thema kurz anzuschneiden.

Besonders deutlich wird dies beim Kapitel “Refactoring“. Die Gründe für Refactoring werden von McConnell sehr gut dargelegt, gleiches gilt für mögliche Strategien. Wie man allerdings den eigenen Code umbauen soll bleibt unklar. Zu mehr als 2-3 Sätzen pro Refactoring-Technik reicht der Platz in diesem Kapitel nicht. Der Praxisnutzen ist dementsprechend gering und das Vorgehen für Refactorings erschliesst sich nur den Lesern, die den zu vermittelnden Inhalt bereits kennen. Da könnte man das Kapitel eigentlich gleich ganz weg lassen.

Leider ist dieser Platzmangel nicht auf ein Kapitel beschränkt sondern zieht sich durchs ganze Buch.

 

Wo es gefährlich wird

Der lockere Umgang mit Studien und der zu knappe Platz um ein Thema wirklich zu erklären birgt ein grosses Gefahrenpotential. Dies wird besonders bei den Kapiteln 25 und 26 deutlich, wo das Thema “Code-Tuning” behandelt wird.

Nach einem Hinweis über die Wichtigkeit von Messungen zu Beginn der Optimierung (Baseline) beginnt eine kaum enden wollende Reihe von Mikro-Optimierungen. Ist es schneller eine Schlaufe zum zuweisen der Array-Werte zu verwenden oder sollte man diese einzeln aufschreiben? Soll man bei verschachtelten Schlaufen zuerst über die innere oder über die äussere Schlaufe iterieren?
Zu all diesen Fragestellungen gibt es einen Codeschnipsel und eine Tabelle. Je nach Sprache und Problem variiert die Grösse der Einsparmöglichkeiten oder ist sogar negativ. Es fehlt einzig ein Hinweis wie diese Werte zustande kommen.

Erst nach gut 50 Seiten dieser Mikro-Optimierungen erklärt McConnell wie er diese Werte berechnet hat:

[For the first edition] I ran most of the tests in this chapter 10‘000 to 50‘000 times to get meaningful, measurable results. For this edition I had to run most tests 1 million to 100 million times. When you have to run a test 100 million times to get measurable results, you have to ask whether anyone will ever notice the impact in a real program.

Diese Fragestellung hätte McConnell zu Beginn des Kapitels aufwerfen müssen. So allerdings erklärt man den Lesern erst ausführlich wie gross die Unterschiede zwischen den einzelnen Varianten sind obwohl diese in der Realität keine Bedeutung haben.
In der Folge davon darf man in unzähligen Projekten grosse Diskussionen über die Reihenfolge von Schlaufen führen. Denn schliesslich hat McConnell ja gezeigt das dieser Ansatz 73% schneller ist…

 

Alternativen

Wer seine Lesezeit sinnvoller verwenden will sollte sich diese 3 Bücher anschauen:

Lässt man die Anhänge weg sind diese Bücher zusammen auch rund 960 Seiten lang. Allerdings werden hier die jeweiligen Themen praxisnah und verständlich beschrieben.

 

Fazit

Auf den ersten Blick ist “Code Complete” ein sehr gutes Buch mit zahlreichen interessanten Ideen. Betrachtet man es genauer sieht man sehr bald die vielen Unstimmigkeiten. Aus einer objektiven Darstellung wird so ein zurechtrücken von Studien und durch die vielen angeschnittenen Themen fehlt der Platz um einen wirklichen Praxisnutzen zu vermitteln.

Für Einsteiger ist dieses Buch dadurch nicht geeignet und durch die realitätsfremden Mikro-Optimierungen sogar gefährlich. Und wer sich mit der Thematik bereits auskennt wird kaum etwas Neues finden. Statt “Code Complete” liest man besser die 3 alternativen Bücher, da hat man am Ende auch etwas mit Praxisbezug gelernt.

 

Zum Buch

Code Complete – A Practical Handbook of Software Construction (2nd edition)” von Steve McConnell, 2004 Microsoft Press, ISBN 978-0-7356-1967-8, 960 Seiten, Englisch

 

Schlagworte: , ,

5 Bücher die jeder Software-Entwickler kennen sollte (Ausgabe 2014)

7. Januar 2014 2 Kommentare

Vor gut 1.5 Jahren habe ich bereits einmal eine Top 5 Liste mit Büchern veröffentlicht. Seither habe ich viel gelesen und es ist daher höchste Zeit die Leseempfehlungen zu aktualisieren.

Ich versuchte wiederum eine möglichst technologieneutrale Liste zusammenzustellen. Frameworks kommen und gehen und sind stellenweise in erschreckend kurzer Zeit wieder obsolet. Die hier vorgestellten Bücher behandeln Themen die schon länger aktuell sind und es allem Anschein nach noch einige Jahre bleiben werden.

 

Practical Object-Oriented Design in Ruby

POODR Obwohl sehr viel über OO-Design geschrieben wird ist es sehr schwer ein gutes Buch für den Einstieg zu finden. Sandi Metz hat einen guten Mittelweg zwischen Theorie und Praxis gefunden und es gelingt ihr dieses Thema in verständlichen Schritten zu erklären. Auch wer sich mit Ruby nicht auskennt kann hier viel über OO-Design lernen.

Da die Beispiele recht kurz sind kann man sich auf genau den behandelten Teilaspekt konzentrieren. Dies hilft nicht nur Einsteigern sondern ist auch sehr gut als Auffrischung für erfahrene Programmierer geeignet.
(ISBN: 978-0-3217-2133-4 | detaillierte Rezension)

 

Refactoring

Trotz seines Alters ist Refactoring nach wie vor das Standardwerk zur Restrukturierung von Code. Der ausführliche Katalog mit Strategien zur Verbesserung der Codebasis ist aus meinem täglichen Entwicklerleben nicht wegzudenken.

Dies bedeutet keinesfalls dass ich alle darin vorgestellten Methoden auswendig kenne. Aber Refactorings wie das Umbenennen von Variablen oder das Extrahieren von Methoden sind Dinge die jeder beherrschen sollte. Diese sind sehr einfachen und verbessern den Code doch enorm.
(ISBN: 978-0-201-48567-7 | detaillierte Rezension)

 
 

The Art of Unit Testing (Second Edition)

The Art of UnitTesting 2nd editionRoy Osherove liefert das aus meiner Sicht bisher beste Buch über Unit Testing. Es gibt viele Bücher die gut sind, seine Erklärung von komplexeren Themen wie dem Mocken von Abhängigkeiten ist aber immer noch unerreicht. Und mit der 2. Ausgabe wurden die Praxisbeispiele und Tipps nochmals besser.

Gerade diese Praxisbeispiele helfen einem dabei auch die komplexeren Bereiche mittels Unit Tests abzudecken. Nur wenn man diese Herausforderungen meistern kann wird man Unit Tests in die eigenen Projekte integrieren.
(ISBN: 978-1-6172-9089-3 | detaillierte Rezension)

 
 

Clean Code

Unit Tests und Refactoring sind Techniken die den Code sauberer machen. Wenn einem diese Richtung gefällt ist Clean Code von Robert C. Martin der nächste Schritt.

Sein Buch geht den Weg weiter und verbindet verschiedenste Erkenntnisse in der Software-Entwicklung der letzten Jahre zu einem Ganzen.
Bei Clean Code ist es aus meiner Sicht aber besonders wichtig das man das Ziel bei all den Regeln nicht aus den Augen verliert. Verständlicher Code sollte immer vor einer in Stein gemeisselten maximalen Anzahl Zeilen für eine Methode gehen.
(ISBN: 978-0-13-235088-4 | detaillierte Rezension)

 
 

Patterns of Enterprise Application Architecture

Patterns of Enterprise Application ArchitectureDas 2. Buch von Martin Fowler in meiner Liste behandelt die Patterns rund um Geschäftsanwendungen. Die Problemstellungen in diesem Bereich sind so grundlegend dass die meisten Entwickler in ihren Projekten damit zu tun haben – ganz egal ob ihre Projekte den Stempel „Enterprise“ tragen oder nicht.

Fowler beschränkt sich nicht nur darauf die einzelnen Patterns aufzulisten, sondern erklärt auch die jeweiligen Vor- und Nachteile. Diese Gegenüberstellung macht für mich den Wert dieses Buches aus, da man nur so eine fundierte Entscheidung treffen kann.
(ISBN: 978-0-3211-2742-6 | detaillierte Rezension)

 
 

Soweit meine aktualisierte Liste von Büchern die ich als “Must-Read” bezeichne. Ich würde mich freuen zu erfahren was andere Entwickler als unverzichtbare Bücher auflisten.

 

Schlagworte: , , ,

Buch-Rezension zu “The Art of Unit Testing (2nd Edition)”

27. November 2013 2 Kommentare

The Art of UnitTesting 2nd editionSeit Ende letzter Woche gibt es mit “The Art of Unit Testing, Second Edition” eine neue Ausgabe meines favorisierten TDD-Buches. Die erste Ausgabe erschien 2009 und beeinflusste mein Verständnis von Test-Driven Development nachhaltig.

Ich war einerseits gespannt auf die neue Ausgabe und andererseits auch ein wenig unentschlossen ob es wirklich eine neue Ausgabe benötigt. Konnte die neue Ausgabe die kleineren Mankos der 1. Ausgabe wirklich beheben? Oder gibt es am Ende ein ganz anderes Buch das nur den gleichen Namen trägt?

 

Aufbau beibehalten, Inhalt überarbeitet

Die Kapitelstruktur der 2. Ausgabe unterscheidet sich nur minimal von der 1. Ausgabe. Der ehemalige Anhang A “Design and testability” ist nun ein “richtiges” Kapitel und Mock-Frameworks werden in einem zusätzlichen Kapitel noch eingehender angeschaut. Die übrigen Kapitel blieben alle erhalten und wer sich nur am Inhaltsverzeichnis orientiert wird diese 2. Ausgabe wohl schnell wieder weglegen.

Die grossen Neuerungen finden sich in den Kapitel selber. Diese wurden komplett überarbeitet und liefern nun eine noch bessere Erklärung wieso man seine Unit Tests auf diese Art organisieren und strukturieren soll. Die Beispiele sind nun so gut dass man dieses Buch auch problemlos einem Anfänger geben kann. Roy Osherove führte zwischen den 2 Büchern zahlreiche TDD-Kurse durch und hat seine dabei gewonnenen Erkenntnisse in die 2. Ausgabe einfliessen lassen. Dadurch wurde auch hinsichtlich der Praxistauglichkeit nochmal ein Schritt nach vorne gemacht, was sich vor allem an den viel klareren Namensregeln zeigt.

Wenn man die erste Ausgabe kennt und täglich mit Unit Tests arbeitet wird man fast nur bei den Mock-Frameworks neue Erkenntnisse bekommen. Die aktuelle Liste lieferte einem eine gute Übersicht und kann einem auch helfen sich gegen ein bestimmtes Framework zu entscheiden:

MSFakes might be free and included with Visual Studio, but it will cost you a lot of money down the line in developer hours, fixing and trying to understand your tests.

Wer seine erste Ausgabe nicht nur als Staubfänger nutzt sollte sich die 2. Ausgabe zulegen. Ob man das Buch als Nachschlagewerk, zum Auffrischen seiner Unit Testing Kenntnisse oder für neue Teammitglieder braucht – die überarbeiteten Kapitel sind einfacher zu verstehen und näher an der Praxis.

 

Fazit

Mit der 2. Ausgabe konnte Roy Osherove die hohen Erwartungen übertreffen und ein noch besseres Buch über Unit Testing liefern. Die darin beschriebenen Vorgehensweisen helfen in der Praxis die Unit Tests im Griff zu behalten und eine Struktur hinein zu bringen. Wenn man die erste Ausgabe besitzt und damit noch arbeitet lohnt sich auch der Kauf der 2. Ausgabe.

 

Zum Buch

The Art of Unit Testing, Second Edition” von Roy Osherove, November 2013 Manning, ISBN 978-1-6172-9089-3, 296 Seiten, Englisch

 

Schlagworte: , , ,

Buch-Rezension zu “Kanban and Scrum”

3. Oktober 2013 Kommentare aus

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

 

Buch-Rezension zu “Kanban”

1. Oktober 2013 Kommentare aus

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

 

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an