Software zu entwickeln ist bekanntermaßen nicht einfach. Auch heutzutage schlagen immer noch viele Software-Projekte aus verschiedenen Gründen, wie schlechter Kommunikation, unzureichender Anforderungsermittlung oder unrealistischen Zielen, fehl. Es gibt viele wichtige Kriterien, die für den Erfolg einer Softwareentwicklung entscheidend sind, insbesondere müssen aber folgende zwei Dimensionen sichergestellt werden:
1. Wir bauen die richtige Software, d. h. die Software muss die Anforderungen korrekt adressieren und einen echten Mehrwert für die Benutzer stiften.
2. Wir bauen die Software richtig, d. h. die Software erfüllt verschiedene Qualit.tskriterien wie Wartbarkeit, Fehlerfreiheit, Effizienz und Zuverl.ssigkeit.
Hinzu kommt, dass Software-Projekte zunehmen in agilen und „leanen“ Szenarien umgesetzt werden müssen, bei denen teilweise alle Anforderungen noch gar nicht klar sind und das Geschäftsmodell erst noch gefunden werden muss.
Behavior Driven Development (BDD) ist eine agile Softwareentwicklungsmethode, die auf diese Herausforderungen und Ver.nderungen reagiert. Sie wurde 2003 von Daniel Terhorst-North als Verbesserung gegenüber Test Driven Development (TDD) entwickelt. Beim TDD schreibt man vor dem eigentlichen Feature einen automatisierten Test (ebenfalls als Code), der dieses Feature testen soll. Selbstverständlich wird dieser Test zunächst fehlschlagen, da das Feature selbst noch nicht entwickelt ist (1). Im Anschluss programmiert man gerade ausreichend Code, damit der Test erfolgreich ist (3). Im Anschluss kann man den Code aufräumen und verbessern (3). Der Vorteil hierbei ist, dass man sofort bemerkt, wenn eine Änderung einen Fehler hervorruft, weil in diesem Fall der Test wieder fehlschlagen würde. Am Ende hat man also einen sauberen, wartbaren und qualitativ hochwertigen Code und ein funktionierendes Feature.
BDD übernimmt den Ansatz, geht aber noch einige Schritte weiter. BDD wird auch „anforderungsgetriebene Softwareentwicklung genannt“, denn hier wird der Fokus auf das eigentliche Benutzerverhalten gelegt. Somit kann man BDD auch während der Anforderungsermittlung und -dokumentation verwenden. Ein Beispiel zur gemeinsamen Anforderungsspezifikation ist die Sprache „Gherkin“ (diese Methode ist ebenfalls im Buch beschrieben). BDD trägt somit neben Dimension 2 „Wir bauen die Software richtig“ ebenfalls insbesondere zu Dimension 1 „Wir bauen die richtige Software“ bei.
Dementsprechend ergeben sich einige Vorteile von BDD, wie folgende unvollständige Liste zeigt:
• fördert die gemeinsame Kollaboration zwischen Entwicklern, Product Owner, Tester und weiteren Stakeholdern,
• fördert die gemeinsame Kommunikation und Diskussion, bspw. durch die Sprache „Gherkin“,
• verbessert die Code-Qualität, minimiert Bugs und erhöht diverse Kriterien wie Wartbarkeit und Wiederverwendbarkeit,
• durch die automatisierten Tests und Spezifikationen wird die Dokumentation erhöht,
• unterstützt die Anforderungsermittlung.
• Sicherstellung der Wertschöpfung von Features,
• wir reduzieren Verschwendung und Kosten, da wir nur die Features bauen, die auch einen Wert stiften.
Im Gegenzug muss aber sichergestellt werden, dass das gesamte Team mit dieser Methode vertraut ist und gemeinsam damit arbeitet. Gemeinsame Kommunikation und Kollaboration sind erfolgskritisch, damit BDD seine Vorteile ausspielen kann. Des Weiteren kann BDD seine Stärken wie oben beschrieben vor allem in agilen Szenarien ausspielen.
