In diesem Blogbeitrag sollen die wichtigsten aufgekommenen Punkte des GDCR '18 in Karlsruhe bei Fiducia & GAD IT AG zusammengefasst werden.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Einschränkung auf eine Einrücktiefe pro Methode, sowie eine maximale Methodenlänge von drei Zeilen.
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.
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.
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.
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.
Dieser Constraint brachte die Teilnehmer regelmäßig aus ihrer Komfortzone, was genau das war, was wir erreichen wollten. 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.
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.
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.
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.
https://keybase.pub/chr1shaefn3r/slides/ka-gdcr18.pdf
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.