Kolumne: Dino talks

Lassen Sie sich vom Verhalten treiben
Kommentare

Nahezu jeder Entwickler kann Ihnen eine ähnliche Geschichte wie diese erzählen: Nach mehreren Wochen Arbeit sieht der Benutzer eine Demo auf dem Computer, lächelt und sagt dann vorsichtig: „Das ist, wonach wir möglicherweise gefragt hatten, doch ist dies sicherlich nicht das, was wir wirklich brauchen.“ Dieser Satz bedeutet schlichtweg, dass Stunden von Entwicklung und Testen (das sprichwörtliche Kind) mit der Analyse einfach weggeworfen (mit dem sprichwörtlichen Bad ausgeschüttet) wurden. Was ist schief gelaufen? Und wann hat es begonnen, schiefzugehen? Wahrscheinliche Ursachen oder Begleitumstände des Phänomens sind mangelndes Verständnis für den Kontext und schlechte Kommunikation zwischen Entwicklungsteam und Kunden. Soweit die Theorie. Doch was können wir in der Praxis tun, um den Entwicklungsprozess zu verbessern?

Das Akronym BDD assoziiert man fast einhellig mit dem Ausdruck „Behavior-driven Development“ (verhaltensgetriebene Entwicklung). In diesem Artikel möchte ich aber eine etwas andere Sichtweise darlegen, bei der wir das letzte D als „Design“ interpretieren können. Mit anderen Worten ist BDD eine agile Methodik, ausreichend flexibel, um als vollständiger Entwicklungsprozess anstelle von TDD (Test-driven Development, testgetriebene Entwicklung) zu dienen, aber auch als hilfreiches Analysetool, das sich sowohl für das Schreiben von Akzeptanztests als auch als Eingabe für das Softwaredesign eignet.

BDD befindet sich immer noch in seiner Anfangsphase, wie es Dan North von ThoughtWorks erstmals 2006 eingeführt hat. Einen Essay des ersten Artikels können Sie online lesen. Ursprünglich war BDD lediglich ein effektiverer Weg, um Best Practices für testgetriebene Entwicklung zu erklären. Die Methodik besitzt aber ein riesiges Potenzial und ergänzt meiner Meinung nach einfach die Werkzeugpalette des Softwarearchitekten. Zunächst gehe ich auf die Verantwortlichkeit des Architekten ein und wende mich dann BDD und den heute verfügbaren Tools zu, um mit BDD bequem in Visual Studio 2010 umgehen zu können.

Die Verantwortlichkeiten des Architekten

Wie der Standard ISO/IEC 42010 besagt, ist ein Architekt die Person, die für die Architektur eines softwareintensiven Systems verantwortlich ist. Der Architekt nimmt an allen Phasen des Entwicklungsprozesses teil: Analyse der Anforderungen, Entwurf der Architektur, Implementierung (einschließlich Testen und Integration) und Bereitstellung. Zuallererst ist ein Softwarearchitekt für die Annahme und das Verstehen der Softwareanforderungen verantwortlich. Als Nächstes erwartet man von ihm, dass er dieses Wissen anwendet, um das System in ein Netz von miteinander verflochtenen Komponenten zu zerlegen und Bereiche möglicher Änderungen, besonderer Sicherheits- oder Skalierbarkeitsbedürfnisse und ähnlicher Anforderungen aufzuzeigen.

Der Architekt ist auch für alles zuständig, was mit der Implementierung der verschiedenen Komponenten zu tun hat, angefangen beim Entwurf der zu erstellenden Klassen bis zur Auswahl vorhandener Tools, Bibliotheken und Technologien, die eingesetzt werden sollen. Auch wenn der Architekt seine Fachkenntnisse einbringen soll, um beste Produkte und Technologien vorzuschlagen und zu fördern, hat er nicht bei jeder Entscheidung das letzte Wort, außer wenn diese Verantwortlichkeit explizit gewährt oder delegiert wird. Schließlich muss der Architekt über gute Kommunikationsfertigkeiten verfügen, sodass er Schwierigkeiten frühzeitig identifizieren und beseitigen kann, um die Dinge unter Dach und Fach zu bringen und zur nächsten Phase überzugehen.

Konfrontiert mit der Herausforderung eines neuen Projekts, beginnt der Architekt bei den Anforderungen. Während wir einen Überfluss an Paradigmen, Prinzipien und Mustern haben, um eine Architektur zu definieren, bleibt oftmals die erste Phase in fast jedem Projekt der Improvisation überlassen. Dem Architekten wird üblicherweise ein Stapel von Word-Dokumenten übergeben, die jeweils mit einer endlosen und unstrukturierten Liste von Aufzählungspunkten vollgestopft sind. Dann bleibt er auf sich allein gestellt, um sich daraus etwas zusammenzureimen. Aus Worten soll eines Tages ein Verhalten werden.

Das Verhalten eines Systems herausfinden

Das Verhalten eines Softwaresystems lässt sich kaum auf eine einzige Liste von Aufzählungspunkten reduzieren. Verschiedene Interessenvertreter produzieren unterschiedliche Listen. Wahrscheinlich verwenden sie abweichende Formulierungen, beschreiben ein Verhalten aus unterschiedlichen Perspektiven und priorisieren es entsprechend ihrer unterschiedlichen Interessen. Meistens haben unterschiedliche Interessenvertreter nicht einmal die Vorstellung vom System in seiner Gesamtheit. Ungeachtet dessen verfolgen alle dasselbe (oftmals nicht ausgedrückte) Ziel. Das Verständnis des wirklichen Ziels jedoch bleibt die Hauptaufgabe des Architekten.

Der Kern eines verhaltensgetriebenen Konzepts für die Analyse dreht sich um reproduzierbare Techniken, die darauf abzielen, fehlerhafte und fehlende Kettenglieder zu finden, die Feedback von den Endbenutzern zum Architekten bringen. Eine verhaltensgetriebene Philosophie ist durchdringend/tiefgreifend und fördert die Zusammenarbeit zwischen den verschiedenen Akteuren, die auf der Bühne zu unterschiedlichen Zeiten auftreten.

Während der Analysephase fördert ein verhaltensgetriebener Ansatz den Dialog zwischen Architekten, Fachleuten, Projektmanagern und der Geschäftsführung. Das Ergebnis ist eine klare Definition von Aufgaben, Features und Prioritäten, die in einer gemeinsam abgestimmten Liste von Abnahmebedingungen resultieren. Während der Entwicklungsphase hilft das verhaltensgetriebene Konzept den Architekten, den Entwicklern, Testern und Designern, mit einer klaren Vorstellung davon fortzufahren, worin das endgültige Ziel der Software liegt. Somit vermeiden sie ein riskantes Abkommen vom Weg, der zu Erweiterbarkeit und zukünftigem Wachstum des Systems führen soll.

Der Kern der verhaltensgetriebenen Analyse kann in einem Satz ausgedrückt werden, den nahezu jeder Entwickler/Architekt mindestens einmal gehört hat: „Zeige mir etwas und dann beginnen wir zu reden …“ Benutzer sind nicht die Architekten (selbst wenn es manchmal einige von ihnen scheinbar möchten) und können die Anforderungen schwerlich genügend formal und präzise spezifizieren. Andererseits ist die Liste der Punkte, die sie produzieren, eine Art Einkaufsliste, die aber nicht als Dogma verstanden werden sollte. Verhaltensgetrieben fühlen heißt, zu fragen „warum würde man dieses konkrete Feature mögen/benötigen?“ Nur weil der Kunde König ist, muss er nicht der Gebieter sein. Wir wollen nun BDD in verhaltensgetriebenes Design (Behavior-driven Design) umbenennen und seine Fähigkeiten und Tools analysieren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -