Vor einer Woche hatte ich das Clean-Code-Developer-Praktikum in München mitgemacht. Die Teilnahme war der Lohn für die Lösung der vorgeschalteten Bewerbungsaufgabe von Ralf Westphal und Stefan Lieser.
Kennenlernen
Montag früh um 9:00 sind wir gestartet. Zusammen mit 4 weiteren Mitstreitern habe ich die Dozenten Ralf Westphal und Stefan Lieser persönlich kennengelernt. Nach der Vorstellungsrunde, in der jeder Teilnehmer kurz etwas über sich erzählte, war mir klar, das Niveau dieser Truppe ist überdurchschnittlich hoch. Wie sich noch herausstellte, galt dies auch für unsere Motivation.
Schnell hatten Ralf und Stefan uns eröffnet, dass wir an einem Experiment teilnahmen. Die beiden wollten ihr Vorgehensmodell für die Softwareentwicklung im Feldversuch erleben. Ihr Vorgehen beruht natürlich auf den Grundsätzen der Clean-Code-Developer.
Das Vorgehensmodell der beiden lautet vereinfacht:
- Anforderungen verstehen,
- gemeinsame Sprache entwickeln (Ubiquitous Language)
- Features der Anwendung ermitteln und priorisieren
- Umsetzung planen
- Coding – (Test-First)
In den nächsten Tagen hatten wir die Möglichkeit mit diesem Vorgehen an mehreren kleinen Projekten Erfahrungen zu sammeln.
Anforderungsanalyse
Bei der Anforderungsanalyse hieß es immer wieder von einem der beiden: “Welche Glaskugel verwendest du denn jetzt?” Mit Witz und Sachverstand haben die beiden uns immer wieder gewarnt: “YAGNI, lauert überall!”.
Gemeint war damit, das wir die Anforderungen nicht interpretieren sollen, sondern direkt vom Kunden abfragen. Nicht unsere Vorstellung von der Problemdomäne bestimmt was zu realisieren ist, sondern was der Kunde wirklich braucht. Immerhin ist der Kunde meist Spezialist innerhalb der Problemdomäne.
Ubiquitous Language
Der nächste Schritt im Vorgehen ist eine gemeinsame Sprache, die “Ubiquitous Language”, zu entwickeln und vor allem auch zu verwenden. Hier ist das Ziel, dass diese Sprache Einzug in den Code erhält. Die konsequente Verwendung dieser gemeinsamen Sprache aller Beteiligten führt zu einer präzisen Kommunikation. Diese wiederrum mindert die Zahl der Missverständnisse und beschleunigt das Verständnis.
Zur Verdeutlichung der gemeinsamen Sprache wurden verschiedene Hilfsmittel eingesetzt. Mal war es eine Concept-Map, mal eine einfache Liste der entdeckten Begrifflichkeiten. Ein anderes Mal war es ein konzeptionelles Datenmodell, das ausreichte, um die Beziehungen zwischen den Begriffen zu verdeutlichen.
Wichtig war hier vor allem, das wir die Begriffe auch aktualisierten, sobald wir bessere fanden. So stellte sich im Datenmodell zur Kinokasse heraus, dass “Sitz” ein passenderer Begriff als “Platz” war, wenn der Stuhl im Kinosaal bezeichnet werden sollte, den der Kunde für eine bestimmte Vorstellung reservierte. Sofort wurde dieser Begriff im Datenmodell wie auch in der Liste der Ubiquitous Language angepasst.
Features der Anwendung
Im dritten Schritt wurden die Features der Anwendung erhoben und priorisiert. Beide Tätigkeiten wurden aus Sicht des Kunden durchgeführt. Das heißt auch hier steht der Kundennutzen im Mittelpunkt. Der Kunde soll am Ende der ersten Iteration ein lauffähiges Produkt erhalten. Ein Produkt, dass ihm einen Nutzen liefert. Ein Produkt mit dem er arbeiten, das er testen und bewerten kann. Dazu muss klar sein, welche Features zu welchem Kundennutzen führen. Erst dann kann priorisiert und festgelegt werden, “Was” zu realisieren ist.
Umsetzung planen
Nach dem die Features priorisiert wurden, war klar in welcher Reihenfolge sie zu realisieren sind. In der Umsetzungsplanung geht es nun darum, Klarheit über das “Wie” zu schaffen. Mit dem “Wie” wird nun bestimmt, welche Prozesse und Prozessschritte zur Realisierung der Features nötig sind. Hier wird also auch der Ablauf modelliert.
Die Prozessschritte, die thematisch zueinander passen, werden zu Komponenten zusammengefasst und jeweils einem oder einem Team zur Realisierung übertragen.
Überraschend war hier, dass wir in allen Beispielprojekten während der Umsetzungsplanung eine andere Lösung planten, als die, die wir bei der Vorstellung der Aufgabe im Kopf hatten.
Soll heißen: Bei der Vorstellung der Aufgabe hatte jeder Entwickler ganz automatisch eine Vorstellung davon im Kopf, wie er die Aufgabe lösen würde. Während der Diskussion, die uns bis zur Umsetzungsplanung führte, entstand in der Gruppe immer eine andere, neue Lösung.
Nicht so überraschend war hingegen, das diese neue Lösung besser zum Problem passte, da wir mittlerweile das Problem gedanklich besser durchdrungen hatten.
Coding – endlich!
Zum Schluss kamen wir dann endlich auch zum coden. Einzige Prämisse hier: Test First musste es sein, aber das ist selbstverständlich, wenn man was auf sich hält, als Software-Entwickler.
Das Ergebnis zum Thema Coding:
- Das Coding war in jedem der Projekte sehr schnell erledigt,
das war zu erwarten gewesen, wenn man sich so intensiv mit den zugrundliegenden Problemen beschäftigt. - Das Coding war sehr fehlerarm.
Nun, das könnte auch an dem Test First – Ansatz liegen. Werden hier doch für alle relevanten Codefragmente Tests geschrieben. - Das Coding wurde parallel durchgeführt
Das war die eigentliche Überraschung. Wir konnten parallel entwickeln und hatten kaum Probleme im Zusammenspiel der Komponenten.
Das heißt: die Komponenten zusammenstecken und laufen lassen - fertig.
Eine weitere Erkenntnis zum Coding ist: Durchstich-orientiert zu programmieren. Das heißt möglichst früh ein Lieferergebnis herstellen. Lieber nur einen Teil der Ziel-Funktionalität realisieren, dafür aber immer die vollständige Strecke des Ziel-Prozesses umsetzen.
Fazit
Fr. 17:00 ging es zu Ende und mein Fazit lautet: Für mich war es eine überaus kurzweilige und lehrreiche Erfahrung. Die Dozenten haben uns ein sehr interessantes Thema der Software-Entwicklung äußerst unterhaltsam und sachkundig rüber gebracht.
Vieles von dem was ich in dieser Woche und auf der Seite der
gelernt habe, kann ich direkt in meiner Arbeit verwenden. Insbesondere den Punkt: “Soviel Zeit wie nötig, für die Analyse und Planung zu verwenden” möchte ich hier nochmal hervorheben.
Doch wir hatten auch Glück mit der Gruppe, denn sowohl die Motivation wie auch die soziale und technische Kompetenz waren hoch.
Alles in allem hat es mir sehr viel Spaß gemacht und ich freue mich auf die online-Fortführung dieses Experiments.
