Virtual Box VDI unter Mac OS X mounten

Diese Woche hatte ich mal wieder einen Grund, mit FreeDOS zu arbeiten.
Viele Leute hassen DOS, ich fühle mich jedes Mal an meine ersten Gehversuche am PC erinnert…

Auf jeden Fall ist die Installation von FreeDOS unter Virtual Box eine wahre Freude.

Anschließend hatte ich aber das Problem, die Daten, die ich in der virtuellen Maschine benötige, auch hinein zu bekommen.
Unter Unix gibt’s ja N+1 Möglichkeiten, wer aber schon mal versucht hat, unter DOS TCP/IP zu betreiben, weiß, dass das wenig Spaß macht.

Also habe ich mich nach Alternativen umgeschaut und bin auf die Möglichkeit gestoßen, VDIs mit hdutil unter MacOS X zu mounten.
Weiterlesen

Eclipse Mirror anlegen

Man kenn es ja, ab und an braucht’s ein Update der Eclipse Plugins.
Dann werden 23 mal die JBoss Tools runtergeladen und 47 mal die Juno-Updates für die Scala IDE.

Kann man so machen, muss man aber nicht.

Die Eclipse stellt mit P2 nämlich einen ziemlich coolen Mechanismus bereit, um Update Sites zu spiegeln.
Das habe ich mir gestern mal hergenommen und ein Script gebaut, dass sämtliche (mir) wichtigen Update Sites spiegelt und auf meinem internen Web Server bereitstellt.
Ich will auch meinen Beitrag zur Bandbreitenschonung leisten ;-)

Weiterlesen

Vortrag auf der Agile World 2013

Das Programm für die Agile World 2013 wurde gestern vorgestellt und mein Vortrag wurde angenommen.

Am 28.06.2013 spreche ich im Track Transformation – Erfahrungen und Konzepte über Agile Softwareentwicklung im Tien Shan.
Der Vortrag dreht sich um interkulturelle Einflüsse bei verteilter Softwareentwicklung und Möglichkeiten, räumliche Distanzen zu überwinden.
Natürlich erkläre ich die Konzepte basierend auf Scrum :-)

Ich freue mich schon sehr auf die Agile World und viele weitere spannende Vorträge.

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.

Das I in INVEST – wie unabhängig können User Stories sein?

Heute hatte ich eine sehr spannende Diskussion. Es ging um das INVEST-Paradigma für User Stories, speziell um das I in INVEST. Das I steht für independent, also unabhängig.
Gute Stories sollen genau das sein: unabhängig.

Während der Diskussion ist mir bewusst geworden, dass das I in INVEST mindestens ebenso häufig falsch interpretiert wird, wie das zweite Wertepaar im Agilen Manifest.

Unabhängigkeit bei User Stories kann nämlich als die Möglichkeit einer beliebigen Reihenfolge verstanden werden. Wenn sich dieses Verständnis für Unabhängigkeit festgesetzt hat, führt das häufig zu künstlich unabhängigen oder zu großen User Stories und langwierigen Diskussionen über die Qualität der User Stories.
Künstliche Unabhängigkeit versucht um jeden Preis zu vermeiden, dass eine Story A implementiert sein muss, bevor eine Story B umgesetzt werden kann. Damit einher gehen häufig ziemlich schräge Akzeptanzkriterien oder es gibt eine Story-Explosion, weil versucht wird, so lange gemeinsame Teilaspekte aus den beiden Stories heraus zu splitten, bis die Abhängigkeit aufgelöst ist. Was aber nie passieren wird, Abhängigkeiten lassen sich manchmal vielleicht verstecken, aber nicht eliminieren.
Die zweite Variante, die ich beobachtet habe, führt dazu, dass Story B, die von Story A abhängt eben zu einer Story AB zusammengefasst werden. Die Story Points werden schnell addiert und man ist fein raus – glaubt man.
Meistens passt die Story dann nicht mehr in einen Sprint oder man erkennt erst, nach der Umsetzung von A und B, dass B überflüssig war. Bei zwei einzelnen Stories wäre diese Erkenntnis billiger zu haben gewesen.

Ich bin der Überzeugung, dass es völlig OK ist, wenn eine Story die Erledigung einer anderen Story voraussetzt. Insbesondere große und komplexe Systeme lassen sich gar nicht anders aufbauen. Die Unabhängigkeit von User Stories bedeutet eben gerade nicht, dass sie in beliebiger Reihenfolge realisiert werden können. Vielmehr bedeutet die Unabhängigkeit von User Stories, dass der Product Owner die Möglichkeit hat, im aktuellen Sprint das in Story A beschriebene Feature von einem Team realisieren zu lassen, ohne dass das von Story B beschriebene Feature auch realisiert werden muss. Story B kann zu einem beliebigen späteren Zeitpunkt von einem anderen Team realisiert werden. Genau das ist die Unabhängigkeit, die mit User Stories erreicht werden soll und die sowohl den Teams als auch dem Product Owner nützt.
Dazu ist es natürlich notwendig, dass die Story A in sich abgeschlossen ist. Hier spielen das T (Testable) und das V (Valuable) in INVEST mit der Unabhängigkeit zusammen. Insofern muss es in jedem größeren System Stories geben, die Vorbedingung für andere Stories sind.
Die Unabhängigkeit bezieht sich auf die Entscheidungsfreiheit des Product Owner, Features neu einzuplanen und neu zu priorisieren – nicht auf die notwendige technische Reihenfolge.

User Story Pattern: Teile und Herrsche

In meinem zweiten Artikel zum Thema Story Pattern möchte ich auf ein Problem eingehen, das mir vor kurzem bei einem Kunden begegnet ist.

Es gibt eine große Menge von auf den ersten Blick eher klein erscheinenden Änderungen an meinem Produkt, die bis zu einem bestimmten Zeitpunkt, z.B. einem Messeauftritt, fertig gestellt sein müssen. Die Liste der Änderungen kommt zu mir als Product Owner in Form einer Excel-Tabelle oder einer Powerpoint-Präsentation. Mit der Qualität der Beschreibungen können sowohl mein Team als auch ich gut leben. Wir wissen aber alle, dass die Menge der Änderungen zu groß ist, als dass sie bis zum gesetzten Termin umgesetzt werden können.
Weiterlesen

New, In Progress, Done – mehr nicht?

Ein Scrum Board kennt drei Zustände für Aufgaben, die im Sprint ausgeführt werden müssen. Nach dem Sprint Planning sind alle Aufgaben im Zustand „New“. Die so überschriebene Spalte des Scrum Boards repräsentiert das Sprint Backlog. Von links nach rechts sind die Aufgaben themenweise gruppiert und von oben nach unten sind die Themen priorisiert.
Sobald jemand eine Aufgabe beginnt, wandert diese Aufgabe in den Zustand „In Progress“. Ein guter Zeitpunkt um das zu machen ist das Daily Standup Meeting, aber natürlich kann man auch zu anderen Zeiten Aufgaben beginnen. Das Daily dient nur dazu, das Team zu informieren, was man an einem Tag alles tun möchte. „In Progress“ ist die Aufgabe erst, wenn man sie wirklich beginnt.
Den letzten Zustand „Done“ erreicht eine Aufgabe erst, wenn sie komplett abgeschlossen ist. Aufgaben von „In Progress“ nach „Done“ zu verschieben ist ebenfalls etwas, das im Daily Standup passieren sollte. Während es zumeist kein Problem ist, außerhalb des Daily Standup eine Aufgabe „In Progress“ zu nehmen, kann man mit dem Zustandswechsel auf „Done“ eigentlich problemlos bis zum nächsten Daily Standup warten.
Weiterlesen

Code-Reviews, ganz persönlich

Immer wieder begegne ich Entwicklern, die Tools für Code-Reviews benutzen. Ich tue das nicht mehr. Bisher ist mir kein einziges Review-Tool begegnet, das es mir ermöglicht, einen Review in der Qualität durchzuführen, die ich anstrebe. Weder Crucible, noch Jupiter oder mein Namensvetter Gerrit.
Weiterlesen

User Story Pattern: Teilen nach Schnittstellen

Dass User Stories dem INVEST-Prinzip genügen sollen, ist keine Neuigkeit und leicht zu verstehen. Wie man es in der Praxis erreichen kann, dass Stories diesen Prinzipien entsprechen, ist schon schwieriger. Sucht man bei Google nach Pattern für Story Schnitt findet man eine ganze Reihe von Ideen und Empfehlungen.
Ich möchte in einigen kurzen Artikeln einige Pattern vorstellen, die mir in Projekten begegnet sind – oder die ich mir gewünscht hätte :-)

Beginnen möchte ich mit dem Pattern Teilen nach Schnittstellen (Split along interfaces).

Eine Änderung im System bedingt, dass eine Reihe von Schnittstellen, z.B. Web Services, angepasst werden müssen. Das kann z.B. bei Anpassungen am Datenmodell der Fall sein, wenn die gleichen Daten von verschiedenen Web Services für unterschiedliche Kontexte oder Anwendungsfälle benutzt werden.

Hier würde ich für jede Schnittstelle immer eine separate Story erstellen. Das wirkt vielleicht zunächst sehr aufwändig, weil vielleicht jede Story die gleiche Änderung beschreibt. Tatsächlich vereinfacht es aber meine Aufgaben als Product Owner.

Der Vorteil einer Story pro Schnittstelle liegt darin, dass ich als Product Owner die Möglichkeit habe, zu priorisieren. Habe ich nur ein Entwicklungsteam, kann ich entscheiden, welche Schnittstellen am wichtigsten sind und die Stories in eine entsprechende Reihenfolge zu bringen. Habe ich mehr als ein Team zur Verfügung kann ich bei getrennten Stories eine höhere Parallelisierung erreichen.

Ein gutes Schnittstellen-Design vorausgesetzt, sind sämtliche Stories isoliert voneinander testbar. Neben der Priorisierung schafft dieses Pattern auch Transparenz für mich als Product Owner. Ich kann jederzeit erkennen, wie weit mein Team mit den Änderungen fortgeschritten ist.