{"id":187,"date":"2017-09-30T22:05:07","date_gmt":"2017-09-30T20:05:07","guid":{"rendered":"http:\/\/www.yves-ostwald.de\/blog\/?p=187"},"modified":"2017-10-02T22:38:46","modified_gmt":"2017-10-02T20:38:46","slug":"reading-group","status":"publish","type":"post","link":"http:\/\/www.yves-ostwald.de\/blog\/2017\/reading-group\/","title":{"rendered":"Reading Groups &#8211; Die Wahrheit hinter dem Mythos"},"content":{"rendered":"<p>Seit einiger Zeit geht das Konzept der <em>Reading Group<\/em> in vielen Projekten umher und wird als Allheilmittel kosteng\u00fcnstiger Ausbildung von Teammitgliedern in IT-Projekten gepriesen \u2013 aber ist das wirklich so?<\/p>\n<p><!--more--><\/p>\n<p>Das Prinzip erscheint einfach &#8211; Lasse dein Team gemeinsam ein Buch lesen und rede \u00fcber das gelesene. Das so angelesene Wissen setzt sich und kann vom Team direkt bei der t\u00e4glichen Arbeit angewandt werden.<br \/>\nDie Vorteile scheinen auf der Hand zu liegen:<\/p>\n<ul>\n<li>\n<div>Es fallen verh\u00e4ltnism\u00e4\u00dfig geringe Kosten an.<\/div>\n<ul>\n<li>Je Teammitglied muss ein Buch gekauft werden, dieses kann sequenziell von mehreren Teams verwendet werden.<\/li>\n<\/ul>\n<\/li>\n<li>Es werden weder Schulungsr\u00e4ume, noch teure Trainer ben\u00f6tigt.<\/li>\n<li>Einmal alle zwei Wochen trifft sich das Team und spricht gemeinsam \u00fcber das gelesene \u2013 Aufwand ca. 1h.<\/li>\n<li>Das Team setzt das erlernte Wissen direkt im Projekt um.<\/li>\n<\/ul>\n<p>Klingt toll, aber ist eine <em>Reading Group<\/em> wirklich so effektiv?<br \/>\nSchauen wir uns die Vor- und Nachteile einmal im Detail an.<\/p>\n<h2>Die Vorteile<\/h2>\n<p>Wir haben ein neues Team zusammengestellt und wollen sicherstellen das alle ein einheitliches Verst\u00e4ndnis \u00fcber die anstehende Thematik haben. Im Kick-Off wurden die Teammitglieder einander vorgestellt und die Themen der n\u00e4chsten Monate vorgestellt.<br \/>\nDamit das Team sich mit der neuen Thematik besser auseinandersetzen und identifizieren kann wird eine Reading Group beschlossen \u2013 und das Team beginnt zu lesen.<\/p>\n<p><strong>Ein Leitbild f\u00fcr das Team erarbeiten:<\/strong><br \/>\nNehmen wir ein mal an das verschiedene Entwickler in die Architektenrolle ihres Teams eingef\u00fchrt werden sollen. Das Team beschlie\u00dft nun ein Buch \u00fcber die Rolle der Architektur in der Softwareentwicklung zu lesen.<br \/>\nDabei werden Prinzipien und Werte der Architektur im Team erarbeitet und als Leitbild festgehalten: &#8222;<em>Als Architekt wollen wir nicht im eisernen Turm sitzen, sondern Verantwortung f\u00fcr die Architektur \u00fcbernehmen<\/em>&#8222;.<\/p>\n<p><strong>Methodiken lernen und einsetzen:<\/strong><br \/>\nEin weiterer Ansatz ist es Aufgaben mit dem Team direkt umzusetzen, wie die Erstellung eines &#8222;Big Pictures&#8220; in Form von 4C Diagrammen (Context, Component, Container, Class) oder die Durchf\u00fchrung eines &#8222;Risk-Stormings&#8220; mit den Entwicklerteams.<br \/>\nDas Team entwickelt sich so mit jedem Kapitel weiter und liefert zugleich noch einen Businessnutzen f\u00fcr das Projekt in Form des &#8222;Big Pictures&#8220; oder dem &#8222;Risk-Storming&#8220; welches wiederum Schwachstellen der Architektur offenbaren kann.<\/p>\n<p><strong>Paradigmen der Softwareentwicklung festigen:<\/strong><br \/>\nEin weiterer Vorteil ist das erarbeiten eines gemeinsamen Verst\u00e4ndnisses im Team. Nimmt man einmal das Thema &#8222;Dependency Injection&#8220; zum Ziel, so erarbeitet man sich zun\u00e4chst ein Grundvokabular (Constructor Injection, Property Injection, Ambient Context, etc.), mit dem sichergestellt wird das jeder im Team wei\u00df wovon der andere gerade redet.<br \/>\nKlingt trivial, aber jeder der schon einmal in einem bunt gemischtem Entwicklerteam gearbeitet hat, wei\u00df wie breit gestreut das Wissen jedes einzelnen sein kann.&nbsp;<\/p>\n<h2>Die Nachteile<\/h2>\n<p>Reicht ein gemeinsames Vokabular? K\u00f6nnen wir wirklich davon ausgehen das das einfache Lesen eines Kapitels in einem Buch jedes Teammitglied in die Lage versetzt das gelesene auch im Projekt umzusetzen?<\/p>\n<p>Das Konzept der <em>Reading Group<\/em> bringt gleich mehrere Nachteile mit sich:<\/p>\n<ul>\n<li>Da sich das Team nur alle zwei Wochen trifft, um die gelesenen Kapitel zu besprechen dauert es seine Zeit bis das Wissen im Projekt genutzt werden kann.<\/li>\n<li>Sind die Themen zu abstrakt, fehlt dem Team der Zusammenhang zum aktuellen Projekt und das Wissen kann nicht effektiv eingesetzt werden.<\/li>\n<li>Wird das Erlernte nicht sofort eingesetzt, geht viel wissen wieder verloren. Nur selten wird das Wissen dann vom Team erneut abgerufen. Meist ben\u00f6tigt man dann einen kleinen Auffrischungskurs.<\/li>\n<li>Setzt das Team das Wissen Kapitel f\u00fcr Kapitel direkt im Projekt um, l\u00e4uft es Gefahr erst sp\u00e4t zu erkennen wenn es vom Weg abgekommen ist, oder es verliert sich in umst\u00e4ndlichen Paradigmen.<\/li>\n<\/ul>\n<p>Vieles h\u00e4ngt zudem von der Zusammensetzung des Teams ab. Handelt es sich um ein sehr junges Team mit viel Junioren, kann es sein das das Wissen nicht gleich richtig verstanden wird oder einfach falsch angewandt wird.<\/p>\n<h2>Erfahrungswerte<\/h2>\n<p>Bewegt sich das Team auf einem einigerma\u00dfen vergleichbarem Niveau, so kann eine <em>Reading Group<\/em> helfen ein gemeinsames Verst\u00e4ndnis f\u00fcr ein spezielles Thema zu erlangen (Beispielsweise Domain Driven Design).<br \/>\nWerden die Gelesenen Kapiteln mit Beispielen aus dem aktuellen Projekt angereichert, hilft es das Wissen sofort im Projekt umzusetzen und zu vertiefen.<\/p>\n<p>In unseren <em>Reading Groups<\/em> haben wir uns meist nach der ersten Viertelstunde vom Kapitel gel\u00f6st und bezogen die aktuelle Lage des Projektes in die Diskussion mit ein, um m\u00f6gliche L\u00f6sungen zu erarbeiten.<\/p>\n<p>Sind die Wissensl\u00fccken im Team allerdings zu gro\u00df, so ist es der bessere Ansatz spezielle Themen gezielt zu Schulen. Meist nehmen solche Ma\u00dfnahmen weniger Zeit in Anspruch, als das Lesen mehrerer Kapitel \u00fcber Wochen hinweg. Zudem ist eine Kontrolle, ob das erlernte auch wirklich verstanden wurde leichter zu gew\u00e4hrleisten.<\/p>\n<p>Das Team auf einem vergleichbarem Niveau zu halten ist essenziell in einer <em>Reading Group<\/em>. Bei unerfahrenen Entwicklern ist die Gefahr zu gro\u00df, das das gelesene falsch Verstanden wird und zu mehr Verwirrung f\u00fchrt als es nutzen bringt. In diesen F\u00e4llen sollte die <em>Reading Group<\/em> immer von einem erfahrenen Entwickler\/Coach betreut werden, der gezielt durch die einzelnen Kapitel leiten kann.<\/p>\n<h2>Fazit<\/h2>\n<p>H\u00e4lt man sich an diese Regeln, so kann man \u00fcber einen l\u00e4ngeren Zeitraum eine Wissensbasis im Team aufbauen und festigen. F\u00fcr das erlernen spezieller Technologien sind allerdings gezielte Schulungen besser geeignet. Zudem ist eine <em>Reading Group<\/em> nicht f\u00fcr jeden Lerntyp geeignet und ersetzt dadurch nicht das individuelle lernen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Seit einiger Zeit geht das Konzept der Reading Group in vielen Projekten umher und wird als Allheilmittel kosteng\u00fcnstiger Ausbildung von Teammitgliedern in IT-Projekten gepriesen \u2013 aber ist das wirklich so?<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[18],"tags":[17],"class_list":["post-187","post","type-post","status-publish","format-standard","hentry","category-education","tag-reading-group"],"_links":{"self":[{"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/posts\/187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/comments?post=187"}],"version-history":[{"count":7,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/posts\/187\/revisions"}],"predecessor-version":[{"id":219,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/posts\/187\/revisions\/219"}],"wp:attachment":[{"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/media?parent=187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/categories?post=187"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.yves-ostwald.de\/blog\/wp-json\/wp\/v2\/tags?post=187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}