UDD – Bei jeder Iteration

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.