Bericht von der OOP 2014 (Teil 2)
Donnerstag, 06.02.2014
Impact Maps und Story Maps
Am nächsten Morgen ging es mit dem Vortrag „Impact Maps und Story Maps: liefern was wirklich zählt“ von Christian Hassa weiter.
Er stellte eine Möglichkeit vor, dass das Backlog eines Projekts nicht überquillt. Hier nannte Impact Maps, die sichtbar machen sollen, welche Auswirkung ein bestimmtes Feature hat und was man dafür liefern muss. Daneben stellte er noch Story Maps vor, die auch irgendwas können.
Mir war der Vortrag leider viel zu hoch. Wer noch nicht mit User Stories im agilen Umfeld arbeitet, konnte mit dem Vortrag leider nichts anfangen.
Continuous Documentation statt Endless Specification
Der zweite Vortrag „Continuous Documentation statt Endless Specification - den Fokus auf nachhaltige Artefakte legen“ von Susanne Mühlbauer war da schon etwas besser, aber auf ähnlichem Niveau.
Die Referentin stellte zur Diskussion, ob es sinnvoll sei, dass man an vielen Stellen im Projekt mehrfach das Gleiche auf andere Art und Weise dokumentiert. Sie hält Prozess- und Projektdaten (Besprechungsprotokolle, Zwischenergebnisse etc.) für weniger wert als den entstandenen Code oder Designbeschreibung. Dieser Output könnte dann bei einem iterativen Verfahren wie Scrum wieder in die Anforderungsdokumentation wandern, um die Spezifikation zu verbessern.
Als Beispiele für solchen nachhaltigen Artefakte, die man aufheben sollte, zählt Mühlbauer Motivationen und Entscheidungen sowie der grobe Überblick über das Thema. Ebenso ist oft ein Benutzerhandbuch notwendig. Auch beschrieben werden sollten die Schnittstellen und nicht-funktionale Anforderungen, ebenso wie die Testfälle.
Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr
Siemens-Mitarbeiter Michael Stal sprach dann aus, was alle Software-Architekten denken: „Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr“.
Die Architektur ist das Rückgrat des Systems und so sind auch die Architekten wichtig, die dieses pflegen. Oft sind Architekten aber „nur“ normale Entwickler, die dazu ernannt wurden, aber keinerlei sonstigen Erfahrungen dafür mitbringen. Ein Problem ist dabei sicher auch, dass Architekten in manchen Prozessen einfach kein Platz zugeordnet wird.
Am Beispiel der Siemens AG stellte Stal dann die verschiedenen Architekten-Anforderungen und dessen Verantwortungen vor. Neben Design Skills benötigen sie Erfahrung im Requirement Engineering und Teststrategien. Vor allem die Soft Skills sah Stal als extrem wichtig an. Ebenso sollten auch Architekten noch implementieren – etwas, was sehr oft nicht mehr der Fall ist.
Zusätzlich sollte man als Architekt (und in meinen Augen auch allgemein) nicht alles bis ins kleinste Detail vorab spezifizieren, designen und berechnen, sondern lieber einfach etwas ausprobieren und dann nachjustieren, wenn es nicht stimmt. Das erfordert aber Mut.
Gut fand ich auch den Hinweis, dass man als Architekt auf ein guten Ausgleich zwischen Arbeits- und Privatleben achten sollte. Mehr als 40 Stunden kann ein Mensch auf die Dauer in einer Woche nicht sinnvoll arbeiten ohne sich kaputt zu machen bzw. ohne dass die Qualität leidet.
Keynote: An Agile Challenge
Die Keynote „An Agile Challenge: Munich Germany Takes On The Columbus Ohio USA Agile Benchmark Study“ war in meinen Augen dann eher wenig erwähnenswert.
Es wurden nur Ergebnisse von ein paar europäischen Firmen vorrgestellt, die an einer Agile-Benchmark-Studie teilgenommen hatten.
Über Freud und Leid der Entwickler beim Schätzen ihrer Aufgaben
Der Vortrag „'Och, nicht schon wieder ...!'; - Über Freud und Leid der Entwickler beim Schätzen ihrer Aufgaben...“ war eigentlich weniger Vortrag als Erfahrungsaustausch.
Die beiden Referenten Paul Herwarth von Bittenfeld und Joachim Seibert teilten den Raum in zwei Gruppen auf, die wiederum in drei Teilgruppen geteilt wurden. Diese drei Teilgruppen sammelten sich dann um drei Fragen an drei Tischen. Jeder sollte sich mit den anderen austauschen und aufschreiben, was 1. die Motivation für Schätzungen ist, 2. welche Störungen es gibt, die Schätzungen zunichte machen können, und 3. welche gute Erfahrungen mit Schätzen gemacht wurde. Die Teilgruppen wanderten dann zum nächsten Tisch weiter und am Ende wurden die erarbeiteten Ergebnisse vorgestellt.
Das ganze bezog sich natürlich auf das Abschätzen in Scrum-Projekten, sodass ich nicht direkt mitreden konnte, dennoch kam Einiges zusammen. Vor allem aus dem Scrum-Umfeld konnte ich so ein paar Begriffe wie „Planning Poker“ oder „Magic Estimation“ aufgreifen (hier grob erklärt).
Mir hat die Veranstaltung sehr gut gefallen, weil man so einmal mit seinen Tischnachbarn ins Gespräch kam und sich austauschen konnte. Dazu im Fazit mehr …
Keynote: Software Design in the 21st Century
Danach trat Martin Fowler mit seiner Keynote „Software Design in the 21st Century“ an. Martin Fowler ist kein Unbekannter in der Software-Welt und hatte/hat einen großen Einfluss auf die Entwicklung im Bereich Software-Architektur, Refactoring und Extreme Programming.
Dementsprechend habe ich mich auch auf seinen Vortrag gefreut, der zweigeteilt war. Der erste Teil beschäftigte sich mit den verschiedenen Arten des Refactorings. Neben Test-Driven-Development-Refactoring nannte er auch noch Little-Pickup-Refactoring, Comprehension-Refactoring, Preparatory-Refactoring, Planned Refactoring (im Backlog) und Long-Term-Refactoring.
Die guten Gründe, die für Refactoring sprechen, sind: Qualität, sauberer Code, Professionalität und dass es einfach das Richtige ist. Diese Gründe sollte man aber gegenüber den Geldgebern/Projektleitern nie nennen. Besser wäre es, wenn man „Okönomie“ als Grund angibt: Man kann nach dem Refactoring mehr und schneller liefern.
Der zweite Teil befasste sich weniger mit normalen Software-Themen, sondern griff die Nachricht der Keynote von Constanze Kurz vom Vortag mit auf. Fowler betonte, dass wir Entwickler nicht bloß „Code monkeys“ seien, sondern unser Gehirn einschalten sollten. Wir sollten das Richtige und Moralische während unser Arbeit tun. Dazu zählt auch die Privatsphäre der Nutzer zu schützen.
Er verwies dabei auch auf den kommenden Dienstag. Am 11. Februar 2014 ist der Tag, an dem wir zurückschlagen: The Day We Fight Back – Against Mass Surveillance. Martin Fowler rief jeden dazu auf, teilzunehmen, was ich nur unterstützen kann.
Ich hätte nicht mit so einem kritischen Thema auf der OOP gerechnet, bin deswegen aber umso mehr begeistert gewesen. Auch heise hat darüber berichtet.
Agile Softwarearchitektur - 5 Dinge die vom Hype bleiben
Im vorletzten Vortrag ging es um das Thema „Agile Softwarearchitektur - 5 Dinge die vom Hype bleiben“. Stefan Toth erzählte, wie Softwarearchitektur in die agile Welt passt.
Es sind dabei vor allem fünf Dinge, die bleiben: Schlanke Vorarbeit (d.h. nicht totdesignen, bevor man anfängt zu kodieren), gemeinsame Architekturarbeit aller Beteiligten/Entwickler, Architekturanforderungen müssen festgehalten sein, Architektur und Entwicklung verzahnen (iterativ mit Metriken und Tests verifizieren und korrigieren) und Reflexion der Architektur.
Insgesamt war es ein guter und interessanter Vortrag, der dabei half, das Thema Softwarearchitektur im agilen Umfeld korrekt einzuordnen.
SOLID Deconstruction
Den Abschluss – und mein Highlight – bildete der Vortrag SOLID Deconstruction von Kevlin Henney. Ich habe Henney bereits auf der OOP 2012 gehört und freute mich daher auf ihn. Grund war und ist, dass man in seinen Vorträgen Tränen lacht und trotzdem etwas lernt.
Henney nahm die SOLID-Prinzipien auseinander und erklärte zu jedem Prinzip, wo es herkam und was es ursprünglich bedeutete und wieso wir es in der heutigen Zeit manchmal falsch anwenden bzw. falsch verstehen.
Interessant war auch sein Verweis auf das Dreyfus-Modell zum Erwerb von Fähigkeiten, was den Menschen in fünf Typen unterteilt, wie er etwas lernt und aufnimmt. Dementsprechend sollte man auch mit den SOLID-Prinzipien umgehen.
Der Vortrag war wie erwartet sehr erheiternd. Kleinere Anekdoten und ein sehr lockerer Vortragsstil reißen einen einfach mit. Zusätzlich habe ich einiges über SOLID gelernt und kann die Prinzipien (bzw. Henney nennt es lieber Pattern) besser anwenden.
Fazit
Die OOP war wieder sehr gut und ich kann es eigentlich nur jedem empfehlen, der die Möglichkeit hat, dort hinzugehen, es mindestens einmal zu versuchen. Das Programm ist so riesig, dass für jeden etwas dabei ist. Daneben kann man auch viele Kontakte knüpfen …
… wenn die Raumgröße nicht wäre. In jedem Vortrag gab es das gleiche Bild: Zwischen je zwei Zuhörern war ein Platz frei. Immer! Ausnahme: Zwei Entwickler kamen gemeinsam durch die Tür herein und gehörten zusammen. Auch während der Pausen blieben die meisten (wenn sie nicht Teil einer Gruppe waren) für sich. Ich bin unsicher, wieso das so war, aber es fanden so nur wenige Gespräche statt. Einzig bei den Gruppenarbeiten in den Vorträgen (was bei mir nur zwei waren), wurde das Eis gebrochen und die Gespräche fingen an.
Interessant waren auch die Ausstellungen im unteren Bereich der Halle. Siemens stellte beispielsweise ein 1:2-Modell des Mars Rover aus. Und beim Carl-Hanser-Verlag konnte ich mit den Leuten reden, deren Bücher ich ab und zu lese.
Bilder gibt es im Übrigen beim Veranstalter, wer ein paar Impressionen sehen will.
Comments
Display comments as Linear | Threaded