jensjaeger.com

Eine Usability Driven Development Iteration besteht aus folgenden Phasen:

• Das Planungsspiel
• Aufwandsabschätzung
• Interface Design
• Modellierung
• Testdesign
• Programmierung
• Integration
• Deployment
• Usability Test

Softwareentwicklung muss, um mit den Anforderungen des Marktes Schritt zu halten, mit zunehmender Geschwindigkeit erfolgen. Der Funktionsumfang selbst einfacher Anwendungen wird immer größer, die Anwendungsentwicklung somit komplexer. Zusätzlich ändern sich auch Kundenanforderungen schneller. Methoden der agilen Softwareentwicklung sind ein viel versprechender Ansatz diesen Herausforderungen zu begegnen.

Bedienbarkeit und Benutzerfreundlichkeit ist ein Qualitätsmerkmal guter Software. In Zeiten des Internets, in der die Konkurrenz nur einen Klick entfernt ist, wird Usability immer mehr zu einem entscheidenden Faktor für den Markterfolg. Agile Methoden betrachten Usability nicht in dem Maße, wie es klassische Usability zentrierte Verfahren tun.

Die logische Konsequenz wäre ein Vorgehensmodell das anwenderzentrierte Softwareentwicklung mit Methoden der agilen Softwareentwicklung verknüpft.

Behaviour-Driven Development (BDD) ist eine Evolution des Denkens hinter Test Driven Development. Dabei wird die Sapir-Whorf Hypothese auf das Schreiben von Tests angewandt. Diese besagt: „zwischen den grammatikalischen Kategorien der Sprache, die eine Person spricht und wie diese Person die Welt versteht und sich in ihr bewegt, besteht eine systematische Beziehung“. Siehe Language, Thought and Reality. Selected Writings von Benjamin Lee Whorf.

Die Sapir-Worf Hypothese ist in der Linguistik umstritten. Unstrittig ist jedoch das Sprache unser Denkenin gewisser weise beeinflusst. Diese Aussage kann bis auf Wilhelm von Humboldts Essay „Über das vergleichende Sprachstudium“ von 1820 zurückgeführt werden.

Bei BDD wird im Vergleich zu TDD nicht ein Testfall definiert, sondern ein Erwartung. Das Ziel ist nicht eine Ansammlung von Tests sondern eine ausführbare Spezifikation der zu entwickelnden Software. Nach Astels „arbeitet man bereits mit BDD wenn man TDD richtig anwendet“. Es existieren spezielle BDD Frameworks die Softwareunterstützung für BDD bieten. BDD kann aber auch mit den bekannten xUnit Frameworks umgesetzt werden.

Extreme Programming (XP) ist ein iteratives Vorgehensmodell der Softwaretechnik, welches eine sehr flexible Arbeitsweise erlaubt. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

XP basiert auf 5 zentralen Werten:

• Respekt
• Kommunikation
• Einfachheit
• Feedback
• Mut 

Auf diesen Werten basierende Praktiken bilden das Vorgehensmodell Extreme Programming. Kent Beck hat diese in Extreme Programming zusammengefasst:

• Das Planungsspiel - Der Umfang einer Version wird festgelegt, indem Geschäftsprioritäten mit technischen Aufwandsschätzungen kombiniert werden. Der Plan muss ständig an die Realität angepasst werden.
• Kurze Releasezyklen - Ein einfaches System soll so schnell wie möglich in Produktion gehen. Darauf folgend sollen in möglichst kurzen Iterationsschritten neue Versionen eingeführt werden.
• Metapher - Sämtliche Entwicklungen werden an einer gemeinsamen, einfachen Metapher ausgerichtet. Diese Metapher soll für Geschäftsseite und Entwicklerseite gleichermassen verständlich sein. Dadurch soll die einfache Kommunikation zwischen Kunden und Entwicklern sichergestellt werden. 
• Einfaches Design - Das System soll zu jedem Zeitpunkt so einfach wie möglich strukturiert sein.
• Testen - Es werden für jeden Teil des System fortwähren Komponententests geschrieben, die fehlerfrei ausgeführt werden müssen.
• Refactoring - Das System unterliegt einem ständigen Refactoring, um Redundanzen zu verhindern, den Programmcode zu vereinfachen oder flexibler zu gestalten.
• Programmieren in Paaren - Der gesamte Produktionscode wird von 2 Programmieren geschrieben, die gemeinsam an einem Rechner sitzen.
• Gemeinsame Verantwortlichkeit - Jeder kann jederzeit beliebigen Code im System ändern.
• Fortlaufende Integration - Das System wird ständig integriert. Immer dann, wenn eine Aufgabe erledigt worden ist.
• 40 - Stunden Woche - Man arbeitet prinzipiell nicht mehr als 40 Stunden in der Woche. Überstunden werden nie länger als eine Woche geleistet.
• Kunde vor Ort - Dem Team soll ein echter, lebender Benutzer angehören, der während der gesamten Arbeitszeit zur Beantwortung von Fragen zur Verfügung steht.
• Programmierstandards - Programmierer schreiben sämtlichen Code entsprechend Regeln, die die Kommunikation mithilfe des Codes erleichtern.

Diese Best Practices waren schon vorher bekannt und werden teilweise bereits lange genutzt. XP fasst diese Praktiken zu einem funktionierenden Gesamtkonzept zusammen, definiert diese jedoch nicht als Allheilmittel. Wo sie nicht den individuellen Anforderungen eines Projektes genügen sollen sie angepasst werden. 

Test Driven Development (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten: 

1. Rot - Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
2. Grün - Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
3. Refaktorisiere - Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.

Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich. 

Kent Beck hat in Test Driven Development das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.

Der Begriff Refactoring wurde von William Opdyke geprägt der, 1992, zu diesem Thema promovierte. Refactoring bedeutet: „Verbesserung des Designs von Quellcode nachdem er geschrieben wurde, ohne die Funktion zu verändern“.

Dabei soll insbesondere die Lesbarkeit, Verständlichkeit, Testbarkeit und Erweiterbarkeit verbessert werden. Martin Fowler hat in Refactoring dieses in aller Ausführlichkeit beschrieben. Fowler listet Bad Code Smells auf, die Hinweise geben an welchen Stellen des Quellcodes möglicherweise ein Refactoring notwendig sein könnte und behandelt Methoden, wie verschiedenen Arten von Refactorings durchgeführt werden können.

Refactoring ist heute ein allgemein anerkanntes Werkzeug der Softwareentwicklung. Zahlreiche freie und kommerzielle, meist in IDEs integrierte, Refactoring Browser belegen dies. Für agile Softwareentwicklung ist ständiges Refactoring des Quellcodes eine Grundvorraussetzung.

Das Akronym KISS steht für Keep it simple, stupid. Es besagt, dass stets die einfachste Lösung für ein Problem gewählt werden sollte. Bereits 1654 wurde vom deutschen Philosophen Johannes Clauberg die bekannte Formulierung aufgestellt, dass „Entitäten nicht über das Notwendige hinaus vermehrt werden dürfen“.

Johannes Clauberg bezog sich in seinem Buch auf wissenschaftliche Theorien. Vereinfacht ausgedrückt bedeutet die Aussage: Eine Theorie sollte möglichst einfach gestaltet sein und trotzdem alle wesentlichen Zusammenhänge erklären.

Das KISS-Prinzip verallgemeinert Claubergs Aussage und kann auf Softwaretechnik angewandt, als eine der Vorraussetzungen für agile Softwarentwicklung angesehen werden.

Das Akronym DRY steht für Don’t repeat yourself. Das DRY-Prinzip ist eine Philosophie in der Informationstechnik, die verlangt, dass jede Information nur einmal in einem Projekt vorkommt. Das schliesst im Idealfall Quelltexte, Datenbankschemata, Tests und Dokumentationen ein.

Durch die Vorhaltung von Informationen an nur einer Stelle, wird die Gefahr vermieden, dass redundante Informationen bei Änderungen vergessen werden. Das vermeidet Fehler so wie Inkonsistenzen und erhöht die Übersicht.

Das DRY-Prinzip kann durch Automatisierung und Kapselung erreicht werden. Es ist eines der Kernprinzipien auf denen das bekannte Buch Der Pragmatische Programmierer basiert. Es hält Anwendungen für Änderungen offen und ist damit Vorraussetzung für agile Softwareentwicklung.

Im Februar 2001 wurde von einer Gruppe von 17 Softwareentwicklern in einem Skiressort in Utah das agile Manifest ausgearbeitet. Darin sind die Prinzipien der agilen Softwareentwicklung festgehalten:

1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.