jensjaeger.com

Messen

Eine der wichtigsten Dinge bei UDD ist das Messen. Jeder Entwickler muss die Zeit messen die für eine Iteration benötigt wird und mit der geschätzten Zeit vergleichen. Am Anfang eines Projektes werden diese Schätzungen noch relativ viele Fehler enthalten. Im Verlauf des Projektes werden die Schätzungen jedoch mit jedem Planungsspiel besser werden. Die Geschäftsseite bekommt so genaue Prognosen welche Funktionen bis zum jeweils nächsten Planungsspiel umgesetzt werden können.

Dokumentation

Eine der am Häufigsten genannten Kritikpunkte aller agiler Methoden ist, dass nicht ausreichend auf Dokumentation geachtet wird. Es gibt in UDD keine Phase Dokumentation. Die Dokumentation wird während allen Phasen des Projekt erstellt. Die erstellten Quelltexte sollen nach den Prinzipien des selbstdokumentierenden Quellcodes erstellt werden. Eine genaue Erklärung über selbstdokumentierenden Quellcode findet sich in Kapitel 19 von Code Complete. Kommentare im Quellcode und in den Tests ergänzen den Code zu einer vollständigen Dokumentation. Kommentare müssen wie Quellcode dem DRY und dem KISS-Prinzip entsprechen. Das bedeutet, es soll nicht dokumentiert werden was der Code macht, denn das wäre eine Verletzung des DRY-Prinzips, sondern warum etwas gemacht wird. Dieses Prinzip des Literate Programming wurde bereits 1992 von Donald E. Knuth beschrieben. Werkzeuge, die aus kommentiertem Quelltext eine Html-Dokumentation erzeugen, sind heutzutage weitverbreitet und können als moderne Version des literate Programming bezeichnet werden. Es ist sinnvoll alle erstellte Diagramme direkt in der erstellten Html-Dokumentation zu verlinken und ebenfalls unter Versionsverwaltung zu stellen.

Dieser Abschnitt behandelt nur Entwicklerdokumentation. Anwenderdokumentation kann nicht aus dem Quelltext generiert werden und muss nach wie vor manuell erstellt werden. Wie das am besten durchzuführen ist hängt stark von der Art des Projektes und der benötigten Form der Dokumentation ab (Gedrucktes Handbuch, Online-Hilfe, usw.). Wie Anwenderdokumentation erstellt werden soll kann deshalb nicht generalisiert werden und muss für jedes Projekt individuell entschieden werden.

Die abschliessende Phase einer UDD-Iteration stellt der Usability Test dar. Dabei testet der Entwickler die neu implementierte Funktion. Dabei ist es Hilfreich die Beschreibung der Funktionalität auf der Storycard als Aufgabe zu betrachten, die erfüllt werden muss.

Sollten hierbei trotz der ausgiebigen Test Fehler gefunden werden, ist umgehend das vorhergegangene Deployment rückgängig zu machen, und die Iteration mit dem Ziel der Fehlerbehebung neu zu durchlaufen. Im Normalfall sollte die Funktionalität gewährleistet sein.

Es wird jedoch oft der Fall eintreten, dass Ideen für die Verbesserung der gerade entwickelten Funktionalität oder einer anderen Funktion des Systems entstehen. Diese werden in Form von Storycards notiert und müssen von der Geschäftsseite beim nächsten Planungsspiel priorisiert werden.

Der Begriff Deployment beschreibt die automatische Verteilung und Auslieferung der entwickelten Software. Im Optimalfall sollte die neu erstellte Funktion im Produktivsystem eingespielt werden. Dazu eignen sich beispielsweise Webanwendungen oder serverbasierte Systeme.

Das bringt den Vorteil, dass den Nutzern der Software Weiterentwicklungen sofort zur Verfügung stehen. Dies birgt jedoch trotz umfangreichen Test ein gewisses Risiko, dass Fehler in eine Produktivversion gelangen. Damit man dieses eingehen kann, muss die Möglichkeit bestehen, ein Deployment jederzeit einfach wieder rückgängig zu machen.

Bei Systemen die nicht serverbasiert arbeiten, oder Anwendungen bei denen ein sofortiges Einspielen der neu entwickelten Funktionen nicht erwünscht ist, sollte man das Deployment zumindest auf einem Testsystem vornehmen, um immer ein funktionierendes System mit der neuesten Softwareversion für Tests und Demonstrationen zur Verfügung zu haben.

Integration bedeutet das Zusammenführen des geänderten Quellcodes mit der Codebasis. Bevor dieser Schritt durchgeführt werden kann müssen alle Tests erfolgreich durchlaufen werden.

Als Werkzeug für die Integration sollte unbedingt eine Versionsverwaltung eingesetzt werden. Es ist ratsam zusätzlich zum Quellcode auch die in der Phase Modellierung eventuell erstellten Diagramme in die Versionsverwaltung eingecheckt werden.

Auch auf Werkzeuge die, automatisch bei jeder Softwareversion die in die Versionsverwaltung eingespielt wird alle Tests durchlaufen und einen Build anstoßen, sollte nicht verzichtet werden. Dadurch können Fehler wie, das vergessene Einchecken einer Datei in die Versionsverwaltung, leicht entdeckt werden.

In der Phase der Programmierung werden die Ergebnisse aus den vorherigen Phasen umgesetzt. Das zuvor gestaltete Userinterface wird implementiert, benötigte Klassen und Methoden geschrieben und Datenbankstrukturen entwickelt.

Es sollte hierbei immer die einfachste funktionierende Lösung implementiert werden (vgl. Das KISS-Prinzip). Die Programmierung ist abgeschlossen wenn alle Test fehlerfrei ausgeführt werden können. Nachdem alle Tests erfolgreich ausgeführt werden können, sollte der neu entwickelte Quellcode einem Refactoring unterzogen werden.

Bevor zur nächsten Phase übergegangen werden kann sollte überprüft werden, dass sowohl die in der vorherigen Phase entwickelten Tests, als auch die in dieser Phase entwickelten Klassen und Methoden ausreichend dokumentiert sind. 

Nachdem in der Phase der Modellierung die Einordnung der Funktionalität ins Gesamtsystem erfolgt ist, folgt die Entwicklung der Tests. Dabei werden alle auf der zu bearbeiteten Storycard beschriebenen Funktionalitäten in Form in Tests umgesetzt. So entsteht aus der Storycard, vom Kunden oder Geschäftsseite verfasst, eine ausführbare Spezifikation der Funktionalität (vgl. Test Driven Development). Ausnahmen bilden Storycards die sich ausschließlich mit Verbesserungen der Oberfläche beschäftigen und keine Funktionalität des Systems verändern. Diese können aus einem Usability Test hervorgegangen sein und sind eventuell nur schwer oder gar nicht maschinell testbar. Dann wird die Phase Testdesign übersprungen.

Nachdem die Oberfläche einer Funktion gestaltet ist, kann man sich den schwierigeren Dingen zuwenden. Die Phase Modellierung soll einen Überblick verschaffen, wie die neue Funktionalität in das Gesamtsystem integriert werden kann.

Welche Datenbankfelder werden benötigt, wo im Schichtenmodell soll die Funktion implementiert werden, welche Bibliotheksfunktionen können benutzt werden, welche Algorithmen sind am geeignetsten für das Problem? Diese Fragen sollten sich Entwickler stellen und beantworten.

Im Zweifelsfall sollte die Meinung von Kollegen eingeholt werden oder falls möglich ein Test entwickelt werden. Besonders bei Performancefragen kann ein Lasttest sehr aufschlussreich sein.

Es geht in dieser Phase nicht darum, die zu entwickelnde Funktionalität bis ins letzte Detail mit UML Diagrammen zu beschreiben. Diagramme sollten nur dort eingesetzt werden wo es Sinnvoll ist und dadurch Vorteile entstehen.

Programmierung ist im Vergleich zum Oberflächendesign sehr aufwendig und nur schwer zu verändern.

Deshalb sollte man sich zuerst dem Interface einer Anwendung zuwenden. Die Oberfläche einer Software zu gestalten ist verhältnismäßig leicht. Eine Skizze auf einem Blatt Papier ist schnell angefertigt und einfach zu ändern. Ein anderer wichtiger Grund das Interface zuerst zu gestalten ist, dass die Oberfläche das Produkt ist.

Die Oberfläche ist das, was die Anwender sehen und schlussendlich bezahlen sollen. Mit einer Anwendungssoftware, die zwar über großartige Funktionen verfügt aber eine unattraktive Oberfläche besitzt, wird man nur schwer Kunden gewinnen können.

Bei der Gestaltung von Oberflächen sollte man sich immer das Zitat von Antoine de Saint-Exupéry vor Augen führen: „Perfektion ist erreicht, nicht, wenn sich nichts mehr hinzufügen lässt, sondern, wenn man nichts mehr wegnehmen kann“  ( Wind, Sand und Sterne von Saint-Exupéry und Becker 1941, S.48). Angewandt auf die Oberflächengestaltung bedeutet Saint-Expuérys Zitat nichts anders als die Anwendung des DRY und des KISS-Prinzips. 

Bei umfangreichen Oberflächenänderungen oder Erweiterungen sollte von der Möglichkeit gebrauch gemacht werden in die Phase Usability Test zu springen. So kann das entworfene Design geprüft und eventuell verbessert werden, bevor zu viel Arbeit investiert wurde. 

Jeder Entwickler übernimmt Storycards, die Arbeit bis zum nächsten Planungsspiel enthalten. Dabei wird die Zeiteinschätzung durch die Entwickler selbst vorgenommen. Das Einfachste dieses zu tun ist die “Wetter von gestern Methode”, die besagt, dass das Wetter heute mit hoher Wahrscheinlichkeit das Gleiche wie gestern ist. Das bedeutet das sich Entwickler mit ihren Schätzungen an vorhergehenden Aufgaben orientieren sollen. Nach jeder Iteration werden die Istzeiten mit den geschätzten Sollzeiten verglichen. So entsteht im Verlauf des Projekts eine bessere Basis für weitere Schätzungen.

Die Entwicklung einer Software nach UDD beginnt mit einem Planungsspiel. Der Kunde oder ein Teammitglied der Geschäftsseite notiert alle Aufgaben die das System erfüllen soll in Form von Storycards. Diese Storycards werden nach Priorität sortiert und entsprechend dieser Reihenfolge entwickelt.

Das Planungsspiel wird in bei jeder Iteration wiederholt. Dadurch hat die Geschäftsseite bei jedem Planungsspiel die Möglichkeit die Priorisierung zu ändern und völlig neue Storycards hinzuzufügen. Weitere Storycards kommen durch im Verlauf der Entwicklung durchgeführte Usability Tests hinzu. Diese müssen ebenfalls von der Geschäftsseite priorisiert werden.