XP-Days Germany 2009 – Teil 1
Conferences 2 Comments »Sorry folks, this is German only, since it is about a German conference...
Ende der letzten Woche nahm ich an den XP-Days teil, die von it-agile und andrena objects ausgerichtet wurden und in den Räumlichkeiten der IHK Karlsruhe stattfanden. Da ich bislang mit agilen Entwicklungsmethoden nicht nicht in Berührung gekommen bin, das Thema selber aber für sehr zentral und besonders wichtig für Softwareentwickler erachte, wollte ich mir durch den Konferenzbesuch einen Überblick verschaffen und aktuelle Aspekte kennenlernen.
Bislang hatte ich mich in XP und Scrum nur eingelesen, aber noch keine praktischen Erfahrungen gemacht. Daher habe auch nicht an den Tutorials am Donnerstagmorgen teilgenommen, sondern bin am Nachmittag eingestiegen.
Donnerstag
Collaboration - Agile Softwareentwicklung in verteilten Teams
Sprecher: Wolfgang Kraus
Wolfgang erklärte zunächst, was die Vorteile eines verteilten Teams sind: die Verfügbarkeit von Entwicklungsressourcen und die geringeren Entwicklungskosten. Er berichtet weiter von seinen Erfahrungen über eine Webanwendung, die an drei Standorten weiterentwickelt und gewartet wurde. Da auch der Kunde nicht immer vor Ort sei, sei es auch kein Problem, dass das Team selber nicht vor Ort sei um zusammenzuarbeiten. Während Wolfgang kaum Unterschiede im kulturellen und sprachlichen Bereich gemerkt habe, sei ihm deutlich aufgefallen, dass das Verständnis für Geschäftsprozesse stark vom Standort der Entwickler abhänge. So gelänge es einem Weißrussen leichter, sich in deutsche Geschäftsprozesse einzuarbeiten, als einem Chinesen. Wolfgang stellte heraus, wie wichtig es sei durch geeignete Werkzeuge, die teilweise einfach nötig sind beim verteilten arbeiten (Wiki, SVN), den Entwicklern Vorgaben zu machen und die nötige Transparenz zu erhalten. So lasse sich auch die Qualität eines Entwicklers mit metrischen Kennzahlen einfach messen. Bei dem angesprochenen Projekt wurden sämtliche Planungsmeetings komplett per Chat abgehalten und es fanden während der gesamten Projektdauer nur zwei Treffen mit den Entwicklern statt.
Wolfgangs Vortrag führte schon von Beginn an zu einer kontroversen Debatte. Viele der Teilnehmer hatten bei ihren Offshore-Projekten ganz andere Erfahrungen gesammelt und betonten vor allem, dass sie sehr wohl kulturelle Unterschiede bemerkt hatten. Zudem hat es viele der Anwesenden verwundert, dass sich Meetings im Chat abhalten lassen, da auf diese Weise viele (nonverbale) Signale nicht ankommen, die bei eine Telefon- oder Videokonferenz übertragen werden. Viele hatten zudem die Vermutung, dass durch den überhöhten Einsatz der Werkzeuge eine falsche Sicherheit aufgebaut wird, die echtes Vertrauen in die Entwickler nicht ersetzen kann.
Mir persönlich hat der Vortrag nur in Teilen gefallen. Die Informationen über das Projekt waren, unabhängig davon, ob sie sich auf andere Projekte übertragen lassen, sehr interessant und anschaulich. Allerdings störten die vielen Diskussionen den Erzählfluss, zumal sie bereits nach den ersten Folien begannen. Der Referent verlor dadurch an einigen Stellen den Faden und übersprang die, im übrigen bestenfalls durchschnittlich gestalteten, Folien. Als großes Manko sehe ich an dem Vortrag, dass de Rote Faden nicht sichtbar war, oder zumindest, aufgrund der ständigen Unterbrechungen, nicht sichtbar werden konnte. Mir fehlte dadurch auch ein Fazit.
Pecha Kucha 1
Stop the Line in der Softwareentwicklung von Stefan Roock
Unsere Reise ins agile Land von Markus Andrezak
Mein agiler Koffer von Holger Koschek
Kreativität und Agilität im Unternehmen von Simon Roberts
Vorab muss ich zu dieser Session sagen, dass ich zum ersten mal ein Pecha Kucha miterlebt habe. Da prägnante und anschauliche Form gefällt mir sehr und macht einfach nur Spass mitzuerleben! Der Vortragsraum war so gefüllt, dass ich leider keine Sitzgelegenheit mehr ergattern und somit auch nicht mitschreiben konnte. Ich versuche jetzt, so gut es geht, aus dem Gedächtnis zu schreiben.
Stefan Roock erzählte von den Autofabriken bei Toyota. Dort hängen Leinen, die die Arbeiten ziehen sollen, wenn es ein Problem gibt. Ein Licht an einer für alle einsehbaren Tafel leuchtet dann auf und ein Vorgesetzter sieht sich das Problem an, um zu entscheiden, ob das Band angehalten werden muss. Wenn das Licht nun ständig leuchtet, dann ist der Arbeitsplatz überlastet und die Ressourcen müssen anders verteilt werden oder der Prozess angepasst werden. Wenn das Licht zu selten an ist, ist die Arbeitsgeschwindigkeit zu gering und der Arbeitsplatz nicht genügend ausgelastet. Im Idealfall blinken also alle Lichter mit einer mittleren Frequenz. Stefan zog nun die Analogie vom Toyota Production System auf die Softwareentwicklung und überlegte, ob es nicht auch für uns Entwickler eine Möglichkeit geben sollen, an der Leine zu ziehen um zu signalisieren, dass es ein Problem gibt. Anstatt das Band anzuhalten, könnte man Features streichen oder sogar das Release verschieben.
Markus hat seinen agilen Koffer (übrigens ein Rimova!) für eine Reise gepackt und dabei auf sehr anschauliche und lustige Weise erzählt, was alles in diesen Koffer gehört.
An den Vortrag von Simon habe ich leider keine Erinnerung (mehr). :( Wobei auch ein Pecha Kucha auch ziemlich fordern ist, da man alle 20 Sekunden eine neue Folie hat und parallel dem Erzähler zuhört, welcher offenbar auch ein ganz schönes Tempo anschlägt. Ich meine mich zu erinnern, dass Simon den Vortrag wie eine Geschichte vorgetragen hat...
Update:
Danke an Bernd und Holger, die mich auf diesen Fehler hingewiesen haben: Simon Roberts ist krankheitsbedingt ausgefallen und Holger Koschek ist mit seinem Ersatzvortrag Mein agiler Koffer eingesprungen. Markus hingegen erzählte von der Reise ins agile Land. Alle Klarheiten beseitigt? ;)
TDD mit den Stars (Vorrunde)
In der Pause fand die Vorrunde zu einem Programmierwettbewerb statt, bei dem vier Team gegeneinander in — wie konnte es auch anders sein — Test Driven Development antraten.
Jedes der drei Jury-Mitglieder vergab dabei zwischen 0 und 7 Punkte, die, zur Belustigung aller, mittels drei Ziffern in binär ausgedrückt werden mussten. Während die Jury jedes Team nacheinander bewertetet, hatte das Publikum am Ende aller Vorstellungen noch die Gelegenheit jedes Team mit 3, 5 oder 8 Punkten zu bewerten. Diese Punkte wurden dann zu dem Ergebnis der Jury addiert.
Jedes Team, bestehend aus zwei Personen, hatte die Möglichkeit sich eine Woche auf den Wettkampf vorzubereiten. Es gabe vier Themenvorschläge: Test Driven Refactoring, TDD in Legacy Code, TDD from Scratch und TDD mit Akzeptanztest.
1. Team: Ruby simuliert Pokens. TDD mit TDD mit Akzeptanztest
Es wurden Tests in sprachlichen Anweisungen geschrieben, die dann übersetzt und in Tests umgewandelt wurden. Platz: 4
2. Team: TDD From Scratch in Java. Punkte zählen bei einem Tennisspiel. Platz: 1
3. Team: TDD From Scratch in Groovy. Römische Zahlen werden in arabische konvertiert. Platz: 3
4. Team: Test Driven Refactoring in Java: Eine NASA-Sonde war abgestürzt, weil ein Programmteil in Kilometern und eines in Meilen gerechnet hat. Es sollte ein Einheiten-Objekt eingeführt werden, welche die Umrechnung vornimmt. Platz: 2
Leider konnte ich an der Endrunde nicht beiwohnen, da ich zu diesem Zeitpunkt mit dem Mittagessen beschäftigt war.
Wissensinseln - Schadbild, Bekämpfung und Vorbeugung
Referent: Jens Coldewey (Henning Wolf war erkrankt und konnte somit nicht mitvortragen)
Jens hielt einen sehr gelungenen Vortrag über das Thema Wissensinseln. Man erkenne Wissensinseln, wenn man zum Beispiel in einem Gantt-Diagram immer wieder einen Entwickler in einem kritischen Pfad findet oder anderer Entwickler sofort sagen "das kann nur XYZ machen". Bei agiler Entwicklung tun solche Inseln sofort weh (wenn nicht jeder Entwickler jede Aufgabe übernehmen kann), bei jedem anderen Entwicklungsmodell früher oder später. Um negative Folgen wie Überstunden und Urlaubssperre zu verhindern, gelte es diese Wissensinseln zu finden und trocken zu legen.
Wissensinseln lassen sich finden, indem man zum Beispiel den Code in Bereiche aufteilt und die Entwickler anonym befragt, wie gut sie die Bereiche kennen. Wenn nur eine Personen eine Bereich mit den Schulnoten 1 oder 2 benoten, liegt eine Wissensinsel vor.
Ein generelles Problem dabei sei, dass Arbeitsteilung seit jeher die Effizienz erhöht, dabei aber zu Spezialisierung führt. Um die Entwicklerkapazitäten bestmöglich auszulasten wird die Bildung von Wissensinseln implizit gefördert. Daher sollte der erste Schritt sein zusammen mit dem Management die folgenden zwei Punkte zu klären:
1. Die Gesamtdurchlaufzeiten sind wichtiger als die Auslastung der Entwickler.
2. Effektivität ist wichtiger als Effizienz.
Während des Abbaus von Wissensinseln darf auf keine Überlast auf dem Team sein. Das Team muss sich vertrauen und langfristig eine collective codeownership aufbauen. Zudem darf man in dieser Phase kein Micromanagement anwenden und den Entwicklern vorschreiben, welcher welche Aufgabe übernimmt. Bei einem kritischen Bereich soll von nun an nur noch Pair-Programming verwendet werden, bis sich wenigstens zwei Entwickler ausreichend auskennen. Crossfunctional Team sind ein weiteres gutes Gegenmittel für Wissensinseln. Eine Teamgröße von 4-8 Personen wird empfohlen und die Teams sollten während des Projektes stabil gehalten werden. Vor allem darf nicht vergessen werden, dass der Abbau von Wissensinseln Zeit kostet.
Der Vortrag war rhetorisch perfekt gehalten und durch zahlreiche Beispiele aus der Praxis aufgelockert. Übrigens wurde der Vortrag auch schon von Beginn an so ausgelegt, dass beide Referenten die selben Informationen hatte und somit schon von vorne herein einer Insel vorgebeugt wurde. Jens hat alle graden Seiten erstellt und Hennig alle ungraden...
