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.

Zunächst muss man – aus welchem Grund auch immer – die .VDI-Datei in .IMG umbenennen. .VDI-Dateien führen bei hdiutil immer zu Fehlern, endet die Datei auf .IMG funktioniert alles wunderbar. Es sollte sich auch um eine .VDI mit fester Größe handeln, nicht um einen dynamisch wachsenden Container.

Dann benötigt man einen Hex-Editor z.B. hexdump. Mit diesem muss man nun den Wert an Offset 0×0158 (Zeile 6) aus der .IMG-Datei auslesen. In meinem Fall ist das 0×2000.

mbpgb:~ $ hexdump system.img | less
0000000 3c 3c 3c 20 4f 72 61 63 6c 65 20 56 4d 20 56 69
0000010 72 74 75 61 6c 42 6f 78 20 44 69 73 6b 20 49 6d
...
0000140 95 d1 6c 91 ff 7f 00 00 08 5f 12 00 01 00 00 00
0000150 d0 17 c3 03 00 10 00 00 00 20 00 00 00 00 00 00
0000160 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00

Der Wert ist ein 32 bit Little Edian Integer, also kann man mit folgendem Script das Offset für hdiutil berechnen:

mbpgb:~ $ bc
obase=16;ibase=16;2000/200;
10

Das Offset für hdiutil ist also 0×10, so dass die Kommandozeile für hdiutil folgendermaßen ausschaut:

mbpgb:~ $ hdid -section 0x10 -nomount system.img
/dev/disk4          	FDisk_partition_scheme         	
/dev/disk4s1        	DOS_FAT_16                     	

Damit steht der VDI-Container als /dev/disk4 zur Verfügung und die Partition disk4s1 kann gemountet werden:

mbpgb:~ $ sudo mkdir /Volumes/VDI
mbpgb:~ $ sudo mount -t msdos /dev/disk4s1 /Volumes/VDI/

Jetzt kann man ganz normal mit /Volumes/VDI/ arbeiten und Daten hin- und herkopieren.

Am Ende sollte man den Container wieder als Festplatte abmelden:

mbpgb:~ $ hdiutil detach /dev/disk4
"disk4" unmounted.
"disk4" ejected.

Quellen:

• Mounting VirtualBox VDI images on a Mac OS X host
• Mounting VirtualBox VDI images on a MacOS X host
• Mac OS X: Mounting FAT32 external hard drive via Terminal command line

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

Der Mechanismus ist recht einfach:
Ich habe einen virtuellen Web Server namens http://eclipse/ eingerichtet.
Dieser hat drei Verzeichnisse, nämlich releases, updates und tools.
Releases und Updates werden als Spiegel der Project Update Sites angelegt.
Und Tools sind alle 3rdparty Features, die man immer mal wieder braucht.

Das Script ist relativ trivial.
Man muss nur den Pfad zur Eclipse konfigurieren und als Parameter das Zielverzeichnis übergeben.

Und hier kommt das Script:

#!/bin/bash

#
# Eclipse P2 mirroring script
#
# (c) 2013 Gerrit Beine <gerrit.beine@gmx.de>
#
# See
# http://wiki.eclipse.org/Equinox_p2_Repository_Mirroring
# http://wiki.eclipse.org/Eclipse_Project_Update_Sites
#

# Specify path to Eclipse executable
eclipse="/Applications/eclipse-indigo/eclipse"

# Mirror repository metadata
function mirror_metadata()
{
    local source=$1
    local target=$2
    run_mirror ${source} ${target} "org.eclipse.equinox.p2.metadata.repository.mirrorApplication"
}

# Mirror repository content
function mirror_artifacts()
{
    local source=$1
    local target=$2
    run_mirror ${source} ${target} "org.eclipse.equinox.p2.artifact.repository.mirrorApplication"
}

# Execute Eclipse mirror
function run_mirror()
{
    local source=$1
    local target=$2
    local application=$3
    local options=$4
    echo
    echo
    echo "--------------------------------------------------------------------------------"
    echo
    echo "Mirroring ${source}"
    echo
    ${eclipse} -nosplash -verbose \
        -application ${application} \
        -source ${source} \
        -destination ${target}
    echo
    echo "--------------------------------------------------------------------------------"
    echo
}

target=$1

if [ ! -d ${target} ]; then
    echo "Specificy target directory"
    exit 1
fi

while read LINE; do
	if [[ -z ${LINE} || "${LINE}" == "#"* ]]; then
		continue
	fi
    SOURCE=${LINE%%#>>#*}
    TARGET=${LINE##*#>>#}
    mirror_metadata ${SOURCE} ${target}/${TARGET}
    mirror_artifacts ${SOURCE} ${target}/${TARGET}
done < eclipse-update-sites.map

Damit das ganze funktioniert, braucht man noch die eclipse-update-sites.map.
Deren Prinzip ist eigentlich auch einfach:
Leere Zeilen und Zeilen, die mit # beginnen, werden ignoriert.
Alle anderen Zeilen werden so interpretiert, dass der erste Teil die Quelle ist, die gespiegelt werden soll und der zweite Teil das Zielverzeichnis unterhalb des Pfades, der dem Script als Parameter übergeben wurde.
Getrennt werden die beiden Teile mit der magischen Zeichenkombination #>>#.

Und hier ist dann meine Map – ohne Garantie dafür, dass alles läuft.

# Eclipse Maintenance Update Sites

http://download.eclipse.org/eclipse/updates/4.2#>>#updates/e4.2

#http://download.eclipse.org/eclipse/updates/3.8#>>#updates/e3.8
#http://download.eclipse.org/eclipse/updates/3.7#>>#updates/e3.7
#http://download.eclipse.org/eclipse/updates/3.6#>>#updates/e3.6
#http://download.eclipse.org/eclipse/updates/3.5#>>#updates/e3.5
#http://download.eclipse.org/eclipse/updates/3.4#>>#updates/e3.4

# Eclipse Release Update Sites

http://download.eclipse.org/releases/juno#>>#releases/e4.2

#http://download.eclipse.org/releases/indigo#>>#releases/e3.7
#http://download.eclipse.org/releases/helios#>>#releases/e3.6
#http://download.eclipse.org/releases/galileo#>>#releases/e3.5
#http://download.eclipse.org/releases/ganymede#>>#releases/e3.4

# Oracle Enterprise Pack for Eclipse
#http://download.oracle.com/otn_software/oepe/12.1.1.2.1/juno/repository#>>#tools/oracleenterprise/e4.2
#http://download.oracle.com/otn_software/oepe/12.1.1.1.1/indigo#>>#tools/oracleenterprise/e3.7
#http://download.oracle.com/otn_software/oepe/helios#>>#tools/oracleenterprise/e3.6
#http://download.oracle.com/otn_software/oepe/galileo#>>#tools/oracleenterprise/e3.5
#http://download.oracle.com/otn_software/oepe/ganymede#>>#tools/oracleenterprise/e3.4

# AspectJ Development Tools

http://download.eclipse.org/tools/ajdt/42/update#>>#tools/ajdt/e4.2


http://download.eclipse.org/tools/ajdt/37/update#>>#tools/ajdt/e3.7


http://download.eclipse.org/tools/ajdt/36/update#>>#tools/ajdt/e3.6


http://download.eclipse.org/tools/ajdt/35/update#>>#tools/ajdt/e3.5

# http://archive.eclipse.org/tools/ajdt/34/update#>>#tools/ajdt/e3.4 # Frozen, no longer maintained

# Scala IDE

http://download.scala-ide.org/sdk/e38/scala210/stable/site#>>#tools/scalaide/2.10/e4.2


http://download.scala-ide.org/sdk/e38/scala29/stable/site#>>#tools/scalaide/2.9/e4.2


http://download.scala-ide.org/sdk/e37/scala210/stable/site#>>#tools/scalaide/2.10/e3.7


http://download.scala-ide.org/sdk/e37/scala29/stable/site#>>#tools/scalaide/2.9/e3.7

# http://download.scala-ide.org/releases-28/stable/site#>>#tools/scalaide/2.8/e3.7 # Frozen, no longer maintained

# Google Plugin for Eclipse

http://dl.google.com/eclipse/plugin/4.2#>>#tools/googleplugin/e4.2


http://dl.google.com/eclipse/plugin/3.7#>>#tools/googleplugin/e3.7


http://dl.google.com/eclipse/plugin/3.6#>>#tools/googleplugin/e3.6

# Spring Tool Suite

http://dist.springsource.com/release/TOOLS/update/e4.2#>>#tools/springtoolsuite/e4.2


http://dist.springsource.com/release/TOOLS/update/e3.8#>>#tools/springtoolsuite/e3.8


http://dist.springsource.com/release/TOOLS/update/e3.7#>>#tools/springtoolsuite/e3.7

# ANTLR IDE

http://antlrv3ide.sourceforge.net/updates#>>#tools/antlrv3/e3.7

# http://antlrv3ide.sourceforge.net/updates/3.6#>>#tools/antlrv3/e3.6 # Frozen, no longer maintained
# http://antlrv3ide.sourceforge.net/updates/2.0.2#>>#tools/antlrv3/e3.5 # Frozen, no longer maintained

# subclipse

http://subclipse.tigris.org/update_1.8.x#>>#tools/subclipse/1.8.x

# http://subclipse.tigris.org/update_1.6.x#>>#tools/subclipse/1.6.x # Frozen, no longer maintained
# http://subclipse.tigris.org/update_1.4.x#>>#tools/subclipse/1.4.x # Frozen, no longer maintained

# MoreUnit

http://moreunit.sourceforge.net/update-site#>>#tools/moreunit/2.x.x

# http://moreunit.sourceforge.net/org.moreunit.updatesite/#>>#tools/moreunit/1.x.x # Frozen archive

# Eclipse Metrics Plugin

http://metrics2.sourceforge.net/update#>>#tools/metrics2

# http://metrics.sourceforge.net/update#>>#tools/metrics # Frozen, no longer maintained

# Plugins by Andrei Loskutov

http://andrei.gmxhome.de/eclipse#>>#tools/loskutov

# Plugins by Markus Junginger

http://www.junginger.biz/eclipse#>>#tools/junginger

# EclEmma Code Coverage

http://update.eclemma.org/#>>#tools/eclemma

# CheckStyle integration

http://eclipse-cs.sourceforge.net/update#>>#tools/checkstyle

# Useful addons for CheckStyle

http://sevntu-checkstyle.github.com/sevntu.checkstyle/update-site#>>#tools/sevntu.checkstyle

# PMD

http://sourceforge.net/projects/pmd/files/pmd-eclipse/update-site#>>#tools/pmd

# FindBugs

http://findbugs.cs.umd.edu/eclipse#>>#tools/findbugs

# ShellEd

http://downloads.sourceforge.net/project/shelled/shelled/ShellEd%202.0.2/update#>>#tools/shelled

# WickedShell

http://www.wickedshell.net/updatesite#>>#tools/wickedshell

# Jupiter Code Review

http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/#>>#tools/jupiter

# soapUI

http://www.soapui.org/eclipse/update#>>#tools/soapui

# TestNG

http://beust.com/eclipse#>>#tools/testng/e3.4

# http://beust.com/eclipse1#>>#tools/testng/e3.3 # Frozen archive

# Eclipse Perl Integration

http://e-p-i-c.sf.net/updates#>>#tools/epic/0.5.x


http://e-p-i-c.sf.net/updates/testing#>>#tools/epic/0.6.x

# PyDev

http://pydev.org/updates#>>#tools/pydev

# Unnecessary Code Detector

http://ucdetector.sourceforge.net/update#>>#tools/ucdetector

# JadClipse Java Decompiler plugin

http://jadclipse.sf.net/update#>>#tools/jadclipse

# JD-Eclipse

http://jd.benow.ca/jd-eclipse/update#>>#tools/jd-eclipse

# JBoss Tools

http://download.jboss.org/jbosstools/updates/stable/juno#>>#tools/jbosstools/e4.2


http://download.jboss.org/jbosstools/updates/stable/indigo#>>#tools/jbosstools/e3.7


http://download.jboss.org/jbosstools/updates/stable/indigo/soa-tooling#>>#tools/soatools/e3.7


http://download.jboss.org/jbosstools/updates/stable/helios#>>#tools/jbosstools/e3.6


http://download.jboss.org/jbosstools/updates/JBossTools-3.1.1.GA#>>#tools/jbosstools/e3.5


http://download.jboss.org/jbosstools/updates/JBossTools-3.0.3.GA#>>#tools/jbosstools/e3.4

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; User Stories Applied

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.

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.

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.

Es ist mir schon oft passiert, dass der Product Owner in solchen Fällen eine Story erstellt mit dem Inhalt “Setzt so viele Änderungen wie möglich aus der Liste um” und den Aufwand aus der aktuellen Velocity seines Teams anhand des Enddatums berechnet oder einfach die Timebox hinnimmt.

Ich gehe mit solchen Fällen anders um. Genau das sind Situationen, in denen ich die Aufgaben des Product Owner besonders ernst nehme. Da mich mein Team ohnehin fragen wird, womit sie beginnen sollen, muss ich mich mit den Prioritäten der einzelnen Änderungen beschäftigen. Nur habe ich, wenn ich das in eine Story packe, keine Möglichkeit den Aufwand der für die einzelnen Änderungen notwendig ist, in meiner Priorisierung zu berücksichtigen. Deshalb erstelle ich aus den einzelnen Änderungen einzelne, vermutlich sehr kleine User Stories. Da stöhnt man als Product Owner schon mal, weil das eine lästige und aufwendige Arbeit ist. Aber die Mühe lohnt sich.
Ich kann die USer Stories dann nämlich nach meinen Vorstellungen priorisieren und in der von mir erdachten Reihenfolge von meinem Team schätzen lassen. Sind Stories dabei, deren Kosten/Nutzen-Verhältnis mir nicht gefällt, sortiere ich sie aus. Und wenn die kumulierte Schätzung des Teams bei seiner aktuellen Velocity das Zeitfenster bis zum Endtermin ausfüllt, kann ich das Schätzen abbrechen. Alles weitere wird nämlich bis zum Termin ohnehin nicht fertig, also muss sich damit auch niemand weiter beschäftigen.

Nach dem ganzen Aufwand, den ich dafür getrieben habe, möchte ich als Product Owner natürlich einen Vorteil gegenüber der Nur-Eine-Story-Variante. Das Positive ist: Es gibt nicht nur einen Vorteil.

• Weil das Team die Stories geschätzt hat, wird seine Velocity nicht verfälscht. Damit bleibt meine Planungsgrundlage für die nächsten Sprints stabil.
• Weil ich eine Priorisierung der Stories festgelegt habe, muss das Team mich nicht nach einer Abarbeitungsreihenfolge innerhalb einer großen Story fragen. Ich kann mich also schon um die Inhalte für die nächsten Sprints kümmern.
• Weil ich das Team nur so viel habe schätzen lassen, wie es schaffen kann, bekomme ich ein Maximum an Output. Das Team muss sich nicht mit Dingen beschäftigen, die für mich nicht relevant sind – die habe ich ja aussortiert.
• Und ich bekomme nur die Änderungen, die ich auch als wertvoll hinsichtlich ihres Aufwand/Nutzen-Verhältnisses erachte.

Ich habe dieses Pattern unter dem Aspekt Zeitbegrenzung beschrieben, weil es im letzten Szenario, in dem es mir begegnete genau dieses Ziel verfolgte. Ich kann aber auch das Ziel einer Nutzenmaximierung oder einer Aufwandsbegrenzung damit erreichen, je nachdem was mir als Product Owner gerade wichtig ist.

Warum ist es wichtig, dass das Scrum Board genau drei Spalten hat?
Die Antwort ist ganz einfach: eine Aufgabe kann nur in diesen drei Zuständen sein. Solange sie noch nicht erledigt ist, ist sie „In Progess“ und wenn sie noch nicht „In Progress“ ist, ist sie „New“.

In den letzten vier Monaten bin ich drei Scrum Teams begegnet, deren Boards zusätzliche Spalten hatten. Ich habe diese Teams gefragt, wozu sie diese Spalten benötigen. Der häufigste Vertreter von Spalte Vier+N war „QA“. Diese Spalte wird immer dann angewendet, wenn jemand den Mitgliedern des Teams nicht zutraut, selbst Verantwortung für die Qualität ihrer Arbeit zu übernehmen und eine Kontrollinstanz einbauen wollte. Das widerspricht aber einem Grundprinzip agiler Softwareentwicklung. Vertraue dem Team und behandle die Teammitglieder wie erwachsene Menschen.

Die Spalte „QA“ und ähnliche Konstruktionen führt in allen Teams, die ich beobachten konnte, zu zwei Anti-Pattern die in agiler Softwareentwicklung vermieden werden sollten. Das erste Anti-Pattern ist, dass die Leute abstumpfen. Es gibt ja für alles noch eine Kontroll-Instanz. Und je besser die ist, desto schlechter droht die Qualität der Tasks zu werden. Man entzieht damit dem einzelnen Teammitglied die Verantwortung für die eigene Arbeit.

Das zweite Anti-Pattern ist, dass Aufgaben nicht bis zu ihrem tatsächlichen Ende gebracht werden. Der Idealfall: ein Teammitglied, angenommen ein Junior Developer, ist irgendwann der Meinung, fertig zu sein. Wenn sich der Junior Developer unsicher ist, ob die Aufgabe korrekt bearbeitet wurde, wird er sich selbst an einen Senior Developer wenden*. Der macht vielleicht noch ein paar Anmerkungen und nach deren Einarbeitung ist die Aufgabe erledigt.
Gibt es die Spalte Vier, wird der Junior Developer sich geistig von der Aufgabe lösen, sobald er sie dorthin schiebt. Es ist dann nicht mehr seine Aufgabe. Das ist ungünstig, weil die Aufgabe ja noch nicht „Done“ ist. Sie ist nach wie vor „In Progress“. Das Teammitglied, das eine Aufgabe in Spalte vier schiebt, wendet sich der nächsten Aufgabe zu und gibt damit die Verantwortung für seine Arbeit ab. Irgendwann wird sind jemand um „QA“ kümmern – völlig entkoppelt von der vorherigen Bearbeitung.
Und was dann? Die Aufgabe geht wieder zurück auf „In Progress“?
Dazu müsste der vorherige Bearbeiter entweder seine neue Aufgabe unterbrechen oder aber er stapelt Aufgaben, die aus „QA“ zurückkommen.
Geht die Aufgabe wieder auf „New“? Wie soll dann der Junior Developer lernen, was er falsch gemacht hat? Dazu müsste dann zu jeder Aufgabe die Historie gepflegt werden. Das wiederum ist bei der Kurzlebigkeit von Scrum Board Tasks Zeitverschwendung.
Alles in allem sind Spalte Vier und weitere keine gute Lösung bei einem Scrum Board, weil man die Verantwortung der einzelnen Teammitglieder reduziert und die Menge der tatsächlich in Bearbeitung befindlichen Aufgaben verschleiert. Oft wird diese Spalte sogar zu einem Bottleneck, weil zu wenige Teammitglieder als würdig befunden werden, QA zu betreiben. Dann kommt es kurz vor Sprint-Ende zu einem hektischen QA-Tag – was nichts anderes bewirkt, als dass die Qualität sinkt.

Immer wenn jemand von mir verlangt, eine Spalte Vier wie z.B. „QA“ auf einem Scrum Board einzuführen, antworte ich, dass Qualität nicht gesichert, sondern produziert wird. In einem agilen Team sind Spalte-Vier-Tätigkeiten wie „QA“ eben nicht zusätzliche Spalten eines Scrum Boards zwischen „In Progress“ und „Done“, sondern werden kontinuierlich von allen Teammitgliedern verantwortungsbewusst ausgeführt. „QA“ ist immer „In Progress“.

* Wenn nicht ohnehin Pair Programming praktiziert wird.

Die meisten solcher Review-Tools arbeiten entweder auf Datei- oder Patchset-Ebene und vorgesehen sind nur Kommentare für Zeilen oder Dateien. Die besseren können Blöcke. Assoziationen, Packages, Klassen, eben die Ebene auf der man beim Codieren denkt, unterstützen sie alle nicht. Nun ist es aber für das Verstehen von Code unerlässlich über die Grenzen von Dateien hinweg zu denken und Strukturen zu erkennen und zu hinterfragen, die auf Zeilenebene nur schwer zu verstehen und zu kommentieren sind. Das ist mit einem solchen Tool aber extrem schwierig. Deshalb setze ich mich für Code-Reviews immer neben den Entwickler und lasse mir erklären, was er da warum gemacht hat und hinterfrage das dann. Ich habe festgestellt, dass die Leute beim Erklären oft Schwachstellen in ihrem eigenen Code entdecken, die ich mit Zeilenkommentaren nie hätte erläutern können. Einige davon hätte ich sogar selbst nie entdeckt. Bei solch einem Gespräch können immer zwei lernen.

Abgesehen davon verleiten die meisten solcher asynchronen Tools auch dazu, Reviews zu machen, wenn gerade Zeit ist. Das ist dann meist eine Weile nachdem der vielleicht schlechte Code im Repository gelandet ist. Dabei will man den dort gar nicht haben. Der Review muss meiner Meinung nach vor dem Commit stattfinden. Idealerweise als Gespräch zwischen zwei erwachsenen Leuten. Damit erspart man dem Entwickler auch die Zeit, sich wieder in den Code von vor ein paar Tagen reinzudenken, was eigentlich immer länger dauert, als ihn direkt vor dem Commit kurz durchzugehen.

Software-Architektur und Software-Qualität kann man nicht auf Ebene von Dateien oder Code-Zeilen offline diskutieren – genau das ist aber das Ziel eines Reviews: ein kritisches Gespräch über Architektur und Qualität von Quellcode. Man braucht dazu einen Gegenüber, einen Menschen der einen in seine Gedanken einweiht, dessen Spiegel man sein kann. Nur auf diese Weise besteht die Möglichkeit, Entwicklern Erfahrung und Wissen zu vermitteln, nur auf diese Weise kann man nachhaltig lernen.

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.