Bericht vom Frankfurter Entwicklertag am 21.02.2018
Am 21.+22. Februar 2018 fanden an der Goethe-Universität Frankfurt die Frankfurter Entwicklertage statt. Wie ein roter Faden zog sich die Frage durch die Vorträge, wie Softwareentwicklung in Zeiten der agilen Transformation das Arbeitsleben der Entwickler verändert.
Im Vortrag "Agile Architekturen" von Sippach und Maier wurden sehr strenge und gar nicht leichtgewichtige Verfahren empfohlen, mit denen sich selbst organisierende Teams angeblich die besten Architekturen entwickeln:
Im Vortrag "Erfolgreich Teams bilden durch Self-Selection" von Diefenthäler und Brandt wurde von einer Erfahrung berichtet, bei der sich in einem eintägigen Workshop die Mitarbeiter selbst zu Teams zusammenfanden und in einem Hackathon erste gemeinsame Erfahrungen machten. So entstanden stabile Teams.
Zuletzt schärfte Doc Norton in seinem Key Note Vortrag den Programmierern ein: "Bitte niemals um Erlaubnis, Deinen Job richtig zu machen!" Es ging um technische Schulden und deren Vermeidung ("The Technical Debt Trap"). Oft entstehen technische Schulden durch strategische Entwurfsentscheidungen, die darauf abzielen, eine schnelle Lieferung und frühes Feedback zu erreichen. Der Begriff "technische Schulden" legt nahe, dass man diese Schulden später zurück bezahlen kann. Diese Vorstellung ist jedoch falsch. Man sollte bei der Arbeit niemals absichtlich Unordnung anrichten, sondern eher nach der Boy Scout Rule (Pfadfinderregel) handeln: "Verlasse den Code sauberer als Du ihn vorgefunden hast." Der Entwickler ist nicht nur dafür verantwortlich, dass die Software ihren Zweck erfüllt, sondern auch für deren Qualität. Für Clean Coding braucht es keine Sondergenehmigung!
Im Vortrag "Agile Architekturen" von Sippach und Maier wurden sehr strenge und gar nicht leichtgewichtige Verfahren empfohlen, mit denen sich selbst organisierende Teams angeblich die besten Architekturen entwickeln:
- Ausformulierung der aktuellen und möglichen zukünftigen Anforderungen an Funktionalität und Qualität (Performance, Benutzerfreundlichkeit und Wartbarkeit) prüfbar als Szenarien,
- der systematische Vergleich zweier denkbarer Architekturen bezüglich der Anzahl der Komponenten und dem Aufwand, die Anforderungen umzusetzen,
- Architekturdokumentation,
- Code-Reviews und automatisierte Architektur-Checks.
Im Vortrag "Erfolgreich Teams bilden durch Self-Selection" von Diefenthäler und Brandt wurde von einer Erfahrung berichtet, bei der sich in einem eintägigen Workshop die Mitarbeiter selbst zu Teams zusammenfanden und in einem Hackathon erste gemeinsame Erfahrungen machten. So entstanden stabile Teams.
Zuletzt schärfte Doc Norton in seinem Key Note Vortrag den Programmierern ein: "Bitte niemals um Erlaubnis, Deinen Job richtig zu machen!" Es ging um technische Schulden und deren Vermeidung ("The Technical Debt Trap"). Oft entstehen technische Schulden durch strategische Entwurfsentscheidungen, die darauf abzielen, eine schnelle Lieferung und frühes Feedback zu erreichen. Der Begriff "technische Schulden" legt nahe, dass man diese Schulden später zurück bezahlen kann. Diese Vorstellung ist jedoch falsch. Man sollte bei der Arbeit niemals absichtlich Unordnung anrichten, sondern eher nach der Boy Scout Rule (Pfadfinderregel) handeln: "Verlasse den Code sauberer als Du ihn vorgefunden hast." Der Entwickler ist nicht nur dafür verantwortlich, dass die Software ihren Zweck erfüllt, sondern auch für deren Qualität. Für Clean Coding braucht es keine Sondergenehmigung!
AndreaHerrmann - 27. Feb, 09:24