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.
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
. 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
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.
Wie letztes Jahr waren wir wieder beim Java Forum Stuttgart. Diesmal war die JSE mit fünf Mitarbeitern auf der Konferenz vertreten.Das waren unsere wichtigsten Erkenntnisse:Allgemein:Das Java Forum Stuttgart ist jedes mal wieder ein grandioses Community Event. Man kann der Java User Group Stuttgart nur ein absolutes Lob für die mega Organisation aussprechen. Respekt das ein gemeinnütziger
Read More
Das Java Forum Stuttgart hat schon zum 25ten mal stattgefunden und war ein super Event! Folgende Erkenntnisse haben wir von der Konferenz mitgenommen:Softwarearchitektur:Erst Qualitätsanforderungen definieren, dann die Architekturentscheidungen treffen.Conference Driven Development vermeiden (wenn man was cooles auf einer Konferenz gesehen hat und dann sofort in seine Projekte einbaut)Dokumentation als Code: z.B. mit Doctoolchain. Damit kann
Read More
Nachdem die letzten beiden Jahre die meisten großen Veranstaltungen ausgefallen sind. War ich zwei Tage in Düsseldorf auf der Contra. Der Konferenz für Conversion und Traffic. Vor zwei Jahren habe ich mir die Vorträge von der Contra im Stream angeschaut. Dazu habe ich einen ausführlichen Blogpost geschrieben: Online-Marketing Trends 2020. Nachdem seit einiger Zeit wieder
Read More