Testgetriebene Entwicklung lernen

Viele Unternehmen, die sich im agilen Ökosystem bewegen, arbeiten mit entsprechenden unterstützenden Engineering Practices. Eine davon ist die testgetriebene Entwicklung.

Im Rahmen der Study Group können Mitarbeiter sich gemeinsam weiterbilden und zu gewünschten Themen auch projektübergreifend austauschen. Nach der Abstimmung beim Kickoff, hat sich die Gruppe für eine Vertiefung in testgetriebener Entwicklung (TDD) entschieden.

Ich habe eine kurze definierte Agenda vorbereitet, um der Gruppe viel Raum zu geben, Inhalte und Quellen zu identifizieren. Sehr erkenntnisreich war ein Scaling Dance zum Thema „Wieviel Kenntnisse sind zum Thema bereits vorhanden?“ und „Wieweit möchten wir überhaupt bei dem Thema kommen?“. Es entstand so schnell ein Bild davon, wo die Gruppe steht und bis wo die Entwicklung reichen soll.

Ausgehend von dieser Erwartungshaltung haben wir mit verdeckter Stichwortabfrage und anschließender Priorisierung den folgenden Weg beschlossen:

  • Gemeinsames Lesen von Roy Osheroves Buch „The Art of Unit Testing
  • Zum Sinn von Unit Tests Blogdiskussion von Golo Roden und Ralf Westphal (Beitrag 1, Beitrag 2, Beitrag 3)
  • Einen Überblick über TDD und BDD Frameworks zusammenstellen
  • Ein oder mehrere Coding Dojos veranstalten mit dem angelesenen Wissen

Die Gruppe hat noch deutlich mehr Ideen gesammelt, die zur Vertiefung danach weiter verfolgt werden können. Von Fachartikeln über die Einladung anderer erfahrener Entwickler waren noch weitere schöne Ideen dabei.

An dieser Stelle interessiert mich natürlich: Was sind Eure wertvollsten Ressourcen, um TDD zu lernen?

Wie Scrum die Softwarequalität erhöht und warum der ScrumMaster selten Quellcode liest

Wenn man Scrum erklärt, biegt bei vielen Beschreibungen irgendwann das magische Projektmanagementviereck um die Ecke. Während bei Projekten generell die vier Eckpfeiler Kosten, Funktionsumfang, Zeit und Qualität zur Disposition stehen, sagt Scrum von sich selbst, das Qualität keine verhandelbare Option ist. Unter Projektdruck ist es nicht ungewöhnlich, dass Refactorings unter den Tisch fallen, Dokumentationen weggelassen und Umbauten vermieden werden. Hier sagt diese agile Methode, dass dies nicht passieren darf, um auch langfristig Wert zu schaffen.

Wer korrekt nach Scrum produziert, baut also keine schlechte Software mehr? So einfach ist es natürlich nicht. Hier lohnt es sich, einmal genauer hinzusehen: Wie kann ein solches Framework technische Qualität sicherstellen? Ist ein ScrumMaster ein getarnter Tester, der heimlich beim Abnahmemeeting für den fachlich Verantwortlichen in den Quelltext schaut, ein Code Review macht und mit einem dezenten Lächeln oder mürrigem Dreinblicken dem Product Owner heimlich mitteilt, wie das Team gearbeitet hat?

Guckt man in die Literatur, so hat der ScrumMaster erstmal die Verantwortung für die Prozessqualität. Von technischen Fähigkeiten oder gar Quellcodelesen steht da nichts. Wie kann also durch eine hohe Prozessqualität eine hohe Softwarequalität erreicht werden? Klare Sache: Die Antwort muss in den Prozessbestandteilen zu finden sein.

Bestandteil 1: Potentiell auslieferbare Produkt- / Projektinkremente
Nach dem Ende einer Iteration (also in der Regel nach zwei oder vier Wochen) hat ein Scrum Team eine potenziell auslieferbare Software produziert. Was bedeutet das? Der Anspruch ist hier: Auf CD brennbar, ausrollbar, verkaufbar… Alles, was die Software betrifft, muss erledigt sein. Der ScrumMaster bestärkt den Product Owner darin, Unfertiges abzulehnen und zur Nacharbeit zu geben.

Die „offensichtliche Ware“ ist also sauber. Wie sieht es nun mit dem Innenleben aus?
Hier hängt es maßgeblich vom Team und seiner Erfahrung ab, inwieweit Refactorings durchgeführt wurden, Quellcode bereinigt ist, Module getestet sind. Um so weniger technisches Qualitätsbewußtsein im Team vorherrscht, umso weniger Qualität wird ein Team liefern.

Ist es Aufgabe vom ScrumMaster, sein Team zu mehr technischer Qualität zu bewegen? Jein.  „Technische Schulden“, versäumte Refactorings, schlechte Architekturen  – sie werden durch Scrum sichtbar. Die Geschwindigkeit des Teams wird zum Beispiel geringer, einfache Features liefern riesige Schätzwerte, der Burndowngraph stagniert, am Iterationsende wird nicht geliefert.

Die Aufgabe des ScrumMasters ist es dann, dem Team zum Erkenntnisgewinn zu verhelfen und es darin zu unterstützen, besser zu werden. Findet das Team dann eine gute technische Lösung und die richtigen Maßnahmen? Wir vertrauen ihm und bitten es um Ideen, verfolgen die Umsetzung.

Bestandteil 2: Regelmäßige Auslieferung
Wer verteilte Systeme, interagierende Komponenten, unterschiedliche Bestandteile konstruiert, muss diese irgendwann integrieren und testen.  Hier können viele Probleme im Detail liegen. Um so häufiger hier eine Integration durchgeführt wird, um so sicherer kann das Team sein: Das läuft in der Praxis.

Bestandteil 3: Kanalisierte Kommunikation
Scrum definiert Kommunikationswege und Besprechungen, bringt Ideen für Artefakte mit, die helfen sollen, Anforderungen zu transportieren. Wenn Entwickler keinen Zugang zu weiteren Informationen einer Problemstellung haben, bleibt ihnen häufig nichts anderes übrig, als Annahmen zu treffen.

Scrum minimiert die Anzahl getroffener Annahmen auf ein Minimum, indem es die Kommunikation zwischen Product Owner und Team forciert. Geht man davon aus, dass intensivere Kommunikation eher zu dem gewünschten Produkt führt als ratende Entwickler, erhöht Scrum auch hier die Qualität.

Unbestandteil:  Automatisiertes Testen, kontinuierliche Integration
Scrum schreibt keine technischen Praktiken vor. Das viele der agilen Praktiken aus Extreme Programming eine sinnvolle Ergänzung sind, ist mittlerweile klar. Aber wer bringt nun dem Team TDD, kontinuierliche Integration, Collective Code Ownership und Buildmanagement bei?

Der ScrumMaster ist hiermit zu Recht in der Regel überfordert. Kann er das wissen vermitteln: Prima. Ansonsten kann zum Beispiel auch ein externer Coach mit einem starken Entwicklungshintergrund dazugezogen werden.

Fazit: Scrum sichert Softwarequalität durch seine Prozesselemente. Wie es dem Innenleben einer Software geht, wird nicht durchleuchtet. Die entstehenden Graphen zum Projektfortschritt spiegeln jedoch diese Qualität wieder. Der Rest ist Vertrauen in die Mannschaft. Wünscht das Team bei gewählten Maßnahmen Unterstützung, gibt es viele Lernarten, wie zum Beispiel die Study Group oder ein externer Coach.

Reflektion des Study Group Kickoffs

Vor dem 1. Treffen der Study Group habe ich die Dramaturgie der Kickoff Besprechung erarbeitet. Die Besprechung war für eine Stunde angesetzt, sie hat eine Stunde und 10 Minuten letzendlich gedauert. Es haben 8 Mitarbeiter teilgenommen, einige Teilnehmer waren verhindert.

Inhalt Dauer Ziel Methode
Willkommen 2 min Ankommen
Checkin: Was erwartest Du von dieser Study Group? (1 Satz) 8 min Erwartungen klären Speech Token
Mögliche Themen identifizieren 10 min Themenüberblick VSA
Zusammenführen am Whiteboard 10 min Gefundene Elemente zusammenführen Klumpenbildung
Prioritäten klären 5 min Top 10 zusammenstellen Mehrpunktabfrage Option/2 und max. 2 Punkte je Option
In Liste übertragen 5 min Reihenfolge festhalten Sortierte Liste
Thema wählen 3 min Thema aus der Liste akzeptieren Thumbvoting
Arbeitsmittel und Quellen für Thema 1 12 min Arbeitsmittel und Quellen identifizieren OSA
Rahmenbedingungen 3 min Einigung auf Ort, Intervall und Länge Vorschläge mit Thumbvoting
Checkout 2 min Unterlagen auf Sharepoint kommunizieren

Der Checkin war thematisch etwas unklar, hier musste ich nachsteuern, um den Fokus auf das Ergebnis auf einer höheren Ebene zu bringen, da es noch nicht um konkrete Inhalte geht. Beim nächsten Mal werde ich etwas weiter ausführen, was ich von der Gruppe möchte und ein Beispiel anbringen.

Ich habe zum ersten mal die Adhäsionsfolien als Whiteboardersatz verwendet, da kein Whiteboard mehr frei war. Die Drag & Drop Funktion ist zum Clustering wirklich praktisch, einzig der Preis der Karten schreckt mich noch ein wenig ab. Außerdem ließ sich eine Folie nicht richtig gut säubern und kein Boardcleaner war in Reichweite. Ansonsten ein wirklich tolles Werkzeug für die Moderation.

Die grundlegende Agenda hat sehr gut funktioniert, jedoch stellte sich beim Brainstorming über den am höchsten priorisierten Punkt ein großer Gesprächsbedarf heraus und die Gruppe war sich nicht einig, ob das Thema einer Study Group gerecht wird und der richtige Teilnehmerkreis anwesend sei.

Hier merkte ich schnell in mir das Spannungsfeld zwischen „der Gruppe Raum zur Diskussion geben“ und einen Zeitplan als Moderator einhalten. Mit verschiedenen Angeboten an die Gruppe konnten wir uns dann einigen, das zweitwichtigste Thema als nächsten Punkt anzugehen, damit wir für das wichtigste Thema etwas mehr Vorlaufzeit haben.

Die nächsten Treffen werden sich also um testgetriebene Entwicklung (TDD) drehen, wobei die Herausforderung sein wird, auch gewinnbringende Informationen für den Office-Entwicklungsbereich zu finden.

Als Verbesserungspotential für meine Moderation habe ich die nachstehenden Punkte heute mitgenommen:

  • Wissen Vertiefen in der Gruppendynamiksteuerung
  • Weitere Methoden zur Konsenzfindung in Gruppen
  • Gruppenergebnisse besser konservieren
  • Checkout bewußter durchführen

Ich werde die Besprechung und deren Ergebnisse, die ich zwischenzeitlich fotografiert habe, im Nachgang noch aufbereiten und der Gruppe zur Verfügung stellen.

Study Group: Gemeinsam lernen

Mein Kunde Softwarekontor hat mich beauftragt, eine Study Group zu initiieren. Bei diesem Format geht es um gemeinsame Weiterbildung und Austausch zu definierten Themen.

Das ganze funktioniert so:

  • Auswahl eines Lernbereichs
  • Auswahl von passenden Quellen (Webseiten, Bücher, Demos, Quellcode, Webcasts)
  • Definition, wie das Wissen erschlossen werden soll (Lesen in Vorbereitung oder vor Ort, Buchtausch alle 15 Minuten, Durchstöbern…)
  • Ermittlung des passenden Intervalls und der Länge eines Treffens
  • Erstellen einer Roadmap für alle Treffen zu dem Thema (optional)
  • Einigung auf eine Agenda für das nächste Treffen

Einen weiteren Tipp gab mir Deborah hierzu: Hat man mehrere Bücher zu einem Thema bietet sich an, diese erstmal gemeinsam zu sichten:

  • Jeder nimmt sich ein Buch für 15 Minuten, liest darin, was er möchte. Das kann ein Kapitelanfang sein, das Inhaltsverzeichnis, Skimmen einiger Seiten
  • Danach stellt jeder das gelesene den anderen aus seiner Sicht dar
  • Danach tauscht man die Bücher untereinander nochmal aus und wiederholt die obigen Schritte

Als Ergebnis hat jeder einen Überblick über das Lernmaterial, kann es grob beurteilen und per Konsenz kann entschieden werden, welches Material verwendet wird.

Entschließt sich das Unternehmen kostenfrei Getränke und ein paar Snacks oder direkt einige Pizzen zu ordern, wird aus einer Study Group schnell eine tolle Plattform des innerbetrieblichen Austauschs und der Teamentwicklung.