© Ekaphon maneechot/Shutterstock.com
Automatisierte Akzeptanztests bilden eine lebende Softwarespezifikation

Eine gemeinsame Sprache


Mit zunehmender Akzeptanz und Verbreitung agiler Softwareentwicklungsmethoden ergeben sich neue Herausforderungen an die Zusammenarbeit zwischen Projektleitung, Anforderungsmanagement, Qualitätssicherung und der Entwicklung im engeren Sinn. In einem solchen Umfeld eine bezüglich der beteiligten Disziplinen und Rollen holistische Sicht auf die Softwareentwicklung anzunehmen, ist von entscheidender Bedeutung. Nur wenn alle Akteure am selben Strang ziehen, kann ein optimales Resultat und die von agilen Methoden versprochene Maximierung des Geschäftsnutzens sowie der Softwarequalität erreicht werden. Behaviour-driven Development (BDD) bietet einen integrativen Mechanismus, der es allen Projektbeteiligten erlaubt, eine gemeinsame Sprache zu finden.

Agile Methoden erfreuen sich zunehmender Akzeptanz und Verbreitung in weiten Teilen der Softwareentwicklung. Durch die kürzeren Feedbackschleifen und die engere Einbindung des Kunden ergeben sich für die Softwareentwicklung neue Herausforderungen bezüglich der Zusammenarbeit aller beteiligten Disziplinen und Rollen. Zur erfolgreichen Projektabwicklung mit dem Ziel qualitativ hochwertiger Software mit maximalem Geschäftsnutzen steht hierbei insbesondere die Kooperation zwischen Projektleitung, Anforderungsmanagement, Qualitätssicherung sowie der Entwicklung im Vordergrund. Oftmals sind in Unternehmen diese Funktionen in unterschiedlichen Abteilungen organisiert, die zum Beispiel mittels einer Matrixorganisation an Projekten zusammenarbeiten. Zusätzlich kann oft beobachtet werden, wie in den jeweiligen Disziplinen sehr unterschiedliche Unternehmens-(Sub-)kulturen gelebt werden. Ein agiles Vorgehen bringt nun die beteiligten Disziplinen mit ihren unterschiedlichen „Weltanschauungen“ viel näher zusammen, als konventionelle Methoden das typischerweise tun. Besonders augenfällig wird das anhand der Ideen des agilen Anforderungsmanagements [1] sowie der agilen Qualitätssicherung [2]. Dass eine solche Nähe nicht nur Vorteile, sondern auch Risiken mit sich bringt, kann man in der Praxis vielfach schmerzhaft feststellen.

Die gemeinsame Sprache

Ein hohes Risiko in einem heterogenen Projektteam besteht darin, dass die Beteiligten kein gemeinsames Verständnis des Projekts bekommen, was zwangsläufig zu einer Minderung der Effektivität oder im schlimmsten Fall zum Scheitern des Projekts führen kann. Die unterschiedlichen Perspektiven entstehen aufgrund der unterschiedlichen Subkulturen der Beteiligten, oftmals beruhen sie jedoch auf einfachen Missverständnissen sowie auf der Tendenz einzelner Mitarbeiter, eigenmächtig Annahmen zu treffen und sie nicht zu verifizieren. Um solche Missverständnisse bezüglich der Anwendungsdomäne zu adressieren, können Ansätze aus der anwendungsdomänengetriebenen Entwicklung (Domain-driven Design, DDD) [3] eingesetzt werden, namentlich die Idee der ubiquitären Sprache (Ubiquitous Language). Diese allen Projektbeteiligten gemeinsame Sprache wird basierend auf Begriffen der Geschäfts- beziehungsweise Anwendungsdomäne definiert und eingesetzt, um das Domänenmodell der Software aufzubauen. Ein solches Vorgehen erleichtert maßgeblich die Kommunikation, primär zwischen den Akteuren mit einer Blackbox-Perspektive auf die Software (typischerweise Projektleitung, Anforderungsmanagement und Qualitätssicherung) sowie den Entwicklungsdisziplinen, die aufgrund von Interaktionen mit ihnen die Software erstellen.

Agiles Anforderungsmanagement mit Anwendererzählungen

Im agilen Anforderungsmanagement wird die Spezifikation einer Software zeitnah an deren Implementation erstellt, anstelle in einer ihr vorgelagerten Projektphase. Eine Dokumentationstechnik, die sich bei einem solchen Vorgehen bewährt hat, ist der Einsatz von Anwendererzählungen (User Stories). Eine User Story stellt eine leichtgewichtige Spezifikation eines Anwendungsfalls dar und besteht aus drei Komponenten:

  • Titel sowie textuelle Beschreibung anhand einer vorgegebenen Syntax: „Als <Rolle>, möchte ich <Ziel >, um <dabei erzielter Geschäftsnutzen>.“

  • Gespräche, die dem Ausarbeiten der Anforderung dienen.

  • Akzeptanzkriterien der beschriebenen Anforderung.

Auffallend ist die explizite Aufnahme von Gesprächen zwischen den beteiligten Akteuren als integraler Bestandteil eines Anforderungsartefakts. Das beruht fundamental auf agilen Grundgedanken: So besagt es eines der Prinzipien, die hinter dem agilen Manifest stehen, dass die effizienteste und effektivste Art, Informationen an und innerhalb des Entwicklungsteams zu übermitteln, das Gespräch von Angesicht zu Angesicht ist [4]. Die Gespräche als Teil einer User Story dienen somit der Detaillierung der Anforderungen bei möglichst tiefen Reibungsverlusten, aber die Halbwertszeit eines undokumentierten Gesprächs ist bekanntlich äußerst überschaubar. Um die Langfristigkeit der erarbeiteten Erkenntnisse sicherzustellen, wird der dritte Bestandteil einer User Story, die Akzeptanzkriterien, verwendet. Akzeptanzkriterien stellen, wie ihr Name schon sagt, Kriterien dar, die erfüllt sein müssen, damit eine User Story abgenommen werden kann. Um solche Kriterien greifbar zu machen, werden sie oft in der Form von Akzeptanztests formuliert. Ein solcher kann beispielsweise bestehend aus Vorbedingungen, Testschritten sowie Nachbedingungen formuliert werden. Genau bei ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang