jensjaeger.com

Usability Driven Development (UDD) ist ein Vorgehensmodell der Softwaretechnik das Usability in einen agilen Prozess einbindet.

Es soll Entwicklern ein Werkzeug an die Hand geben um Anwendungen in einem iterativen Entwicklungsprozess, auf die Anforderungen von Kunden maßzuschneidern. Dabei soll das System so schnell wie möglich in Produktion gehen und in kurzen Releasezyklen weiterentwickelt werden.

Das Vorbild hierfür ist Extreme Programming das um Elemente des User Centered Design erweitert wurde. Die Grundprinzipien des Vorgehensmodel sind das DRY und das KISS-Prinzip, die in jeder Phase konsequent verfolgt werden.

UDD wendet diese Prinzipien auf alle Aspekte eines Softwarepro jektes an, von grafischen Oberflächen, über Quellcodes und Dokumentation bis zu Verträgen mit Kunden. 

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.

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.