Im Januar habe ich an zwei Treffen der Software Craftsmanship Bewegung in Deutschland – der Softwerkskammer – teilgenommen. In Münster stand am 14.1.2012 das erste Treffen des SoCraMOB – der Gruppe im Städtedreieck Münster, Osnabrück und Bielefeld – an. Diese treffen sich am jeweils zweiten Samstag im Quartal für einen kompletten Tag. Am 17.1.2012 stand in Hamburg das 4. Treffen an. Hier sind meine Gedanken zu beiden Treffen.
Münster, Osnabrück, Bielefeld
Nähe meiner Heimatstadt gab es ein wenig Interesse zum Thema Software Craftsmanship. Wir haben morgens damit begonnen, Themen über den Tag zu verteilen. Dabei kamen wir auf insgesamt fünf Zeitslots, in denen wir die Themen Software Craftsmanship, TDD & Hamcrest, git und perl-CI, eine Coding Kata sowie die Frage nach der Ausbildung der kommenden Generation von Software Entwicklern beleuchtet haben.
Andreas Simon stellte zu Beginn die Historie von Software Craftsmanship vor. Historisch fing er dabei bei den Pragmatic Programmers an, über Pete McBreen’s Buch, Robert Martin’s Keynote 2008, die Apprenticeship Patterns und das Manifest bis hin zur SoCraTes in 2011. Ein paar Dinge habe ich noch ergänzen können, wie zum Beispiel das verschollene Wandering Book oder die Ethics. Gleich von Folie eins an habe ich Andreas gefragt, ob er den Vortrag bei einer Konferenz eingereicht habe. Ich hoffe, dass dieser im Laufe des Jahres noch an vielen Stellen zu sehen sein wird. Sehr wertvoll für die Historiker in unserem Beruf.
Danach ging es weiter mit einer Demonstration von TDD, aber auch den Hamcrest Matchen. Jan Ernsting zeigte hier eindrucksvoll, was er gelernt hat, und wie sich Unit-Tests fließend beschreiben lassen. Für alle, die die Hamcrest-Matcher noch nicht kannten, sehr informativ. Durch Growing Object-Oriented Software Guided by Tests kannte ich die Matcher allerdings schon, und habe seit Ende 2009 öfter mit ihnen zu tun gehabt. Für mich gab es deshalb wenig neues. Wer nicht dabei sein konnte, sollte auf jeden Fall das Buch von Nat Pryce und Steve Freeman lesen.
Danach stellte Marc Metten vor, wie sie in ihrem Perl-System zu Continuous Deployment gekommen sind. Eindrucksvoll beschrieb er, wie sie für Perl quasi alles selbst gebaut haben. Vom Continuous Integration Server bis hin zum mehrmaligen täglichen Deployen. Der Vortrag war vielleicht unvorbereitet, aber ich habe hier einiges an Wissen auch über Themen wie A-/B-Testing mitgenommen. Ich hoffe, dass er auf einem zukünftigen Treffen noch mehr dazu erzählen und vielleicht auch zeigen kann. Colin Rogowski hat danach noch ein wenig mehr zu git und dem Modell dahinter beigesteuert. Die Einführung ist allerdings etwas harsch von der angelieferten Pizza unterbrochen worden. Ich hatte hier das erste Mal das Gefühl, dass ich branching mit git verstanden habe.
Nach dem Essen gab es dann eine Kata zum Verdauen. Thematisch ging es um die String Calculator Kata. Wir hatten rund 40 Minuten für die Implementierung. Danach haben wir noch ein wenig Zeit in eine kurze Reflektion gesteckt. Interessant dabei war, dass wir alle an einem ähnlichen Punkt gestolpert sind mit einer Ausnahme. Die meisten von uns hatten die Formulierung als nächsten Test interpretiert, während das eine Pair die Anweisung einfach ignoriert hat, und so wesentlich weiter gekommen ist. Manchmal muss man Vorschläge in Abwesenheit des Product Owners vielleicht auch einfach ignorieren, und später adressieren.
Zu guter Letzt habe ich eine Diskussionsrunde angeregt zum Thema, wie denn die nächste Generation von Softwareentwickler mit dem Rüstzeug wie TDD und Refactoring ausgestattet wird. Dabei kristallisierte sich vor allem ein Unterschied zum amerikanischen Modell heraus. In Deutschland hängt anscheinend viel an der Ausbildung in der Universität. Jan Ernsting, der in Kürze wieder an die Uni zurückkehrt, will einmal verschiedene Optionen für die Zusammenarbeit mit der Uni evaluieren. Ein Problem dabei könnte sein, dass Studenten einen freiwilligen Kurs zu TDD oder Refactoring vermutlich nur belegen, wenn sie diesen angerechnet bekommen. Wir hoffen, dass wir aus diesen ersten Gedanken noch ein Modell für Deutschland entwickeln können.
Am Ende des Tages haben wir gemeinsam reflektiert, was wir beim nächsten Treffen am 14.4. anders machen wollen, Auf jeden Fall wollen wir mehr programmieren, aber trotzdem ein paar theoretische Talks auch dabei behalten. Außerdem hoffen wir, dass wir noch mehr Mitstreiter bekommen, um einen ganztägigen OpenSpace durchzuführen. Last but not least suchen wir noch nach einem Ausrichter in Osnabrück. Falls wir bis Ende Januar damit erfolglos sind, werden wir auf Bielefeld ausweichen.
Hamburg
Am Dienstagabend in Hamburg ging es um das Thema Clean Code Developer. Kathleen Kümmel stellte dazu zwei Ansätze vor, die sie in verschiedenen Firmen verwendet hat, um die Diskussion zu besseren Kodierpraktiken anzuregen.
Danach haben wir das Thema der kontinuierlichen Verbesserung aufgegriffen und in einem World-Cafe mehrere Ansätze der Teilnehmer gesammelt. Insgesamt entstanden so die folgenden vier Ergebnisse.
Zum Schluss habe ich die Teilnehmer ermutigt, die Pfadfinderregel auch auf unsere Arbeit anzuwenden, und jeden Tag einen kleinen Beitrag zur besseren Ausbildung unserer Kollegen und zukünftigen Entwickler zu leisten. Da diese Verantwortung bei uns selbst anfängt, hat jeder der Teilnehmer ein Thema mitgenommen, dass er in den kommenden Wochen bei sich und in seiner Arbeitsstelle voranbringen möchte.
Der nächste Termin in Hamburg wird wieder der dritte Dienstag im Monat sein, also der 21.2. Derzeit planen wir, einen OpenSpace stattfinden zu lassen, und die Termine zwischen praktischem (Coding Dojo, Kata, etc.), theoretischen (Clean Code Developer, Was ist Software Craftsmanship) und einem OpenSpace zu alternieren.
