In diesem Blogbeitrag sollen die wichtigsten aufgekommenen Punkte des GDCR '18 in Karlsruhe bei Fiducia & GAD IT AG zusammengefasst werden.
Einleitung
In der Einleitung wurde der Ablauf des Tages, die Programmieraufgabe (Game of Life), Four Rules of Simple Design, TDD und PairProgramming vorgestellt.
Um die Teilnehmer in die Einleitung mit einzubeziehen, ließen wir sie nach ihrer "Hauptprogrammiersprache" Gruppen bilden. Somit konnten die Teilnehmer auch sehen, mit wem man in einer der Session ein Pair bilden könnte um eine Programmiersprache auszuprobieren.
Das Finden der ersten Pairs haben wir unterstützt, indem wir alle Teilnehmer gebeten hatten, sich nach ihrer TDD-Erfahrung in eine Reihe aufzustellen. Die Reihe wurde dann zusammengeklappt, sodass diejenige Person mit der meisten TDD-Erfahrung mit derjenige Person mit am wenigsten TDD-Erfahrung gepaired hat, diejenige Person mit der zweit meisten TDD-Erfahrung mit derjenigen Person mit der zweit wenigsten TDD-Erfahrung, usw.
Sessions
1. Beck's Inbox
Hierbei geht es darum, alles was noch getan werden muss, auf einen Zettel zu notieren. Somit lässt sich auf den jeweiligen Aspekt fokusieren, weitere Dinge werden direkt auf einen Zettel geschrieben. Hat man nun den Aspekt abgeschlossen kann man bei Bedarf die Liste umpriorisieren oder doch nicht mehr benötigte Dinge streichen.
Session-Retro
Teilnehmer haben berichtet, dass man sich bremst, zu große Aufgaben angehen zu wollen und dahin kommt, kleine Schritte zu machen. (Es war nicht ganz klar wie viel Anteil TDD vs. Beck's Inbox daran hatte). TDD Neulinge haben sich schwer getan, erst den Test zu schreiben, bzw. einen ersten kleinen sinnvollen Test zu finden.
Bewertung der Facilitators
Zum Einstieg ein leichtes Constraint hat wieder gut gepasst. Allerdings wurde Beck's Inbox nicht konsequent angewendet. Zumeist wurden Block und Stift genutzt um Spielfeld, Definition von Nachbarn und Algorithmen zu visualisieren.
2. Mute Ping-Pong
Pairprogramming ohne miteinander reden zu dürfen. Hier in der Ausprägung kooperatives pairing, im Kontrast zu "evil" pairing, bei dem der Partner bewusst versucht zu sabotieren.
Fragen zu Sprache, IDE, Shortcuts, OS waren explizit erlaubt. Ein Umgehen des Constraints durch Kommentare im Code oder Schreiben auf einem Block war untersagt!
Ping-Pong haben wir erklärt als Wechsel der Rolle (Driver/Navigator) jeweils nach der Erstellung den nächsten roten Tests.
Session-Retro
Insgesamt haben die Teilnehmer Vor- und Nachteile dieses Constraints erlebt. Vorteile waren z.B. die Erkenntnis, dass man mit guten Variablen-, Methoden- und Testnamen erstaunlich weit kommen kann. Außerdem kann es dabei helfen, Entscheidungen treffen zu müssen.
Allerdings ergeben sich auch einige Reibungspunkte, wie zum Beispiel die fehlende Absprache zu Konzepten, Begriffen und Modellentscheidungen. Das künstliche Unterbinden von Kommunikation führt zu sehr konstruierten Problemen, wie z.B. darf bei einem "offensichtlichen" fachlichen Fehler (assertThat(add(1, 2), is(4)) dem Partner kein Hinweis gegeben werden kann/darf und somit erstmal eine eigentlich fehlerhafte Implementierung entsteht. Zusätzlich erlebten die Pairs verlängerte Zyklen bis wieder gewechselt wurde.
Bewertung der Facilitators
Immer wieder ein spannendes Constraint. Allerdings werden die Probleme um die künstliche Kommunikationsunterbindung deutlich. Der Kosten-Nutzen Mehrwert dieses Constraints sind im Vergleich zu einem reinen Ping-Pong oder Naiv Ping-Pong nicht deutlich.
3. TDD-Cycle
Nach dem Mittagessen haben wir mit dem Constraint TDD-Zyklus weitergemacht. Es geht darum, nochmal deutlich den Fokus auf den red-green-refactor Zyklus zu legen. Wir haben die Teilnehmer ermutigt, mit den Greenbar-Patterns (Fake, Obvious Implementation, Triangulation) zu arbeiten und die eigentliche Implementierung in der Refactoring-Phase entstehen zu lassen.
Session-Retro
Die Teilnehmer waren zu einem erleichtert, dass sie wieder miteinander reden durften, zum anderen taten sie sich schwer in den Anfängen der Implementierung die Refactoring-Phase auszunutzen, da es noch nicht viel zu refaktoren gab.
Bewertung der Facilitators
Die Vermutung ist, dass doch nicht ganz konsequent der TDD-Zyklus angewendet wurde. Im speziellen die Verteilung zwischen geschriebenem Code in der "green"-Phase und "refactor"-Phase. Das heißt es wurde "zu viel" in der green-Phase implementiert und nicht rein auf "make it green" fokusiert.
4. Simple Methods
Einschränkung auf eine Einrücktiefe pro Methode, sowie eine maximale Methodenlänge von drei Zeilen.
Session-Retro
Das Feedback war gemischt. Einige Pairs empfanden, dass ihr Code schlechter wurde durch das stumpfe einhalten der Regeln. Andere Pairs haben durch das Befolgen besseren, testbareren Code geschrieben. Zusätzlich gab es Pairs, die das Constraint als Chance gesehen haben, ihre Struktur zu überdenken (z.B. das Board anstatt als Array als Liste zu implementieren), wodurch sie zu neuen Lösungsansätzen gefunden haben.
Bewertung der Facilitators
Es scheint den Teilnehmern schwer zu fallen, erstmal "dreckigen" Code zu schreiben um diesen dann in der Refactoring-Phase aufzuräumen. Die Constraint-Erklärung könnte wir noch mehr auf die Intention eingehen, um zu vermeiden, dass Stumpf die Regeln eingehalten werden. Zusätzlich wurde als Abschwächung "one dot per line" nicht erwähnt, was wiederum zu Ideen der Teilnehmer geführt hat, dies auszunutzen.
5. Baby Steps
Als letzte Session des Tages, haben wir uns für Baby Steps entschieden, d.h. jeder Zyklus von einem grünen Commit über einen weiteren Test oder über Refactoring hin zu einem grünen Commit darf maximal zwei Minuten lang sein. Falls die Zeit überschritten wird, muss zurückgesetzt werden. Dieses Constraint fördert das kleinteilige Arbeiten im TDD-Zyklus.
Session-Retro
Auch hier gab es wieder gemischtes Feedback zwischen Pairs, denen der Zeitdruck geholfen hat kleine Schritte zu gehen. Während andere Pairs sich sehr schwer getan haben kleine Schritte zu finden. Des Weiteren ist aufgefallen, dass gerade in diesem Constraint das Ausprobieren von neuen Programmiersprachen und/oder IDEs doppelt schwierig wird.
Bewertung der Facilitators
Dieser Constraint brachte die Teilnehmer regelmäßig aus ihrer Komfortzone, was genau das ist, was erreicht werden soll. Das Feedback war wie zu erwarten gemischt, dennoch halten wir es für eine gute Übung um in Richtung kleinteiligem Entwickeln zu kommen. Zusätzlich deckt der Constraint konsequent zu große Schritte auf.
Closing Circle
Das Feedback war überwältigend positiv. Die wieder einmal sehr heterogene Gruppe, mit den verschiedensten Hintergründen, Programmiersprachen und Erfahrungsleveln, hat wieder voll gewirkt und jeder konnte neue Ideen mitnehmen und neue Programmiersprachen ausprobieren.
Bewertung der Facilitators
Ein durchweg erfolgreiches Event: Positive Stimmung, tolles Miteinander arbeiten, konstruktive Diskussionen. Unser Zeitplan hat gut gepasst. Die Entscheidung hin zu fünf Sessions und einem leicht späteren Startzeitpunkt hat sich als sinnvoll dargestellt. Gerade in Diskussion mit TDD-skeptischen Teilnehmern konnten einige neue Blickwinkel ausgetauscht werden.
Nachgang
Peter hat sich nach dem offiziellen Ende bereiterklärt, nochmal im Mob die Aufgabe zu bearbeiten. Mit Fokus auf Outside-In konnten nochmals dediziert Vor- und Nachteile von TDD diskutiert werden. Hintergrund war, es den in den Session-Retros aufkommenden TDD-Diskussionen nochmals ein Forum zu bieten und am gemeinsam geschaffenen Codestand zu diskutieren.
Facilitators Lessons-Learned
- Einen minutiösen Zeitplan als Orientierungshilfe hat viel gebracht um verlorene oder gewonnene Zeit zu erkennen und ggfs. nachsteuern zu können
- Großzügige Sessionplanung hat sich bewährt um auf Gegebenheiten reagieren zu können: 10min. Constraintbeschreibung + 45min. Coden + 15.min Retro + 10min. Pause (1h20min.)
- Geplante Sessions in Kombination mit Ersatz-Sessions haben gut funktioniert um auch in Sachen Constraint auf Teilnehmer und Beobachtungen eingehen zu können. Konkret haben wir "Tell Don't Ask" durch "Simple Methods" ersetzt. Bei Session 3 war ursprünglich ein unangekündigter Cut nach der halben Zeit mit Partnerwechsel (Split Brain) geplant, welchen wir mit Blick auf den aktuellen Verlauf verworfen haben.
Slides
https://keybase.pub/chr1shaefn3r/slides/ka-gdcr18.pdf
Abschluss
Vielen Dank an alle Teilnehmer für das konzentrierte Mitmachen und das positive Feedback. Der zweite ganz groẞe Dank geht an Peter Fichtner der uns bei der Fiducia & GAD IT AG unter optimalsten Bedingungen gehostet hat.