![\"Sessionplanung\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Sessionplanung-300x200.jpg\")
<\/p>\n<\/p>\n
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\u00f6pft in mein Hotelbett. Daf\u00fcr war ich am darauffolgenden Samstag fr\u00fch auf den Beinen und konnte ausgeschlafen an der Session-Planung teilnehmen.<\/p>\n
Im Vorfeld wies Torsten Weber<\/a>, Mitorganisator des Open Spaces<\/a>, darauf hin, dass viele Neulinge dabei sein werden. Ich versprach mir davon frischen Wind und neue Gedanken. Andere bef\u00fcrchteten das Aufkochen bereits abgehakter Themen. Davon war zwar nichts zu sp\u00fcren, dennoch verlief die Session-Planung insgesamt etwas z\u00e4h in diesem Jahr.<\/p>\n In diesem Jahr waren haupts\u00e4chlich Themen aus dem Umfeld der Entwicklung zu finden. So waren beispielsweise Kreativit\u00e4tstechniken, Docker oder Rechte und Pflichten f\u00fcr Selbst\u00e4ndige 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\u00fchrung zu Angular JS, Haskell oder der Rails Disco. Ich selbst habe in einer Session XamlBoard \u2013 das Centigrade-eigene Tool f\u00fcr die Verwaltung von Xaml-Ressourcen<\/a> \u2013 vorgestellt. Eine komplette \u00dcbersicht \u00fcber alle Themen findet sich hier<\/a><\/p>\n 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\u00e4ngigen „Unkonferenz“ wurde dieses Jahr definitiv erreicht: Zwar z\u00f6gerlich 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\u00e4chst mit schallendem Gel\u00e4chter begn\u00fcgen musste. Nichtsdestotrotz wurde Franks Problem in einer eigenen Session diskutiert. Im folgenden gehe ich auf die von mir besuchten Session ein.<\/p>\n <\/p>\n In der Session-Planung wies Ralph darauf hin, dass er Probleme habe, aus einer Gruppe ein Team zu formen und Erfahrungsaustausch w\u00fcnsche. In Ralphs Team arbeiten neben internen auch externe Mitarbeiter, die kommunikativ und hilfsbereit sind… Doch obwohl gemeinsam entwickelt wird, entstehe keine Zusammenarbeit. Ein Erkl\u00e4rungsansatz bestand darin, dass Teilgruppen am Team vorbei mit den Externen im Mittelpunkt Aufgaben vorbereiten. Dadurch sammelten sie das Dom\u00e4nenwissen, auf das sich die anderen verlie\u00dfen. Es stellte sich heraus, dass die Gruppe Scrum-But statt Scrum durchf\u00fchrte, d.h. sie lie\u00dfen wesentliche Teile von Scrum weg: Grooming gen\u00fcge, eine Sprintplanung werde dadurch unn\u00f6tig. Da die Ziele irgendwie erreicht wurden, eskalierte nichts und nach au\u00dfen entstand kein Handlungsbedarf. Ein gemeinsames Commitment gab es dennoch nicht. Lars wies zu Beginn seiner Session darauf hin, dass wir in unserem Leben st\u00e4ndig am Verhandeln sind. Schon die simple Frage „Was tun wir heute Mittag?“ kann zu einer Verhandlung mit dem Partner f\u00fchren. Wichtig ist bei Verhandlungen, nach Win-Win-Situationen zu suchen. Kontraproduktiv ist der Standpunkt „Wenn wir nicht ins Kino gehen, hab ich \u00fcberhaupt 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\u00f6glich, sollten vorab geeignete Auswahlm\u00f6glichkeiten entwickelt werden, um die Suche nach Kompromissen zu erleichtern. Zu einem geeigneten Kompromiss geh\u00f6rt, 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\u00f6nlichen 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<\/a> die Zeit so schnell vorbei, dass das Deeskalieren zu kurz kam.<\/p>\n Nach einer kurzen Einleitung von Lars stellte Torsten einige Kreativtechniken vor. Dazu geh\u00f6rt allen voran nat\u00fcrlich Brainstorming, bei dem es wichtig ist, zun\u00e4chst alles in den Raum zu werfen, um anschlie\u00dfend die Ergebnisse herauszufiltern. Manchmal kann auch die Kopfstandmethode helfen, bei der die Fragestellung einfach umgedreht wird. So kann die Fragestellung „Welche tolle Funktion k\u00f6nnten wir einbauen?“ beispielsweise umgewandelt werden in „Brauchen wir \u00fcberhaupt so viele Funktionen?“ Von diesen Beispielen ausgehend ging Torsten in die Beschreibung von erfolgreichen Teams \u00fcber, 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\u00e4mmt. Und (c) einen Broker, der wei\u00df, welche Informationen wo und bei wem zu finden sind.<\/p>\n 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\u00e4chlich f\u00fcr 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\u00f6glichst mit Lastausgleich. Dem Gesetz der zwei F\u00fc\u00dfe<\/a> des Open Space folgend habe ich diese Session vorzeitig verlassen.<\/p>\n Durch den technologieunabh\u00e4ngigen 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<\/a> zu folgen. Ziel des Programms ist ein besserer Workflow im Umgang mit XAML-Dateien. Die g\u00e4ngigen Tools wie Expression Blend oder Visual Studio sind gut zum Editieren, aber die \u00dcbersicht \u00fcber die verf\u00fcgbaren Ressourcen geht dabei verloren. Hierbei hilft XamlBoard mit einer Live-Ansicht aller gefunden Elemente. Live hei\u00dft nicht nur, dass Controls direkt aus den ResourceDictionarys generiert werden, sondern dass mit ihnen auch interagiert werden kann. Weitere Informationen zu den Ressourcen k\u00f6nnen in zus\u00e4tzlichen 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\u00f6nnen.<\/p>\n Mein pers\u00f6nliches Highlight dieses Open Spaces. Steffen und Alex stellten ihren Paketmanager mit dem unscheinbaren Namen Paket<\/a> vor. Die Nachteile von NuGet<\/em> liegen auf der Hand: Es befinden sich zu viele Informationen in der Datei packages.config<\/em>, hinzu kommt dass die Versionsinformationen zu genau sind. Besonders in den Verzeichnisnamen f\u00fchrt das zu meist zu Merge-Konflikten. Diese Unzul\u00e4nglichkeiten versuchen Alex und Steffen mit Paket zu umgehen. Hierf\u00fcr siedeln sie die Paketabh\u00e4ngigkeiten auf Solution-Ebene an und speichern die berechneten Abh\u00e4ngigkeiten in einer zweiten Datei. Nicht von ungef\u00e4hr wird das Verfahren Ruby<\/em>-Entwicklern bekannt vorkommen: es ist das selbe Verfahren, das Gem<\/em> anwendet. Andreas f\u00fchrte mit dem Qt Creator die Neuerungen von C++ 11 bzw. 14 vor und gab allgemeine Tipps. So braucht die main<\/em>-Funktion kein return-Statement mehr, endl<\/em> macht automatisch ein flush auf die Ausgabe, weshalb „\\n“ benutzt werden sollte (oder eben gerade nicht). Die Regular Expression Funktionen unter std::regex<\/em> bekamen Vorgaben. Linq<\/em>-Ausdr\u00fccke erhielten Einzug und k\u00f6nnen z.B. bei std::find<\/em> zum Einsatz kommen. Mit auto<\/em> kann der Nutzer ohne Typangaben Variablen oder R\u00fcckgabewerte deklarieren. Beides, also Linq<\/em> und auto<\/em> kombiniert, f\u00fchrt 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\u00fcnftig die Vorgabe lautet, einiges aufzur\u00e4umen, wusste ich noch nicht. Exemplarisch sei das Modul-Konzept genannt: Klassen sollen in der .cpp-Datei angelegt werden, ein Export generiert die zugeh\u00f6rige .h-Datei automatisch. Dies ist jedoch zun\u00e4chst ein Proposal.<\/p>\n Marcel und Max begannen die Session, waren allerdings erleichert, als Steffen – der Auto von FAKE – dazukam. Der erkl\u00e4rte per ProjectScaffold<\/a> die Grundz\u00fcge und Ideen hinter FAKE<\/a>. ProjectScaffold soll das Scaffolding eines Projekts wie in Ruby<\/em> erlauben. FAKE selbst ersetzt dabei den Wust an XML-Dateien, den MSBuild<\/em> normalerweise generieren l\u00e4sst, durch einen klaren, funktionalen Ansatz. Das durch Scaffolding erzeugte Ger\u00fcst beinhaltet das Erzeugen eines NuGet<\/em>-Paketes, die Aktualisierung von GitHub-Pages per Oktokit<\/em>, automatisch generierte Dokumentation, Taggen des aktuellen Standes in der Quellcodeverwaltung, Verteilen der erzeugten Binarys und dergleichen mehr. DotCover<\/em> kann ebenfalls als Target in das Buildscript eingef\u00fcgt werden. Dies f\u00fchrte zu einer kurzen Diskussion dar\u00fcber, ob das w\u00fcnschenswert ist oder nicht. 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\u00e4sst. Der Weg ist schon weit von Saarbr\u00fccken 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\u00e4tze aufnehmen wie kaum sonst. Fortgesetzt wird der Ideenaustausch traditionell abends im Joseph-Pub. Wie lange, bleibt jedem selbst \u00fcberlassen. So schlagen sonntags Einige erst recht sp\u00e4t 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\u00e4mmerung. In den n\u00e4chsten Wochen wird man versuchen, das Geh\u00f6rte und Erlebte zu verarbeiten, um sich schlie\u00dflich wieder auf das n\u00e4chste Mal zu freuen…<\/p>\nWechsel von TFS zu Git<\/h3>\n
![\"Marcel\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Marcel-300x199.jpeg\")
Mit der traditionellen Versp\u00e4tung (wie immer) startete die erste Session „Wechsel von TFS zu git“. Thomas sprach \u00fcber die unz\u00e4hligen Probleme mit der Benutzung von TFS und dem Wunsch auf Git zu wechseln. Der Gro\u00dfteil 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 \u00fcberzeugen k\u00f6nnte, sich die Alternative wenigstens einmal anzuschauen. Erschreckend zu h\u00f6ren fand ich, dass es tats\u00e4chlich 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\u00fcrwortern durch Git-TF<\/a> oder git-tfs<\/a> zu ersetzen und zu versuchen, eine eingeschworene Gemeinschaft aufzubauen, die ihren Workflow effizienter umsetzen kann.<\/p>\nScrum: Von der Gruppe zum Team<\/h3>\n
\nVorgeschlagen wurde u.a., die Stories als Durchstich zu gestalten und das Ergebnis als Team zu pr\u00e4sentieren, vermehrt auf Pair Programming zu setzen und auf Coding Dojos zur\u00fcckzugreifen.<\/p>\nVerhandeln und Deeskalieren<\/h3>\n
Kreativtechniken<\/h3>\n
Heterogenes Computing<\/h3>\n
XamlBoard<\/h3>\n
Paket<\/h3>\n
\nAbgesehen von NuGet<\/em>-Paketquellen k\u00f6nnen sogar GitHub-Projekte als Abh\u00e4ngigkeit definiert werden. Versionsabh\u00e4ngigkeiten k\u00f6nnen dadurch viel feingranularer angegeben werden. Die Konvertierung eines Projekts von NuGet<\/em> auf Paket<\/em> kann per Kommandozeilenschalter erledigt werden, so dass einem raschen Umstieg nichts mehr im Wege steht.<\/p>\nC++ 11\/14<\/h3>\n
FAKE<\/h3>\n
\nDurch miterzeugte .yml-Dateien steht dem sofortigen Einsatz des Skriptes innerhalb eines Buildservers nichts im Wege. Durch ein entsprechendes Plugin<\/a><\/p>\nKrieg der Welten – Doku vs Development<\/h3>\n
\nInsgesamt waren die vorgebrachten Punkte verst\u00e4ndlich. 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\u00fcr sie offensichtliche Dinge weg. Dadurch m\u00fcssen Redakteure immer wieder nachhaken, mitunter auch die Antwort \u00fcbersetzen. Ein h\u00e4ufiger Punkt in einer Release-Note lautet: „Wir haben optimiert“. Das f\u00fchrt den Leser zur Frage nach dem Warum: Aus Langeweile? Es w\u00e4re 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\u00f6nnte oder sprachlich etwas zu verbessern w\u00e4re. Das Fazit der Session war, dass Redakteure und Programmierer jeweils ihre „Superkr\u00e4fte“ haben, sie aber gemeinsam mehr f\u00fcr den Kunden rausholen k\u00f6nnen.<\/p>\nFazit<\/h3>\n
Expression Blend und Visual Studio sind Marken oder registrierte Marken der Firma Microsoft Corporation in den USA und \/ oder anderen L\u00e4ndern.<\/div>\n","protected":false},"author":33,"featured_media":0,"template":"","tags":[388],"class_list":["post-5214","blog","type-blog","status-publish","hentry","tag-git-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/5214","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/33"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/5214\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=5214"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=5214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}