Coding Dojo – aber wie?

Wir haben in der Abteilung vor ein paar Wochen eingeführt, am letzten Tag von jedem Sprint einen kleinen Firmeninternen Dojo abzuhalten. Da wir vom Anfang an zu den Münchener Coding Dojos gehen, haben dadurch ziemlich viel Erfahrung gesammelt, wie so ein Dojo durchgeführt wird.

Wie laufen üblicherweise diese Veranstaltungen ab? Der Organisator beschreibt die zur Auswahl stehenden Aufgaben, die Teilnehmer besprechen es kurz, und nachdem die Wahl getroffen wurde, wird fast sofort losgelegt. An der Tastatur. Der erste Test entsteht dann allerdings erst nach 30-40 Minuten. Geplant wird mit einem zuckenden Finger über die Tastatur, der Test entsteht oft nach einem frustrierten Ruf “schreib endlich was, egal was!”. Am Ende jedes Dojos hatten wir dann die Anforderungen erfüllt, aber zur Refactoring kamen wir nie.

Aber wir sind Entwickler, wir entwickeln uns ständig weiter. Seit längerer Zeit spürten wir, dass wir so einen Prozess anders steuern sollten, dass etwas fehlt.

An diesem Freitag haben wir also etwas anderes ausprobiert, sozusagen à la Clean Code: zuerst Anforderungen aufschreiben (das war ja nichts neues), dann nachdenken. Ohne Tastatur, nur am Flipchart. Das war neu. Wir haben die ganze Planung inklusive Funktionseinheiten, Methodennamen, Abhängigkeiten aufgezeichnet.
Danach ging erst das Entwickeln mit TDD los. Nach ca. 90 Minuten waren wir fast fertig und wir haben keine Refactoring mehr gebraucht.

Auf die Frage nach der Meinung den Kollegen, ob das jetzt besser gelaufen war, waren die Antworten geteilt: manche meinten, wir wären auch auf dem anderen Weg zum selben Ergebnis gekommen. Die Wahrheit ist, das Beispiel war recht einfach, es gab nicht sehr viele trennbare Verantwortlichkeiten, aber ich bin sicher, dass man auf dieser Art viel mehr lernen kann. Es reicht ja nicht, eine Sprache zu kennen, ein guter Entwickler muss auch Abstraktionsebenen erkennen und definieren können. Ich finde diese Art zu Arbeiten: zuerst alle Möglichkeiten auf einem Stück Papier zu bewerten und dann sich auf die einzelne Methoden zu konzentrieren, viel effektiver, ich glaube fest daran, dass es zu besserem Code führt.

Also die Frage ist: wie soll eine mit TDD entwickelte Anwendung entstehen? Vom Anfang mit der Tastatur unter den Fingern oder darf es etwas Planung in den Köpfen und auf Papier stattfinden? Haben wir die Regeln von TDD verletzt oder verbessert?