David J. Anderson: Kanban

David J. Anderson: Kanban

David J. Anderson: Kanban

Andersons Kanban-Buch kann man als Meilenstein des Change Managements im IT-Bereich betrachten. Nicht nur, dass es Anderson gelang, mit Kanban eine konsequente Übertragung der Prinzipien des Lean Manufacturing auf den Bereich der Softwareentwicklung zu übertragen. Vielmehr hat er es geschafft, darüber hinaus die Einführung solcher Prinzipien methodisch so aufzubereiten, dass es Managern möglich wird, die notwendigen Veränderungen systematisch durchzuführen.

Das Buch ist in vier Teile gegliedert.
Zunächst wird dem Leser das Dilemma des agilen Managers, nämlich die Suche nach einer konstanten Arbeitsgeschwindigkeit und die grundlegende Funktionsweise eines Kanban-Systems nahegebracht. Danach erläutert Anderson die fünf Schritte, die eine Einführung von Kanban ermöglichen und erklärt anhand von Beispielen aus seiner Management-Praxis, wie sie umgesetzt werden können. Abgeschlossen wird der zweite Teil des Buches mit einer Betrachtung von Kaizen-Kultur.

Im dritten Teil geht es dann mit den praktischen Fragestellungen richtig los. Visualisieren der Prozesse, Einsatz von Kanban zur Koordination, Lieferrhythmen und Work-in-Progress-Limits, um ein paar Stichworte zu nennen. Natürlich geht Anderson auch auf Reporting, Metriken zum Monitoring des Fortschritts und des Reifegrades der Kanban-Implementierung und auf das Thema Skalierung ein. Extrem positiv fallen die vielen verschiedenen Szenarien auf, anhand derer Anderson seine Ideen erklärt.

Der vierte Teil beschäftigt sich mit Problemen, die sich auf die kontinuierliche Verbesserung des Kanban beziehen, wie Variabilität bei den Aufgaben und begrenzt verfügbaren Ressourcen. Abgeschlossen wird das Buch durch den Kanban-Einführungsbericht eines Unternehmens.

Was mir nicht gefallen hat, war Andersons Bashing von Daily Standup Meetings. Hier gehen unsere Meinungen weit auseinander, insbesondere, weil das Standup Koordinationsaufwände transparent macht – etwas, das Anderson immer wieder als wichtig beschreibt. Die deutsche Übersetzung ist an einigen Stellen holprig, referenziert zum Teil völlig anders beschriftete Abbildungen und – das hätte ich bei einem korrigierten Nachdruck nicht erwartet – strotzt nur so vor Rechtschreibfehlern.

Fazit: Das Buch gehört zu den Must-Reads für Agilisten, denn viele Konzepte aus der Welt des Lean können auch in Scrum und Extreme Programming erfolgreich angewandt werden.

Gerard Meszaros: xUnit Test Patterns

Gerard Meszaros: xUnit Test Patterns

Gerard Meszaros: xUnit Test Patterns

457 Seiten ausschließlich über Unit Test Pattern zu schreiben sind eine Leistung. Und die Pattern sind gut!

Meszaros’ Buch hat mit über 900 Seiten einen Umfang, der viel Softwareentwickler zurückschrecken lässt. Aber es ist absolut lohnenswert, sich mit dem Thema Test Pattern zu beschäftigen. Der Autor betrachtet Unit Tests in seinem Buch hauptsächlich aus der Perspektive des Refactorings, die Pattern sind aber nicht nur dafür nützlich.

Das Buch ist in fünf Teile gegliedert. In der Einführung wird neben obligatorischen Begriffserklärungen sehr gut dargestellt, welchen Wert automatisierte Unit Tests für Softwareprojekte haben. Meszaros liefert hiert eine nicht zu unterschätzende Argumentationshilfe für viele Projekte.

Der erste Teil des Buches, mit The Narratives schon fast ironisch betitelt, führt den Leser auf 180 Seiten in die Methodik des automatisierten Testens mit Unit Test Frameworks ein. Dabei werden Unit Tests gegenüber anderen Tests abgegrenzt. Methodisch bleibt der Autor aber nicht auf Unit Tests beschränkt, sondern geht z.B. mit Datenbanktests über die klassischen Grenzen des Unit Tests hinaus. Auch wenn das nicht der reinen Lehre des Unit Tests entspricht, hilft es Entwicklern in der Praxis ungemein, sind derartige Vermischungen der Abstraktionsniveaus von Tests in Projekten schlicht und einfach Alltag – und oft auch unvermeidlich.

Im zweiten Teil werden Test Smells vorgestellt – man könnte sie auch als Anti Pattern nennen, aber der Begriff ist einfach zu ausgelutscht. Meszaros nimmt dazu drei Perspektiven ein: Smells des Test Codes, Smells im Testablauf und Smells in Projekten. Alle drei Perspektiven kennen die meisten Entwickler aus ihrer täglichen Arbeit.

Das eigentliche Thema des Buches, Test Pattern, wird im dritten Teil behandelt. Dieser Teil ist zugleich der dickste des Buches. Da der Autor auf der Website zum Buch alle Pattern aufgeführt hat, verzichte ich hier auf eine ausführliche Diskussion einzelner Pattern. Die Pattern sind allesamt sehr ausführlich erklärt, mit Grafiken ergänzt, die eine Vorstellung des Testablaufs einfach machen. Genauso wünscht man sich Diskussionen zu Pattern.

Abgeschlossen wird das Buch durch eine Reihe Anhänge, in denen unter anderem eine ganze Reihe Unit Test Frameworks und andere Tools vorgestellt werden. Verschiedene Verzeichnisse erleichtern die Suche im Buch und ein Glossar, dass es durchaus mit dem Glossary des ISTQB aufnehmen kann, ist auch enthalten.

Fazit: Ein Buch, das jedes Kilo wert ist. Für Softwareentwickler sollte die Lektüre dieses Werkes Einstellungsbedingung sein. Tester sollten es gelesen haben, um zu verstehen, wie leicht Testen sein kann, wenn man die richtigen Werkzeuge und Methoden kennt.

Johanna Rothman & Esther Derby: Behind Closed Doors

Johanna Rothman & Esther Derby: Behind Closed Doors

Johanna Rothman & Esther Derby: Behind Closed Doors

Ein Buch über Management im Pragmatic Bookshelf musste ich natürlich lesen. Vor allem, wenn mit Esther Derby eine bekennende Agilisting zu den Autoren gehört.

Das Buch erinnert entfernt an Tom DeMarcos Der Termin. Es ist kein klassisches Fachbuch, sondern der Leser begleitet Sam, einen neuen Manager in einer Softarefirma, während seiner ersten sieben Wochen. Jede dieser sieben Wochen entspricht dabei einem Kapitel. Der Stil innerhalb der einzelnen Kapitel variiert sehr stark. Es gibt Szenen, in denen Personen miteinander sprechen und der Leser erfährt, was Sam sich so alles denkt. Nebenbei werden verschiedene Managementmethoden vorgestellt und verschiedene Themen in vom eigentlich Text abgesetzten Boxen erkläutert. Einen direkten Leseweg durch das Buch gibt es nicht, zumal viele der Managementmethoden in Form von Pattern im letzten Kapitel erklärt sind.

Das Buch ist amüsant geschrieben ohne, dass ihm die Ernsthaftigkeit fehlt. Der Leser begleitet Sam während seiner ersten sieben Wochen durch die üblichen Hochs und Tiefs des Managements in Softwareunternehmen. Die beiden Autorinnen haben dazu auch einen ausreichenden Erfahrungsschatz aus dem sie berichten können.

Fazit: Dieses Buch darf neben Der Termin im Regal stehen. Man kann jede Menge über Management im Bereich der Softwareentwicklung lernen. Es liest sich gut und ist auch für Leser, die mit der englischen Sprache nicht so stark vertraut sind, zu verstehen. Besonders das Kapitel über die Techniques for Practicing Great Management sollte zum Curriculum eines jedes Master of Business Administration gehören.

Christof Ebert: Outsourcing kompakt

Christof Ebert: Outsourcing kompakt

Christof Ebert: Outsourcing kompakt

Innerhalb von kurzer Zeit das zweite Buch von Christof Ebert aus der kompakt-Reihe, das ich gelesen habe. Auch dieses Buch ist kurz, knapp und präzise. Der Autor hat es wieder geschafft, dem Titel zu entsprechen.

In der IT-Branche kommt man nicht umhin, sich mit dem Thema Outsourcing zu beschäftigen. Sei es als Dienstleister oder Freelancer auf Seite der Auftragnehmer oder als Projektmanager auf Seite eines Auftraggebers.
Ebert beleuchtet in seinem Buch vor allem die letztgenannte Seite. Wie auch in seinem Buch über Risikomanagement arbeitet der Autor viel mit Checklisten, allein im zweiten Kapitel liefert er drei davon.

Im ersten Kapitel beschreibt er Motivationen für Outsourcing ebenso wie Gründe, warum erfolgreiches Outsourcing so schwer ist. Zusätzlich liefert dieses Kapitel noch eine Übersicht der Begriffe, mit denen der Leser beim Thema Outsourcing konfrontiert wird.
Das zweite Kapitel beschäftigt sich mit der Frage nach den Möglichkeiten des Outsourcing bezogen auf Organisationen und konkrete Projekte. Die Kapitel drei und vier beschäftigen sich mit den Themen der Lieferantenauswahl und der Herausforderungen des internationalen Outsourcing. Hier liegt der Fokus vor allem auf den Großen Drei: Indien, China und Osteuropa. Das folgende Kapitel beschäftigen sich mit dem Thema Lieferantenmanagement, insbesondere den rechtlichen und vertraglichen Aspekten im Zusammenhang mit Outsourcing.

In Kapitel Sechs erklärt der Autor, wie man einen Outsourcing-Prozess aufbaut, welche Rollen wahrgenommen werden müssen – und wie man sich als Auftraggeber schützt. Einer einzigen Rolle ist ein komplettes, wenn auch nur sehr kurzes Kapitel gewidment: dem Outsourcing-Manager. Abgeschlossen wird das Buch durch Kapitel mit Tipps zum erfolgreichen Outsourcing und aktuellen Trends und Entwicklungen des Themas.

Fazit: Wer sich beruflich, insbesondere in der IT-Branche, mit dem Thema Outsourcing beschäftigen muss, egal ob als Auftraggeber oder Auftragnehmer, für den ist das Buch ein guter Einstieg ins Thema. Es hilft, eigene Schwächen zu erkennen und kann als Ausgangspunkt dienen, diese anzugehen.

Christof Ebert: Risikomanagement kompakt

Christof Ebert: Risikomanagement kompakt

Christof Ebert: Risikomanagement kompakt

Ein Buch das im Titel das Wort kompakt trägt darf kurz, knapp und präzise sein.
Christof Eberts Werk zu Thema Risikomanagement in IT- und Softwareprojekten erfüllt alle drei Kriterien.

Das Buch beginnt mit einem Zitat von Tom Gilb zum Thema Risiken, welches dem geneigten Leser ein Schmunzeln ins Gesicht zaubert. Der Autor hat den Anspruch, einen Einstieg und eine Übersicht zum Thema Risikomanagement zu liefern, was ihm auch gelingt. Das Buch beginnt mit einem recht trockenen Kapitel zur Frage was Risiken und Unsicherheiten überhaupt und insbesondere bei IT- und Software-Projekten sind. Darauf folgt jeweils ein Kapitel zu den Themen Identifizieren, Bewerten, Abschwächen und Verfolgen von Risiken. Zwei abschließende Kapitel widmen sich den Fragen der Risikostrategie und einigen allgemeinen Tipps.

Trotz der Kompaktheit des Buches gelingt es dem Autor, jede Menge hilfreiche Checklisten unterzubringen und beinahe sämtliche Standards und Vorgehensmodelle zum Thema Risikomanagement zu erwähnen. Sehr hilfreich sind auch die Hinweise zu weiterführender Literatur.

Leider ist der Schreibstil etwas zäh, so dass es Disziplin erfordert, das Buch komplett zu lesen. Länger als die knapp 140 Seiten hätte es nicht sein dürfen.

Fazit: Ein nützlicher Einstieg ins Thema Risikomanagement bei dem die Würze in der Kürze liegt. Muss man nicht gelesen haben, wenn man weiterführende Werke kennt.

Kent Beck: Test Driven Development by Example

Kent Beck: Test Driven Development by Example

Kent Beck: Test Driven Development by Example

Wer mit Test-Driven Development beginnen möchte, kommt um Kent Becks Buch nicht herum. Es langweilt nicht mit Theorie, wie es laufen sollte, sondern zeigt an drei sehr klaren Beispielen in Java und Python, wie Test-Driven Development funktioniert.

Im ersten Teil wird anhand des berühmten Money-Beispiels gezeigt, wie Test-Driven Development zu gutem Design und klaren Strukturen führt. Dabei entspricht das Ergebnis den Clean Code-Prinzipien, ohne dass man als Entwickler explizit darüber nachdenken muss. Kent Beck zeigt, wie man mit Test-Driven Development Design-Entscheidungen trifft, Refactorings durchführt und den Mut findet, einen Schritt zurück zu gehen, wenn eine Entscheidung sich als nicht mehr optimal herausstellt, weil sich die Anforderungen geändert haben.
Als Sprache für den ersten Teil kommt Java zum Einsatz und – natürlich – JUnit als Framework für die Tests.

Der zweite Teil zeigt am Beispiel von Python, wie man ein xUnit-Framework mit Test-Driven Development erstellen kann. Es lohnt sich, dieses Kapitel zu lesen, wenn man sich eine Vorstellung davon machen möchte, wie Test-Driven Development unter schwierigen Bedingungen funktioniert. Große Kenntnisse in Python sind ebensowenig erforderlich, wie Kenntnisse in Java für den ersten Teil.

Abgerundet wird das Buch mit einem dem Thema Pattern gewidmeten dritten Teil. Sämtliche Pattern werden im Umfeld des Test-Driven Development angewendet, wobei Kent Beck unterscheidet zwischen Test Pattern und Pattern für die Implementierung, die das Testen lediglich vereinfachen. Es ist interessant, dass Kent Beck in diesem Teil z.B. Mock Objects auf ein Pattern reduziert. Eingefleischte Fans von Mock Objects werden sich da sicherlich ungerecht behandelt fühlen, aber aus der Perspektive des Buches ist die Reduzierung an dieser Stelle sicherlich valide. Beispiele für Pattern zur Implementierung sind das Value Object, das Null Object oder die Factory Method.

Für diese und weitere Pattern gibt Kent Beck Empfehlungen dazu, ob sie beim Schreiben von Tests oder beim Refactoring sinnvoller einzusetzen sind. Den Abschluss des dritten Teils bilden Kapitel über Pattern zum Refactoring und zum Meistern von Test-Driven Development.

Der Stil des Buchs ist außergewöhnlich. Kent Beck schreibt, als würde er in einer Pair Programming Session neben einem sitzen. Das irritiert zu Beginn, hilft aber ungemein in das Thema zu finden. Das Buch ist dadurch extrem locker geschrieben und schnell gelesen. Die Code-Beispiele sind sehr gut verständlich.

Fazit: Wer mit Test-Driven Development beginnen möchte, muss dieses Buch gelesen haben. Für Fortgeschrittene ist es zu trivial.

Oliver Hummel: Aufwandsschätzungen kompakt

Oliver Hummel: Aufwandsschätzungen kompakt

Oliver Hummel: Aufwandsschätzungen kompakt

Oliver Hummel legt mit Aufwandsschätzungen kompakt eine gelungene Übersicht gängiger Methoden zur Aufwandsschätzung und Projektplanung.
Besonders erfreulich für mich war der Einstieg mit Story Points, wenngleich man merkt, dass der Autor hier wenig Praxiserfahrung mitbringt. Die Kalulation von Netto-Arbeitsstunden für Sprints ist mittlerweile überholt. Aber für das agile Schätzen hat ja bereits Mike Cohn ein Buch geschrieben. Die im einführenden Kapitel vorgestellten Schätztechniken, wie die einfache Zwei- oder Drei-Punkt-Schätzung sowie Schätzungen auf Basis von Analogien sind gut erklärt und für Softwareentwickler hilfreich.

Einen großen Teil nimmt das Kapitel zur Einschätzung von Komplexität des zu entwickelnden Systems ein. Neben Function Points in verschiedenen Varianten erklärt der Autor auch ähnlichen Modelle wie Object Points nach Banker, Use Case Points und die speziell für Web Applikationen geeigneten Web Objects. Die Einführung in diese Schätzmethoden ist sehr hilfreich und übersichtlich, die Methoden an sich halte ich aber im Projektalltag für wenig tauglich. Der Autor beruft sich auf verschiedene Statistiken, die die Zuverlässigkeit der einzelnen Methoden beweisen, das Problem des Vorausplanens bleibt aber bestehen. Alle Methoden gehen von der Annahme aus, dass ein Projekt eine vorangestellte Planungsphase haben kann, in der die Anforderungen detailliert beschrieben werden können, um auf dieser Basis Schätzungen zu erstellen.

Zur tatsächlichen Aufwandschätzung werden die Methoden COCOMO und SLIM vorgestellt. Beide Methoden können auf Basis einer Komplexitätsschätzung, z.B. auf Basis von Function Points und einer Umrechnungstabelle in Lines of Code, den voraussichtlichen Aufwand für ein Projekt kalkulieren. Die Formeln erscheinen mir sehr willkürlich, kritische Geister werden hier wohl in der Originalliteratur recherchieren.

Im Kapitel über die eigentliche Projektplanung geht der Autor leider nur von klassischen Wasserfallprojekten aus. Ob die heute irgendwo überhaupt noch stattfinden, sei dahingestellt. Eine Gegenüberstellung mir Mike Cohns agiler Projektplanung hätte an der Stelle das Buch rund gemacht. Ein Kapitel mit Praxistipps für Projektallags, zur Kommunikation und Verhandlung von Aufwandsschätzungen, Werkzeugen zur Unterstützung des Schätzens und einer kompakten Übersicht schließen das Buch ab.

Lesenswert machen das Buch die Ausflüge zu Tom DeMarco, Parkikson’s Law, Todesmarsch-Projekten und andere anekdotische Darstellungen. Das Buch ist flüssig geschrieben und gibt Entwicklern einen guten Überblick der Materie.
Zur Anwendung der komplexen Schätzverfahren benötigt man aber viel Erfahrung.

Der Autor bietet auch eine Website mit Korrekturen und vielen interessanten Links zum Buch.

Angelika Langer & Klaus Kreft: Java Core Programmierung

Angelika Langer & Klaus Kreft: Java Core Programmierung

Angelika Langer & Klaus Kreft: Java Core Programmierung

Mit Java Core Programmierung legt der Software & Support-Verlag einen Band vor, dessen Grundlage eine Artikelreihe des Java Magazins ist. Die Autoren haben den einzelnen Kapiteln im Buch auch den Charakter von Magazinartikeln gelassen, so dass sie weitestgehend unabhängig voneinander gelesen werden können. Es ist allerdings hilfreich, die einzelnen Kapitel nacheinander zu lesen, weil etliche Details die in den ersten Kapiteln erklärt werden und später nur noch kurz zusammengefasst sind.

Im ersten Teil des Buches beschäftigen sich die Autoren mit dem Thema Synchronisation und dem Java Memory Modell. Etliche Kapitel sind dem Thema volatile gewidmet, dabei wird insbesondere auf die Fragestellung eingegangen, ob und wann volatile Variablen Sychronisation ersetzen können. Ausgehend davon werden noch Atomic Scalars und atomare Referenzen behandelt. Es werden etliche Pattern und Anti-Pattern erklärt. Die Code-Beispiele sind angenehm kurz und prägnant gehalten, wobei eine Zeilennummerierung schön gewesen wäre.

Der zweite Teil befasst sich ausführlich mit dem Thema Garbage Collection. Die Generational Garbage Collection, die seit Java 1.3 zum Einsatz kommt, wird ausführlich erklärt. Etliche Tuning-Optionen werden vorgestellt und Vor- und Nachteile der einzelnen Algorithmen besprochen. Zum Schluss wird noch auf den Garbage-First (G1) Garbage Collector eingegangen, der seit Update 14 des JDK 6 verfügbar ist.

Das Buch basiert auf dem Java Runtime Environment in der Version 6, die meisten Prinzipien dürften aber nach wie vor gelten. Das Manko des Buches ist ganz klar ein mangelndes Lektorat. Zwar schreiben die Autoren in der Einleitung, dass die einzelnen Artikel nur marginal überarbeitet wurden, allerdings hätte sich der Verlag durchaus die Mühe machen können, offensichtliche Tippfehler und Buchstabendreher zu korrigeren. Als Leser fühlt man sich dabei nicht sonderlich wertgeschätzt.

Fazit: Java-Entwickler sollten dieses Buch gelesen haben, die vermittelten Kenntnisse sind in jedem Fall sehr hilfreich. Wer Zugriff auf alte Ausgaben des Java Magazins hat, kann sich den Kauf aber sparen.

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Wer immer wieder Projekte sieht, in denen das Chaos regiert, in denen die Projektleitung nur reagiert statt zu steuern, dem sei Mike Cohns Agile Estimating and Planning ans Herz gelegt. Ein Buch, das dem Leser eine neue Perspektive darauf gibt, wie Projekte funktionieren können, wenn man nur endlich beginnt, Projekte und ihre Plannung besser zu verstehen.

Das Buch macht einem Lust darauf, Projekte nur noch agil zu planen. Zwar merkt man Cohns deutliche Vorliebe für User Stories und Scrum, aber die Ideen und Konzepte aus diesem Buch sind auch Problemlos mit anderen Methoden des Requirement Engineering oder agilen Vorgehensweisen kompatibel.

Zum Einstieg erfährt der Leser, warum Planung notwendig ist und warum sie so oft daneben liegt. Aus den Gründen für letzteres leitet Cohn ab, dass Planung eigentlich nur agil funktionieren kann – eine Erkenntnis der man unweigerlich zustimmen muss, wenn man neben der agilen auch die Welt des V-Modells kennt.

Im zweitel Teil des Buches nimmt Cohn dem Leser die Angst, zu schätzen. Es wird klar, dass Schätzen inhärenter Bestandteil von Planung ist und die einzige Möglichkeit, besser zu planen, darin besteht, besser zu schätzen. Dazu muss man mit dem Schätzen allerdings erst einmal beginnen. Mit echtem Schätzen, versteht sich. Cohn erklärt, wie man im Team schätzen kann, wann man neu schätzen muss und wann Story Points oder Ideal Days die bessere Grundlage sind.

Der dritte Teil des Buches geht auf die Fragen ein, anhand welcher Werte man priorisieren sollte. Steht das Budget im Vordergrund? Oder eher die Funktionalität? Man erfährt, wie man beides gewichten kann und den Kunden zufrieden stellt. Zum Abschluss des dritten Teils erfährt der Leser noch einiges wichtige über das Splitten von Stories, wie man anhand von Datenstrukturen, Geschäftsprozessen oder Cross-Cutting-Concerns splittet um ein Projekt beherrschbar – und damit planbar – zu machen.

Wie man einen agilen Plan mit einer Zeitplanung versieht, wird im vierten Teil des Buches erklärt. Ausgehend vom Release-Plan geht es zum Plan für Iterationen, entweder basierend auf der Velocity oder basierend auf Commitments. Auch die Unterschiede zwischen Release- und Iterationsplan werden erklärt. Interessant ist auch das Thema Schätzen der Verlocity und wie man in agilen Plänen mit Puffern umgeht. Ein kurzes Kapitel widment sich der Frage, wie man agile Pläne für Projekte mit mehr als einem Team aufstellen kann.

Da auch in agilen Projekten gefragt wird, wie weit das Projekt den voran gekommen ist, erklärt Cohn im fünften Teil des Buches, wie man Release- und Iterationsplänge beobachten kann und Maßnahmen ableitet. Es wird auch darauf eingegangen, wie man über und mit agilen Plänen kommuniziert. Die beiden letzten Teile widmen sich zum einen der Frage, warum agile Planung funktioniert und einer Fallsstudie zum Thema agile Planung.

Fazit: Agile Estimating and Planning ist die konsequente Fortsetzung von User Stories Applied. Wer Projekte plant, egal ob agil oder klassisch, für den ist dieses Buch ein Muss.

Mike Cohn: User Stories Applied

Mike Cohn: User Stories Applied

Mike Cohn: User Stories Applied

User Stories Applied ist nach wie vor das Standard-Werk, wenn es um das Erstellen, Verwalten und Schätzen von User Stories geht. Mike Cohns Buch ist für Anfänger, die gerade beginnen, sich mit User Stories zu beschäftigen, ebenso gut geeignet wie als Inspriration für alte Hasen.

Im ersten, einführenden Teil erklärt der Cohn, was User Stories und Akzeptanztests eigentlich sind. Dabei erklärt er das Schreiben von Stories anhand des INVEST Paradigmas von Bill Wake. Wichtig fand ich das Kapitel 3 über die Benutzerrollen, denn das ist in meinen Augen der ideale Einstieg in einen Story-Workshop. Der Story-Workshop wird in Kapitel 4 als eine Möglichkeit vorgestellt, zu Ideen für User Stories zu kommen. Andere beschriebene Alternativen sind Fragebögen, Interviews und Beobachten von Benutzern. In Kapitel 5 erklärt Cohn, welche Rollen als User Proxy zum Einsatz kommen können und welche Stärken und Schwächen diesen Rollen anhaften. Ein wichtiges Kapitel, denn leider gibt es zu häufig keinen Kontakt zwischen den Entwicklungsteams und den Nutzern. Wie man Akzeptanztests für die User Stories erstellt, wie viele man benötigt und was sie beinhalten sollten wird im darauf folgenden Kapitel erklärt. Beendet wird der erste Teil des Buches einem Kapitel, das zusammenfasst, wie man gute User Stories schreibt. Man sollte mit klaren Zielen anfangen, große Stories aufteilen, das User Interface erst sehr spät beschreiben und noch einiges mehr.

Der zweite Teil des Buches beschäftigt sich mit Fragen rund um das Planen mit und das Schätzen von Stories. Zunächst geht Mike Cohn auf die Idee der Story Points ein. Er erklärt, warum es wichtig ist, dass das Team die User Stories gemeinsam schätzt. In Kapitel 9 wird erklärt, wie man ein Release mit User Stories plant. Kapitel 10 macht deutlich, wie die Arbeit mit User Stories in Interationen erfolgen kann (z.B. Sprints in Scrum). Zum Abschluß des zweiten Teils erklärt Cohn noch, wie die Velocity gemessen werden kann, wie sie bei der Planung hilft und wozu Burn Down Charts eingesetzt werden können.

Alle Themen, die nicht in die beiden ersten Teile passen, aber wichtig sind, werden im dritten Teil “Frequently Discusses Topics” besprochen. Das erste dieser Themen ist in Kapitel 12 die Frage, was User Stories nicht sind, gefolgt von einem Kapitel zur Frage, warum man User Stories benutzen sollte. Kapitel 14 stellt einige Story Smells vor, die leider immer wieder passieren und in Kapitel 15 geht Cohn kurz auf das “Dream-Team” User Stories mit Scrum ein. Abgeschlossen wird der dritte Teil mit verschiedenen Randthemen wie der Frage, nach den Zusammenhängen von Bugs und User Stories aus Anforderungs- und Planungssicht.

Das Buch wird durch einen vierten Teil abgerundet, in dem in mehreren Kapiteln ein Beispiel durchgesprochen wird. Dieser Teil ist im Wesentlichen für Einsteiger interessant, die Orientierung für das Handwerk benötigen.

Wie eigentlich alles, was Mike Cohn schreibt, kann ich auch dieses Buch wärmstens empfehlen.