Eine Themenübersicht – Coding Dojo bis Pair Programming

Mit den hier gelisteten Artikeln möchte ich Euch einen Einstieg in die verschiedenen Methoden der Agilen (Software-) Entwicklung geben:

1. Coding Dojo
   • Was ist das?
   • Vorbereitungen und erste Schritte
   • Let´s do it – Legen wir los!
   • Insights – ein Blick hinter die Kulissen
   • Let`s talk about Pairing, 4-Augen Prinzip, aber was ist hier wichtig?
2. Agil, Pairing (XP), aber was steckt dahinter?
   • Neue Wegen gehen, Unbekannte Gewässer
   • Notwendige Rahmenbedingungen (Teil 1)
   • Notwendige Rahmenbedingungen (Teil 2)
   • Nutzen und Risiko
   • Agile Arbeitsmethoden – ein Zwischenfazit
3. Standard Prozesse
   • DevOps – eine kurze Erklärung
   • DevOps – zwei Welten, ein gemeinsames Ziel?!
   • DevOps – Definition of Done
   • DevOps – Ständig neue Anforderungen, Qualität?
   • DevOps – Testen, aber richtig! Klassisch vs. Unit Tests
   • DevOps – geänderte Anforderungen, neue Fehler?

   Glossar:

   • XP: Extreme Programming
   • Pairing: Pair Programming, ist ein Teil von XP
   • Dojo, Kata: Übung
   • TDD: Ein Methodik, die den Test-First Ansatz verfolgt
   • DevOps: Development trifft auf Operations

Coding Dojo – Let`s talk about Pairing

Pair Programming – aber was versteht man darunter?
Pair Programming ist nichts anderes als ein dauerhaftes 4-Augen Prinzip – und das kennt jeder.

Bereits seit vielen Jahren werden die meisten sicherheitsrelevanten Aufgaben von mindestens zwei unterschiedliche Personen durchgeführt. Ein sehr aktuelles Beispiel ist das Team rund um ein Cockpit. Als effektive Maßnahme wird seit kurzem heftig darüber diskutiert aus den 4-Augen ein 6-Augen Prinzip zu machen – zumindest solange ein Augenpaar abgelenkt ist.

Aber zurück zur (Software-) Entwicklung und den agilen Prozessen. Im Folgenden ein paar grundlegende Punkte:

1. Unbekannte Gewässer, etwas Neues wagen!
   • Wie steigert man die Bereitschaft im Team und/oder Unternehmen etwas „Neues“ zu testen oder gar einzuführen?
   • Lässt sich eine neue Methodik / Prozess / Arbeitsweise per Fingerschnippen einführen?
2. Erforderliche Rahmenbedingungen
   • Ist ein gemeinsames Verständnis auf allen Ebenen vorhanden?
   • Welche bekannten Herausforderungen sind zu meistern?
   • Wie schaut der Vergleich zwischen Lehrbuch und Praxis aus?
   • Gibt es K.O. Kriterien?
   • Gefährliche Missverständnisse bzw. Schlussfolgerungen vermeiden
3. Tägliche Hürden nehmen – in kleinen Schritte denken!
   • Welche Voraussetzungen können weiter verbessert werden?
   • Welche Vorbereitungen sind zu treffen?
   • Welche Fachliteratur eignet sich für den Einstieg?
   • Was ist bei der Zusammensetzung der Teams zu beachten?
4. Die Unternehmenssicht (Wirtschaftlichkeit)
   • Wie lässt sich mit wenig Aufwand prüfen und belegen, welcher tatsächliche Mehrwert erzeugt wird?
   • Lohnt es sich tatsächlich, zwei Personen dauerhaft gemeinsam (im Paar) arbeiten zu lassen?
   • Welche Kosten entstehen aus Unternehmenssicht?
   • Welcher Nutzen entsteht – und wie lässt sich dieser messen?
   • Belegbare Zahlen im Vergleich – Zahlen, Daten, Fakten (ZDF)
   • Welche wissenschaftliche Arbeiten gibt es?

Fragen über Fragen – nur wo bekomme ich die ganzen Antworten her? Es gibt viel Literatur rund um das Thema Agile Methoden. Durch die Entwicklung der letzten Jahre und die Tendenz alles immer schneller fertigstellen zu müssen, haben sich einige wenige Methoden als nachhaltig erwiesen – dazu gehört für mich das Pair Programming.

Es dauert einfach seine Zeit, um sich mit einem Thema näher zu befassen. Denn neben reichlicher Literatur, vielen Tools und einigen „Masterplänen a la Lehrbuch“ auf der grünen Wiese, sind auch noch die jeweiligen spezifischen Projektbedingungen zu beachten. Meistens ist der erste Schritt der Schwerste.
Mein Ziel ist es, die selbst erlebten Erfahrungen kurz zu umreißen, an Euch weiterzugeben und damit Interessierte zu erreichen. Dies ist der Einstieg in eine Artikelserie, durch die ich sicherlich bei dem einen oder anderen etwas Licht ins Dunkle bringen kann.

Coding Dojo – Insights

Worauf es bei einem Dojo bzw. Code Kata ankommt, habe ich hier beschrieben.

Der Spaßfaktor soll absolut im Vodergrund stehen. Das ist einer der wichtigsten Lerneffekte der letzten Jahre für mich, frei nach Steve Jobs „You only do great work, if you love what you do“.

Hier geht es nicht darum, wie im Alltag unter Zeitdruck die übergebene Aufgabe schnellstmöglich abzuschließen. Sondern es geht um das Lernen, dabei Spaß zu haben, sich gemeinsam mit einem Thema zu beschäftigen und sein bisheriges Wissen mit anderen zu teilen. Daraus entsteht meistens eine Gruppendynamik, die einen voll in ihren Bann zieht. Ein Dojo soll als eine Übung für was neues sein, z.B. JavaScript.

Auch wenn Kollegen anfangs skeptisch sind, lasst euch nicht einschüchtern. Nehmt Euch die Zeit, klärt sie über die Theorie auf und haltet dann kleine Workshops ab – schnappt Euch eine leichte Übung wie z.B. FizzBuzz. Macht daraus einen kleinen Wettbewerb – klassische Methode vs. Pairing mit TDD.

Das Ergebnis wird nicht nur für Euch selbst verblüffend sein, sondern auch bei den anderen ein „Aha“ auslösen. Mit den ersten Multiplikatoren fängt dann das langsame Umdenken an. Geht auf die Leute zu, holt Euch sachliche Kritik ab. Dadurch verbessert ihr Euer eigenes Know-how rund um Workshops, Coaching und Co.

Fangt noch heute an – es kostet nicht viel Zeit und bringt Euch aber in kleinen Schritten nach vorne.

Viel Spaß beim Üben

Coding Dojo – Let`s do it

Was ein Dojo ist und was bei den ersten Schritten zu beachten ist, habe ich bereits hier beschrieben.

Wenn sich die Gruppe auf die grundlegenden Sachen geeinigt hat, kann es auch schon losgehen. Der erste Schritt ist hier meistens der Schwerste – wie fängt man denn am besten an?
Ein kleiner Tipp: Lest Euch die Aufgabenstellung erneut durch und zerschneidet sie in kleinste Teile mit dem Ziel pro Aufgabe mehrere Tests zu erstellen.

Nehmen wir beispielsweise das Kata FizzBuzz – hier geht es darum eine Zahlenreihe von 1 bis 100 auszugeben.
Bei jeder Zahl, die durch drei teilbar ist, soll Fizz ausgegeben werden. Bei jeder Zahl, die durch fünf teilbar ist, soll Buzz ausgegeben werden. Und wenn die Zahl durch drei und fünf teilbar ist, soll FizzBuzz ausgegeben werden.

Wie sieht dann der erste Test aus? Ganz klar. Nimm die erste Ziffer, die Du prüfen willst, und stelle fest, ob eine der Regeln angewendet werden kann. Danach nimm die zweite Ziffer, usw. Sobald sich die Kombination aus mehreren Regeln ergibt, wird es interessant, da hier auch die Reihenfolge relevant sein kann. Ganz wichtig bei den ersten Schritten – geht streng nach dem Test Driven Prinzip mit Red – Green – Blue vor. Ob ihr lieber Design oder Development nutzt, ist Euch überlassen
Red, d.h. Euer Test muss fehlschlagen.
Green, d.h. Euer Test hat funktioniert.
Blue, d.h. Refactoring – Zeit, um den geschriebenen Code zu verbessern.

Danach geht es mit dem nächsten Test (Red) weiter. Nehmt Euch die Zeit und probiert es aus.

Coding Dojo – Vorbereitungen und erste Schritte

Was ein Coding Dojo ist, habe ich in diesem Beitrag beschrieben.

Dieses Mal geht es mir darum, etwas Licht in die Vorgehensweise bei einem Dojo zu bringen. Schließlich geht es hier neben dem Spaßfaktor vor allem darum, gemeinsam Neues zu lernen, Gelerntes besser zu verstehen oder zu vertiefen.

Die ersten Schritte laufen immer gleich ab – das Team muss sich erstmal zurecht finden. Je nach Team oder Gruppengröße nimmt das schon mal etwas mehr Zeit in Anspruch. Danach muss man sich in der Gruppe auf die Plattform, die Entwicklungsumgebung (IDE) und die gewünschte Sprache einigen. Erst wenn hier ein gemeinsamer Beschluss gefasst ist, kann es losgehen.
Kurze Annahme der Einigung: Visual Studio 2015 RC, Visual C# und .Net Framework 4.5.

Zusammengefasst, folgende Punkte sind wichtig und durchzuführen:

1. Gruppen bzw. Teamfindung, ein erstes Kennenlernen
2. Neues entdecken (Plattform, Sprache, Entwicklungsumgebung)
3. Gruppendynamik entsteht
4. Spaßfaktor am gemeinsamen Lernen wird nachhaltig gesteigert

Probiert es aus, fangt heute an – es lohnt sich!

Coding Dojo – Was ist das?

Der Begriff Dojo bezeichnet einen Trainingsraum für verschiedene japanische Kampfkünste. Aber was hat das alles mit Software oder Entwicklung zu tun?

Ein Coding Dojo ist in der IT Branche eine Art Übung an der viele Entwickler, Designer oder einfach interessierte Personen teilnehmen. Hierbei gibt es ein paar wichtige Regeln, die einem das Leben viel einfacher machen:

1. Es gibt keine bessere oder schlechtere Lösung – es wird in Teams gearbeitet.
   =>  Werten ja, aber nicht Bewerten!
2. Es wird nach der Methodik „Test First“ bzw. TDD vorgegangen.
   =>  Hier soll das Prinzip des Pair Programming geübt und vertieft werden (Pilot/Co-Pilot, 4-Augen Prinzip)
3. Es geht hier vor allem um den Spaß am Lernen – egal welche Plattform, Sprache oder Aufgabe
   =>  Der Spaß am Programmieren und am gemeinsamen Erarbeiten einer Lösung steht hier an erster Stelle

Es werden kleine Gruppen gebildet und dann geht es auch schon los – die erste kleine Programmieraufgabe, ein sog. Kata, zu lösen.

Eine gute Übersicht erhält man auf den folgenden Seiten

• Übersicht bekannter Katas für Coding Dojos
• IT Agile, Wissen rund um Code Katas und Coding Dojos
• Weitere Code Katas