Blog

Developer Open Space 2014 in Leipzig

Jörg Preiß
4. Dezember 2014
Tags

Sessionplanung

Am 17.10.2014 war es endlich wieder soweit. Nachdem ich die letzten beiden Male pausiert hatte, wollte ich dieses Jahr wieder drei aufregende und anregende Tage in Leipzig verbringen. Am vorhergehenden Workshop-Tag konnte ich leider nicht teilnehmen. Nach knapp sechs Stunden Anfahrt und einem arbeitsreichen Tag fiel ich abends nur noch erschöpft in mein Hotelbett. Dafür war ich am darauffolgenden Samstag früh auf den Beinen und konnte ausgeschlafen an der Session-Planung teilnehmen.

Im Vorfeld wies Torsten Weber, Mitorganisator des Open Spaces, darauf hin, dass viele Neulinge dabei sein werden. Ich versprach mir davon frischen Wind und neue Gedanken. Andere befürchteten das Aufkochen bereits abgehakter Themen. Davon war zwar nichts zu spüren, dennoch verlief die Session-Planung insgesamt etwas zäh in diesem Jahr.

In diesem Jahr waren hauptsächlich Themen aus dem Umfeld der Entwicklung zu finden. So waren beispielsweise Kreativitätstechniken, Docker oder Rechte und Pflichten für Selbständige Bestandteil einiger Sessions. Auch technische Themen waren vertreten, wie Wearables&Smarthome, Sensorik bei autonomen Robotern und Kinect 2.0. Entwicklung selbst war Thema bei einer Einführung zu Angular JS, Haskell oder der Rails Disco. Ich selbst habe in einer Session XamlBoard – das Centigrade-eigene Tool für die Verwaltung von Xaml-Ressourcen – vorgestellt. Eine komplette Übersicht über alle Themen findet sich hier

Seit meinem letzten Besuch wurde der .NET Open Space umbenannt in Developer Open Space, um der Vielzahl an .NET-fernen Themen Rechnung zu tragen. Das Ziel einer technologieunabhängigen „Unkonferenz“ wurde dieses Jahr definitiv erreicht: Zwar zögerlich und mit Respekt vor der Menge gab sich ein Java-Entwickler als solcher zu erkennen. Er wurde jedoch respektvoller aufgenommen als Frank, der um Hilfe bei Performanceproblemen mit WCF bat – und sich zunächst mit schallendem Gelächter begnügen musste. Nichtsdestotrotz wurde Franks Problem in einer eigenen Session diskutiert. Im folgenden gehe ich auf die von mir besuchten Session ein.

Wechsel von TFS zu Git

MarcelMit der traditionellen Verspätung (wie immer) startete die erste Session „Wechsel von TFS zu git“. Thomas sprach über die unzähligen Probleme mit der Benutzung von TFS und dem Wunsch auf Git zu wechseln. Der Großteil seines Teams ist jedoch zufrieden mit der aktuellen Situation und er hat bislang nur einen Mitstreiter. Seine Frage an die Runde war, wie er die anderen davon überzeugen könnte, sich die Alternative wenigstens einmal anzuschauen. Erschreckend zu hören fand ich, dass es tatsächlich noch Entwickler gibt, die aus Angst vor Konflikten mit dem Einchecken bis zu drei Monate warten. Der Konsens war, den Zugriff auf die Quellcodeverwaltung erst einmal bei den Befürwortern durch Git-TF oder git-tfs zu ersetzen und zu versuchen, eine eingeschworene Gemeinschaft aufzubauen, die ihren Workflow effizienter umsetzen kann.

Scrum: Von der Gruppe zum Team

In der Session-Planung wies Ralph darauf hin, dass er Probleme habe, aus einer Gruppe ein Team zu formen und Erfahrungsaustausch wünsche. In Ralphs Team arbeiten neben internen auch externe Mitarbeiter, die kommunikativ und hilfsbereit sind… Doch obwohl gemeinsam entwickelt wird, entstehe keine Zusammenarbeit. Ein Erklärungsansatz bestand darin, dass Teilgruppen am Team vorbei mit den Externen im Mittelpunkt Aufgaben vorbereiten. Dadurch sammelten sie das Domänenwissen, auf das sich die anderen verließen. Es stellte sich heraus, dass die Gruppe Scrum-But statt Scrum durchführte, d.h. sie ließen wesentliche Teile von Scrum weg: Grooming genüge, eine Sprintplanung werde dadurch unnötig. Da die Ziele irgendwie erreicht wurden, eskalierte nichts und nach außen entstand kein Handlungsbedarf. Ein gemeinsames Commitment gab es dennoch nicht.
Vorgeschlagen wurde u.a., die Stories als Durchstich zu gestalten und das Ergebnis als Team zu präsentieren, vermehrt auf Pair Programming zu setzen und auf Coding Dojos zurückzugreifen.

Verhandeln und Deeskalieren

Lars wies zu Beginn seiner Session darauf hin, dass wir in unserem Leben ständig am Verhandeln sind. Schon die simple Frage „Was tun wir heute Mittag?“ kann zu einer Verhandlung mit dem Partner führen. Wichtig ist bei Verhandlungen, nach Win-Win-Situationen zu suchen. Kontraproduktiv ist der Standpunkt „Wenn wir nicht ins Kino gehen, hab ich überhaupt keine Lust etwas zu unternehmen“, weil er nicht auf die Position des Verhandlungspartners eingeht. Hierbei kann es helfen, Menschen und ihre Interessen getrennt voneinander zu behandeln. Auch sollte man sich auf die Interessen der Beteiligten konzentrieren, und nicht auf ihre aktuellen Positionen. Wenn möglich, sollten vorab geeignete Auswahlmöglichkeiten entwickelt werden, um die Suche nach Kompromissen zu erleichtern. Zu einem geeigneten Kompromiss gehört, die gute Beziehung zu erhalten und beide Seiten gewinnen zu lassen. Faule Tricks sind in der Verhandlung sofort anzusprechen. Die Beteiligten sollten sich zudem nicht unter Druck setzen lassen, sondern gegebenenfalls die Verhandlung unterbrechen. Persönlichen Angriffen gilt es geschickt auszuweichen. Und das Wichtigste: immer die Gegenposition anerkennen und im Auge behalten. Leider ging bei der weiteren Diskussion des Harvard-Konzeptes die Zeit so schnell vorbei, dass das Deeskalieren zu kurz kam.

Kreativtechniken

Nach einer kurzen Einleitung von Lars stellte Torsten einige Kreativtechniken vor. Dazu gehört allen voran natürlich Brainstorming, bei dem es wichtig ist, zunächst alles in den Raum zu werfen, um anschließend die Ergebnisse herauszufiltern. Manchmal kann auch die Kopfstandmethode helfen, bei der die Fragestellung einfach umgedreht wird. So kann die Fragestellung „Welche tolle Funktion könnten wir einbauen?“ beispielsweise umgewandelt werden in „Brauchen wir überhaupt so viele Funktionen?“ Von diesen Beispielen ausgehend ging Torsten in die Beschreibung von erfolgreichen Teams über, in denen es meistens drei Rollen gibt: (a) Einen Creator, der gerne neue Sachen ausprobiert, immer mit der Technik geht. (b) Einen Owner, der den Tatendrang und die Informationsflut des Creators in geeignete Bahnen lenkt und die Technikvielfalt eindämmt. Und (c) einen Broker, der weiß, welche Informationen wo und bei wem zu finden sind.

Heterogenes Computing

Hier hatte ich leider den Abstract von Mathias falsch verstanden. Gehofft hatte ich auf eine Session mit Sprachenvielfalt im Vordergrund. Mathias interessierte sich jedoch hauptsächlich für das Aufteilen von Aufgaben auf verschiedene Hardware. Zum Beispiel braucht das Sortieren auf einer GPU ein anderes Verfahren als auf einer CPU. Ebenso war Grid-Computing ein Thema, Mathias war auf der Suche nach Verfahren, Rechenoperationen im Netzwerk zu verteilen, möglichst mit Lastausgleich. Dem Gesetz der zwei Füße des Open Space folgend habe ich diese Session vorzeitig verlassen.

XamlBoard

Durch den technologieunabhängigen Charakter des Open Space waren nicht ganz so viele WPF-Entwickler vor Ort wie in vorangegangenen Jahren. Trotzdem konnte ich einige begeistern, meiner Vorstellung des XamlBoards zu folgen. Ziel des Programms ist ein besserer Workflow im Umgang mit XAML-Dateien. Die gängigen Tools wie Expression Blend oder Visual Studio sind gut zum Editieren, aber die Übersicht über die verfügbaren Ressourcen geht dabei verloren. Hierbei hilft XamlBoard mit einer Live-Ansicht aller gefunden Elemente. Live heißt nicht nur, dass Controls direkt aus den ResourceDictionarys generiert werden, sondern dass mit ihnen auch interagiert werden kann. Weitere Informationen zu den Ressourcen können in zusätzlichen Metadaten abgelegt werden, wie etwa Keywords zum Suchen oder eine Beschreibung, wann eine Ressource eingesetzt werden sollte. Weitere Highlights sind die anpassbare Anzeige der Ressourcen durch eigene Templates oder die Interaktion mit Visual Studio aus XamlBoard heraus. In einer internen Version ist bereits der Export von Bildern integriert, um sie mit nicht-WPF-Projekten wie etwa Qt austauschen zu können.

Paket

Mein persönliches Highlight dieses Open Spaces. Steffen und Alex stellten ihren Paketmanager mit dem unscheinbaren Namen Paket vor. Die Nachteile von NuGet liegen auf der Hand: Es befinden sich zu viele Informationen in der Datei packages.config, hinzu kommt dass die Versionsinformationen zu genau sind. Besonders in den Verzeichnisnamen führt das zu meist zu Merge-Konflikten. Diese Unzulänglichkeiten versuchen Alex und Steffen mit Paket zu umgehen. Hierfür siedeln sie die Paketabhängigkeiten auf Solution-Ebene an und speichern die berechneten Abhängigkeiten in einer zweiten Datei. Nicht von ungefähr wird das Verfahren Ruby-Entwicklern bekannt vorkommen: es ist das selbe Verfahren, das Gem anwendet.
Abgesehen von NuGet-Paketquellen können sogar GitHub-Projekte als Abhängigkeit definiert werden. Versionsabhängigkeiten können dadurch viel feingranularer angegeben werden. Die Konvertierung eines Projekts von NuGet auf Paket kann per Kommandozeilenschalter erledigt werden, so dass einem raschen Umstieg nichts mehr im Wege steht.

C++ 11/14

Andreas führte mit dem Qt Creator die Neuerungen von C++ 11 bzw. 14 vor und gab allgemeine Tipps. So braucht die main-Funktion kein return-Statement mehr, endl macht automatisch ein flush auf die Ausgabe, weshalb „\n“ benutzt werden sollte (oder eben gerade nicht). Die Regular Expression Funktionen unter std::regex bekamen Vorgaben. Linq-Ausdrücke erhielten Einzug und können z.B. bei std::find zum Einsatz kommen. Mit auto kann der Nutzer ohne Typangaben Variablen oder Rückgabewerte deklarieren. Beides, also Linq und auto kombiniert, führt zu anonymen Funktionen, und vieles vieles mehr… das ein oder andere war von anderer Stelle schon bekannt. Doch dass die Fehlermeldungen des Compilers klarer werden sollen und auch zukünftig die Vorgabe lautet, einiges aufzuräumen, wusste ich noch nicht. Exemplarisch sei das Modul-Konzept genannt: Klassen sollen in der .cpp-Datei angelegt werden, ein Export generiert die zugehörige .h-Datei automatisch. Dies ist jedoch zunächst ein Proposal.

FAKE

Marcel und Max begannen die Session, waren allerdings erleichert, als Steffen – der Auto von FAKE – dazukam. Der erklärte per ProjectScaffold die Grundzüge und Ideen hinter FAKE. ProjectScaffold soll das Scaffolding eines Projekts wie in Ruby erlauben. FAKE selbst ersetzt dabei den Wust an XML-Dateien, den MSBuild normalerweise generieren lässt, durch einen klaren, funktionalen Ansatz. Das durch Scaffolding erzeugte Gerüst beinhaltet das Erzeugen eines NuGet-Paketes, die Aktualisierung von GitHub-Pages per Oktokit, automatisch generierte Dokumentation, Taggen des aktuellen Standes in der Quellcodeverwaltung, Verteilen der erzeugten Binarys und dergleichen mehr. DotCover kann ebenfalls als Target in das Buildscript eingefügt werden. Dies führte zu einer kurzen Diskussion darüber, ob das wünschenswert ist oder nicht.
Durch miterzeugte .yml-Dateien steht dem sofortigen Einsatz des Skriptes innerhalb eines Buildservers nichts im Wege. Durch ein entsprechendes Plugin

Krieg der Welten – Doku vs Development

Anne und Kate haben sich unter die Entwickler gemischt und viele von ihnen durch die provokante Fragestellung in ihre Session gelockt. Sie wollten wissen, wie sich die Zusammenarbeit zwischen Entwicklern und der Dokumentationsabteilung verbessern lässt.
Insgesamt waren die vorgebrachten Punkte verständlich. Wir sollten uns beim Dokumentieren (und nicht nur dort) mehr in die Anwender hineinversetzen: Was wollen sie wissen, womit wollen sie starten? Wo ich mich immer noch dabei erwische: Entwickler lassen gerne für sie offensichtliche Dinge weg. Dadurch müssen Redakteure immer wieder nachhaken, mitunter auch die Antwort übersetzen. Ein häufiger Punkt in einer Release-Note lautet: „Wir haben optimiert“. Das führt den Leser zur Frage nach dem Warum: Aus Langeweile? Es wäre ein Hinweis angebracht, an welcher Stelle sich die Optimierung auswirkt. In der Dokumentation sollte der Entwickler folgende Fragen beantworten: Was ist es? Was kann es? Wie konfiguriere ich es? So hat der Redakteur eine gute Ausgangsbasis, um konzentriert nach Stellen zu suchen, an denen etwas fehlen könnte oder sprachlich etwas zu verbessern wäre. Das Fazit der Session war, dass Redakteure und Programmierer jeweils ihre „Superkräfte“ haben, sie aber gemeinsam mehr für den Kunden rausholen können.

Fazit

Der Weg ist schon weit von Saarbrücken nach Leipzig. Trotzdem rechtfertigt der Open Space den Weg. Es sind ja nicht nur die oben beschriebenen Sessions, an denen man ja auch mitplant. Zwischen den Sessions, in den Pausen oder beim Mittagessen kann man soviel Know-How und neue Denkansätze aufnehmen wie kaum sonst. Fortgesetzt wird der Ideenaustausch traditionell abends im Joseph-Pub. Wie lange, bleibt jedem selbst überlassen. So schlagen sonntags Einige erst recht spät wieder in den Sessions auf – teilweise auch in ihren eigenen. Sonntag nachmittag klingt das Event langsam aus, letzte Gruppen bilden sich und diskutieren bis in die Dämmerung. In den nächsten Wochen wird man versuchen, das Gehörte und Erlebte zu verarbeiten, um sich schließlich wieder auf das nächste Mal zu freuen…

Expression Blend und Visual Studio sind Marken oder registrierte Marken der Firma Microsoft Corporation in den USA und / oder anderen Ländern.

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Senior UX Manager
+49 681 959 3110

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.