Effektive Praktiken für eine erfolgreiche Softwaretransition

In der Softwareentwicklung wünschen wir uns oft ein stabiles Team, das von Anfang bis Ende an einem Produkt arbeitet. Doch in der Realität kommt es häufig vor, dass ein Software-System an ein neues Team übergeben wird, sei es aufgrund von Wechseln in den Zuständigkeiten oder bei der Einführung neuer Lieferanten. Dieser Übergang wird als Transition bezeichnet. Die Frage ist nun, wie man diese Transition optimal gestalten kann. Glücklicherweise können wir hier auf verschiedene Praktiken der agilen Softwareentwicklung zurückgreifen. Agile Softwareentwicklung legt großen Wert auf gut funktionierende Teams und fördert den effektiven Wissens- und Fähigkeitsaufbau im gesamten Team.

Im Folgenden werde ich fünf Praktiken vorstellen, die besonders im Kontext von Transitionen wirksam sein können. Um diese Praktiken effektiv anzuwenden, empfehle ich, während der Transition ein gemeinsames Team aus alten und neuen Teammitgliedern zu bilden. Im Laufe der Zeit können dann nach und nach die alten Teammitglieder das Team verlassen, um einen sanften Übergang zu ermöglichen.

Pair Programming – eine Praktik für zwei Personen

Beim Pair Programming arbeiten zwei Entwickler an einem Arbeitsplatz, um gemeinsam Code zu entwickeln. Dabei folgen sie einem festgelegten Interaktionsmuster, wie zum Beispiel dem Driver-Navigator-Muster. Dabei programmiert eine Person (Driver), während die andere Person das Design überprüft und Feedback gibt (Navigator). Die Rollen wechseln in kurzen Zeitabständen, oft mehrmals pro Stunde.

Im Kontext von Transitionen kennt man seit vielen Jahren das Prinzip des Shadowing und Reverse-Shadowing. Im Vergleich zum traditionellen Shadowing bietet Pair-Programming jedoch einen wesentlichen Vorteil:

• Beim Shadowing übernimmt eine Person eine passive Rolle, was oft in der Praxis zu stundenlangem Zuschauen mit gelegentlichen Rückfragen führt. Echtes Können wird aber erst im konkreten Handeln aufgebaut. Beim Pair Programming wird dies durch regelmäßigen Wechsel der Driver- und Navigator-Rolle sichergestellt. Zudem greift auch der Navigator durch sein kontinuierliches Feedback aktiv in die Entwicklung ein.

Im Kontext einer Softwaretransition sollte das neue Teammitglied in der Driver-Rolle beginnen und von Anfang an ins Handeln kommen, anstatt nur passiv zuzuschauen. Da oftmals zwischen dem Tandem große Wissens- und Erfahrungsunterschiede existieren, ist es wichtig, dass der Navigator immer wieder den Kontext vermittelt. In manchen Fällen kann es sich zudem lohnen, die Pairing-Session an einem Whiteboard zu beginnen, oder mit einem gemeinsamen Blick in die Systemdokumentation zu starten.

Eine interessante Alternative zum Pair Programming stellt übrigens Mob Programming dar. Bei dieser Praktik arbeiten weitere Personen und manchmal auch das gesamte Team an einem Arbeitsplatz. Eine Person ist der Driver, alle anderen sind Navigator. Mob Programming kann gerade zu Beginn einer Softwaretransition für einen initialen Wissenstransfer sorgen.

Testgetriebene Entwicklung – wirklich praktisch

Bei der testgetriebenen Entwicklung bzw. dem Test-Driven Development (TDD) werden Tests zur Steuerung der Softwareentwicklung genutzt. Der Ablauf der Praktik ist zyklisch:

• Für ein Stückchen Funktionalität wird ein Unit-Test geschrieben, der zunächst fehlschlägt, da die Implementierung der Funktionalität noch nicht existiert.
• Es wird soviel Code implementiert, dass der Unit-Test erfolgreich durchläuft.
• Bei Bedarf werden Test und Code reviewt und einem Refactoring unterzogen.

Bei testgetriebener Entwicklung geht es jedoch nicht nur darum, eine hohe Testabdeckung mit Unit-Tests zu erreichen; die Unit-Tests stellen eher einen sehr wertvollen Seitennutzen dar. Durch das Schreiben eines Tests vor der eigentlichen Implementierung verstehen neue Teammitglieder die Aufgabenstellung besser, da die Intention der Implementierung klar ersichtlich wird. Zudem macht das Arbeiten in kleinen Schritten die Komplexität für alle Beteiligten handhabbarer.

In der Praxis erweist sich die konsequente Anwendung von TDD in Verbindung mit Pair Programming als extrem nützlich. Idealerweise schreibt ein Mitglied des alten Teams die Unit-Tests, während eine Person des neuen Teams die Implementierung des Codes übernimmt. Ein zusätzlicher Vorteil ist die größere Sicherheit bei Anpassungen von bestehendem Code, da die vorhandenen Unit-Tests schnelle Rückmeldungen für die Implementierung bieten. Testgetriebene Entwicklung im Rahmen einer Transition ist also wirklich praktisch.

Der Austausch in Retrospektiven

Kennen Sie die Situation, dass Transitionen nach dem Prinzip “Augen zu und durch” ablaufen? In der Praxis konnte ich schon mehrfach beobachten, wie ein Ablaufplan fixiert und abgearbeitet wurde, allerdings unabhängig davon, wie gut oder schlecht die Transition tatsächlich voranschritt.

Retrospektiven können ein wertvolles Mittel sein, um innezuhalten, und gemeinsam mit dem Team zu reflektieren, wie die Transition tatsächlich vonstattengeht. Nutzt ein Team bereits die Retrospektive als Hilfsmittel zur Verbesserung der Zusammenarbeit, dann ist es naheliegend, auch aktiv über die Transition zu sprechen. Wichtig ist dabei, den Fokus explizit auf die Transition zu richten, sodass der Austausch thematisch nicht zu breit wird.

Für Teams, die noch nicht im Rahmen ihrer Methodik mit Retrospektiven arbeiten, kann dies ein guter Ausgangspunkt für einen regelmäßigen Austausch sein. In solchen Fällen werden sich die ersten Retrospektiven thematisch mit der Transition beschäftigen, wobei die Hoffnung besteht, dass das Team diese grundsätzlich wertvolle Praktik auch nach der Transition beibehält.

Done Done – die vereinbarte Qualität

Done Done bedeutet, dass ein Team eine klare, explizite Vereinbarung darüber trifft, welche Arbeiten zur Fertigstellung einer neuen Funktionalität benötigt werden. Die Definition of Done (DoD) ist eine solche Vereinbarung, die in zweierlei Hinsicht hilft:

1. Sie unterstützt Mitglieder des neuen Teams dabei, glasklar zu verstehen, welche Tätigkeiten nötig sind, um eine Funktionalität fertigzustellen. So wird verhindert, dass Aktivitäten des alten Teams, wie bspw. die Erstellung einer Systemdokumentation oder die Verwendung von Unit-Tests, vom neuen Team einfach weggelassen werden.
2. Sie hilft zu erkennen, wo die Transition wirklich steht. Das Liefern von produktiver Software, die sämtliche Qualitätskriterien der Definition of Done erfüllt, ist eine harte Währung, die sich im Gegensatz zu vielen anderen Methoden nicht so einfach fälschen lässt.

Die Erfahrung zeigt, dass ein neues Team, das bereits aktiv eine Definition of Done im Zuge der Entwicklung von Software nutzt, häufig Grund zum Optimismus liefert. Da es sich bei der DoD auch um ein “lebendiges” Dokument handelt, empfiehlt es sich in der Praxis, die Kriterien zyklisch zu hinterfragen und ggf. anzupassen, bspw. wenn das neue Team Punkte identifiziert, die es nicht zu leisten vermag.

Ubiquitous Language – die Praktik der allgegenwärtigen Sprache

Zahlreiche Transitionen finden in einem internationalen Umfeld statt. Babylonische Sprachverwirrung herrscht aber leider häufig nicht nur bei den natürlichen Sprachen, sondern auch bei den Ausdrücken, die Teammitglieder untereinander verwenden.

Ubiquitous Language, eine Technik aus dem Domain Driven Design, schafft hier Abhilfe. Sie schlägt vor, dass sich alle Teammitglieder innerhalb eines bestimmten Kontexts auf gemeinsame, durchgängig zu verwendende Ausdrücke einigen. Idealerweise leiten sich die Ausdrücke aus der fachlichen Domäne, z. B. einem Domänenmodell, ab.

Angenommen, ein Team hat die Aufgabe, aus einer Beschreibung von Musik Notenblätter in XML zu generieren. Die Ubiquitous Language des Teams sollte sich nicht um XML-Begriffe wie Entitäten, Elemente oder Attribute drehen, sondern Begriffe wie Partitur, Stimme, Notensystem, Notenschlüssel, Notenzeichen usw. verwenden.¹

Die Praxis von Transitionen zeigt immer wieder, dass zu Beginn eines Vorhabens niemand davon ausgehen sollte, dass alle Personen das gleiche Verständnis von bestimmten Begrifflichkeiten besitzen. Es ist wichtig, den Mitgliedern des neuen Teams eine gemeinsame Sprache zu vermitteln, denn dies erleichtert sowohl die Kommunikation untereinander als auch mit Stakeholdern. Hier obliegt es den Mitgliedern des alten Teams, neue Personen auf ihre ggf. unscharfe oder fehlerhafte Begriffsverwendung hinzuweisen.

Ohne die Verwendung einer Ubiquitous Language ist Verwirrung vorprogrammiert. Neue Teammitglieder wissen mit Begrifflichkeiten des alten Teams wenig anzufangen, oder – was noch gravierender ist – sie interpretieren die Begriffe unterschiedlich. Immer wieder sorgt dies für Missverständnisse und fehlerhafte Implementierungen können die Folge sein.

Fazit

Die Anwendung der fünf Praktiken

• Pair Programming,
• testgetriebene Entwicklung,
• Retrospektiven,
• Done Done und
• Ubiquitous Language

haben mir in mehreren Transitionen wertvolle Dienste geleistet. Für sich genommen bietet jede einzelne Praktik zahlreiche Vorteile, in der Kombination der Praktiken entfalten sie zudem eine ganz besondere Dynamik.

Natürlich bewähren sich die Praktiken nicht nur in Transitionen: Sie leisten grundsätzlich einen Beitrag bei der Entwicklung guter Software. Und gute Software lässt sich wiederum einfacher an neue Teams übergeben. Sie profitieren also zweifach von den Praktiken. Probieren Sie es einfach bei nächster Gelegenheit aus.

Hinweise:

Wollen Sie sich mit Jonathan Frankenberger über agile Arbeitsweisen, Machine Learning oder Softwareentwicklung austauschen? Leicht können Sie mit ihm über LinkedIn Kontakt aufnehmen.

[1] Das Beispiel stammt aus “The Art of Agile Development”, 2. Auflage 2021, Seiten 329-331

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.