In diesem Blogbeitrag soll der GDCR '16 in Karlsruhe bei Fiducia & GAD IT sowie die wichtigsten aufgekommenen Punkte zusammengefasst werden.
Durch das Feedback aus dem letzten Jahr ("einmal ohne Constraint bitte") wurde in der ersten Runde komplett auf Constraints verzichtet. Damit hatten die Teilnehmer die Möglichkeit sich voll auf das Problem bzw. die Domäne zu konzentrieren und diese dadurch kennen zu lernen.
Der kleine Bruder von Object Calisthencs: Parameter und Rückgabewerte dürfen nicht aus primitiven Datentypen wie Zahlen oder Strings bestehen sondern müssen domainenspezifische Objekte gekapselt werden (Ausnahme: Die Konstruktoren dieser domainenspezifische Objekte).
Um die Teilnehmer mit viel Gesprächsstoff in die anschließende Mittagspause schicken zu können, haben wir uns für "Mute Ping Pong" entschieden, d.h. das Sprechen in den Pairs ist während der Session verboten (Ausnahmen Fragen zum Editor/IDE). Erkenntniss: Die Teilnehmer haben erkannt, wie wichtig der Austausch während der pairens ist.
Das Constraint Baby Steps (drei Minuten um einen roten Test zu schreiben und ihn dann grün zu kriegen) fördert das kleinteilige Arbeiten im TDD-Zyklus. Vermeintlich kleinste Schritte lassen sich oft in noch kleinere Schritte unterteilen.
Erkenntniss: Die Teilnehmer haben die Regel umschifft, in dem sie ausserhalb der drei Minuten überlegt und besprochen haben, was sie genau vorgehen wollen und damit die reine Tipparbeit in die drei Minuten gelegt.
Während der ersten vier Sessions haben die Teilnehmer meist zu "obvious implementation" und "Fakes" gegriffen. Wir haben zu Beginn die green bar patterns, im deutschsprachigen oft auch als "drei Wege zu grün" bezeichnet ("obvious implementation", "fake it 'til you make it" und "triangulation") vorgestellt. Die Teilnehmer sollten sich dann für jeden Zyklus im Vorfeld überlegen, auf welchem der drei Wege sie den kommmenden Schritt lösen möchten.
Erkenntnis: Die Vorstellung hilft den Teilnehmern zukünftig eine gemeinsame Sprache zu sprechen. Viele haben unbewusst bzw. intuitiv zwei bis drei der Möglichkeiten genutzt.
Zum Abschluss gab es ein eher methodisches Constraint: Die Teilnehmer sollten bewusst versuchen ihre Ideen und Aufgaben (d.h. Testfälle, Refactorings, ...) auf einem Stück Papier festzuhalten, zu priorisieren und diese Liste während des Arbeits entsprechend zu aktualisieren: erledigte oder nicht mehr als nötig angesehene Aufgaben streichen, neue Aufgaben oder Ideen aufnehmen, Aufgaben neu priorisieren. Diese Methode wird u.a. in Kent Becks Buch "Test Driven Development by Example" vorgestellt, daher auch der Name des Constraints.
Erkenntnis: Kam zu spät, wäre in einer der ersten Session besser platziert gewesen.