Test Driven Development erfolgreich in Projekten einsetzen
Test Driven Development (TDD) ist schon länger aus der Ecke der exotischen Spinnereien in die Liga der anerkannten Arbeitstechniken aufgestiegen. Es gibt viele Schulungen und Weiterbildungen oder "Community Events" wie "Coding Dojos" und "Code Retreats", in denen Entwickler TDD aus eigenem Antrieb heraus trainieren. Trotzdem wird TDD kaum in echten Projekten eingesetzt. Warum ist das so?
Mit diesem Artikel möchte ich aufzeigen, welche Einflussfelder für ein TDD-freundliches Umfeld wichtig sind und wie sie gestaltet werden können, um den langfristigen und erfolgreichen Einsatz von TDD in der Softwareentwicklung zu fördern.
Viele Organisationen haben bereits erkannt, dass Test Driven Development (TDD) zur Verbesserung der Code-Qualität und in der Folge zu höherer Termintreue in lang laufenden Projekten führt. Sie sind sogar bereit, TDD-Schulungen für ihre Entwickler zu organisieren. Aber reicht es aus, einzelne Entwickler mit dem notwendigen Wissen auszustatten, damit TDD in Projekten langfristig erfolgreich zum Einsatz kommt?
Die Antwort ist: Nein. Grenny, Patterson, Maxfield, McMillan und Switzler beschreiben in ihrem Buch "The Influencer" ein wichtiges Phänomen: "For every behavior you see the world around that person is perfectly designed for that behavior to happen." [1]
Verhaltenseinflüsse
| Motivation | Fähigkeiten | |
|---|---|---|
| persönlich | Ist die Person vom positiven Verhalten überzeugt? | Ist die Person physisch in der Lage, positives Verhalten zu zeigen bzw. negatives Verhalten zu vermeiden? |
| Unternehmen (Umgebung) | Reagieren die Gruppenmitglieder direkt auf negatives Verhalten? | Folgt die Person anderen, die negatives Veralten zeigen? |
| Gruppe (sozial) | Unterstützt die Organisation negatives Verhalten, bzw. wird positives Verhalten nicht unterstützt? | Fördern die physikalischen Bedingungen negatives Verhalten? |
Demnach liege es also nicht nur am jeweiligen Entwickler, wenn dieser nicht TDD betreibt. Die Autoren beschreiben sechs Einflussfaktoren, die das Verhalten einer Person in eine bestimmte Richtung lenken. Diese Einflussfaktoren ergeben sich aus der Kombination von Fähigkeiten und physischen Voraussetzungen auf der einen und motivatorischen Aspekten auf der anderen Seite, die innerhalb der Organisation auf verschiedenen Ebenen angesiedelt sind.
Welche Konsequenzen ergeben sich aus diesen Einflussfaktoren für die Softwareentwicklung und den Einsatz von TDD als Arbeitsmethode? Wie können Unternehmen in ihren Projekten ein Umfeld errichten, in dem TDD einen festen Platz hat?
TDD-freundliches Umfeld
Persönliche Motivation
Ist der einzelne Entwickler vom TDD überzeugt? Und warum ist es wichtig, dass jeder Entwickler die Vorteile des TDD für sich persönlich erkennt und TDD als Arbeitsmethode für sich annimmt?
Der Grund dafür ist, dass Softwareentwicklung ein kreativer Prozess ist. Jede Form von von außen ausgeübten Drucks ist hier wenig zielführend, weil dieser Druck Widerstände erzeugt, die kognitive Ressourcen beanspruchen oder in die falsche Richtung lenken. In meinen Projekten habe ich erlebt, dass Kollegen, die nicht hinter der Idee des TDD standen, und daher die Erstellung von Unitests als notwendiges Übel ansahen, die Tests zu formalistisch und nicht in der notwendigen Granularität erstellten, sodass die Tests als Dokumentation bzw. als Hilfsmittel zur Fehlersuche unbrauchbar waren. Zudem waren die "mit Druck von oben" erstellten Unitests oft zu stark mit der Implementierung gekoppelt und behinderten so das Refaktorisieren des Produktionscodes, das sie ja eigentlich fördern sollten.
Als beste Motivation für den Einsatz von TDD gelten positive Erfahrungen. Schulungen und Community Events sind dazu leider weniger geeignet, weil dort zwar TDD als Lösungsweg trainiert wird, dies aber üblicherweise "auf der grünen Wiese" geschieht. Die positiven Erfahrungen muss der Entwickler also in echten Projekten sammeln, in denen TDD bereits erfolgreich eingesetzt wird. Eine Möglichkeit wäre, einen ungeübten Entwickler als Partner im sogenannten Pair Programming einzusetzen, wo er TDD von einem "alten Hasen" lernen kann. Das klingt nach einem "Henne/Ei"-Problem. Und das ist es auch. Wie Unternehmen dieses Problem in der Praxis sinnvoll lösen können, beschreibe ich weiter unten (Motivation der Gruppe).
Persönliche Fähigkeiten
Ist der einzelne Entwickler in der Lage, TDD einzusetzen?
Wie eingangs erwähnt sind immer mehr Unternehmen bereit, ihre Entwickler zu den Themen Unitests und TDD weiterzubilden. Allerdings müssen die Entwickler diese Fertigkeiten, die sie in der Praxis benötigen, ständig weiterentwickeln und verbessern. Gerade in Organisationen, in denen TDD noch nicht zum Projektalltag gehört, ist es darum wichtig, dass Entwickler die Anwendung von TDD regelmäßig üben, zum Beispiel im Rahmen von Community Events wie Coding Dojos [2] und Code Retreats [3]. Dabei sollten Entwickler die Gelegenheit zur Teilnahme an solchen Veranstaltungen auch außerhalb ihrer Arbeitszeit wahrnehmen. Letztendlich liegt Weiterbildung auch ein Stück weit in ihrer eigenen Verantwortung.
Motivation der Gruppe
Wie verhält sich das Team gegenüber einem Mitarbeiter, der kein TDD einsetzt?
Solange ein Entwickler zu seiner konventionellen Arbeitsweise keine negative Rückmeldung aus dem Team bekommt, wird er sich nicht entschließen, seine Arbeitsweise zu ändern. Dabei ist entscheidend, dass eine solche Rückmeldung nicht nur vom Teamleiter kommt, sondern dass das Team als Ganzes deutlich macht, dass es den Einsatz von TDD von jedem Teammitglied erwartet. Wenn ein Team die konventionelle Arbeitsweise einzelner Mitglieder zu lange toleriert, werden die Argumente gegen den Einsatz von TDD mit der Zeit höchstwahrscheinlich zunehmen und TDD würde immer weniger genutzt.
Für ein Unternehmen kann es deshalb hilfreich sein, seine Teams so zusammenzustellen, dass "TDD-Verweigerer" in den Projekten, in denen TDD eingesetzt werden soll, in der Unterzahl sind. Damit verschiebt sich die Gruppendynamik in Richtung TDD. Im Umkehrschluss bedeutet das aber auch, dass es immer noch Projekte mit "klassischem" Vorgehen geben muss, solange im Unternehmen der Anteil jener Mitarbeiter, die TDD einsetzen wollen und können, nicht signifikant überwiegt.
Fähigkeit der Gruppe
In vielen Teams gibt es eine Person, die die Teammitglieder besonders respektieren und an deren Verhalten sich die anderen orientieren. Für den erfolgreichen Einsatz von TDD sind die Motivation und die Fähigkeiten dieser Person entscheidend. Das Problem kann sein, dass die Rolle eines solchen "Leitwolfs" nicht unbedingt eine Personalunion mit dem Teamleiter bildet. Hier spielen gruppendynamische Prozesse eine große Rolle. Daher muss es Aufgabe der dem Team übergeordneten Hierarchie sein, diese gruppendynamischen Prozesse im Team zu verfolgen und ggf. Änderungen in der Zusammensetzung des Teams vorzunehmen, falls eine "graue Eminenz" das Team gegen TDD einnehmen sollte.
Motivation der Organisation
Die zentrale Frage für den erfolgreichen Einsatz von TDD ist nicht nur, ob das Unternehmen den Einsatz von TDD motiviert, sondern auch, ob das Unternehmen – möglicherweise unabsichtlich – eine konventionelle Arbeitsweise immer noch in irgendeiner Weise belohnt.
Die Antwort auf diese Frage ist oft nicht so eindeutig, wie es auf den ersten Blick scheint. Hat der Einzelne tatsächlich Nachteile, wenn er nicht TDD einsetzt? Dabei geht es nicht um finanzielle oder disziplinarische Konsequenzen. Viel wichtiger ist, dass diese Mitarbeiter im täglichen Projektgeschäft spüren, dass solche (konventionellen) Arbeitsweisen unerwünscht sind. Dabei kann das Unternehmen schon viel erreichen, wenn es bei der Zusammenstellung der Projektteams die Hinweise aus den Abschnitten 2.3 und 2.4 berücksichtigt.
Für einzelne Entwickler, die noch nicht bereit sind, ihre konventionelle Arbeitsweise abzulegen, könnte darüber hinaus eine wirksame Konsequenz sein, nicht eigenständig an neuen Funktionalitäten arbeiten zu dürfen, oder seine Änderungen einem strengeren Review in seinem Beisein zu unterwerfen.
Damit solche Maßnahmen ihre bestmögliche Wirkung entfalten, sollten sie im Rahmen eines formalen Prozesses im gesamten Unternehmen kommuniziert und in allen (TDD-)Projekten praktiziert werden. Die Maßnahme wird ihre Wirkung verfehlen, wenn der Betroffene sie als persönliche Bestrafung oder gar als Mobbing empfindet.
Die Motivation des Unternehmens zeigt sich auch darin, ob das Unternehmen bereit ist, TDD-Projekten genügend Ressourcen für die Umsetzung solcher Maßnahmen bereitzustellen und unternehmensweit Regelungen zu 2.3 und 2.4 einzuführen.
Beratungsfirmen sind leider in besonderer Weise anfällig dafür, die konventionelle Arbeitsweise ihrer Entwickler zu fördern. Das liegt vor allem daran, dass Beratungsfirmen oft dann engagiert werden, wenn es darum geht, eine neue Anwendung zu erstellen und in Betrieb zu nehmen. Aber gerade in der Anfangsphase eines Projektes benötigt TDD mehr Zeit als der konventionelle Ansatz. Seine Vorteile kann TDD erst ausspielen, wenn das Projekt reift und die ersten Änderungsanforderungen Umstrukturierungen im bestehenden Code erfordern.
Unternehmen sind nicht nur für die Ausbildung, sondern auch für die Motivation der Mitarbeiter verantwortlich.
An dieser Stelle ergibt sich für Beratungsfirmen oft ein Konflikt, der in der Regel nur unter Mitwirkung des Kunden gelöst werden kann. Daher stehen Beratungsfirmen einer besonderen Herausforderung gegenüber, wenn sie ein TDD-förderndes Umfeld schaffen wollen, weil sie nicht nur die eigenen Mitarbeiter, sondern auch ihre Kunden von den Vorteilen des TDD überzeugen müssen.
Unternehmen, die TDD im Projekteinsatz fördern wollen, sollten die in Abschnitt 2.2 genannten Community Events unterstützen und ihre Mitarbeiter zur Teilnahme daran ermutigen. Dabei ist es nicht notwendig, solche Veranstaltungen innerhalb der Arbeitszeit zu organisieren oder die Teilnahme daran als solche anzuerkennen. In jedem Fall aber können Unternehmen bei der Durchführung von Community Events mitwirken, indem sie Infrastrukturen wie Räumlichkeiten und Ausstattung – eben gerade auch außerhalb der "Geschäftszeiten" – zur Verfügung stellen oder ein Catering übernehmen.
Fähigkeit der Organisation
Die Fähigkeiten der Organisation bestehen in der Bereitstellung erforderlicher Arbeitsmittel. Für die Softwareentwicklung sind das Hardware und Software.
Hardware: Glücklicherweise sind wir heute in einer Situation, in der die Hardware im Sinne von "Computertechnik" kein beschränkender Faktor mehr ist. Dank Gigaherz-Prozessoren, hochauflösenden Monitoren und Solid State Disks (SSD) sind mittlerweile selbst Laptops jeder Herausforderung gewachsen, die bei der Softwareentwicklung entsteht. Zudem sorgen günstige Datentarife der Mobilfunkanbieter und die ständig wachsende Zahl freier WLAN-Zugänge für einen nahezu unbeschränkten Zugang zum Internet auch abseits des Arbeitsplatzes im Büro.
Blicken wir aber über den Tellerrand von TDD hinaus auf andere Arbeitsweisen aus dem Portfolio des Extreme Programming, nämlich zum Beispiel auf das Pair Programming, dann bedürfen die Arbeitsplätze der Entwickler oft noch einer "Aufrüstung". Sie müssen groß genug sein, damit zwei Entwickler bequem nebeneinander daran sitzen können. Idealerweise sind die Arbeitsplätze auch zum Stehtisch verstellbar, weil Rollen- und damit verbundene Positionswechsel im Stehen viel einfacher sind. Die dafür notwendigen höhenverstellbaren Arbeitstische in der benötigten Größe gehören aber noch nicht flächendeckend zur Standardausstattung.
Software: Auch im Bereich der Software ist die Situation überwiegend erfreulich. Für die meisten der aktuell in den Projekten verwendeten Programmiersprachen gibt es (kosten-)freie Entwicklungsumgebungen (IDE) und Frameworks zum Erstellen und Ausführen von Unitests.
Leider gilt das nicht für alle Sprachen. Bei einigen Programmiersprachen fallen für den Einsatz effektiver IDEs oder Testing-Frameworks zum Teil erhebliche Kosten durch Kaufpreise oder Lizenzgebühren an. Bevor Unternehmen ihren Entwicklern allerdings die Verwendung einer "günstigeren" Variante vorschreiben, sollten sie prüfen, ob sie damit nicht zu sehr die Motivation und Kreativität ihrer Entwickler bremsen. Wer sich über die Limitierungen seiner IDE oder eines Frameworks ärgert, auch wenn diese nur gefühlt sind, verbraucht dafür unnötig Energie und kann diese dann nicht mehr in die für das Programmieren benötigte Kreativität umsetzen.
Fazit
Der Schlüssel zum erfolgreichen Einsatz von TDD in Softwareprojekten ist die Einrichtung eines TDD-freundlichen Umfelds. Dafür braucht es sowohl physische Voraussetzungen wie Tools, Zeitrahmen und Kenntnisse, aber auch psychologische wie die Motivation auf den drei Ebenen Mitarbeiter, Team und Unternehmen.
Die Umsetzung eines solche TDD-freundlichen Klimas ist für Beratungsfirmen besonders anspruchsvoll, weil sie meist mit engen Terminvorgaben arbeiten und selbst oft nicht in den Genuss der Vorteile kommen, die TDD in lang laufenden Projekten bietet. Dessen sollten sich die Auftraggeber bewusst sein.
- J. Grenny, K. Patterson, D. Maxfield, R. McMillan, A. Switzler, 2013: Influencer: The new science of leading change, second edition
- S. Lieser, R. Westphal: Clean Code Developer School
- C. Haines: Coderetreat Community Network
