22.06.2011
/ Von Christoph Mathis

Katas und Coding Dojos sind für mich in letzter Zeit eine immer wichtigere Lernform geworden. Ich kann damit nicht nur das Einrosten meiner Programmierkenntnisse bekämpfen (ich mache zu viele Schulungen und programmiere zu wenig, als es für meine Routine gut ist) sondern ich habe auch einige neue Anwendungsgebiete kennengelernt:

  • Scrum Master Dojo, wie es auf dem Scrum Gathering 2010 in Amsterdam angeboten wurde (die Session war dort leider nicht so gut wie die Idee)
  • Ein Coaching-Dojo auf dem Agile Coach Camp. Das wird in Gruppen zu ca. fünf Telnehmer durchgeführt. dabei „spielt“ jeweis ein Teilnehmer den Suchenden, zwei agieren als Pair-Coachs und zwei andere beobachten und geben am Ende Feedback.
  • Neue Programmiersprachen kennenlernen. Ich selbst habe Katas genutzt, um mich einfacher in Ruby und Scala zurecht zu finden.

Jetzt haben wir (Johannes Link hat die Session moderiert) auf dem Agile Coach Camp eine Programmierkata in einer Coding Dojo Session durchgeführt, die, wenn man den resultierenden Code ansieht, völlig aus dem Ruder gelaufen ist.

Auf der anderen Seite haben wir dabei sehr viel gelernt und hatten eine phantastische Retrospektive. Und das kam so (ich muss da ziemlich tief in die Details einsteigen): Wir wollten die „Harry Potter Kata“ umsetzen. Diese hat nichts mit Zauberei zu tun, sondern mit einer komplizierten Rabattberechnung bei Kauf der verschiedenen (damals 5) Bände von Harry Potter. Dem Rabattprinzip liegt zu Grunde, dass man mehr Rabatt bekommt, wenn man mehr verschiedene Bücher einer „Suite“ kauft. Nachdem man eine Suite zusammengerechnet hat, muss man für weitere Einzelexemplare wieder von vorn anfangen. Zum Beispiel erhält man bei Kauf von 2xBand1, 1xBand2, 1xBand3 einen dreier-Rabatt für den Kauf von Band 1, 2 und 3 – man muss aber für die zweiter Kopie von Band 1 wieder den vollen Preis bezahlen.

Die Stunde der Wahrheit kommt dann, wenn man eine Sequenz von 2xBand 1, 2xBand 2, 2xBand 3, 1xBand 4, 1xBand 5 kauft. Das Programm muss dann herausfinden, dass man billiger fährt, wenn man das als zwei Vierer-Gruppen statt einer Fünfer- und einer Dreiergruppe rechnet. In unserem Dojo haben wir dann auch wie gewohnt mit den ersten Schritten angefangen: ein Buch, zwei Bücher, und so weiter. Ziemlich bald kamen dann aber zwei Wege zum Vorschein: Einer läuft darauf hinaus, wie gewohnt immer neue Testfälle zu hinzuzufügen und den Code schrittweise zu erweitern. Die andere, einen rekursiven Algorithmus zu implementieren, der die verschiedenen Lösungen generiert und dann die besten Ergebnisse auswählt.

Wir haben diese „Spaltung“ in der Gruppe nicht erkannt, was dazu geführt hat, dass wir uns öfter gegenseitig den Code mit dem jeweils anderen Ansatz gelöscht haben, weil wir ihn einfach nicht verstanden hatten. Bei unserem Java-Coding-Dojo am 21.6.2011 hatten wir ein ähnliches Problem, da hat Daniel Zappold eine Idee für die Lösung genannt: manchmal muss man auch hier am Anfang eine Design-Session durchführen. Manchmal sind einfach die Aufgaben noch nicht genau genug definiert. Damit wird die Dojo-Session noch „lebensnäher“, denn wenn man einen Task als Pair mit TDD umsetzt, ist es auch eine gute Praxis dass man sie zunächst eine TODO-Liste mit den einzelnen Schritten zurecht legt. Jetzt suchen wir nach Ideen, wie man diesen Design-Schritt integrieren kann, der hilft den minimalen Aufwand zu definieren, der am Anfang infach sein muss. Vielleicht kommt am Ende auch eine neue Form heraus, so etwas wie eine Design-Kata. Für Ideen und Erfahrungen sind wir dankbar, wir arbeiten auch daran weiter, bleibt dran.

Artikel wurde in den Warenkorb gelegt.