Agile Software Engineering

„Agile Entwicklung“, „testgetriebene Entwicklung“, „Pair Programming“ – neumodischer Krams! Ich habe das bisher für Sektiererei, Schulungs-Pyramidenschema, Eingeweihten-Echokammer und Schlimmeres gehalten. Das war doch gut so, wie wir das schon immer gemacht haben, da muss man doch nichts umstellen!

Vorurteile

Ich kannte das bisher alles nur auf Schlagwortebene vom Hörensagen und bin da bisher nie genauer eingetaucht. Meine schön gepflegten Vorurteile waren mir als solche bewusst, aber halt da:

Erst Test schreiben, dann Software schreiben

„Ja, wie soll das denn gehen? Wenn ich noch keine Java-Klasse geschrieben habe, weiß ich nicht, wie der Code aussieht, was soll ich denn dann testen. Im Maximalfall habe ich einen Compilefehler.“ Allerdings habe ich seit jeher z.B. neue Services Stück für Stück so getestet: Erstmal Aufruf ohne Exception, dann mit leerer Rückgabe, dann mit festen Rückgabewerten und schließlich richtig. Ist ja auch ganz naheliegend und logisch, das so zu tun.

Pair Programming

„Entweder, ich bin schnell an der Tastatur, dann kann mir keiner folgen, oder ich erwische einen langsamen Tipper als Partner und gucke aus dem Fenster. Bestenfalls hat mein Partner Spaß mit meiner Emacs-Tastenbelegung oder meinem Windowmanager.“ Ich hatte da eine gefühlsmäßige Abneigung – trotzdem geisterte mir ein „musst Du auch irgendwann mal ausprobieren, so schlecht kann es ja nicht sein, wenn sich das schon so lange hält“ im Kopf rum. Bauchgefühl „geh weg“ gepaart mit rationalem „wenn ich mich mal nicht mehr dagegen wehren kann, dann ja“ mit ganz leichter Tendenz zu „wann kann ich das mal ausprobieren?“. Wohlgemerkt nur, um danach qualifizierter meckern zu können ;-)

Agile Entwicklung

Meine bisherige Erfahrung zeigt, dass ein Projekt um so besser läuft, je mehr man sich vorher Gedanken macht, was man eigentlich will und von vorneherein Struktur reinbringt. (Zugegebenermaßen waren das auch meist Projekte, wo das vorab auch mehr oder weniger möglich war, wenn man denn wollte.) Wenn das gut lief, war man auch hintenraus flexibel genug, auf die eine oder andere Änderung oder Zusatzanforderung zu reagieren. Und das soll durch Planlosigkeit und Chaos ersetzt werden? Dazu ist das Thema gefühlt auch die Sau, die seit ein paar Jahren durch wirklich jedes Dorf getrieben wird. An anderer Stelle gehört: „Das ist dafür da, um unerfahrene Entwickler eng an der Leine zu halten und zu steuern, selbständiges und eigenverantwortliches Arbeiten ist nicht kompatibel“. Also bin ich da auch tendenziell erstmal auf Abstand gegangen.

Aber das alles hat sich jetzt geändert: Vor ca. drei vier fünf Wochen (erstmal habe ich etwas gebraucht, um das alles zu verdauen; danach habe ich mit dem Blogartikel getrödelt) hatte ich insgesamt fünf Seminartage:

• 1 Tag Scrum-Grundlagen
• 1 Tag Test Driven Development
• 3 Tage Agile Softwareentwicklung

Soviel schon vorweg: Fünf ausgesprochen positive Seminartage!

Scrum

Die Grundkonzepte agiler Projekte waren mir bekannt, aber alles nur so vom Hörensagen und mündlich überliefert. Aktuell stecke ich in einem agilen Projekt, das für mich und einige andere Mitarbeiter das erste agile Projekt ist. Dementsprechend gut läuft das alles :-)

Seit dem Seminar sind wir mit theoretischem Hintergrund gestählt und können das in der Zukunft nutzen, um uns das im Projekt etwas schöner zu machen: Wir wissen jetzt, warum und wieso und wozu die Dinge so sind, wie sie sind, und was wir noch für Optionen haben.

Das hat auf jeden Fall optimistisch gestimmt und meine ganze Schwarzseherei zu dem Thema „agil“ auch gut abgedämpft. Möglich ist einiges; was man draus macht, hat man dann selber in der Hand.

Test Driven Development

Hier ging’s mit Java und Programmieren los: Allgemeine Einführung in Test Driven Development, dazu aber auch so grundlegende Dinge wie Code Dojos und Katas, die uns dann an den Folgetagen begleiten sollten. Erste Vorstellung von Pair Programming, erstes Ausprobieren der Techniken „auf dem Trockenen“.

Agile Software Engineering

Diese drei Tage hatten es dann in sich: In fünf Sprints haben wir eine kleine Anwendung weiterentwickelt und gepimpt und dabei jeweils abwechselnd Fokus auf verschiedene Dinge gelegt: Stories kleinschneiden, Refactoring, Abhängigkeiten zwischen den einzelnen Programmierteams, Continuous Integration usw.

Mich hat vor allem beeindruckt, wieviele echte Probleme sich an dem Beispielprojekt haben aufzeigen lassen:

• missverständliche Anforderungen
• vorab gut platzierte Fehler, die sich dann zeigen, wenn an einer ganz anderen Stelle etwas Unschuldiges geändert wird
• Probleme durch fehlende Absprachen untereinander
• Merge-Hölle für die, die nicht oft und früh genug einchecken

Da hat bestimmt jemand jahrelang an diesem Mini-Beispiel geschraubt, das ist genial.

Wir haben den ganzen Tag über intensiv Pair Programming betrieben, generell überzogen und an zwei Abenden noch ein freiwilliges Code-Dojo drangehängt: Das macht Spaß, geht aber echt an die Substanz. Ich habe die Tage zu Hause noch was gegessen, vielleicht eine Kleinigkeit ausprobiert (Cucumber für Perl) und mir dann eine Stunde Diablo zum Kopf-Leeren gegeben - mehr war nicht drin. Ich war echt so platt wie schon lange nicht mehr!

Genau wie schon Ende letzten Jahres, als ich spontan in den Selbstlern-Zaubertopf mit Gradle, Jenkins und Mockito geworfen wurde (mit dem ganzen Krams hatte ich vorher nie zu tun; seitdem nutzen diverse meiner github-Projekte Travis-CI und Codecov…), konnte ich förmlich dabei zugucken, wie sich mein Gehirn einmal umgekrempelt hat, um die ganzen neuen Denkansätze zu verstauen.

Und es gab viel Neues und viel zu verdauen. Input Input Input! Alleine schon was ich durch das Pair Programming alles an Eclipse-Tastenkürzeln gelernt habe, spart mir seitdem täglich Zeit. Ich habe jetzt sogar wieder von meiner hochheiligen Emacs-Tastenbelegung zurück zum Eclipse-Standard gewechselt, damit ich leichter bei anderen abgucken kann und die bei mir nicht wahnsinnig werden, wenn wir uns die Tastatur teilen. (Ich warte drauf, dass ich das zu Hause öfter brauche, dann muss ich noch einen Key-Lock-Modus in meinen Windowmanager einbauen, damit dessen Kürzel nicht den die Eclipse-Kürzeln in die Quere kommen.)

Fazit

Mein Fazit: Trotz des ganzen Hypes ist das in sinnvollen Dosen alles sehr nützlich.

Nicht jedes Projekt ist ein Nagel, das man mit agilem Vorgehen als Hammer bearbeiten sollte. Und man muss nicht sofort alles auf 100% Test Driven umstellen, aber ich habe sinnvolle Ansätze mitgenommen, wie man etwas Mocking unsere Unittests schöner bekommt oder das man zur Abwechselung von Zeit zu Zeit einfach mal Pair Programmen sollte (auf dem Plan stand eigentlich ein „Pair Powerpointing“, aber wie so oft ging das im Alltag unter). Und wenn es mal ganz gut kommt, stürmen wir an einem Freitag Nachmittag mal mit ein paar Leuten einen Raum mit Beamer und geben uns eine Stunde Code Dojo. Kann man immer was bei lernen.

Ich bleibe dabei, dass das alles sektenhafte Züge hat (den Certified Scrum Developer muss ich in zwei Jahren auffrischen, das ist bestimmt kostenpflichtig!), aber jetzt bin ich Teil des Systems und muss sagen, dass es auf dieser Seite der Hecke auch grünes Gras gibt. Man kann was Sinnvolles mitnehmen und es zwingt einen ja keiner, das ständig zu benutzen. Dass es im Scrum-Seminar von sich aus hieß „Scrum lohnt sich nicht per se für jedes Projekt“ zeigt mir exemplarisch, dass das nicht alles komplett abgehobener Hipsterkrams ist, sondern durchaus bodenständige Ansätze hat :-)

Kann man mal machen, das alles.

Und überhaupt sollte man auch böse neue Dinge mal genauer betrachten, immerhin ist die IT-Branche ja im ständigen Wandel (was nicht heißt, dass man jedem neuen Trend sofort hinterherlaufen muss). Und wenn ich jetzt höre, dass wir ein Code Dojo für Testgetriebene Entwicklung mitsamt webbasierten automatischen Testtreibern für unsere COBOL-Programme aufsetzen, dann regt sich in mir auch der kleine Nerd.

(Und yay, diesen Sommer tummele ich mich sogar auf der SoCraTes 2016.)