Schlagwort-Archive: Coding Dojo

Was wollt ihr über Coding Dojos wissen?

Ich schreibe aktuell an einem Artikel zu dem Thema. Für mich sind Coding Dojos ein effektives Mittel um aktiv die kontinuierliche Verbesserung voranzutreiben. Das ist mir sehr wichtig, denn es geht viel Potential verloren, indem Wissensmanagement nur passiv abläuft. Wer sich z.B. den eigenen Code von vor 3 Jahren anschaut, wird hoffentlich feststellen, dass er heute besser entwickelt. Dieser Prozess vollzog sich quasi nebenbei. Meine Intension ist deshalb aktiv Werkzeuge zu testen und nutzen, um Verbesserungen forcierter anzugehen.

Coding Dojos sind in dem Kontext ein erprobtes Mittel. Weitere habe ich in diesem Artikel bzw. in der unten stehenden Grafik aufgelistet:

 

image

 

Den geneigten Leser würde ich bitten mir auf Twitter, Facebook oder am besten hier in die Kommentare mitzuteilen, welche Erfahrungen er mit Coding Dojos gemacht hat, wo Probleme liegen, was Erfolge waren und was er gerne in einem Artikel dazu lesen würde. Zur Anregung kann diese kleine MindMap dienen:

image

Kata 2048

Kürzlich nahm ich bei der .NET User Group Karlsruhe an der Kata 2048 teil. Eine vollständige Formulierung in Form von User Stories oder einer Anforderungsliste gibt es bisher nicht. Weil im Netz aber so viel darüber diskutiert wird, möchte ich an dieser Stelle meinen Kata Vorschlag veröffentlichen.

In den nächsten Tagen werde ich noch einen kleinen Bericht und/oder Video online stellen, in dem ich von einer Scrum Schulung berichte, die wir Inhouse anhand des Spiels durchgeführt haben. Bei genauer Betrachtung bietet 2048 reichlich Diskussionsstoff, so z.B. für die gemeinsame Domänensprache und die Priorisierung von Anwenderwünschen.

Die Kata ist als Architektur-Kata zu verstehen, die in mehreren Sprints umgesetzt werden soll (auch wenn ich keine User Stories geschrieben habe…). Als Veranstalter des Coding Dojos empfehle ich deshalb die einzelnen Teile erst nacheinander pro Runde herauszugeben. Darüber hinaus habe ich absichtlich schwammige und doppeldeutige Begriffe gewählt, um den Alltag mit den Fachabteilungen zu simulieren. Ich setze voraus, dass die Teilnehmer das Spiel zumindest kurz gespielt haben oder zuvor gezeigt bekommen.

 

Sprint Goal 1: Veröffentlichung der ersten Basisversion für Tester und Product Ownerimage 

  • Das Spielfeld ist quadratisch und hat 4×4 Felder
  • Beim Start des Spiels werden zwei zufällige Felder mit dem Wert 2 belegt
  • Ab diesem Zeitpunkt hat der Spieler immer 4 Zugmöglichkeiten: Rechts, Links, Oben, Unten
  • In allen Fällen bewegt sich jedes Feld so weit in die vorgegebene Richtung, bis eine von 3 Situation eintrifft:
    • Der Rand des Spielfeldes ist erreicht
    • Das Feld trifft auf ein benachbartes Feld mit einem unterschiedlichen Wert (Bsp.: Feld mit Wert 2 trifft auf Feld mit Wert 4)
    • Das Feld trifft auf ein benachbartes Feld mit gleichem Wert (Bsp. Feld mit Wert 2 trifft auf Feld mit Wert 2)
  • Felder mit gleichen Werten “paaren” sich. Die Summe erhält das Feld, das näher an dem Rand liegt, in dessen Richtung gezogen wurde. Das andere Feld verbleibt ohne Wert.
  • Es handelt sich um einen gültigen Zug, wenn sich mindestens ein Feld bei dem Zug verändert hat. Andernfalls ist es ein ungültiger Zug.
  • Bei einem gültigen Zug entsteht auf einem zufällig gewähltem, leeren Feld der neue Wert 2
  • Bei einem ungültigen Zug passiert nichts
  • Das Spiel ist zu Ende, wenn keine gültigen Züge mehr möglich sind oder ein Feld den Wert 2048 erreicht

 

Sprint Goal 2: Go Live Version releasen

  • Statt zufällig gewählte Felder mit dem Wert 2 zu belegen, soll der Wert zufällig 2, 4 oder 8 sein
  • Die Größe des Feldes soll konfigurierbar sein. Es bleibt aber bei der quadratischen Form und die Mindestgröße beträgt 4×4
  • Der Wert zum Gewinnen des Spiels soll konfigurierbar sein. Möglich sind 1024, 2048 oder 4096
  • Biete 2 unterschiedliche Oberflächen an (z.B. Konsole, WinForm, WPF, Web)

 

Sprint Goal 3: Kostenpflichtige Version mit erweitertem Gameplay entwickeln

  • Füge die Option hinzu genau einen Zug rückgängig machen zu können
  • Einführung eines Highscore: Wenn sich zwei Felder “paaren”, dann soll der neu entstandene Wert zu dem Highscore hinzugezählt werden. Der Highscore wird solange hochgezählt bis das Spiel zu Ende ist

 

Sprint Goal 4: Wünsche der kostenpflichten Abonnenten einbauen

  • Das Spielfeld muss nun nicht mehr quadratisch sein. Beispiel gibt es hier.
  • Erweitere die Option des Rückgängigmachens auf beliebig viele, sodass bis zum Start des Spiels zurückgegangen werden kann

 

Sprint Goal 5: Das Spiel ist ein Riesenerfolg und die Wissenschaftler auf der ganzen Welt benötigen eine automatische Lösungsroutine

  • Schreibe einen Solver. Treffe dafür notwendige Annahmen und versuche eine allgemeine Schnittstelle für Dritthersteller anzubieten

 

Meine Lösung möchte ich demnächst auf GitHub zur Verfügung stellen. Gerne verlinke ich die Implementierung der Leser oder nehme Erweiterungen der Kata mit auf. Falls eine Umstellung der einzelnen Anforderungen innerhalb der Sprint Goals Sinn macht, bitte in die Kommentare posten.

%d Bloggern gefällt das: