Der Begriff „Agil“ beschreibt zunächst einmal nur eine Art und Weise, wie man etwas angehen kann, ohne dabei wirklich konkret zu werden. Um eine Software oder ein Projekt agil anzugehen, bedarf es etwas mehr. Dafür benötigt man Vorgehensweisen, Praktiken und ein stimmiges Gesamtkonzept. Im Bereich der agilen Software-Entwicklung haben sich eine Handvoll Frameworks und Methodiken etabliert. Diese möchte ich hier vorstellen und aufzeigen, wie sie sich voneinander unterscheiden und welchen Fokus sie jeweils haben.

Dies ist der dritte und letzte Teil einer dreiteiligen Blog-Reihe.

Den ersten Blog-Beitrag zu Kanban, Lean Software Development (LSD), Scrum und Extreme Programming (XP) finden Sie hier.

Den zweiten Blog-Beitrag zu Agile Unified Process (AUP) / Disciplined Agile Delivery (DAD), Crytsal Familie und Dynamic Systems Development Method (DSDM) finden Sie hier.

Bei den drei heute vorgestellten Vorgehensweisen, handelt es sich eher um Techniken als eigenständige Frameworks zur agilen Software-Entwicklung.

Test Driven Development (TDD)

Test Driven Development (TDD; auf Deutsch testgetriebene Software-Entwicklung) legt den Fokus während der Entwicklung auf den Test. Für eine neue Funktionalität werden zuerst die Tests geschrieben. Da die Funktionalität selbst noch nicht existiert, muss man sich im Vorfeld Gedanken darüber machen, welche Parameter und Ergebnisse erwartet werden. Erst dann wird die Funktionalität implementiert. Das bedeutet, das die Tests am Anfang erst einmal alle fehlschlagen werden. Nach und nach werden dann immer mehr Tests erfolgreich durchlaufen.

Wenn die Funktionalität am Ende fertig implementiert ist und alle Tests fehlerfrei laufen, wird die Funktionalität noch einmal überarbeitet und optimiert (Refactoring). Deswegen nennt man den gesamten Prozess auch “Rot, Grün, Refactoring” (engl. “Red, Green, Refactoring”).

Dadurch, das die Tests als erstes entwickelt werden, gibt es keinen ungetesteten Code und bei der Implementierung wird dann auch eher auf die Testbarkeit geachtet.

Ursprünge

TDD soll von Kent Beck entdeckt worden sein. Die Idee geht auf das Test-First-Konzept im Extreme Programming (XP) zurück und wurde dort etwa 1999 eingeführt. TDD hat sich aber zu einem eigenständigen Konzept weiterentwickelt und ist mittlerweile ein Bestandteil vieler agiler Methoden.

Prominente Konzepte, Tools & Techniken:

• Test-First Ansatz
• frühes Refacturing
• einfache Designs

Behaviour Driven Development (BDD)

Behavior Driven Development (BDD; auf Deutsch etwa verhaltensgesteuerte Software-Entwicklung) legt den Fokus auf die Zusammenarbeit zwischen Entwicklung und Qualitätssicherung bzw. Anforderungsanalyse. Dabei werden Anforderungen in einer Art dokumentiert, dass die zu entwickelnde Software später automatisiert auf ihre Einhaltung getestet werden kann.

Dazu werden Anforderungen meistens in einer maschinentauglichen Sprache (Domain Language) erfasst, die gleichzeitig für Nicht-Entwickler lesbar und für das Test-Tool ausführbar ist. Es kommen häufig „Wenn … dann …“-Sätze zum Einsatz.

Für die Umsetzung von BDD gibt es zahlreiche Frameworks (z.B. JBehave, RBehave, NBehave, MSpec, Cucumber (früher RSpec)). Hinsichtlich der Sprache für die Formulierung der Anforderungen gibt es keinen übergreifenden Standard.

Ursprünge

Behavior Driven Development wurde erstmals 2003 durch Dan North als Reaktion auf das eher Entwickler-getriebene Test Driven Development (TDD, siehe oben) entwickelt. Von Dan North stammt auch eines der ersten BDD Frameworks JBehave.

Prominente Konzepte, Tools & Techniken:

• Konzentration auf die Stakeholder
• Test-first Ansatz
• Definition von Tests in „natürlicher“ Sprache

Feature Driven Development (FDD)

Feature Driven Development (FDD; auf Deutsch etwa funktionalitätsgetriebene Software-Entwicklung) stellt die Funktionalität (engl. Feature) in den Mittelpunkt. Dabei spielt der Software-Architekt (bzw. die FDD-Rolle Chefarchitekt) eine besonders wichtige Rolle, weil er die Gesamtarchitektur und die übergreifende Funktionalität der Gesamtanwendung im Blick hat und gegebenenfalls regulierend eingreifen kann.

FDD definiert eigene Rollen und Prozesse, die sich gut in vorhandene (auch klassische) Projektstrukturen einfügen. Deswegen kann FDD auch gut außerhalb der agilen Software-Entwicklung verwendet werden. Tatsächlich fällt es manchen Firmen leichter FDD einzuführen, als auf ein agiles Framework oder eine agile Methodik umzusteigen.

Ursprünge

FDD wurde im Jahre 1997 von Jeff De Luca für ein großes zeitkritisches Projekt entwickelt und wird seitdem kontinuierlich weiterentwickelt. Die erste Version von FDD wurde von den Ideen von Peter Coad zur Modellierung objektorientierter Systeme und seinen Feature-Listen inspiriert.

Prominente Konzepte, Tools & Techniken:

• Domain Object Modell
• Jede Klasse hat einen Besitzer
• Teams nach Funktionalität
• Regelmäßige Builds
• Transparenter Projektfortschritt