Praxiserfahrungen mit Behaviour-Driven Development in einem Softwarekonzern
Software mit hoher Qualität und im Zeit- und Kostenrahmen zu entwickeln, schließt sich nicht zwangsläufig gegenseitig aus. BDD zeigt, wie es funktionieren kann.
(Bild: Black Jack/Shutterstock.com)
- Nils Kasseckert
Wahrscheinlich kennen alle Entwickler*innen mindestens eines der folgenden Probleme: Der Zeit- und Kostenrahmen für das Projekt ist zu eng gesteckt und es bleibt keine Kapazität mehr, um sich um die Qualität der Software zu kümmern. Oder nach fast abgeschlossener Entwicklung stellt sich heraus, dass die Software am Kunden vorbei entwickelt worden ist. Damit das nicht mehr geschieht, entstand das sogenannte Behaviour-Driven Development (BDD).
BDD (zu deutsch: verhaltensgetriebene Softwareentwicklung) ist eine aus dem Test-Driven Development (TDD) entstandene agile Form der Softwareentwicklung. Sie wurde 2013 durch Dan North erstmalig beschrieben und hat sich seitdem kontinuierlich von einer reinen Erweiterung des TDDs zu einer eigenen Methodik weiterentwickelt. Wie beim TDD steht bei der verhaltensgetriebenen Entwicklung der Test im Mittelpunkt. Bevor eine Änderung im produktiven Code stattfinden kann, muss zuerst ein Test entwickelt werden.
Worin unterscheiden sich BDD und TDD?
Der Unterschied zwischen den beiden Entwicklungsmethoden liegt in der Definition des Tests. Beim Test-Driven Development kommt in der Regel ein Unit-Test zum Einsatz. Er ist in der jeweils verwendeten Programmiersprache verfasst und für gewöhnlich nur für Entwickler verständlich. Beim Behaviour-Driven Development hingegen wird der Test in der natürlichen Sprache der jeweiligen Domäne verfasst. Er dient gleichzeitig auch als lebende Dokumentation der Software. Das hat den Vorteil, dass nicht nur Entwickler, sondern auch Product Owner, Tester und andere nicht technikaffine Personen den Test verstehen und bestenfalls sogar verbessern können. Wie angedeutet ist das Ziel beim Einsatz von BDD, eine einfach zu wartende Software mit hoher Qualität nach Wünschen der Kunden zu erhalten.
In der Praxis wird das Behaviour-Driven Development oft mit Techniken des Extreme Programming kombiniert. Extreme Programming lässt sich als eine Sammlung verschiedener Methoden auffassen, die allesamt dieselben Ziele wie die verhaltensgetriebene Softwareentwicklung verfolgen. TDD und BDD stellen einen Teil dieser Methoden dar. In meinem Team findet genau eine solche Kombination statt. Aus diesem Grund präsentiere ich im Folgenden die Methoden, die in einem Scrum-Team innerhalb eines großen Konzerns zum Einsatz kommen. Zu ihnen zählen:
- der Test-First-Ansatz
- das Pair Programming
- die gemeinsame Verantwortung
- Tests als Dokumentation und Planung
- der Kunde vor Ort
Beim Einsatz des Test-First-Ansatzes wird vor der Entwicklung der Funktionalität zuerst ein entsprechender Test geschrieben. Diese Tests sollen sich immer wieder automatisch ausführen lassen. Somit ist es wichtig, dass sie unabhängig voneinander sind und sich nicht gegenseitig beeinflussen. Auch beim Auftreten eines Bugs werden zuerst der entsprechende Test entwickelt und erst im Anschluss daran der Fehler behoben. Das stellt sicher, dass dieser spezielle Fehler ab sofort automatisch die Testung durchläuft und somit in der Produktion nicht mehr auftreten kann. Durch den Test-First-Ansatz lassen sich mehrere Probleme auf einmal lösen. Zum einen stellt er eine hohe Testabdeckung sicher, da für jede Funktionalität zwangsläufig ein Test zu entwickeln ist. Zum anderen kann sich das Team im Allgemeinen darauf verlassen, dass der entsprechende Test die Fehler findet. Der Test sollte vor dem Start der Entwicklung fehlschlagen. Ist das nicht der Fall, ist der Test falsch entwickelt und vor der eigentlichen Implementierung zu ändern. Dieser False-Positive-Fall lässt sich bei einer nachträglichen Testentwicklung kaum entdecken. Ein Test, der immer, unabhängig von den Rahmenbedingungen, erfolgreich ist, ist ein nutzloser Test.
Das Pair Programming wird zur Erhöhung der Codequalität und des Bus-Faktors eingesetzt. Der Bus-Faktor ist eine Kennzahl zur Abschätzung von Projektrisiken. Er beschreibt, wie viele Personen ausfallen können, ohne dass es das Projekt gefährdet. Beim Pair Programming arbeiten in der Regel zwei Personen an einer Funktionalität. Eine Person ist für die Eingabe des Programmcodes verantwortlich und die andere Person für die Kontrolle des eingegebenen Codes. Die Rollen wechseln mindestens täglich. Spätestens einmal pro Woche sollten die Paare getauscht werden. Kürzere Abstände sind möglich, je nach Aufgabe jedoch nicht sinnvoll. Eine Zeile Code entspricht immer dem Konsens zweier Personen. Wenn eine der beiden Personen ausfällt, lässt sich dennoch ohne Weiteres an der Funktionalität weiterarbeiten. Auch verbessert sich in der Regel der Code, wenn man gemeinsam darüber spricht.
In vielen Entwicklungsteams herrscht eine strikte Trennung von Themen und Aufgaben. Tritt ein Bug auf, ist meist sofort klar, wer für diesen Bereich zuständig ist und das erforderliche Wissen zur Behebung des Fehlers besitzt. Ist die betreffende Person jedoch gerade nicht verfügbar, kennt sich niemand anderes beim Thema aus. Das Prinzip der gemeinsamen Verantwortung kann ein solches Problem lösen. Für ein spezielles Aufgabengebiet ist nicht nur eine Person verantwortlich, sondern jeder ist für alles zuständig und besitzt auch entsprechendes Wissen. Durch das Pair Programming lässt sich das in der Praxis einfach umsetzen. Bei jedem Wechsel der Partner kommen die noch offenen Aufgaben zur Sprache. Eine Person im Pair behält die Verantwortung für die Aufgabe und ist gleichzeitig für den Wissenstransfer zu ihrem neuen Pairing-Partner zuständig. Die andere Person wechselt in ein neues Pair mit einem anderen Thema. Hierbei ist zu beachten, dass eine Person nie länger als zwei bis drei Wochen in einem Thema bleiben sollte. Ansonsten lässt sich der Wissenstransfer von anderen Themen für diese Person nicht gewährleisten.
Eine zwingende Grundvoraussetzung für den Einsatz dieser Methoden ist ein gutes Auskommen miteinander. Existieren Abneigungen zwischen einzelnen Mitgliedern, ist das Pair Programming nur schwer zu realisieren. Auch muss sich jeder mit dem zu entwickelnden Produkt identifizieren können, damit das Prinzip der gemeinsamen Verantwortung auch gelebt wird und nicht nur auf dem Papier besteht. Weiterhin ist ein ähnliches Wissensniveau hilfreich, da es sonst beim Pair Programming zur Unter- oder Überforderung kommen kann. Auch sollte die Teamgröße nicht mehr als zehn Entwickler betragen. Ansonsten sind der Aufwand zum Austausch und zum notwendigen Wissenstransfer zu hoch.
