Der dritte und für mich letzte Konferenztag stand an. Die Sessions drehten sich um Craftmanship, Tools, Projektplanung und Vorgehensmodelle, Windows 8, Softskills, PHP, Web-Projekte, Mobile Projekte und Trends.
Mein persönlicher Tagesablauf sah so aus:
- Empathic Refactoring von Johannes Hofmeister
- Gute Projekte fallen nicht vom Himmel von Robert Misch
- Aufwände schätzen statt raten von André Krämer
- Code Reviews, Aller Anfang ist schwer von Laurin Stoll
- Single Responsiblity Principle to the eXtreme von Ralf Westphal
- E.VA Anforderungsmanagement von Dr. Matthias Schramm
- Abschlusskeynote „Raus aus der Steinzeit“ von Ralf Westphal
Empathic Refactoring von Johannes Hofmeister
Ich habe Johannes bereits letztes Jahr mit seinen beiden Vorträgen auf der DDC erlebt. In 120 Minuten ratterten mehr als 200 Folien durch. Damals hatte er präzise auf den Punkt gebracht wie jeder von uns Code schreiben sollte damit er für andere lesbar und somit änderbar bleibt. Klar, da waren auch einige abgehobene Ansätze und Machbarkeitsstudien dabei. Er beendete seine Vorträge mit der Information dass er ein Psychologie-Studium beginnt und so wurde der diesjährige Vortrag für mich umso spannender.
Mit weniger Folien und angenehmen Tempo brachte er diesmal auf den Punkt was aus menschlichem Hintergrund passiert wenn wir Code schreiben und lesen. Aus seiner Sicht sollte das Ziel weiterhin bleiben einfacheren Code zu schreiben. Das hat den Vorteil das weniger Tests geschrieben werden müssen, das der Code von uns verstanden und salopp gesagt von unserem Gehirn verarbeitet werden kann.
Einen faszinierenden Ansatz fand ich das Thema „Chunking“. Chunking bezeichnet die logische Zusammenfassung von einzelnen Einheiten. Beispielweise können wir uns 2-4-1-2-9-0 kaum merken. Machen wir daraus „24-12-90“ fällt es bereits leichter. Mit Klassen und Methoden tun wir ähnliches, wir bilden Chunks. Somit verringern wir die Komplexität, umso kleiner wir sie halten umso kleiner bleibt die Komplexität.
Johannes hat ebenfalls den Begriff „weasel word“ geprägt. Das „CustomerRepository“ ist beispielsweise ein solches „weasel word“. Was passiert dabei? Es werden zwei Bereiche miteinander verbunden die getrennt werden sollten: Die fachliche und die technische Domäne. Unnötige Information mein Johannes, wie wäre es mit „Customers“?
Das Buch „Working Effectively with Legacy Code“ von Robert C. Martin legt er jedem nahe noch vor dem Clean Code Buch zu lesen. Es ist dünner und besitzt mehr wichtige Punkte.
Aus dem kurzen praktischen Teil von Johannes nehme ich zusätzlich einige R#-Shortcuts mit, denn: schnelles Refactoring gehört zum Handwerkszeug, zumindest Rename, Extract Method, usw.
Gute Produkte fallen nicht vom Himmel von Robert Misch
Wie man als Product Owner den Kunden dabei unterstützt aus einer Idee ein gutes Produkt entstehen zu lassen erklärte Robert Misch. Er fokussiert den wichtigen Punkt wie der Product Owner zu möglichst guten Anforderungen kommt.
Die Grundlage: Produkte und Features schnellstmöglich auf den Markt bringen um frühzeitige Umsätze zu generieren, einer der ersten am Markt zu sein und Risiken klein zu halten.
Er gliederte diesen Prozess in 5 Schritte:
- Kunde kennenlernen
- Kundenanliegen verstehen
- Rückfrage an mich selbst/mein Unternehmen: Kann ich seine Aufgabenstellung umsetzen?
- Rückfrage an mich selbst/mein Unternehmen: Kann ich seine Aufgabenstellung umsetzen?
- Inkrementell starten
- Regelmäßig validieren
Dabei bevorzugt Robert Misch so dicht wie möglich an den Kunden heranzukommen: Wie ist der Tagesablauf meines Kunden? Welche Prozesse sollen in Software umgesetzt werden? Wie können Prozesse vereinfacht werden? Beispielsweise begleiteten die Entwickler von Immobilienscout24 verschiedene Makler deutschlandweit um zu verstehen wie der Arbeitsalltag ausschaut und durch eine App der Papierkram verringert werden kann.
Es gibt verschiedene Methoden die er vorstellte:
- 6-3-5 Methode oder Brainwalking
![buildMeasureLearn]()
- Bullet Pointing
- Customer Journey
- Abbild/Persona
- Business Model Canvas
Abgerundet wurde der Vortrag durch den Hinweis dass es für Entwickler heute schwer ist die komplexen Anforderungen zu verstehen und umzusetzen. Robert verweist hier auf den Lean-Ansatz: Build – Measure – Learn.
Aufwände schätzen statt raten von André Krämer
Nur ein Drittel der Software Projekte werden nicht pünktlich fertig. André Krämer glaubt das liegt mit an ungenauen Schätzungen.
Er gab einen theoretischen Überblick welche Schätzmethoden es gibt: Empirische Methoden wie die Expertenschätzung, Schätzung vom Team, die Delphi Methode oder Analogieverfahren bei denen man vergleichbare Projekte analysiert die als Schätz-Grundlage herangezogen werden.
Um die Schätzgenauigkeit zu verbessern empfiehlt er Mockups & Dialoge, Anwendungsfälle, detaillierte Spezifikationen aber auch die Prüfungen wie klar sind die Vorgaben des Kunden, wie hoch ist die Erfahrung in diesem Bereich und wie Reif ist die Technologie die eingesetzt werden soll.
Abgerundet wird sein Vortrag durch algorithmische Schätzmethoden und eine konkrete Analyse warum es zu Schätzfehlern kommt:
- 30 % der Aktivitäten werden vergessen
- Dokumentation, Online Hilfe und Tests werden nicht mit in die Schätzung einbezogen
- Security und Performance bleiben unberücksichtigt und die Inbetriebnahme wird häufig vergessen
- die Zeit für die Kommunikation mit dem Kunden wird unterschätzt
Gefallen hat mir das die PERT-Formel erwähnt wurde mit der die Genauigkeit der Schätzungen verbessert wird.
André empfiehlt grundsätzlich sich Zeit zu nehmen für Schätzungen, Checklisten hinzuzunehmen, in Intervallen zu schätzen und die Schätzung von jemand anders analysieren zu lassen.
Ralf Westphal rundet die Konferenz ab und macht Schluss mit dem Monolithen
Den Nachmittag füllte Ralf Westphal. Er vermittelte um was es bei dem Single Responsibility Prinzip geht. Das ein oder andere erschien mir zunächst fremd, das gab mir Grund genauer darüber nachzudenken. Aufnehmen, verstehen und bewerten. Aber nicht vergessen zu prüfen ob man das verstanden hat was mein Gegenüber mitteilen wollte. Die Folien waren präzise und umfangreich.
In seiner Abschluss-Session geht Ralf auf den Monolithen ein. Er sprach von Abhängigkeiten im Alltag, in unserem Leben, unserer Entwicklungsumgebung und in unserer Software.
Widerstände gegen Veränderung führen laut seiner Ansicht zu großen Monolithen die keiner beherrschen will und kann. Das führt irgendwann zum „Big elefant in the room“. Ein Thema das keiner mehr ansprechen möchte, dieses Thema wird im Laufe der Zeit größer bis es irgendwann nicht mehr lösbar ist.
Weitere Aspekte seien niedrige Motivation, überholter Tool- und Kenntnisstand, kaum Neuzugänge und gigantische Backlogs. Ich möchte das ergänzen: Backlogs die keiner kennt.
Linderung kann erfolgen durch reversible Architekturentscheidungen, Transparenz, Flüssigkeit und ausreichend Puffer.
Mein Fazit zur DWX
Mein kurzes Fazit: Es hat sich gelohnt, ich komme gerne wieder.
Die ausführliche Form: Innerhalb von drei Tagen habe ich so viel gelernt wie schon lange nicht mehr. Die Vielzeit der parallelen Sessions ermöglichte von allem etwas mitzunehmen. Vom groben Überblick und Einstieg bis hin zu tiefen Wissen zu verteilten Anwendungs-Architekturen.
Besonders begeistert war ich von dem Thema „Domain Driven Design“. Ich habe einen groben Überblick mitgenommen den ich auf jeden Fall im Laufe der nächsten Zeit vertiefen möchte. Das Thema Software-Lösungen viel näher an die Anforderungen und Kunden des Kunden zu bringen halte ich für extrem wichtig und natürlich auch besonders spannend, das hält die Motivation aufrecht.
Vor allem das „CQRS“-Architekturpattern wirkte genial, ausgeschrieben „Command Query Responsibility Segregation“. mehr dazu in meinem gestrigen Bericht. Überwältigt war ich von der Vielzahl der kompetenten Referenten die vor allem mit praktischen Erfahrungen und guter Didaktik punkten konnten: „High potential Experts“ Sie können vieles, manches davon exzellent!
