tag:blogger.com,1999:blog-60904831814559533052024-03-14T00:18:43.964+01:00One Man Think Tank GedankenSpontanes und Überlegtes aus meinem "Denkraum" - www.ralfw.deRalf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.comBlogger424125tag:blogger.com,1999:blog-6090483181455953305.post-2851479332342544192015-12-08T10:56:00.001+01:002015-12-08T10:56:09.257+01:00Teaser: Der dunkle Bruder des Feedback<p>Feedback ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern am Ende kurzer Iterationen bekommen Entwickler Feedback innerhalb von Tagen oder wenigen Wochen, ob sie ihr Werkstück näher an die Zielvorstellung jener heranentwickelt haben.</p> <p>Mit der Agilität ist das Feedback aus dem Schatten von Gevatter Plan getreten. Das ist eine zentrale Leistung der Agilität.</p> <p>Doch irgendetwas stimmt nicht. Es herrscht jetzt nicht einfach Friede. Die Entwicklung schreitet nicht einfach zügig voran. Ganz merkwürdig zagt und stolpert sie immer noch – trotz des klaren, sauberen Anführers Feedback.</p> <p>Das liegt an einer Kraft, die bisher unbenannt ist. Sie beeinflusst den Fortschritt stark, doch niemand benennt sie so recht. Alle kennen sie, aber man räumt ihr keinen gleichwertig offiziellen Platz neben dem Feedback ein. Ich will sie deshalb den dunklen Bruder des Feedback nennen.</p> <p><a href="http://ralfw.de/2015/12/der-dunkle-bruder-des-feedback/" target="_blank">[Lesen Sie weiter in meinem neuen Blog…]</a></p> <h3>Neue RSS-Feeds</h3> <p>Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner <a href="http://ralfw.de/blog/">Homepage</a>.</p> <p>Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.</p> <ul> <li><a href="http://ralfw.de/blog/feed/" target="_blank">RSS-Feed mit allen Artikeln</a> <li><a href="http://ralfw.de/category/deutsch/feed/" target="_blank">Nur deutsche Artikel</a> <li><a href="http://ralfw.de/category/english/feed/" target="_blank">Nur englische Artikel</a> <li><a href="https://twitter.com/ralfw" target="_blank">Twitter @ralfw</a></li></ul> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-44158481612838559512015-12-04T08:53:00.001+01:002015-12-04T08:53:32.996+01:00Teaser: Microservices verbinden in Datenflüssen<p>Mir hat der Blogartikel von Tobias Flohre gut gefallen, in dem er die Kommunikation zwischen Microservices mit asynchronen Events beschreibt. Er tut das als Gegenentwurf zu einer Darstellung mit BPMN und einer Implementation auf der Basis einer Workflow-Engine.</p> <h2>Entkoppeln mit Events</h2> <p>Gut gefallen hat mir der Artikel, weil Tobias damit eine Lanze für das Principle of mutual Oblivion (PoMO) bricht. Es besagt, dass Funktionseinheiten in Software nicht funktional abhängig von einander sein sollen. Logik in der einen sollte Logik in der anderen nicht kennen, nicht nutzen. Jede Funktionseinheit sollte vielmehr quasi selbstvergessen “nur ihr Ding machen” und sich nicht um die Umwelt scheren. So tut das in einem Organismus jede Zelle; warum also nicht auch jede Funktionseinheit in einer Software? (Das ist aus meiner Sicht sogar, was Alan Kay ursprünglich unter Objektorientierung verstanden hat. Hier dazu eine Artikelserie von mir: OOP as if you meant it.)</p> <p>Ich schreibe hier bewusst “Funktionseinheit”, weil ich auf konzeptioneller Ebene spreche. Eine Funktionseinheit kann im Code eine Funktion oder eine Klasse… oder eben auch ein Microservice sein. Eben ein Modul als Träger von Verhalten herstellender Logik.</p> <p>Eine PoMO-konforme Funktionseinheit bekommt von irgendwoher “etwas”, arbeitet daraufhin und liefert anschließend “etwas anderes” ab. Woher “etwas” kommt, wohin “etwas anderes” geht, das ist der Funktionseinheit einerlei. Das mag seltsam klingen – doch Sie sind damit ganz vertraut. Jede Funktion T f<S,T>(S s) arbeitet so.</p> <p>Hier ein Beispiel für eine solche Funktionseinheit aus Tobias’ Artikel:</p> <p><a href="http://ralfw.de/2015/12/microservices-verbinden-in-datenfluessen/" target="_blank">[Lesen Sie den ganzen Artikel in meinem neuen Blog…]</a></p> <h3>Neue RSS-Feeds</h3> <p>Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner <a href="http://ralfw.de/blog/">Homepage</a>.</p> <p>Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.</p> <ul> <li><a href="http://ralfw.de/blog/feed/" target="_blank">RSS-Feed mit allen Artikeln</a> <li><a href="http://ralfw.de/category/deutsch/feed/" target="_blank">Nur deutsche Artikel</a> <li><a href="http://ralfw.de/category/english/feed/" target="_blank">Nur englische Artikel</a> <li><a href="https://twitter.com/ralfw" target="_blank">Twitter @ralfw</a></li></ul> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-84068125342465124732015-12-03T16:30:00.000+01:002015-12-03T16:30:00.333+01:00Teaser: Ziele erreichen mit tugendhafter Emergenz<p>Manche Ziele scheinen mir so schwer erreichbar, dass ich denke, man kann sie gar nicht direkt erreichen.</p> <p>Wie sieht es mit einem erfolgreichen Unternehmen aus? Oder was tun, um Software stets wandlungsfähig zu halten? Kann man auf diese Ziele Maßnahme für Maßnahme zugehen?</p> <h3>Probleme zentraler Steuerung</h3> <p>Es wird schwer, auf ein Ziel zuzusteuern, wenn man die dafür relevanten Teile und Aktivitäten nicht mehr überblickt. Solange man sie überblickt, kann man versuchen, sie direkt anzusteuern. Jenseits des Überblicks jedoch… das stellt sich schnell ein Gefühl des Kontrollverlustes ein – umso mehr, je stärker man glaubt, doch eigentlich zu wissen, was zu tun nötig ist.</p> <p>Unabhängig vom Überblick kann es aber auch an Zeit mangeln. Selbst wenn eine zentrale Instanz wüsste, wie Teile zu steuern wären, kann es schlicht zu lange dauern, sie zu informieren und auf Antwort zu warten, um angemessen schnell zu reagieren.</p> <p>Und schließlich noch die Inkompetenz. Egal wie groß die Zahl der Teile und wie lang die Kommunikationswege: wenn die Komplexität wächst, werden in Bezug zu ihr zentrale Entscheider zunehmend inkompetent. Sie können einfach nicht mehr wissen, was zu tun ist, um gewünschte Zustände durch konkrete Steuerungsmaßnahmen zu erreichen. Das ist nur möglich, solange die Situationen kompliziert sind.</p> <p><a href="http://ralfw.de/2015/11/ziele-erreichen-mit-tugendhafter-emergenz/" target="_blank">[Lesen Sie weiter in meinem neuen Blog…]</a></p> <h3>Neue RSS-Feeds</h3> <p>Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner <a href="http://ralfw.de/blog/">Homepage</a>.</p> <p>Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.</p> <ul> <li><a href="http://ralfw.de/blog/feed/" target="_blank">RSS-Feed mit allen Artikeln</a></li> <li><a href="http://ralfw.de/category/deutsch/feed/" target="_blank">Nur deutsche Artikel</a></li> <li><a href="http://ralfw.de/category/english/feed/" target="_blank">Nur englische Artikel</a></li> <li><a href="https://twitter.com/ralfw" target="_blank">Twitter @ralfw</a></li></ul> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-89791774638303660712015-12-01T16:25:00.000+01:002015-12-01T16:25:00.242+01:00Teaser: Bereiche der Schätzbarkeit<p>In den letzten beiden Tagen habe ich mal wieder zusammen mit <a href="http://zeitgewinn-hamburg.de" target="_blank">Andrea Kaden</a> einen Zeitmanagement-Workshop für Softwareentwickler gegeben. Natürlich kamen wir dabei auch auf das Thema Schätzung. Das treibt Entwickler immer wieder und immer noch sehr um. Sie empfinden schlicht großen Stress, wenn es vorhersagbar nicht klappt, Schätzungen einzuhalten. Sie fühlen sich unwohl, zur Unehrlichkeit gezwungen zu werden.</p> <p>Das verstehe ich sehr gut. Deshalb bemühe ich mich, Hilfestellung bei diesem Thema zu geben. Ich versuche zu erklären, warum es mit dem Schätzen schwer bis unmöglich ist. Ich versuche, einen alternativen Weg aufzuzeigen, auch ohne Schätzungen verlässlich wertvolle Software herzustellen. Ich verweise auf andere, die auch versuchen, Entspannung zu vermitteln.</p> <p>Deshalb heute auch dieser Blogartikel. Ein weiterer Versuch, Softwareschätzungen besser verständlich zu machen. Und zwar ausgehend von einer Analogie.</p> <p><a href="http://ralfw.de/2015/11/bereiche-der-schaetzbarkeit/">[Lesen Sie weiter in meinem neuen Blog…]</a></p> <h3>Neue RSS-Feeds</h3> <p>Seit Oktober 2015 schreibe ich sowohl meine deutschen wie meine englischen Blogartikel nur noch im neuen konsolidierten Blog direkt auf meiner <a href="http://ralfw.de/blog/">Homepage</a>.</p> <p>Wenn Sie über neue Artikel automatisch informiert werden wollen, abonnieren Sie doch einen meiner RSS-Feeds oder folgen Sie mir bei Twitter.</p> <ul> <li><a href="http://ralfw.de/blog/feed/" target="_blank">RSS-Feed mit allen Artikeln</a></li> <li><a href="http://ralfw.de/category/deutsch/feed/" target="_blank">Nur deutsche Artikel</a></li> <li><a href="http://ralfw.de/category/english/feed/" target="_blank">Nur englische Artikel</a></li> <li><a href="https://twitter.com/ralfw" target="_blank">Twitter @ralfw</a></li></ul> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-30354701464785514002015-10-10T11:09:00.001+02:002015-10-10T11:09:49.784+02:00Gelebte inkrementelle Dekomposition <p>Neulich war große Freude. Ein Produktentwicklungsteam eines Kunden zeigte mir, wie es meinen Vorschlag eines anderen Umgangs mit Anforderungen umsetzt - und dadurch flüssiger arbeitet.</p> <h3>Inkrementelle Dekomposition</h3> <p>Mein Vorschlag war und ist, Anforderungen des Kunden bzw. die User Stories eines Product Owners nach einem Schema “zu zermahlen”, um für die weitere Entwicklung sehr präzise Ausgangspunkte zu bekommen.</p> <p>Ausführlicher habe ich dieses Schema in einem <a href="http://blog.ralfw.de/2014/09/vom-problemtrichter-zum-losungsbaum.html">früheren Artikel</a> beschrieben. Deshalb skizziere ich es hier nur noch und stelle es in einen Prozesszusammenhang.</p> <p>Für mich sieht ein Teil des Softwareproduktionsprozesses so aus:</p> <p><a href="http://lh3.googleusercontent.com/-I9R7CB2xcbU/VhjVzgCnmkI/AAAAAAAAF5I/ALNjyR1OAMM/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-1EMZtRISjV4/VhjV0ZSBQbI/AAAAAAAAF5M/TSidkISp77M/image_thumb%25255B2%25255D.png?imgmax=800" width="554" height="80"></a></p> <p>Ein Strom von unstrukturierten Anforderungen wird von einem Product Owner im Rahmen eines so genannten <em>Story Development</em> durchgekaut und in User Stories transformiert. Die sind klein, konkret, wertorientiert, priorisiert.</p> <p>Allerdings sind User Stories rein aus der Sicht von Kunde/Anwender formuliert. Die Programmierung kann sie nicht einfach implementieren. Vielmehr muss darauf eine Vorverarbeitung stattfinden.</p> <p>Entwickler (und Tester) sitzen dafür zunächst mit dem Product Owner zusammen und analysieren die User Stories. Bisher hat ja nur der Product Owner verstanden, was zu tun ist. Dieses Wissen muss in die Köpfe der Programmierer übertragen werden. Das bedeutet, die Welt des Problems muss an die Welt der Lösung angeschlossen werden. Es müssen Bezüge hergestellt werden, ein Mapping stattfinden.</p> <p>Mit <a href="http://blog.ralfw.de/2014/09/vom-problemtrichter-zum-losungsbaum.html">meinem Ansatz</a> plädiere ich dafür, die User Stories “in einen Problemtrichter zu stopfen”, aus dem unten einzelne Funktionen mit zugehörigen Akzeptanzkriterien heraustropfen.</p> <p>User Stories stellen die Anforderungen in Form von Inkrementen vor, d.h. für den Kunden wertvolle Zuwächse an Funktionalität oder Effizienz. <em>Slices</em> sind Inkremente mit konkretem Bezug zur Welt der Codierung, d.h. der Lösung.</p> <p>Die Problemanalyse transformiert einen Strom von User Stories also in einen Strom von Slices unterschiedlicher Dicke. Hier die Liste der wichtigsten Slices mit den ihnen entsprechenden Programmierartefakten (Module):</p> <ul> <li>Anwendung = Bibliothek</li> <li>Dialog = Klasse</li> <li>Interaktion = Funktion</li> <li>Feature = Funktion</li></ul> <p>Jede User Story entspricht dann in der Hierarchie der Slices einem oder mehreren Pfaden der Form Anwendung/Dialog/Interaktion/Feature. Das ist für die weitere Programmierung sehr, sehr viel konkreter, als eine User Story. Die Programmierung fühlt sich auf diese Weise weniger allein gelassen mit Verständnis und Übersetzung von Anforderungen. Ja, die Programmierung bekommt durch die gemeinsame Problemanalyse mit dem Product Owner sogar schon konkrete Hinweise auf eine minimale Modularisierung des Codes. Und die spiegelt dann auch noch das agile Vorgehen wider.</p> <p>Während üblicherweise User Stories nach der Implementation nicht mehr im Code zu erkennen sind, bleiben bei diesem Vorgehen Inkremente als Artefakte im Code erhalten. Das ist von unschätzbarem Wert für die Nachvollziehbarkeit und Verständlichkeit von Code.</p> <p>Der ursprüngliche Strom von Anforderungen wird also in zwei Schritten zerlegt in Inkremente (inkrementelle Dekomposition):</p> <ol> <li>Story Development -> User Stories</li> <li>Problemanalyse -> Slices</li></ol> <p>Beide zusammen dienen der Qualitätssicherung des Input in die weitere Programmierung. Das ist wichtig, da einer der häufigsten Engpässe bei der Softwareproduktion die Implementation oder die anschließende QA ist. Hohe Inputqualität für den Engpass ist Voraussetzung für hohe Qualität seines Output. Und die ist wichtig, damit der Engpass später nicht mit Nachbesserungen belastet wird.</p> <p>Soweit die Theorie. Jetzt die Praxis.</p> <h3>Im realen Projekt</h3> <p>Als Trainer in Sachen flüssige Softwareproduktion und Clean Code Development stelle ich diese Vorgehensweise vielen, vielen Entwicklern vor. Wir üben sie dann tapfer in Workshops. Doch die Übertragung solcher “Theorie” in den Arbeitsalltag fällt den Teilnehmern immer wieder sehr schwer. Über die Gründe kann man diskutieren und lamentieren - aber nicht heute. Heute möchte ich zur Abwechslung zeigen, wie der Transfer eben auch klappen kann.</p> <p>Das Team bei meinem Kunden besteht im Wesentlichen aus 2 Entwicklern, 3 Testern und 1 Product Owner. Beide Entwickler hatten an 2 Schulungstagen der <a href="http://ccd-school.de">Clean Code Developer School</a> teilgenommen, an denen wir uns auf den Umgang mit Anforderungen konzentriert hatten. Dann am Ende des dritten Schulungstages luden sie mich ein, sich ihre Umsetzung des Lernstoffes in ihrem team room einmal anzusehen.</p> <p>An der Wand sah ich dort diesen Notizenbaum:</p> <p><a href="http://lh3.googleusercontent.com/-GmnERnkWjkk/VhjV1DpE3dI/AAAAAAAAF5Y/WRz3Q5buIJY/s1600-h/image%25255B9%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-WhqqvBjg56I/VhjV14J8vaI/AAAAAAAAF5c/ZYkrdbFNQCA/image_thumb%25255B5%25255D.png?imgmax=800" width="557" height="255"></a></p> <p>Die Anwendung, an der das Team arbeitet, steht außer Frage. Die muss nicht explizit modelliert werden.</p> <p>Der Dialog, auf den sich die (derzeit) zu realisierenden User Stories beziehen, steht ebenfalls außer Frage. Die ganze Wand konzentriert sich auf diesen Dialogentwurf:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-dPni4PTccVo/VhjV2VlNvPI/AAAAAAAAF5k/AWvM1G86Fy8/image%25255B15%25255D.png?imgmax=800" width="355" height="233"></p> <p>Aus diesem Grund ist der Dialog auch nicht an der Wand zu sehen. Das finde ich verständlich, aber meine Empfehlung ist, ihn dennoch dort ebenfalls zu visualisieren. Dadurch wird jedes Denken über Slices konkreter. Bei Diskussionen kann man leichter Bezug nehmen, um über Interaktionen und Features zu sprechen. Niemand muss im Zweifelsfall in irgendwelchen Dokumenten nach dem aktuellen Stand des Dialog-Layouts suchen.</p> <p>Aber auch ohne Dialog finde ich die Darstellung an der Wand klasse. Dort sind nämlich die von mir vorgeschlagenen Slices systematisch als Baum zu sehen:</p> <ul> <li>Quer über die Wand stehen grüne Karten für Interaktionen des Dialogs. Jede lässt sich einem Button oder dem Klick auf eine Liste usw. zuordnen.</li> <li>Senkrecht stehen orange und gelbe für Features der jeweiligen Interaktion. Die Darstellung der Feature-Hierarchie ist an der Wand leider begrenzt. Mit Farben wurden zwei Ebenen unterschieden und es gibt eine gewisse physische Unterordnung. Letztlich kommt hier der Umgang mit Kärtchen aber an seine Grenzen. Doch das Team ist kreativ mit seinen Mitteln umgegangen. Super!</li></ul> <p>An diese Wand kann ich herantreten, eine beliebige Karten auswählen und bin sicher, dafür eine Entsprechung im Code zu finden. Da es sich um Interaktionen und Features handelt, gibt es für jede 1 Funktion im Code.</p> <p>Das ist die Sicht der Entwickler. Gleichzeitig stellt jede Karte aber auch noch Wert für den Product Owner dar! Alle Karten repräsentieren Inkremente. Zu allen Karten kann der Product Owner Feedback geben, ob das gewünschte Verhalten schon nach seinem Geschmack umgesetzt wurde.</p> <p>(Zu dieser Regel gibt es nur eine Ausnahme: Die zweite grüne Karte von Links steht nicht für eine Interaktion sondern für die Datenstruktur des Dialogs, d.h. für die Steuerelemente mit den zugehörigen Datentypen und einige Validationsregeln. Dass dies visualisiert wird, ist natürlich eine gute Sache. Doch ich empfehle eine deutliche Unterscheidung von den Slices, z.B. durch räumliche Trennung oder andere Farben.)</p> <p>Diese Systematik zu sehen, hat mich schon begeistert. Doch das Team zeigte mir noch mehr. Es setzt nämlich auch meine Empfehlung um, einzelne Features dem Product Owner über einen Prüfstand zum Feedback vorzulegen.</p> <p>Hier der Prüfstand für den Cluster von Features, den ich an der Wand hervorgehoben habe:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-V-9sfQMWoo0/VhjV2-n3tEI/AAAAAAAAF5s/OmGaRfHE8NM/image%25255B21%25255D.png?imgmax=800" width="342" height="224"></p> <p>Der Product Owner (oder auch ein Tester) kann mit dem Prüfstand wie mit einer speziellen Messsonde gezielt einen kleinen Teil des Gesamtverhaltens prüfen, ohne die ganze Anwendung oder auch nur den ganzen Dialog zu bemühen.</p> <p>Das macht erstens das Feedback einfacher. Zweitens wird der Product Owner damit frei, sich Features in quasi jeder beliebigen Reihenfolge zu wünschen. Und drittens können Features, Interaktionen, Dialoge nun viel einfacher parallel entwickelt werden.</p> <p>Voraussetzung für den Prüfstand ist, dass Inkrement-Wünschen des Product Owners sehr konkrete Artefakte der Programmierung zugeordnet sind. Genau das leistet die inkrementelle Dekomposition mit der Herstellung von Slices jedoch.</p> <p>Das Fazit von Entwicklern wie Testern sowie Product Owner bisher: die Softwareproduktion ist viel flüssiger geworden.</p> <p>Darüber freue ich mich sehr! Und ich bin überrascht. Denn so eine pragmatische und zügige Umsetzung des in der CCD School vorgestellten Ansatzes hatte ich bisher noch nicht gesehen. Hier zeigt ein Team, was möglich ist, wenn man echt etwas verändern will. Die Initiative zweier motivierter Entwickler reichte aus, die anderen Teammitglieder waren offen für eine Veränderung und die Führungsebene darüber hat den Freiraum zu solcher Selbstorganisation gegeben.</p> <p>Drei notwendige Faktoren sind bei diesem Kunden also glücklich zusammengekommen. Super!</p> <p>Mehr Fluss, mehr Produktivität sind möglich mit systematischerer Softwareproduktion. Das so deutlich zu sehen, spornt mich an, nicht nachzulassen bei der Vermittlung von und Suche nach besseren Methoden.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-59853367597847934062015-09-09T20:10:00.001+02:002015-09-09T20:28:38.464+02:00Eine Chance zur Integrationshilfe <p>Eigentlich ist für mich als Hamburger die Flüchtlingswelle, die nach Deutschland fließt, eine recht abstrakte Größe. Am Straßenbild hat sich für mich bisher nichts verändert. Menschenbunt ist Hamburg schon lange. Nur die Medien hatten mir bisher davon berichtet, was da so zukunftsverändernd gerade massiv passiert.</p> <p>Jedenfalls bis neulich. Denn da habe ich Nour Saeed aus Syrien kennengelernt.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-F-XdF7BNbeI/VfB2ALYt52I/AAAAAAAAF30/hKQGXGZtxdw/image%25255B4%25255D.png?imgmax=800" width="470" height="365"></p> <p>Aber der Reihe nach: Eigentlich hatte ich ein kleines Programmierprojekt, das ich outsourcen wollte. Zuerst wollte ich den Entwickler in Indien wieder engagieren, mit dem ich schon einmal zusammengearbeitet hatte. Doch dann überlegte ich, dass dies vielleicht eine Chance sei, einem Flüchtling zu helfen. Unter denen gibt es doch bestimmt auch Softwareentwickler. Nur wie das herausfinden?</p> <p>Da fügte es sich, dass ich einen Hinweis auf die Plattform <a href="http://workeer.de">workeer.de</a> bei facebook sah. Manchmal ist facebook doch tatsächlich nützlich ;-) workeer.de bezeichnet sich als “Die erste Jobbörse für Geflüchtete und Arbeitgeber, die ihnen Chancen eröffnen wollen.”</p> <p>Also habe ich die Liste der Jobsuchenden durchgeblättert und fand sogar einen Softwareentwickler mit C#-Kenntnissen darin: Nour Saeed. Bingo, Glückstreffer!</p> <p>Nach Anmeldung bei workeer.de konnte ich mit ihm Kontakt aufnehmen. Er spricht derzeit noch kein Deutsch, aber mit Englisch ging es auch. Also begannen wir über die Konditionen zu verhandeln, wie er für mich tätig werden könnte.</p> <p>Nour ist als Flüchtling anerkannt und darf in Deutschland arbeiten. Das Jobcenter stellt ihm eine Wohnung zur Verfügung und darüber hinaus noch 400€, von denen er einen Teil für die Wohnung abgibt, Elektrizität und den Internetzugang bezahlt - und dann von ca. 300€ seinen Lebensunterhalt bestreitet. Allerdings weiß Nour nicht, wie unser Arbeitssystem funktioniert. Wo ist der Unterschied zwischen Praktikum, Anstellung, Selbstständigkeit? Wohin könnte ich ihm einen vereinbarten Stundensatz überweisen? Könnte er mir eine Rechnung schreiben? Das waren Fragen, mit denen er überfordert war. Und er fühlte sich auch außerstande, sie mit seinem Jobcenter zu klären, denn dort spricht man eher kein Englisch.</p> <p>Wie es sich ergab, rutschte die Priorität für mein Projekt im Verlauf der Tage, die wir per Email kommunizierten aus verschiedenen Gründen, die nichts mit Nour zu tun hatten, aber nach unten. Die Umsetzung war nicht mehr wichtig. Also auch nicht mehr die Beantwortung dieser Fragen für mich. Ich bot Nour daher alternativ an, er könne sich aber mit Code Katas des <a href="http://ccd-school.de/coding-dojo">Coding Dojo</a> der CCD-School schon einmal warmprogrammieren ;-) Ich würde ihm gern Feedback zu seinen Lösungen geben.</p> <p>Dabei hätte es bleiben können. Aber dann ließ mich das Thema Flüchtlingswelle doch nicht in Ruhe und ich überlegte, ob ich mehr für Nour tun könnte. Also bot ich ihm an, einmal nach Güstrow zu kommen, wo er derzeit lebt. Mit einem Artikel in meinem Blog hoffte und hoffe ich, seine Sichtbarkeit als motivierten Softwareentwickler zu erhöhen. Vielleicht findet sich ja ein Unternehmen, dass für ihn einen Platz hat.</p> <p>Nour ist derzeit 26 Jahre alt und hat seinen Bachelor in <em>Information Systems Engineering</em> mit Schwerpunkt in <em>Software application development</em>. Interessanterweise hat er den letzten Baustein zum Abschluss seines Studiums per Skype eingebaut. Denn zu dem Zeitpunkt war er schon nicht mehr in Syrien. Es war ihm einfach sehr wichtig, einen qualifizierten und international relevanten Abschluss trotz aller Widrigkeiten zu schaffen. Denn eines war klar: Wo immer er aufgenommen würde, er will arbeiten, seinen Lebensunterhalt selbst verdienen und sich weiterentwickeln.</p> <p>Das Gepäck, dass er, seine zwei Brüder und seine Eltern aus Damaskus mitnehmen konnten, war naturgemäß klein. Der Vater hatte sein Geschäft verkauft, um die Flucht finanzieren zu können. Was nicht in einen Rucksack und einen Koffer pro Person passte, musste zurückgelassen werden.</p> <p>Aber Nour hatte nicht nur seinen Laptop eingepackt, sondern auch <em>C# 2.0 - The Complete Reference</em>, d.h. das für ihn beste verfügbare Buch zum .NET Framework. Dieses seitenstarke Buch sollte ihm in den folgenden Monaten ein treuer Begleiter sein.</p> <p>Als ich in seine Wohnung in Güstrow komme, sehe ich es gleich auf der Fensterbank liegen. Dass er es durch alle Strapazen der Flucht behalten hat, beeindruckt mich. So sieht Lernwille aus.</p> <p>Begonnen haben Nour und seine Familie die Flucht wohl Ende 2013. Auslöser war sein bevorstehender Studiumsabschluss. Er musste fürchten, danach von der syrischen Armee eingezogen zu werden. Eine Aussicht, die ihm Angst machte, da er für dieses Regime nicht Gefahr laufen wollte, sein Leben zu opfern. Aber auch die Alternative, bei einer der vielen Gruppen von Freiheitskämpfern zu dienen, war für ihn keine Option. Im Verlauf unseres Gesprächs berichtet er davon, wie Freunde von ihm auf dieser Seite gefallen waren - und wofür? Es war nicht einmal klar, ob die jeweilige Gruppe wirklich etwas für das Volk getan hatte oder nur für eigene Vorteile.</p> <p>Darüber hinaus wäre seine Familie aber auch nicht sicher vor Übergriffen der einen oder anderen “Armee” gewesen. Er berichtete von Folterungen und Tötungen auch Unbeteiligter. Sich schlicht für Freiheit auszusprechen, birgt in Syrien ein hohes Risiko. Zum Beleg zeigte er mir ein Video in der arabischsprachigen “Parallelwelt” bei Youtube, auf dem Zivilisten brutal von Soldaten der regulären syrischen Armee zu Tode gebracht werden unter höhnischen Fragen, was sie nun zu ihrer Idee von Freiheit sagen würden. Nour übersetzte - und für mich war es kaum auszuhalten, das mitansehen zu müssen.</p> <p>Dass Nour und seine Brüder sich in dieser Realität dafür entschieden haben, sich und ihre Familien in Sicherheit zu bringen… Wer würde ihnen das verdenken?</p> <p>Der Plan war jedoch zunächst, nach Auflösung des väterlichen Geschäfts, nur in die Türkei zu flüchten. Das schien ihnen ausreichen weit entfernt und gleichzeitig immer noch heimat- bzw. kulturnah. Der Weg führte sie mit einer normalen Ausreise nach Beirut im Libanon, von dort mit einer Fähre nach Mersin/Türkei. Dort verbrachten sie einige Zeit, um dann nach Istanbul weiter zu ziehen.</p> <p><a href="http://lh3.googleusercontent.com/-VA17c89WdoE/VfB2BuLqSdI/AAAAAAAAF38/O5Q9vBaQXCg/s1600-h/image%25255B8%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-mxMqiRB7_Ew/VfB2Cbh_F6I/AAAAAAAAF4A/1V0roeSFbiY/image_thumb%25255B3%25255D.png?imgmax=800" width="359" height="341"></a></p> <p>Insgesamt lebten sie 7 Monate in Instanbul. Dort fing Nour an, Türkisch zu lernen und versuchte, Arbeit als Softwareentwickler zu finden. Leider ohne Erfolg.</p> <p>Als das mitgebrachte Geld sich dem Ende zuneigte, sah die Familie keinen anderen Ausweg, als weiterzuziehen. Sie erkundigten sich, wo es größere Chancen auf Arbeit gebe. Deutschland und Schweden wurden als Ziele auserkoren.</p> <p>Mit dem unverheirateten Bruder und einigen Freunden versuchte Nour, über die grüne Grenze nach Griechenland zu gelangen. Zweimal ohne Erfolg. Beim ersten Mal, weil die Gruppe getrennt wurde. Beim zweiten Mal, weil sie geschnappt wurden. Als er das berichtet, lacht er und sagt, “But it was fun!” Bei aller Ungewissheit und Angst sei es ja am Ende gut ausgegangen. Die türkischen Soldaten, die sie aufbrachten, waren nett, hatten zwar Hunde und Gewehre - aber nur zur Abschreckung. Geladen waren die Gewehre nicht.</p> <p>Nach diesem Misserfolg ging es zurück nach Istanbul. Jetzt konnte nur noch eine Schlepperbande helfen. Für mehrere Tausend Euro pro Person wurde ein Transfer erkauft, der sie über Izmir, Bodrum, Marmaris in einen Lastwagen führte. Der brachte sie bei Nacht und Nebel irgendwo an der Küste zu einem Boot, das sie nach Kalymnos übersetzte.</p> <p>Von dort nahmen sie eine reguläre Fähre nach Athen, wo er sein Flugticket nach Deutschland bekam. Das galt jedoch ab Kreta, von wo er schließlich nach Berlin gelangte. Seine Brüder folgten erst später.</p> <p>Die Eltern nahmen derweil die Route Italien, Kopenhagen nach Schweden.</p> <p>In Berlin angekommen suchte Nour sich mit Hilfe eines türkischen Taxifahrers ein Hotel - das der sogar bezahlte. Am nächsten Tag stellte er sich bei den Behörden vor und fand nach einem weiteren Monat seinen vorläufigen neuen Heimatort: Güstrow in Mecklenburg-Vorpommern.</p> <p>Das war im September 2014. Nach Monaten in der Türkei und in Griechenland, nach Reisen zu Lande, zu Wasser und in der Luft war Nour angekommen. Die deutschen Behörden haben ihn “ins System” aufgenommen. Alles läuft seinen Gang. Nour lebt mit seinem Bruder in einer Wohnung. Nebenan wohnt der andere Bruder mit seiner Frau. Die Einrichtung ist bescheiden. Aber alle sind satt und warm.</p> <p>Aber das war es dann auch schon.</p> <p>Denn seit September 2014 ist nichts mehr passiert. Das Jobcenter verwaltet Nour und seine Brüder, macht aber keine Angebote. Für August 2015 war ein Sprachkurs in Rostock in Aussicht gestellt - doch dann wurde das Zugticket dahin doch wieder gestrichen. Es würde demnächst ein Sprachkurs in näherer Umgebung beginnen. Welch verschenkte Chancen durch eine Wartezeit von mehr als 12 Monate auf einen simplen Sprachkurs!</p> <p>Nour hat also in Deutschland ein Jahr lang im Grunde keine wirkliche Integration erfahren. Der Kontakt mit den Behörden ist umständlich, weil man dort kaum Englisch spricht. Er muss immer Bekannte um Vermittlung bitten. Während ich ihn besuche, klingelt die Postzustellerin mit einem Paket. Nur durch meine Vermittlung kann geklärt werden, was es damit auf sich hat.</p> <p>Die Selbstversorgung klappt. Internet gibt es auch. Aber Kontakt besteht nur zu anderen Flüchtlingen - via Smartphone und Laptop. Ständig höre ich aus dem Nebenzimmer die Benachrichtigungstöne von Apps wie Skype, Whatsapp oder Viber.</p> <p>Nours Hoffnung ist, einen Job als Entwickler in einer Großstadt zu bekommen. Berlin, Hamburg… das ist ihm egal. Er würde gern in C# arbeiten und eher serverseitig zu Web-Anwendungen beitragen. Doch auch das ist verhandelbar. Hauptsache es geht voran.</p> <p>Das größte Problem für Nour und seine Brüder ist die Untätigkeit, die Langeweile. Güstrow ist auch wirklich keine Stadt, die mit Ablenkungsangeboten glänzt. Und da das Geld sehr knapp ist, sind Ausflüge in die weitere Umgegend nicht einfach.</p> <p>Sein kleiner Bruder möchte weiter nach Schweden zu den Eltern. Aber Nour kann sich ein Leben in Deutschland gut vorstellen. Dass die Verhältnisse in seinem Heimatland eine Rückkehr nahelegen, sieht er nicht ab. Dort wieder angstfrei leben zu können, dort zum Wiederaufbau der Gesellschaft beitragen zu können, das ist sein Traum. Doch bis dahin will er hier für sich sorgen und etwas lernen.</p> <p>In mehr als sechs Stunden Gespräch kommen wir aber irgendwie nicht dazu, mal etwas gemeinsam mit .NET zu machen. Eigentlich hatte ich gedacht, wir gehen eine kleine Aufgabe an, so dass ich mal Nours Arbeitsweise kennenlerne. Doch es gibt so viel zu fragen und zu erzählen. Außerdem will er mir noch ein syrisches Gericht servieren: Kichererbsen stundenlang gekocht mit Brotstücken in Spezialsoße nach Geheimrezept seines Vaters.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-nLmW62WO310/VfB2C1ZaATI/AAAAAAAAF4I/OSE6sFnr9Os/image%25255B14%25255D.png?imgmax=800" width="369" height="292"></p> <p>Da die Besorgung einer Zutat durch den Bruder etwas stockt, verschiebe ich meine Rückreise. Aber das lohnt sich, denn das Ergebnis von Nours Kochkunst ist sehr lecker.</p> <p>Natürlich sprechen wir in der ganzen Zeit auch über Softwareentwicklung und sein Studium. Nour hat in Damaskus auch mit Java und C++ Erfahrung gesammelt. Doch C# hat ihm am Ende am meisten gefallen.</p> <p>Und genauso natürlich kommen Kultur und Religion zur Sprache. Islam im Fernsehen ist etwas anderes als gelebter bzw. erzählter Islam von Praktizierenden.</p> <p>Doch die unterschiedlichen Auffassungen in dieser Hinsicht sind am Ende unwichtig. Verbindend ist das gemeinsame Interesse an der Softwareentwicklung und vor allem an einem Leben, das von Sinn erfüllt ist und in Frieden sich entwickeln kann. Mehr sucht Nour nicht. Er möchte seine Interessen und Kenntnisse einbringen können.</p> <p>Ich als Freiberufler kann ihm dabei nur begrenzt helfen. Selbst ein kleines Projekt hier und da sind ja nicht das, wonach Nour sucht. Wer könnte also mehr bieten? Wo ist ein Team, das noch etwas Verstärkung braucht? Wer kann pragmatisch helfen bei der <a href="http://blog.ralfw.de/2015/09/mehr-kohasion-als-alternativlos-erachtet.html" target="_blank">Integration</a> eines Kollegen aus dem fernen Syrien? Eine Email an mich genügt. Ich stelle gern den Kontakt zu Nour her. Der würde sich sehr freuen.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-KzvGTJNQePQ/VfB2Dyn9ClI/AAAAAAAAF4Q/dww7V46sYe0/image%25255B20%25255D.png?imgmax=800" width="375" height="294"></p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com4tag:blogger.com,1999:blog-6090483181455953305.post-62792234279685268462015-09-09T08:11:00.001+02:002015-09-09T08:11:05.139+02:00Vorschläge zur Messung von Agilität<p>Wann ist ein Team, eine Organisation agil? Gibt es mehr oder weniger Agilität? Das sind Fragen, die eigentlich jeden umtreiben müssten, der sich mit dem Thema Agilität beschäftigt, egal ob Enthusiast oder Skeptiker.</p> <p>Was für mich den Kern von Agilität ausmacht, habe ich <a href="http://blog.ralfw.de/2012/07/pseudowissenschaft-agilitat.html">an anderer Stelle</a> mal beschrieben. Darauf hat nun Volker Meurer mit einem <a href="http://flow.volker-meurer.de/2015/09/zwei-begriffe-von-agil.html">interessanten Beitrag</a> reagiert.</p> <p>Volkers Idee, Agilität als einen Raum zu betrachten, der durch mehrere Dimensionen aufgespannt wird, finde ich anschaulich und hilfreich. Damit kommt Agilität aus der pseudowissenschaftlichen Ecke heraus, sie wird quantifizierbar(er).</p> <p>Mit solchen Dimensionen würde Agilität besser greifbar. Es gäbe etwas zu messen – und das ist für jeden der bewusst seine Fähigkeiten verbessern will, immer eine gute Sache. Messungen geben Feedback über Fort- bzw. Rückschritt. Außerdem kann man sich damit Ziele setzen.</p> <h2>Agilität aus dem Manifest destilliert</h2> <p>Das <a href="http://agilemanifesto.org">Agile Manifest</a> ist in seiner Beschreibung von Agilität schwammig; wann man agil ist, kann man nicht so genau wissen. “Individuals and interactions over processes and tools” usw.: das klingt gut, da ist eine Menge dran – aber hat man es denn schon realisiert? Ja, genau, real-isiert. Ist es schon real? Wie stellt man das für eine Organisation fest? Wie misst man das? Und ist es wichtig dafür, dass morgens alle im täglichen Standup-Chor singen? Muss man dafür Story Points schätzen?</p> <p>Alles, was Scrum und XP – die beiden ursprünglichen agilen Vorgehensmodelle - vorschlagen sind nur, lediglich und nicht mehr als Mittel. Ebenso “customer collaboration” oder “individuals and interactions”. Alles nur Mittel. Aber zu welchem Zweck? Was soll durch mehr “individuals” denn “tools” erreicht werden?</p> <p>Auch in meiner Beschreibung eines Kerns von Agilität habe ich vor allem Mittel genannt. Als Destillat stellten sie für mich Muster in Softwareproduktionen dar, die mir typisch für ein bestimmtes positives Gesamtverhalten, ein gutes Ergebnis schienen. Das kann man dann “agile Softwareproduktion” nennen; mir persönlich schmeckt “flüssige Softwareproduktion” allerdings besser. Doch beides sind wieder nur verkürzende Etiketten. Die Frage bleibt: Ja, was ist denn das, wofür Inkremente oder daily stand-ups oder Reflexion oder co-located teams usw. Mittel sind, es herzustellen?</p> <p>Aus diesem kreiselnden Denken, aus der Gefahr des <a href="https://de.wikipedia.org/wiki/Cargo-Kult">Cargo-Kults</a> müssen wir endlich aussteigen. Wir müssen irgendeine Softwareproduktion herstellen, die was taugt. Wie die heißt, das ist egal. Also, worum gehts?</p> <h3>Worum geht es?</h3> <p>Unter einem Berg an gut gemeinten Mitteln finden sich im Agilen Manifest Hinweise. Hier die richtungsweisenden Begriffe in Reihenfolge der Fundstellen bei den <a href="http://agilemanifesto.org">Werten</a> und den <a href="http://agilemanifesto.org/principles.html">Prinzipien</a>:</p> <ul> <li>“Working software”</li> <li>“responding to change”</li> <li>“satisfy customer”</li> <li>“welcome changing requirements”</li> <li>“harness change for the customer’s competitive advantage”</li> <li>“Deliver working software”</li> <li>“Working software is the primary measure of progress”</li> <li>“sustainable development”</li></ul> <p>Aus dieser Liste lässt sich herauslesen, wie damals die Welt der dysfunktionalen Softwareproduktion gesehen wurde. Und eben, was man daraus für Schlüsse für eine bessere Softwareproduktion gezogen hat:</p> <ul> <li>Die Softwareentwicklung hat sich mehr um sich selbst als um den Kunden gedreht. Man war verstrickt in technische Belange. Materialien und Werkzeuge haben viel Energie absorbiert. Ob die Gründe dafür tatsächlich in einem Mangel an genügend leistungsfähiger Technologie lag oder eher in der Psyche der damaligen Softwareentwickler, sei dahingestellt. Jedenfalls rief das Manifest zu einem Umdenken auf. “Working software” (3 Nennungen) und Wert für den Kunden (“satisfy customer”, “customer’s competitive advantage”) sollten der Leitstern sein. <strong>Agil ist also, was qualitätsorientiert ist. Denn <a href="http://secretsofconsulting.blogspot.de/2012/09/agile-and-definition-of-quality.html">Qualität</a> ist, wofür irgendwer bereit ist, Geld auszugeben.</strong></li> <li>Außerdem erschien die Softwareentwicklung damals als schwerfällig und starr. Die Erkenntnis war, dass sich Kundenwünsche schneller ändern als man darauf reagieren kann. Vielleicht, weil der Kunde tatsächlich neuen/anderen Bedarf hat; vielleicht, weil der Kunde zu Beginn der Entwicklung nicht genau wusste, was er wollte; vielleicht, weil er es wusste, aber nicht gut ausdrücken konnte; vielleicht, weil das Verständnis der Entwickler mangelhaft war oder das Ergebnis fehlerhaft. Einerlei. Jedenfalls war die Beweglichkeit der Softwareproduktion nicht groß genug. Deshalb fordert das Agile Manifest “responding to change” und “welcome changing requirements” und “harness change”. <strong>Agil ist also, wo die Softwareentwicklung schmerzfrei den Kurs ändern kann, wenn Kundenwünsche sich ändern.</strong></li> <li>Und schließlich hielt man die Softwareproduktion für zu sehr auf den Moment konzentriert. Weil man starr war und technikfokussiert, hinkte man der Qualität immer hinterher. Qualität herzustellen war damit quasi eine Form von kurzfristiger Reparatur. Das Ergebnis: <a href="https://en.wikipedia.org/wiki/Death_march_(project_management)">Todesmarschprojekte</a> und rasant wachsender Legacy Code. Dem sollte die allerdings nur einmalige Nennung von “sustainable development” entgegenwirken. <strong>Agil ist also Softwareproduktion, die nicht nur an heute denkt, sondern nachhaltig arbeitet in allen Aspekten.</strong></li></ul> <p>In einem Satz:</p> <p><strong>Agile Softwareentwicklung ist nachhaltig reaktionsfreudig qualitätsorientiert.</strong></p> <p>Das ist doch knackig, oder? Das lässt sich twittern ;-)</p> <p>Ich habe es auch bewusst ohne Kommata geschrieben, um den Zusammenhalt der Adjektive zu stärken. Agilität bedeutet eben nicht nur qualitätsorientiert zu sein, sondern das in reaktionsfreudiger Weise: reaktionsfreudige Qualitätsorientierung. Und eben nicht nur das, sondern auch auch soll diese reaktionsfreudige Qualitätsorientierung nachhaltig sein: nachhaltige reaktionsfreudige Qualitätsorientierung. Agilität gibts nur als Paket. Sie ist eben mehr als eine Aufzählung von Attributen; sie ist ein Ganzes, quasi nachhaltigreaktionsfreudigqualitätsorientiert.</p> <h3>Warum Agilität?</h3> <p>Klar, man kann noch fragen, <em>warum</em> sollte Softwareentwicklung agil sein. Aber darauf ist die Antwort ja einfach: agil scheint wirtschaftlicher als nicht agil. Agilität erhöht die Wahrscheinlichkeit für das Überleben eines Unternehmens - und zwar das des Kunden wie das des Softwareproduzenten. Alles andere wäre ja uninteressant.</p> <h3>Wie erreicht man Agilität?</h3> <p>Und nun, da klarer ist, was bessere Softwareproduktion als früher ist, wie erreicht man diese Art Softwareproduktion?</p> <p>Das ist im Grunde völlig egal. Agilität, die sich auf bestimmte Mittel versteift, ist fehlgeleitet.</p> <p>Das Agile Manifest gibt zwar Hinweise für Hilfsmittel und Verhaltensweisen. Weitere sind zusammengefasst in den agilen Vorgehensmodellen Scrum und XP. Aber letztlich können das nicht mehr als Empfehlungen sein. Es haben sich halt Muster herausgeschält, die kausal verantwortlich scheinen für Verhältnisse, auf die die obige Definition von Agilität passt. Nicht weniger, aber auch nicht mehr.</p> <h2>Agilität messbar machen</h2> <p>Viel wichtiger als die Frage nach dem Wie ist die nach dem Ob. Ob man nämlich schon die agile Vision realisiert hat? Wie ist man auf dem Weg zu Agilität vorangekommen? Wenn der Einsatz von Mitteln kein Maßstab sein darf - da wäre nur Cargo-Kult -, dann muss eine andere Messlatte her. Ohne Messlatte kein Feedback zum Fortschritt auf einem Weg.</p> <p>Auftritt Volker Meurer. Genau solch eine Messlatte schlägt er vor. Ob und wie agil eine Softwareproduktion ist, soll bestimmt werden durch Messungen in drei Dimensionen:</p> <ul> <li>Reaktionszeit</li> <li>Aufwand</li> <li>Wert</li></ul> <p>Diese Grundidee gefällt mir sehr gut. Und doch passt da für mich etwas noch nicht ganz. Ich glaube, das liegt daran, dass Volker von einer weniger differenzierten Definition ausgegangen ist.</p> <p>Ich meine, wenn schon messen, dann das, wofür Agilität steht. Dazu müssen die Grade bestimmt werden, zu denen Qualitätsorientierung, Reaktionsfreudigkeit und Nachhaltigkeit erreicht sind.</p> <h3>Reaktionsfreudigkeit</h3> <p>Reaktionsfreudigkeit scheint der am einfachsten zu messen Aspekt von Agilität zu sein. Volkers Reaktionszeit-Dimension bezieht sich offensichtlich ebenfalls darauf.</p> <p>Reaktionsfreudig/-fähig ist, wer auf eine neue Anforderung, eine Überraschung, eine unerwartete Kursänderung schnell reagiert. Das kann nötig sein, weil ein vom Support gemeldeter Bug dringend gefixt werden muss. Oder es stellt sich bei der Abnahme einer gelieferten Qualität heraus, dass die nun doch nicht auf einem zufrieden stellenden Niveau für den Kunden ist und deshalb eine baldige, wenn schon nicht unmittelbare Nachbesserung erforderlich wird.</p> <p>Jeder einzelne Entwickler mag total reaktionsfreudig sein und alles stehen und liegen lassen, wenn der Kunde einen neuen Wunsch äußert. Diese Reaktionsfreude ist sogar durchaus weit verbreitet - stellt aber ein Anti-Pattern dar.</p> <p>Es geht vielmehr um Reaktionsfreudigkeit des gesamten Produktionsprozesses. Und das auch noch unter einer Bedingung: Es darf dabei keine Verschwendung entstehen. Darauf bezieht sich Volkers Wert-Dimension.</p> <p>In welcher Ferne liegt im Gesamtprozess der nächste Punkt zur Kursänderung, ohne bisherige Qualität zu vernichten (Regression) oder in Arbeit befindliche Qualität nicht fertig zu stellen?</p> <p>Kann in 4 Stunden oder in 5 Tagen oder in 4 Wochen eine neue, dem Kunden wichtige Änderung begonnen werden? Natürlich unter Berücksichtigung begrenzter Kapazität; andere Qualitäten, deren Realisierung gestern noch als nächstes anstanden, müssen u.U. zurückstecken.</p> <p>In keinem Fall jedoch wird der grundsätzliche Produktionsfluss dadurch aus der Bahn geworfen.</p> <p>Reaktionsfreudigkeit ist mithin mehr als Reaktionszeit. Zu der Frage “Wie lange, bis zum nächsten ‘Unterbrechungspunkt’, damit nichts Angefangenes auf Halde gelegt werden muss?” muss die Frage treten “Wie viel existierende Qualität wird vernichtet durch diese unerwartete Kursänderung?”</p> <p>Die erste Frage lässt sich mit Blick auf die Uhr bzw. auf den Produktionsplan gem. de facto Produktionsprozess beantworten.</p> <p>Die zweite Frage jedoch brauch ein anderes Messinstrument. Existierende Qualität kann nur durch Tests gemessen werden. Agilitätsbestimmung setzt mithin automatisierte Tests mit angemessener Abdeckung voraus, weil sonst nicht zu jedem Zeitpunkt der aktuelle Qualitätsstand leicht gemessen werden kann.</p> <p>Automatisierte Tests dienen also nicht nur als Sicherheitsnetz, sondern als Messinstrument. Ohne angemessene Testabdeckung fehlt ein Messinstrument. Und damit - so würde ich sagen - fehlt per se Agilität.</p> <p>Es gibt keine Agilität ohne automatisierte Tests. Da kann man sich in Iterationen drehen, wie man will. Ohne automatisierte Tests kann man sich schlicht alles in die Tasche lügen. Verschwendung durch Qualitätsvernichtung ist dann nicht auf dem Radar.</p> <p>Und noch eine weitere Frage stellt sich im Rahmen der Reaktionsfreudigkeit. Selbst wenn der nächste Unterbrechungspunkt nahe ist, selbst wenn existierende Qualität durch die Kursänderung nicht vernichtet würde, so kann die Reaktionsfreudigkeit doch suboptimal sein.</p> <p>Denn der nächste Zeitpunkt zum Beginn der Arbeit an einer Anforderung ist nur oberflächlich interessant. Viel wichtiger ist, wann kann mit der produktiven Arbeit an den für die neue Anforderung relevanten Aspekten begonnen werden? Das meint Volker mit seiner Aufwand-Dimension, glaube ich.</p> <p>Wenn schon in 4 Stunden die neue Anforderungen in Angriff genommen werden könnte, ohne dass Verschwendung entstünde, dann wäre das super. Weniger super wäre jedoch, wenn dann erstmal 3 Tage lang refaktorisiert werden müsste, um produktiv zu werden.</p> <p>Refaktorisierung würde ich nicht als Verschwendung bezeichnen. Aber die dafür aufgewandte Zeit ist unproduktiv. Weniger davon ist besser. In Analogie zur materiellen Produktion würde ich sie als Rüstzeit bezeichnen. Sie muss sich sogar nicht nur auf das Material (Code) beziehen, sondern umfasst auch die Bereitstellung von Maschinen (Tools, Infrastruktur) und Menschen. Alles, was verändert werden muss, um die eigentlich vom Kunden gewünschte Qualität herzustellen, ist hier einzurechnen.</p> <p>Wie kann man solche Rüstzeit messen? Natürlich mit der Uhr. Wenn man weiß, dass es sie gibt, dann muss man schauen, wo man Anzeichen dafür sieht, dass die Produktion sich gerade in Rüstzeit befindet. Ein Blick ins Repository kann Hinweise liefern. Refaktorisierungen sollten dort als solche gekennzeichnet sein. Aber auch eine Befragung der Entwickler hilft. Hier könnte ein daily stand-up meeting als Messinstrument dienen. “Wie viel Zeit hast du gestern mit Refaktorisierung zur Vorbereitung einer Aufgabe verbracht?” oder “Wie viel Zeit hast du gestern in das Aufsetzen von Infrastruktur zur Vorbereitung gesteckt?” oder “Wie lange haben wir gestern auf Beiträge von Dritten gewartet, um mit der neuen Aufgabe zu beginnen?” sind Fragen nach Rüstzeit.</p> <p>Ein daily stand-up meeting begründet mit “individuals and interactions” ist schwach. Und die Frage “Was hast du gestern gemacht?” in einem co-located Team ist langweilig. So degenerieren stand-ups schnell zu Pflichtveranstaltungen, zu Cargo-Kult. Sich allgemein kollaborativ austauschen kann man auf andere Weise besser. Aber mit der konkreten Aufgabe “Rüstzeit messen” ist die Kraft hinter einem stand-up ganz anders. Spüren Sie das? Da weiß jeder ganz genau, worum es geht und worauf man am Tag achten muss. (Ob ein daily stand-up das beste Messinstrument ist, sei aber weiter dahingestellt. In jedem Fall ist es eines, mit dem Sie leicht beginnen können.)</p> <p><strong>Reaktionsfreudiger ist also, wer mit kürzerer Reaktionszeit und mit weniger Verschwendung und weniger Rüstzeit auf neue Anforderungen reagieren kann als andere oder vormalig er selbst.</strong></p> <h3>Qualitätsorientierung</h3> <p>Volkers Dimensionen dienen der Bestimmung des Agilitätsgrades einer Organisation. Aber sie beziehen sich aus meiner Sicht nur auf den Aspekt der Reaktionsfreudigkeit. Der ist wichtig, aber nicht eben nicht der einzige.</p> <p>Wer Agilität implementieren will, der muss mehr sein, als reaktionsfreudig. Der muss Qualitätsorientierung zeigen. Nur wie drückt die sich aus? Wie kann man die messen?</p> <p>Qualität ist etwas von Wert. Dafür ist der Kunde bereit, zu zahlen. Die erste Frage muss daher lauten: Wird der Fortschritt der Produktion an werthaltigen Aufgaben gemessen?</p> <p>Es gibt immer wieder Projekte, in denen Meilensteine lauten, “Kommunikationsframework eingebaut” oder “ORM entwickelt”. Natürlich zielen solche Aufgaben auf die Herstellung irgendeiner Qualität ab. Doch die Qualität selbst ist eben nicht Aufgabe. Technologien, Infrastruktur, Tools sind lediglich Mittel, um Qualitäten herzustellen.</p> <p>Für den Kunden ist mit spürbarem Wert also nichts geschafft, wenn ein Kommunikationsframework eingebaut oder ein ORM entwickelt wurde. Das ist kein messbarer Fortschritt. Ob das gut getan ist, kann er nicht sagen.</p> <p>Qualitätsorientierten Fortschritt gibt es nur, wenn Aufgaben Feedbackfähiges betreffen. Use Cases oder User Stories sind anerkannter Ausdruck dafür; ich würde aber lieber etwas neutraler von Inkrementen sprechen. Je mehr Inkremente den Ausgangspunkt der Produktionsplanung darstellen, desto agiler die Softwareentwicklung.</p> <p>Aber dabei sollte die Messung nicht stehenbleiben. Denn wir hoch ist der Wert jeder dieser hübsch formulierten Aufgaben? Ihre Formulierung zeigt, dass sie irgendeinen Wert haben, aber nicht welchen. Weder absolut noch im Vergleich. Ohne eine Wertzuordnung ist aber nicht einschätzbar, ob die Produktion gerade viel Wert oder wenig herstellt.</p> <p>Ein zweiter Maßstab für Agilität ist daher, in welchem Ausmaß Inkremente mit einem Wert versehen sind. Sehr große Aufgaben haben gewöhnlich einen vom Management oder Kunden bezifferte Wert. Aber wie steht es mit kleineren und kleinsten Aufgaben?</p> <p>Wert muss dabei nicht direkt etwas mit Geld zu tun haben. Es geht nicht darum zwanghaft einen vermuteten Umsatz an eine Aufgabe zu hängen oder cost of delay zu berechnen. Auch die Zahl der Anwender, die von der Umsetzung einer Aufgabe profitieren, stellt einen Wert dar. Oder die erwartete Nutzungshäufigkeit einer Qualität. Oder ein Erkenntnisgewinn über Kundenverhalten oder Technologiefunktionalität. Der Wert an Information ist nicht zu unterschätzen. Das schließt die Ausräumung von Unsicherheiten ein.</p> <p>Damit aber nicht genug. Wert allein macht auch nicht glücklich, kann man sagen. Viele kleine Verbesserungen schnell ausgeliefert können mehr bewirken als die mega Verbesserung in ferner Zukunft.</p> <p>Qualitätsorientierung muss dem Wert einer Aufgabe daher einen Aufwand gegenüberstellen. Es muss also ebenfalls gemessen werden, wie weit Aufgaben mit geschätzten Aufwänden versehen sind. Die Maßeinheit ist dabei egal (Fibonacci-Zahlen oder T-Shirt-Größen). Es geht auch nicht um Vorhersagen, wie lange die Realisierung einer Qualität zeitlich dauern wird.</p> <p>Lediglich eine vergleichende Schätzung von Aufgaben, die derzeit auf dem Tisch sind, ist nötig. Wichtig ist einzig der Faktor, in dem sie sich unterscheiden. Beispiel: Aufgabe A ist die kleinste, ihr Faktor ist 1. Aufgabe B braucht geschätzt doppelt so viel Aufwand, ihr Faktor ist 2. Aufgabe C braucht ca. 50% mehr Aufwand als B, ihr Faktor ist also 3.</p> <p>Ob in diesem Beispiel am Ende A in 2 Tagen und B daher in 4 Tagen realisiert würde oder wurde, ist uninteressant. Die Messung im Nachhinein ist zwar möglich - aber sollte nicht zur Kalibrierung von Faktoren führen. “Aha, der Faktor 2 bedeutet 4 Tage! Beim nächsten Mal werden wir das bei der Planung berücksichtigen.” Solche Gedanken sind irrig. Sie führen konsequent in Konflikte aufgrund von falschen Voraussagen. Sie erzeugen Unzuverlässigkeit.</p> <p>Außerdem sind solche Voraussagen für eine Qualitätsorientierung völlig überflüssig. Durch (nicht einhaltbare) Versprechen von einer bestimmten Qualität zu einem bestimmten Zeitpunkt wird <em>keine</em> Qualität hergestellt. Qualität wird ausschließlich dadurch hergestellt, dass man programmiert. Schnellstmöglich geschieht das, wenn die Reihenfolge der Aufgabenabarbeitung wertmaximierend ist.</p> <p>Es ist also viertens zu messen, in welchem Umfang die feedbackfähigen Aufgaben gemäß Wert und Aufwand priorisiert abgearbeitet werden. Dazu wird der Wert durch den Aufwand geteilt. Das Verfahren heißt Weighted Shortest Job First (WSJF) und berechnet für jede Aufgabe ein Gewicht, das umgekehrt proportional zur Priorität einer Aufgabe ist: je kleiner das Gewicht, desto höher die Priorität.</p> <p>Dass irgendwann irgendwer beurteilt, ob eine Aufgabe mit der erwarteten oder dann benötigten Qualität umgesetzt wurde, muss nicht diskutiert werden. Das ist auch in voragilen Zeiten so gewesen.</p> <p>Echte Qualitätsorientierung braucht jedoch mehr. Sie will möglichst schnell wissen, ob sie erfolgreich ist. Es kommt also nicht nur auf die Reaktionszeit für die Aufnahme der Arbeit an einer neuen Anforderung an, sondern auch auf die Reaktionszeit des Abnehmers.</p> <p>Bei der Reaktionsfreudigkeit kann es zu Verschwendung kommen. Bei der Qualitätsbeurteilung auch. Sie setzt ein, sobald die Abnahme einer fertiggestellten Qualität sich verzögert. Dann liegt Wert auf Halde. Was erarbeitet wurde, kann seinen Wert - falls es den hat - noch nicht entfalten. Es wurde ja noch nicht beurteilt.</p> <p>Zu messen ist also die Zeit zwischen Fertigstellung und Abnahme. Wie lange dauert es, von dem Moment, da die Programmierung sagt “Fertig! Aufgabe umgesetzt.”, bis zu dem Moment, da der Abnehmer sich das anschaut?</p> <p>Dass der Verzug möglichst klein sei, ist aber nicht nur für den Kunden von Interesse, damit er schnell Wert in die Hand bekommt. Denn nicht immer ist die gewünschte Qualität ja auch durch die Softwareproduktion erreicht. Das Vorgestellte kann einen Fehler enthalten, missverstanden sein oder aus anderen Gründen nicht recht passen. Dann muss nachgebessert werden.</p> <p>Nachbesserungen reduzieren die Kapazität der Softwareproduktion für Neues. Nachbesserungen stellen Wert verspätet her. Das kann nicht im Sinne von Agilität und Flüssigkeit sein. Daraus ergibt sich eine weitere Messlatte: Wie oft kommt es zu Nachbesserungen?</p> <p>Nachbesserungen können bei der Abnahme gefordert werden; es handelt sich um Bugs oder Korrekturen von Missverständnissen bzw. Unvollständigkeiten. Oder sie kommen quer herein vom Support. Je mehr es gibt, desto schlechter ist es um die Qualitätsorientierung bestellt.</p> <p>Bitte bemerken Sie: Ich fordere hier keine Unit Tests oder eine QA. Auch keine Rolle für die Anforderungsanalyse. Das sind alles nur mögliche Mittel, um die eine oder andere Metrik zu verbessern. Genau das ist ja aber hier nicht der Punkt. Es geht nicht um Maßnahmen, sondern erstmal nur den Vorschlag einer Sammlung von Messlatten für die Agilität.</p> <p>Eine Rolle für die Abnahme ist jedoch zwingend. Sonst kann das, worum es der Agilität geht, nicht beurteilt werden.</p> <p><strong>Qualitätsorientierter ist also, wer inkrementeller in gewichteter Weise voranschreitet und schnelleres Feedback mit weniger Nachbesserungswünschen erhält als andere oder vormalig er selbst.</strong></p> <h3>Nachhaltigkeit</h3> <p>Zu guter Letzt die Nachhaltigkeit. Wie könnten wir die messen?</p> <p>Nachhaltig handeln bedeutet, jetzt etwas tun, das unsere Optionen in der Zukunft nicht verringert, sondern bestenfalls sogar erhöht. Ressourcen, die heute zur Verfügung stehen, dürfen ihre Kapazität nicht verlieren; sie sollten sie sogar tendenziell steigern.</p> <p>Nachhaltigkeit erfordert also die Beobachtung der Entwicklung von Ressourcen.</p> <p>Die für die Softwareentwicklung relevanten Ressourcen sind: die Menschen, der Produktionsprozess und die implementierte Lösung, d.h. Code und nötige Infrastruktur.</p> <p>Zu messen ist zunächst, ob die Beobachtung dieser Ressourcen <em>überhaupt</em> stattfindet.</p> <p>Nach allgemeinem Sprachgebrauch würde ich sagen, dass Reviews die implementierte Lösung beobachten und Retrospektiven Menschen und Prozess.</p> <p>Wie die Beobachtung in Reviews und Retrospektiven erfolgt, ist eine zweite Sache. Aber die Diskussion darüber ist nicht Teil dieser Betrachtung.</p> <p>Beobachten ist gut, nur was passiert dann mit den Erkenntnissen? Sicherlich werden in Reviews und Retros Entscheidungen für Veränderungen getroffen, die umgesetzt werden müssen. Das mag für einige “einfach so” im Tagesgeschäft gehen. Um das verlässlich hinzubekommen, muss die Organisation ein Bewusstsein für und den Willen zu Verlässlichkeit haben. Hat sie das aber wirklich? Das sollte gemessen werden. Welche Versprechen werden gegeben, wie viele davon werden eingehalten, wie viele gebrochen, wie viele neu verhandelt, bevor man sie erfüllt?</p> <p>Nicht alle beschlossenen Veränderungsmaßnahme lassen sich jedoch sofort umsetzen. Angesichts der Entwicklungsgeschwindigkeit unserer Branche ist zu erwarten, dass immer etwas so neu und umfangreich ist, dass die Organisationsmitglieder es sich erst außerhalb der normalen Produktion erarbeiten müssen. Dafür muss Raum zum Lernen bereitstehen - und zwar nicht nur gelegentlich, ad hoc, sondern kontinuierlich. Nur so erhält sich jeder Einzelne und die Organisation als Ganzes Zukunftsfähigkeit. Zu messen ist also mindestens der Anteil der Lernzeit an der Arbeitszeit. Besser jedoch sollte auch noch gemessen werden, wie hoch die Lernfrequenz ist.</p> <p>Beobachten und Lernen ist gut, aber kann auch zu spät kommen oder nicht die gewünschte Wirkung entfalten. Zur Nachhaltigkeit gehören deshalb Puffer, um Minderleistungen bzw. Unerwartetes jeder Art abzufedern. Die Organisation darf gar nicht erst in eine Situation kommen, die ihre Existenz bedroht.</p> <p>Welche Puffer es geben kann/gibt, hängt von den im Einsatz befindlichen Ressourcen ab. Naheliegend ist da der Gedanke ans liebe Geld. Oder der an Maschinen. Aber auch Mitarbeiter, deren Zeit, deren Motivation, deren Kenntnisse, deren Kreativität sind Ressourcen. Oder Kunden. Oder Zulieferer.</p> <p>All das und mehr hat jeweils eine Menge, Leistungskraft, Kapazität, die für die aktuelle Produktion gerade reicht - oder eben größer sein sein. Was ist, wenn unerwartete Veränderungen in der Umwelt oder in der Organisation fordern, dass eine Ressource sich mehr als bisher einbringt? Ein Mitarbeiter will in die Elternzeit gehen, ein Mitarbeiter kündigt, ein Zulieferer fällt aus, ein Kunde springt ab, eine neue Technologie soll zukünftig verwendet werden, eine neue Anforderung erweist sich als deutlich schwieriger als angenommen in der Umsetzung… Das sind Belastungen jenseits des Normalen, für deren Bewältigung Reservekapazität, d.h. Puffer vorhanden sein müssen.</p> <p>Gibt es dafür Puffer? Das sollte gemessen werden. Zugegeben, das mag nicht leicht fallen. Aber das Mindeste ist, sich überhaupt der Wichtigkeit von Puffern bewusst zu sein. Existiert also zumindest dieses Bewusstsein? Gibt es einen Willen zum Aufbau und Vorhalten von Puffern? Ich denke, das lässt sich schon in Gesprächen mit Organisationsmitgliedern herausfinden.</p> <p><strong>Nachhaltiger ist also, wer reflektierter und zuverlässiger bewusst lernend und gepuffert produziert als andere oder vormalig er selbst.</strong></p> <h2>Zusammenfassung</h2> <p>Puh… da ist einiges zusammengekommen. Das hätte ich am Anfang nicht gedacht, als ich begann, diesen Artikel zu schreiben. Vorher wusste ich das nicht so genau, weil Schreiben für mich immer auch Nachdenken ist. Während des Schreibens entwickelt sich oft erst, was ich eigentlich denke.</p> <p>Hier die Messinstrumente nochmal in der Übersicht:</p> <ul> <li> <p>Reaktionsfreudigkeit</p></li> <ul> <li> <p>Reaktionszeit bis zur Aufnahme der Arbeit an einer neuen Anforderung</p></li> <li> <p>Umfang der durch eine Änderung entstehenden Regression</p></li> <li> <p>Rüstzeit bis zum Beginn produktiver Arbeit an einer neuen Anforderung</p></li></ul> <li> <p>Qualitätsorientierung</p></li> <ul> <li> <p>Prozentsatz der Aufgaben, die Inkremente darstellen</p></li> <li> <p>Prozentsatz der Inkremente, die mit einem Wert versehen sind</p></li> <li> <p>Prozentsatz der Inkremente, die mit einem Aufwand versehen sind</p></li> <li> <p>Prozentsatz der Inkremente, die nach Gewicht (Wert/Aufwand) priorisiert abgearbeitet werden</p></li> <li> <p>Wartezeit von Fertigstellung einer Aufgabe bis zur Abnahme</p></li> <li> <p>Menge der Nachbesserungen bei Abnahme und vom Support</p></li></ul> <li> <p>Nachhaltigkeit</p></li> <ul> <li> <p>Frequenz von Reviews</p></li> <li> <p>Frequenz von Retrospektiven</p></li> <li> <p>Zahl der erfüllten, gebrochenen, nachverhandelten Versprechen</p></li> <li> <p>Prozentsatz der Lernzeit an der Arbeitszeit</p></li> <li> <p>Frequenz der Lernzeiteinheiten</p></li> <li> <p>Anzahl und Größe von Puffern</p></li></ul></ul> <p>Ist das nicht ein bisschen viel? Volkers drei Dimensionen waren so schön übersichtlich.</p> <p>Keine Ahnung, ob das am Ende zu viele Messinstrumente sind. Im Augenblick wüsste ich aber nicht, welches davon unnötig wäre. Sie scheinen zwar unterschiedlich wichtig zu sein, man muss wohl nicht sofort alle in Anschlag bringen. Andererseits ist ja auch nicht alles schwierig zu messen.</p> <p>Wie es um Reviews steht oder ob in Inkrementen vorangeschritten wird, ist doch leicht zu messen. Rüstzeiten oder der Umgang mit Versprechen hingegen, mögen schwieriger zu beurteilen sein.</p> <p>Würde es nicht reichen, einfach nur auf Scrum oder Kanban zu setzen? Scrum führt doch z.B. Retros und Inkremente ein und zwingt zu Versprechen. Damit wird doch das Richtige getan. Ja, einerseits. Dagegen ist nichts zu sagen - solange man versteht, warum (!) Scrum das macht. Solange man versteht, dass das nicht alles ist. Eine Diskussion über Kriterien und Metriken für Agilität ist eine andere als eine über Maßnahmen.</p> <p>Wenn einige der Metriken hier schon wie klare Empfehlungen zu Maßnahmen aussehen, dann ist das ja nicht schlecht. Bei anderen Metriken habe ich mich aber bewusst zurückgehalten. So dachte ich z.B., dass auch gemessen werden könnte, ob/wie Zeitmanagement gelebt wird. Aber das wäre zu viel Vorgabe. Solange Zuverlässigkeit vorhanden ist, ist es egal, wie sie entsteht. Dito muss nicht gemessen werden, ob ein ProductOwner vorhanden ist, der Inkremente formuliert. Woher die kommen, wer die Werte und Aufwände bestimmt… keine Ahnung. Solange es geschieht, ist das doch egal.</p> <p>Maßnahmen, wie Messwerte über die Zeit verbessert werden können, können sich Organisationen selbst überlegen oder von anderen abschauen und ausprobieren. Dafür ist die Reflexion da. Dass die da ist, muss dann jedoch gemessen werden.</p> <p>Und warum reicht Kanban nicht einfach? Für meinen Geschmack stellt sich Kanban in mancher Hinsicht zu dumm. Transparenz + WIP Limit: mehr braucht es am Ende nicht. Das mag ultimativ korrekt sein - nur dauert es dann womöglich länger als nötig, um die richtigen Maßnahmen zu finden.</p> <p>Bei systemischen Ansätzen soll der Klient ja die Lösung immer in sich finden. Schöner Gedanke. Natürlich muss die Lösung auch zum Klienten passen. Die Frage ist nur, wie kommt der Patient zu dieser Lösung? Ich glaube, dafür darf der Klient erstens Input von außen erhalten; ein Coach darf Vorschläge unterbreiten und Sichtweisen äußern. Und zweitens gehört dazu eben eine sehr feine Wahrnehmung. Um beurteilen zu können, was ihm taugt, muss der Klient die Effekte, die eine Idee oder probeweise Veränderung hervorruft, sehen, hören, schmecken, tasten, spüren, fühlen. Es braucht schlicht Messungen entlang vieler Dimensionen.</p> <p>Ein WIP-Limit und der aus seinem Erreichen resultierende Schmerz sind mir da zu wenig und kommen womöglich zu spät. Wenn ich von einer Sache keine Ahnung habe, dann fange ich vielleicht mit diesem Minimum an. Aber von Softwareentwicklung sollten wir Ahnung haben und deshalb schon wissen, wo es haken kann. Da sollten wir dann Messpunkte einrichten. Dafür habe ich hier mal ein paar Vorschläge gemacht.</p> <p>Ausgehend von einer Definition dessen, was überhaupt erreicht werden soll - reaktionsfähige nachhaltige qualitätsorientierte Softwareproduktion - sollten wir zunächst darüber sprechen, wie sich deren Güte ausdrücken könnte. Welche Attribute hat sie? Wenn wir sofort zu Maßnahmen springen, dann ist das gut gemeint, führt aber eben schnell zu Ritualen ohne Verbesserung der Attributwerte. Der Effekt ist das, was wir seit Jahren bei der Agilität sehen: Es wird Orthodoxie und Häresie gesprochen. Die Maßnahmen werden zum Problem. Das eigentliche Problem tritt in den Hintergrund.</p> <p>Wenn wir uns jedoch zunächst über geeignete Messpunkte unterhalten, dann sind wir viel offener, was die Maßnahmen angeht. Vielleicht behalten manche Maßnahmen ihren Wert. Vielleicht finden sich aber auch ganz andere Maßnahmen, ohne dass man sich dafür entschuldigen müsste. Denn es zählen die Ergebnisse: bessere Messwerte. Morgens zusammen stehen oder co-location oder story point Schätzungen… Ist doch egal, solange etwas besser wird.</p> <p>Die Verlagerung des Fokus auf Attribute und Messinstrumente lässt auch Raum für unterschiedliche Level an Agilität. Muss denn jeder maximal agil sein? Oder reicht es, angemessen agil zu werden für einen gewissen Kontext? Oder gibt es eben ganz unterschiedliche Maßnahmenausprägungen für Agilität je nach Kontext?</p> <p>Messungen statt Maßnahmen an den Anfang zu setzen, scheint mir überfällig und zeitgemäß. Damit wird der Individualität von Organisationen mehr Rechnung getragen. Damit erhalten Organisation mehr Autonomie, den ihnen gemäßen Weg zur Agilität zu finden.</p> <p>Agilität ist kein Absolutum. Sie ist ein Mittel, das dosiert einzusetzen ist, um mit Unsicherheit, mit Komplexität umzugehen. Wenn die aber unterschiedlich ist für verschiedene Organisationen, dann sollte die Agilität das widerspiegeln.</p> <p>Das bedeutet: Am Anfang jeder Agilität steht die Entscheidung für eine Definition und der Wille zur Messung relevanter Attribute mit kontinuierlicher Reflexion über die Beobachtungen und Ableitung geeigneter Maßnahmen, um die Werte mehr in Einklang zu bringen mit den Notwendigkeiten, die sich aus Veränderungen im Außen und Innen ergeben.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com1tag:blogger.com,1999:blog-6090483181455953305.post-59560262844260957722015-09-06T12:35:00.000+02:002015-09-06T12:35:42.996+02:00Mehr Kohäsion als alternativlos erachtet<div class="MsoNormal">
Kohäsiv ist, was zusammenhält. In der Softwareentwicklung
ist es eine Tugend, das Kohäsive zu identifizieren und ihm durch ein Modul auf
angemessenem Level eine Form zu geben. Module sind Container für das, was zusammengehört.
Zum Zwecke der Wandelbarkeit.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Was in einem Modul zusammengefasst ist, kann sich weniger
gestört durch die Umwelt weiterentwickeln. Das Modul zieht eine Grenze, einen
Schutzwall.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Umgekehrt schützt das Modul die Umwelt vor den Entwicklungen
in ihm. Jedenfalls wenn die Modulgrenze angemessen ausgelegt ist.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Hohe Kohäsion, lose Kopplung: das ist einer der zentralen
Sätze für zukunftsfähige Softwarearchitektur.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aber was ist kohäsiv? Und ist das, was heute zusammenhängt,
morgen auch noch zusammenhängend? In <a href="http://geekswithblogs.net/theArchitectsNapkin/archive/2015/04/27/sweet-aspects.aspx">„Sweet
Aspects“</a> habe ich versucht, die Relativität und Volatilität von Kohäsion
anschaulich darzustellen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Es ist also nicht die Frage, ob es in einer Menge von
Elementen Kohäsion gibt, sondern welche. Wird erkannt, was kohäsiv ist? Und
wird dem Rechnung getragen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So ist das bei Software. Aber so ist das auch bei Menschen.
Menschen gehören zueinander. Anders als bei Softwareartefakten, wählen wir selbst
jedoch die, die uns nahestehen. Wir modularisieren uns sozusagen autonom.
Familie, Sportmannschaft, Verein, Unternehmen, Glaubensgemeinschaft, Nation...
Das sind unsere ideellen Container. Die grenzen wir von anderen ab. Dafür
suchen wir uns sogar physische Entsprechungen, vom Gebäude bis zum Territorium.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Und umgekehrt: Was „auf einem Haufen“ versammelt ist, hat
besser hohe Kohäsion. Sonst kommt es zu Unverständnis und Spannungen. Sonst
entsteht keine Gemeinschaft. Kräfte werden dann unproduktiv in Konflikten
verschwendet, statt sie auf die Erreichung gemeinschaftlicher Ziele anzuwenden.
Und am Ende zerfällt der nicht kohäsive Haufen in kleinere mit höherer
Kohäsion.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Das ist nur natürlich. Manchmal funktioniert es besser,
manchmal nicht so gut. So ist das menschliche Gemeinschaftsgefüge auch immer in
Bewegung. Derzeit wieder ganz gehörig.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Die Zusammensetzung der Mitglieder in unserem hübschen
Staatscontainer „Deutschland“ ändert sich gerade gewaltig. Wir haben mal geglaubt,
die Zuwanderung von Gastarbeitern sei ein Problem, das zu Überfremdung führt. Doch
das ist schon länger kein Thema mehr. Gastarbeiter sind keine Gastarbeiter
mehr, sondern Dauerarbeiter geworden. Sie gehören zu Deutschland wie der
deutsche Wald. Knapp 20% der Bevölkerung Deutschlands haben erwähnenswerten Migrationshintergrund.
10% sind sogar immer noch Ausländer. Das ist normal. Das ist gut so.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Die, die zunächst keine hohe Kohäsion hatten – Deutsche und
Spanier, Griechen, Italiener, Türken, Chinesen und wer noch alles zugezogen
sein mag –, haben sich zusammengerauft. Das nennt man erfolgreiche Integration.
Wir haben uns auf einander zu bewegt.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Dass nicht alles eitel Sonnenschein ist, ist klar. Das war
es im „ursprünglichen Deutschland“ aber auch nicht. Vor historisch gesehen kurzer
Zeit haben allein wir Deutschen uns selbst und der Welt ja noch so einige
Probleme bereitet.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Integration hat funktioniert. Über 20, 30, 40, 50 Jahre sind
Millionen von Ausländern zu Inländern geworden. Eine großartige Leistung!<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Vor allem aber auch eine nötige Leistung, denn sonst wäre
der deutsche Staatscontainer auseinandergebrochen. Er hätte sich quasi selbst
refaktorisiert. <i style="mso-bidi-font-style: normal;">Extract nation</i> hätte
die Operation wohl geheißen. So wie 1990 die Operation <i style="mso-bidi-font-style: normal;">Inline nation</i> ausgeführt wurde: Die DDR ist der BRD beigetreten.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Exportweltmeister sind wir ja schon. Vielleicht sollten wir
uns also auch Integrationsweltmeister nennen? 20 Millionen Ausländer, 20
Millionen DDR-Bürger: alles integriert – und immer noch ein Land, in dem wohl
die meisten gerne leben. Ist das nicht eine großartige Leistung?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Andere finden das Ergebnis jedenfalls sehr attraktiv. So
attraktiv, dass sie ebenfalls nach Deutschland kommen wollen. Sei es aus
wirtschaftlichen Gründen oder weil sie schlicht Schutz für Leib und Leben suchen.
Ihr Bild von Deutschland: hier gibt es Geld und/oder Sicherheit.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Können wir nicht stolz darauf sein, so ein Bild zu
vermitteln? Trotz oder vielleicht sogar wegen all der Integrationsleistung, die
in Deutschland vollbracht wurde, sind wir so etwas wie das gelobte Land
geworden.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Dieses Bild ist sicher eine Überhöhung. Wir können ihm nicht
einfach so gerecht werden. Milch und Honig fließen hier nicht. Doch woanders
fließen mehr Tränen und vor allem Blut. Selbst wenn wir nur Milchpulver und
Zuckerrübensirup zu bieten hätten, wäre das für viele eine deutliche
Verbesserung.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aber wollen wir das? Über diese Frage lässt sich lange
diskutieren. Letztlich ist sie jedoch müßig. Die kanzlerische
Alternativlosigkeit findet hier nämlich eine berechtigte Anwendung. Wir können
nicht anders, als Menschen, viele Menschen an- und aufnehmen zu müssen. Sie
sind schlichtweg da. Nicht nur vor der Tür, sondern schon im Flur oder gar im
Wohnzimmer. Wer fragt „Wolle ma se reinlasse?“ kann das nur rhetorisch meinen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Zwar hatten wir schon länger keine explizite Einladung mehr
ausgesprochen – Deutschland ist kein Einwanderungsland, das aktiv um Zugüge im
Ausland wirbt –, d.h. die, die nun schon da sind, sind keine geladenen Gäste.
Deshalb ist die Frage selbstverständlich erlaubt, wen wir diesseits der Haustür
wirklich bewirten wollen. Und die Antwort wird nicht für alle, die schon drin
sind, positiv ausfallen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Doch egal, wie das Gastkriterium auch formuliert ist oder
werden mag, es werden viele bleiben. Und wohl vor allem schneller mehr, als in
bisherigen Jahrzehnten. Das ist so. Das ist auf die eine oder andere Weise eine
schlicht historische Konsequenz. Ich möchte hier sogar von Karma sprechen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Deutschland und vor allem Europa erleben eine Bewegung, die
vor Jahrzehnten oder gar Jahrhunderten angestoßen wurde. Von wem? Irgendwie
wäre das schon wichtig zu eruieren, wenn man versuchen möchte, näher an der
Wurzel etwas zu verändern. Andererseits führt diese Frage auch schnell in ein
unendliches Fingerzeigen, das bei Obama/Bush beginnen mag und selbst bei Papst
Urban II nicht enden würde.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Im Menschlichen herrscht, wie in der Physik, das Prinzip
Actio und Reactio. Wer Gewalt benutzt, wird Gegengewalt erzeugen. Früher oder
später. Der Abgrund ruft den Abgrund.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aber einerlei. Es ist wie es ist. Die Tür ist auf, viele,
viele Gäste strömen herein. Quasi Facebook-Party auf nationalem Niveau.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Die Frage der Stunde lautet: Was tun? Und die allererste,
alternativlose Antwort ist: Integration. Jetzt! Sofort! So schnell wie möglich.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Zwei Phasen müssen wie bei jede Katastrophe schnellstmöglich
durchlaufen werden:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="margin-left: 39.05pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18.0pt;">
<!--[if !supportLists]--><span style="mso-fareast-font-family: "Times New Roman";"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt "Times New Roman";"> </span></span></span><!--[endif]-->Triage<o:p></o:p></div>
<div class="MsoListParagraphCxSpLast" style="margin-left: 39.05pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18.0pt;">
<!--[if !supportLists]--><span style="mso-fareast-font-family: "Times New Roman";"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt "Times New Roman";"> </span></span></span><!--[endif]-->Hilfe<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Ursachenanalyse usw. muss auch geschehen. Parallel. Vor Ort
kann es jedoch keine zwei Meinungen geben. Da sind die Ressourcen knapp und
sollen bestmöglich eingesetzt werden.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wenn es so sein kann, dass nicht alle die, die Deutschland
so attraktiv finden, auch willkommen sind, dann muss das Kriterium dafür
schnellstmöglich angewandt werden. Jeder Tag, den seine Anwendung später
erfolgt, kostet Ressourcen, die der echten Hilfe nicht zur Verfügung stehen.
Das ist Verschwendung pur. Jeder Tag Verzögerung lässt auch den Widerstand in
der Bevölkerung wachsen, weil Unentschiedenheit als Führungslosigkeit gedeutet
wird und Unsicherheit schürt.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Triage ist eine harte Sache. Immer. Sie wiederspricht dem
Reflex des Altruismus. Aber es hilft im wahrsten Sinne des Wortes nichts: Wo
Ressourcen knapp sind, müssen sie hier zugewiesen und woanders entzogen werden.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Über die Kriterien kann man ja, nein, muss man diskutieren.
Aber nicht darüber, ob es Kriterien geben sollte. Und wenn man sich festgelegt
hat, dann muss man sie anwenden. Zügig. Und dann muss man beobachten, ob man
mit dem Ergebnis zufrieden ist. Und man muss akzeptieren, dass es zu Fehlern
kommt. Es wird zu <i style="mso-bidi-font-style: normal;">false positive</i> und
zu <i style="mso-bidi-font-style: normal;">false negative</i> Bewertungen kommen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Je größer der Ansturm der Gastkandidaten, desto eher
brauchen wir quasi Judge Dredd vor Ort für eine Triage. Das ist bei jeder
Katastrophe so. Und die liegt vor.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Nach der Triage schnellstmögliche Hilfe. Das bedeutet in
diesem Fall: Integration der Gäste. Rigoros. Alternativlos.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Denn wie lange die Gäste bleiben, ist ja unbekannt. Und
angesichts des Weltenlaufs in den letzten Jahrzehnten sollten wir uns wohl eher
auf länger denn kürzer einstellen. Aber selbst wenn sie nach 2-3 Jahren wieder
heimreisen sollten, würden sie und wir von einer schnellen Integration
profitieren. Sie nähmen in ihre Heimat nämlich ein bestätigtes gutes Bild von
Deutschland mit. Deutschland wäre das Land, in dem sie so willkommen geheißen
wurden, dass man sie sogar integriert hat.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Integration bedeutet natürlich vor allem Angleichung der
Gäste an den Gastgeber Deutschland. Das ist für Deutsche selbstverständlich;
Gäste mögen da eher zögerlich bis unwillig sein. Sie wollten doch „nur“ Geld
und/oder Schutz. Aber es hilft nichts. „Nur“ gibt es nicht in dieser
Größenordnung. Geschenke kann es geben im Leben – doch wie spätestens die
vielen Gratisangebote im Internet auch dem letzten klar gemacht haben sollten:
am Ende ist doch nichts umsonst. Und der Preis für den Empfang der Segnungen
Deutschlands ist... Integrationswille. Jeder Gast ist aufgefordert, nach
Kräften mitzumachen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Doch die Integration ist keine Einbahnstraße. Es ist nicht
zu vermeiden, dass auch die deutsche Gesellschaft sich den „Neuzugängen“
annähert. Es ist immer eine Co-Evolution. Anderes anzunehmen wäre naiv. Wir
sehen es ja jeden Tag auf der Straße.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wenn man das zulässt, dann ist das auch angenehm. Wer möchte
auf die kulturelle Vielfalt in Deutschland denn wirklich verzichten? Nicht nur
will ich in Hamburg einen Schwarzwälder Schinken genießen, ich möchte auch zum
türkischen Friseur oder libanesischen Restaurant oder einem Diskussionskreis in
der Moschee gehen können.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Also Integration. Aber wie?<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Beim Couchsurfing im fernen Land sich nur mit Händen und
Füßen verständigen, mag für ein paar Tage witzig sein. Da lernt man etwas fürs
Leben.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wenn Flüchtlinge und andere „Deutschlandfans“ jedoch nach der
Triage hier bleiben dürfen, dann ist es nicht witzig, wenn sie uns und wir sie
nicht verstehen. Das behindert vielmehr die so wichtige Integration. Kein
gesellschaftlicher Anschluss, keine Job ohne gute Sprachkenntnisse.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wir brauchen Kohäsion und die beginnt bei der Sprache. Sie
ist die Bedingung für die Möglichkeit jedes anderen Kontaktes und damit
weiterer Annäherung.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Ohne gemeinsame Sprache ist der Grundstein gelegt für den
Verbleib im physischen und geistigen Ghetto. Ohne unsere Sprache können Gäste
sich nicht zurechtfinden und auch nicht wirklich die Segnungen unserer
Gesellschaft schätzen lernen. Vieles muss ihnen kryptisch erscheinen und
bleiben. Und umgekehrt: Uns muss vieles als fremd und damit potenziell
bedrohlich erscheinen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aber sofortige Sprachvermittlung von spätestens Tag 1 nach
der Triage an ist nur der Anfang. Wie gesagt: die Bedingung für alle anderen
Möglichkeiten.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Der nächste Schritt der Integration muss Bildung sein, die
dazu führt, dass Gäste zu unserer Gastgebergesellschaft beitragen können.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Sicherlich gilt das in gleichem, nein, eigentlich sogar
größerem Maß zunächst für schon deutsche Bürger. Da mangelt es im Grunde auch
an Integration in diesem Sinn. Aber das ist ein anderes Thema. Mir geht es hier
um das akute Problem der vielen Einströmenden.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Ja, ich denke, Bildung sofort tut Not. Bildung in Bezug auf
unsere Kultur und gesellschaftliche Organisation. Aber auch Bildung im Hinblick
auf einen möglichen Beitrag zu dem, was unsere Attraktivität ausmacht und
überhaupt ermöglicht, dass wir fähig sind, Gäste aufzunehmen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wer kurz zu Besuch kommt, wird bedient. Das ist Ehrensache.
Wer aber kommt, um unabsehbar zu bleiben... der wird vom ersten Tag an in
unseren Alltag eingebunden. Das weiß jeder, der schonmal in einer WG gewohnt
hat.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Aufgabe der Integration ist mithin, die Beitragsfähigkeit
alle anerkannten Gäste herzustellen. In maximaler Geschwindigkeit. Jeder Tag
Verzug sorgt für Verschwendung und Unsicherheit.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Wenn dann einer schneller wieder geht als gedacht, ohne
einen Beitrag geleistet zu haben, dann ist die Investition in ihn auch kein
Verlust. Er wird gut davon daheim berichten. Und angesichts der hohen Chance,
dass er bleibt, haben wir das Richtige getan: Wir haben Aufbauarbeit geleistet
für einen baldigen Beitrag. Wir haben Kohäsion hergestellt. Jeden Tag ein wenig
mehr.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Denn ohne Kohäsion keine Einheit. Und wenn die Kohäsion
einer Einheit sinkt durch Einflüsse von außen, dann müssen Anstrengung zu ihrer
Aufrechterhaltung und Auffrischung unternommen werden. Das ist die oberste
strategische Notwendigkeit. Alles andere ist ein Gefahr für die Einheit. Es ist
wahrhaft Lebensgefährlich, nicht sofort in Integration zu investieren.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Softwareartefakte werden fremdorganisiert. Wir als Menschen
müssen uns selbst organisieren. Die Gesetzmäßigkeiten sind jedoch dieselben:
Erfolg setzt Kohäsion voraus. Ohne Kohäsion keine Kohärenz, keine Kraft zur
Erreichung von Zielen.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>DE</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="0" Name="Hyperlink"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Normale Tabelle";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
</style>
<![endif]-->
<!--StartFragment-->
<!--EndFragment--><br />
<div class="MsoNormal">
Sinkt die Kohäsion durch Einmischung neuer Menschen, dann
muss dem gegengesteuert werden. Grenzziehung hilft da nur bedingt. Vor allem
muss integriert werden. Nur dann sind wir auf Dauer fähig, uns weiter mit der
Welt zu wandeln – zumindest wenn wir das Modul „Deutschland“ für erhaltenswert
befinden.<o:p></o:p></div>
Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com1tag:blogger.com,1999:blog-6090483181455953305.post-38476916488483662932015-07-20T20:51:00.001+02:002015-07-20T20:51:48.238+02:00Geschätztes Desaster <p>Glauben Sie noch, dass sich Aufwände in der Softwareentwicklung abschätzen lassen? Ja, wirklich? Dann beruht Ihr Glaube zumindest zum Teil auf der Vorstellungen, dass sich Schätzfehler ausgleichen. Mal schätzen Sie etwas zu wenig Aufwand, ein andermal aber schätzen Sie etwas zu viel Aufwand. Oder?</p> <p>Ja, das hört sich plausibel an. Manche Aufgaben stellen sich als schwieriger heraus, als gedacht, andere als leichter. In Summe heben sich also die Schätzfehler auf. Deshalb funktioniert das Schätzen unterm Strich, auch wenn es nicht fehlerfrei ist.</p> <p>Ok, dann hier ein Gedankenexperiment:</p> <h3>Das Spiel</h3> <p>Sie haben eine Münze, mit der Sie Kopf oder Zahl mit einer Wahrscheinlichkeit von jeweils 0,5 werfen können.</p> <p>Nun bekommen Sie das Angebot, mit dem Münzwurf Geld zu verdienen - oder zu verlieren. Wenn Sie Kopf werfen, bekommen Sie 1€, wenn Sie Zahl werfen, dann müssen Sie 1€ abgeben. Es geht also um +1€ und –1€ mit einer 50%igen Wahrscheinlichkeit.</p> <p>Wenn Sie mit 0€ auf Ihrem Spielkonto beginnen würden, wie viel Geld wäre ungefähr nach 50 Würfen darauf?</p> <p>a) ca. 0€ b) ein deutlich von 0€ abweichender Betrag</p> <p>Überlegen Sie ruhig einen Moment…</p> <p>Ich habe diese Frage einigen mathematisch normal gebildeten Menschen gestellt. Deren überwiegende Antwort war a). Sie glauben, dass sie mit so einem Spiel über 50 Würfe weder Geld verdienen noch verlieren würden.</p> <p>Die Begründung: Gewinn und Verlust gleichen sich ja wegen der Wahrscheinlichkeit von 50% für beide Ergebnisse aus.</p> <h3>Die Statistik</h3> <p>Die Antwort aus dem Bauch heraus ist verständlich. Sie ist auch korrekt für eine genügend große Zahl von Spielen. Über ganz viele Spiele hinweg sollte der Kontostand bei 0€ sein. So wie der Mittelwert über viele Münzwürfe (Kontobewegungen) auch 0€ ist.</p> <p>Die Frage war ja aber nicht, wie der Kontostand im Mittel am Ende von vielen Spielen wohl wäre, sondern am Ende <em>eines</em> Spieles. Und da liegt die Antwort aus dem Bauch heraus weit neben der Realität.</p> <p>Am Ende eines Spieles ist der Kontostand sehr wahrscheinlich deutlich von 0€ abweichend. Hier als Beispiel ein Simulationsergebnis:</p> <p><a href="http://lh3.googleusercontent.com/-9rUJHUYlQ0A/Va1C5M7TQaI/AAAAAAAAFv4/jrAH5aylZww/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-1cPfuG64w0c/Va1C5-xNfvI/AAAAAAAAFwA/Hwhk-BEYa9U/image_thumb%25255B2%25255D.png?imgmax=800" width="561" height="155"></a></p> <p>Sie sehen, am Ende des Spiels hätten Sie 10€ verloren!</p> <p>Oder hier ein Verlust von 4€:</p> <p><a href="http://lh3.googleusercontent.com/-Oylq1C1wqpE/Va1C6zX_IrI/AAAAAAAAFwI/SILcNT-Cvi4/s1600-h/image%25255B9%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-NyWebDVgqz8/Va1C7iYgmwI/AAAAAAAAFwQ/_hOFfRo_3zs/image_thumb%25255B5%25255D.png?imgmax=800" width="563" height="174"></a></p> <p>Oder hier ein Verlust von 16€:</p> <p><a href="http://lh3.googleusercontent.com/-LXqyDuYiG0A/Va1C8XBXtdI/AAAAAAAAFwY/KVYiyXVOiIs/s1600-h/image%25255B14%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-uqp1AHrdDhQ/Va1C9YXUM1I/AAAAAAAAFwg/SGal7THlHd0/image_thumb%25255B8%25255D.png?imgmax=800" width="564" height="176"></a></p> <p>Oder hier, oh, ein Gewinn von 4€:</p> <p><a href="http://lh3.googleusercontent.com/-ZvBaQhsbWPg/Va1C-KdyYjI/AAAAAAAAFwo/Z-ob0VVdyNg/s1600-h/image%25255B19%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-IevcO9a1f0g/Va1C-2w7LtI/AAAAAAAAFww/8pbg781lGc0/image_thumb%25255B11%25255D.png?imgmax=800" width="565" height="174"></a></p> <p>Usw. usf.</p> <p>Die Kontobewegungen (blaue Linie) in den Simulationen bewegen sich hübsch pendelnd um die Nulllinie. Pro Spiel ist die Zahl der Würfe groß. Der Mittelwert der Kontobewegungen ist nahe 0€.</p> <p>Doch die Kontostände… die bewegen sich deutlich unterhalb oder oberhalb der Nulllinie.</p> <p>Noch ein Beispiel gefällig? Hier ein Gewinn von 5€ - allerdings nur bis knapp nach der Spielmitte. Danach stürzt das Konto ab auf –6€.</p> <p><a href="http://lh3.googleusercontent.com/-_7dKIcLsPZ8/Va1DAcvCVNI/AAAAAAAAFw4/TUIkD6AvPJw/s1600-h/image%25255B24%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-Tleso1TidrU/Va1DBaynSBI/AAAAAAAAFxA/xC14pK-5hv4/image_thumb%25255B14%25255D.png?imgmax=800" width="566" height="175"></a></p> <p>Sie sehen, auch das Spiel mit einer Wahrscheinlichkeit von 50% für Gewinn und Verlust ist ein Spiel, bei dem Sie deutlich verlieren (oder gewinnen) können.</p> <h3>Auf der schiefen Bahn</h3> <p>So weit das faire Spiel. Beide Münzseiten werden mit derselben Wahrscheinlichkeit geworfen. Was aber, wenn die Münze unregelmäßig ist? Was, wenn Sie mit etwas größerer Wahrscheinlichkeit verlieren? Statt 50% Gewinnchance haben Sie vielleicht nur 45%. Dann kann Ihnen das passieren:</p> <p><a href="http://lh3.googleusercontent.com/-hEGKWlqKmQ0/Va1DFWhRZcI/AAAAAAAAFxI/Ngt1v4JYchc/s1600-h/image%25255B27%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-MMGV1-35SAQ/Va1DHrnFIQI/AAAAAAAAFxQ/r0-T_QI2SFI/image_thumb%25255B15%25255D.png?imgmax=800" width="244" height="74"></a></p> <p><a href="http://lh3.googleusercontent.com/-bTiIwY4zhA8/Va1DJpbXuAI/AAAAAAAAFxY/h4ylnkFwt5Y/s1600-h/image%25255B30%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/--DiiIjnIzkU/Va1DMqvXtgI/AAAAAAAAFxg/3zF__pk5S4E/image_thumb%25255B16%25255D.png?imgmax=800" width="244" height="75"></a></p> <p><a href="http://lh3.googleusercontent.com/-rzlDMBHN9E8/Va1DP2EMDgI/AAAAAAAAFxo/sCCBgGTxR3k/s1600-h/image%25255B33%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-KhAZjScdUHo/Va1DQi31ESI/AAAAAAAAFxw/bgIL3qPgx4Q/image_thumb%25255B17%25255D.png?imgmax=800" width="244" height="76"></a></p> <p>Klar, das Ergebnis muss nicht immer unter 0€ liegen - aber selbst im Mittel über viele Spiele hinweg, werden Sie die 0€ nicht mehr erreichen, sondern Verlust machen. Und das wird immer schlimmer, je weiter sich die Wahrscheinlichkeit für Zahl zu Ihren Ungunsten verschiebt.</p> <p>Mit einer größeren Wahrscheinlichkeit für Verlust als für Gewinn kommen Sie auf eine schiefe Bahn. Sie rutschen in die Spielschulden. Garantiert über mehrere Spiele hinweg. Aber auch steiler innerhalb nur eines Spieles.</p> <h3>Geschätzte Annahmen</h3> <p>Nun zurück zur Softwareentwicklung. Ich denke, Sie verstehen, worauf ich mit diesem Gedankenexperiment hinaus will:</p> <p>Selbst wenn sich Ihre Schätzfehler aufheben, laufen Sie Gefahr, Ihr Projekt ins Desaster zu fahren.</p> <p>Ihr Projekt ist wie ein Spiel. In dem schätzen Sie 50 Aufwände oder 100 oder 500… Das bedeutet aber nicht, dass Sie bei sich aufhebenden Schätzfehlern am Ende <em>on time, on budget</em> herauskommen. Wie die Simulationen zeigen, können Sie sich weit, weit in die Miesen gefahren haben. Und das, obwohl die Wahrscheinlichkeit für positives und negatives Verschätzen gleich sind.</p> <p>Sie könnten auch gewinnen. Das stimmt. Aber wollen Sie bei einem Projekt wirklich spielen? Ist es das, was Sie für Ihren Kunden sein wollen: ein Spieler, der auf sein Glück hofft?</p> <p>Wie die Grafiken zeigen, kann Sie das Glück ganz schön pro Spiel, ich meine, pro Projekt im Stich lassen. Und das, obwohl hier sehr günstige Annahmen zugrunde liegen.</p> <p>Annahme 1: Positives und negatives Verschätzen gleichen sich aus. Ist das aber in der Realität wirklich, wirklich anzunehmen? Das glaube ich nicht. Diese Abschätzung, die Sie da machen, dass das Verschätzen eine Wahrscheinlichkeit von 50:50 hat, hat einen Fehler. So wie ich die Entwicklungsrealität kennengelernt habe, verschätzen Sie sich mit viel größerer Wahrscheinlichkeit zu Ihren Ungunsten. Wir müssten also nicht mit 50:50 simulieren, sondern eher mit 20:80: nur mit einer Wahrscheinlichkeit von 0,2 schätzen Sie zu große Aufwände; in 80% der Fälle schätzen Sie jedoch zu kleine Aufwände. Damit fährt das “Projektkonto” direkt in die Miesen. Probieren Sie es selbst aus in einer kleinen Excel-Simulation.</p> <p>Annahme 2: Wenn Sie glauben, dass Sie sich in etwas so oft zu Ihren Gunsten wie zu Ihren Ungunsten verschätzen, dann beziehen Sie das wahrscheinlich auf die <em>Anzahl</em> Ihrer Schätzungen: bei 50 Schätzungen schätzen Sie 25 Mal zu wenig und 25 Mal zu viel.</p> <p>Aber was ist eigentlich mit der Größe des geschätzten Aufwandes? Der hängt von der Größe der Aufgabe ab. Diese Größe variiert jedoch wahrscheinlich beträchtlich. Mal sind die Aufgaben klein, mal sind sie größer, dann sogar groß. Wie ist diese Größenverteilung? Und verschätzen Sie sich bei jeder Größe in gleicher Weise?</p> <p>Glauben Sie wirklich, dass Sie auch das realistisch einschätzen? Ich erlaube mir, das zu bezweifeln.</p> <p>Wenn nun aber die Größen der Aufgaben unterschiedlich sind und Ihr Schätzfehler ebenfalls unterschiedlich ist… dann wird damit die Unvorhersehbarkeit des “Projektspiels” angeheizt.</p> <h3>TL;DR</h3> <p>Wenn Sie glauben, Aufwandsschätzungen in der Softwareentwicklung könnten funktionieren, weil sich positive und negative Schätzfehler doch aufheben würden… dann machen Sie die Softwareentwicklung zu einem Glücksspiel. Denn auch bei 50:50 Chancen für Gewinn und Verlust, kann Sie ein einziges Spiel mit mehreren “Würfen” weit in die Miesen führen.</p> <p>Dafür, dass das Gesetz der großen Zahl Ihnen ein ausgeglichenes Konto beschert, führen Sie einfach zu wenige Projekte durch.</p> <p>Widerstehen Sie also der Spielsucht. Glauben Sie nicht länger, am Ende doch noch abzuräumen und alle Schulden zurückzuzahlen.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com17tag:blogger.com,1999:blog-6090483181455953305.post-39577228339299783502015-05-21T18:33:00.001+02:002015-10-30T06:42:52.860+01:00Rezension: Macht, was ihr liebt!<p>Schon wieder ist es passiert: Ich habe ein Buch des Autorenduos Förster & Kreuz gelesen. Beim letzten Mal ist es “Nur Tote bleiben liegen” gewesen. Das hatte ich dann zufällig und positiv <a href="http://blog.ralfw.de/2010/10/lesenswerte-widerlegung.html">in einem Blogartikel erwähnt</a> - und schon wurde ich nun angesprochen, ob ich nicht auch das neueste Buch rezensieren möchte.</p> <p><a href="http://www.amazon.de/Macht-was-ihr-liebt-Anstiftungen-ebook/dp/B00R6TXWAS" target="_blank"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="http://lh3.googleusercontent.com/-ljC0zbKGHmY/VV4ItHNq3tI/AAAAAAAAFHE/XYrvYx0u6RQ/image%25255B4%25255D.png?imgmax=800" width="117" height="177"></a>Da der Verlag - diesmal nicht Campus, sondern Pantheon - mir sogar eine eBook-Version zur Verfügung stellte, habe ich gern einmal reingeschaut und schreibe als Gegenleistung darüber. Aber keine Sorge, ich fühle mich nicht gekauft. Weitere Zuwendungen gab es nicht. Und da es mir an Lesestoff nicht mangelt, habe ich auch das Gratisbuch nicht als Lohn empfunden.<br>Also, dieses Mal nun “<a href="http://www.amazon.de/Macht-was-ihr-liebt-Anstiftungen-ebook/dp/B00R6TXWAS">Macht, was ihr liebt!</a>”.</p> <p>Lohnt es sich, das Buch zu lesen?</p> <p>Ich sage es mal so: Wenn man von den Autoren noch nichts gelesen hat und/oder Ermunterung für einen Aufbruch in Lebens- bzw. Arbeitsveränderungen sucht, dann sind die 9,99€ für die eBook-Ausgabe gut angelegt.</p> <p>Dafür bekommen Sie 66 1/2 sehr überschaubare “Muntermachgeschichten” für Zwischendurch geliefert. Die lassen sich beim Pendeln mit Bus und Bahn locker zwischendurch lesen. Oder morgens als “Energizer” für den Tag. Lassen Sie das Radio aus, vermeiden Sie den Blick in die Tageszeitung. Was Sie dort hören oder lesen ist frustrierend; ein guter Start in den Tag sieht anders aus.</p> <p>Motivierend ist hingegen, was Förster & Kreuz in Kurzform über Menschen zusammengetragen haben, die “einfach” tun, was sie lieben.<br>Das ist nicht tiefschürfend, aber vielfach einfach wahr. Ich jedenfalls konnte nicht anders als immer wieder innerlich zu nicken. Meine eBook-Seiten sahen deshalb alsbald so aus:<br></p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; border-top-width: 0px; border-bottom-width: 0px; margin-left: auto; border-left-width: 0px; margin-right: auto; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-Nn2gHz_yCLU/VV4ItrUG0cI/AAAAAAAAFHI/0gmYGmgbCZU/image%25255B11%25255D.png?imgmax=800" width="428" height="402"><br>Kaum eine Seite vergeht ohne einen Satz, der der Hervorhebung lohnt.<br>Es ist also nicht falsch, wenn ich sage, das Buch hat mir gefallen. Ich kann es empfehlen.<br>Einerseits.</p> <p>Denn andererseits… Es ist doch auf die Dauer etwas seicht, finde ich. So viel gute Laune, so viele kleine Motivationshappen… und sonst eben recht wenig. Es berichten zwei Paradiesvögel vor allem über andere Paradiesvögel. Da bleibt mir das Praktische, das Umsetzbare ab und an auf der Strecke.</p> <p><a href="http://en.wikipedia.org/wiki/Iris_Apfel">Iris Apfel</a> und <a href="http://en.wikipedia.org/wiki/Vhils">Alexandre Farto</a> sind zweifellos beeindruckende und inspirierende Persönlichkeiten. Nur hebt die Häufung solcher Persönlichkeiten zwischen zwei Buchdeckeln irgendwann ab. Da wären mir doch ein paar mehr Geschichten von Menschen wie du und ich noch lieber. Wo ist Ines Bäuerlein (38), Zahnarzthelferin in Unna, die glücklich ist, weil sie macht, was sie liebt? Wo ist Gunnar Schenk (52), Steuerberater in Radebeul, der glücklich ist, weil er macht, was er liebt?</p> <p>Es ist nicht zu verkennen: Zwei Menschen mit Haus in Frankreich, die sich auch einen Business Class Flug nach Tokio leisten können, schreiben, weil sie das lieben. In jeder Geschichte, die eigene Anekdoten enthält, wird deutlich: Hier sind zwei authentisch. Das ist wunderbar. Weniger wäre für das Thema auch schlecht.</p> <p>Leider macht es diese Authentizität ca. 97% der Bevölkerung nicht leichter, der Aufforderung zu folgen. Denn angesichts der Einkommensverteilung in Deutschland sind es wohl 97%, die nicht über diese Mittel verfügen. Wer arbeitslos oder alleinerziehend mit zwei Kindern ist, wer als Paketzustellerin oder Verkäufer bei H&M arbeitet, dessen Mittel sind so viel begrenzter.<br>Etwas mehr Handreichung oder “Volksnähe” würden das Buch meiner Meinung nach also noch besser machen.</p> <p>So viel zu andererseits.</p> <p>Meine bottom line: Es war nett zu lesen. Aber es ist wohl mein letztes Förster & Kreuz Buch gewesen. Stil und Botschaft wiederholen sich. Das eine oder andere Buch der beiden Autoren lohnt der ermunternden und horizonterweiternden Lektüre. Quasi als Gegengift zum sonstigen Miesepeterjournalismus. Sie zeigen “Es geht auch anders!” Das ist gut.</p> <p>Nur wenn ich dann bereit bin, es auch anders zu versuchen… dann braucht es wohl andere Lehrer und Lektüre.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-60762252150754974292015-04-13T12:13:00.001+02:002015-04-14T07:18:20.464+02:00Konsequente Verlässlichkeit - Promise Like a Pro<p>Die grundlegenden Kompetenzen, die jeder Softwareentwickler haben sollte sind nach <a href="http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html">Joel Spolsky</a>:</p> <blockquote> <ol> <li>Smart, and <li>Get things done.</li></ol></blockquote> <p>Dem kann ich nur zustimmen. Und nicht nur für Softwareentwickler gilt dies, würde ich sagen. Es sind die Voraussetzungen für jeden “Wissensarbeiter”, egal ob Programmierer, Tester, Product Owner, Softwarearchitekt, Entwicklungsleiter usw.</p> <p>Wie es mit der Smartness in der Branche steht, will ich hier nicht diskutieren. Das ist ein schwieriges Feld. Auch wenn ich ein Gefühl dafür habe, was “Smart” bedeutet… eine klare Definition fällt mir noch nicht ein. Da geht es um Auffassungsgabe, Denkvermögen, Abstraktionsvermögen, Konzentrationfähigkeit, Lernfähigkeit und -willigkeit. Weniger allerdings um schon vorhandenes Wissen. Nur soviel ist klar: Smartness ist sehr unterschiedlich verteilt.</p> <p>Wie es allerdings mit “Get things done” steht, das soll hier mein Thema sein. Denn da ist das Bild grimm.</p> <p>“Get things done” setze ich gleich mit “zuverlässig sein”. Jemand liefert Zugesagtes wie vereinbart. Ganz einfach. Ohne, dass man ihn andauernd anstoßen muss.</p> <p>Solche Zuverlässigkeit sehe ich in unserer Branche am Boden. Genauso wie bei der “Büroarbeit” im Allgemeinen. In Ersteres habe ich selbst Einblick, über Letzteres erfahre ich immer wieder von meiner Freundin, die <a href="http://zeitgewinn-hamburg.de">Professional Organizer und Efficiency Trainer</a> ist.</p> <p>Was wird denn zuverlässig erledigt? Im Kleinen wir im Großen grassiert die Unzuverlässigkeit. Man kommt zu spät zum Meeting, man ruft nicht wie versprochen zurück, Emails werden nicht (in angemessener Zeit) beantwortet, Abschätzungen werden nicht eingehalten, Zulieferungen werden nicht in vereinbarter Qualität gemacht, man vergisst Unterlagen usw. usf. ad nauseam.</p> <p>Natürlich sind die Entschuldigungen vielfältig. Meist sind “die Umstände” schuld, dass man unzuverlässig ist. Ist das nicht verständlich?</p> <p>Und da jeder unzuverlässig ist, entschuldigt man sich auch gegenseitig immer wieder. Man nimmt es hin. Man sagt gar “Ach, ist doch nicht so schlimm.” - weil man es ohnehin schon geahnt hatte, dass es nicht so kommen würde, wie es vereinbart war.</p> <p>Ja, so ist das. Das beobachte ich überall. Und es kotzt mich an. Was ist denn das für eine Art des Umgangs miteinander?</p> <p>Unabhängig von der Respektlosigkeit die in dieser epidemischen Unzuverlässigkeit steckt, ist sie auch noch kontraproduktiv. Sie trägt dazu bei, dass die Arbeit länger dauert, als sie müsste. Sie trägt dazu bei, dass die Arbeit teurer wird, als sie müsste. Unzuverlässigkeit erzeugt Verschwendung.</p> <p>Leider ist der Preis, den jeder Einzelne wie auch Unternehmen dafür zahlen, oft kaum messbar. Nachbesserungen und Wartezeiten und zusätzliche Transaktionskosten aller Art sind meist unterhalb des Radars des Controlling. Das sieht dann nur ungünstige makroskopische Effekte und versucht - kaum verwunderlich - mit wenig tauglichen Maßnahmen gegenzusteuern. Eher verschlimmern solche Maßnahmen sogar die Unzuverlässigkeit. Eine negative Spirale beginnt sich zu drehen…</p> <p>Die Klagen sind laut über die Unzuverlässigkeit. Warum, zum Teufel, können denn Zusagen nicht eingehalten werden? Warum wird zu spät geliefert? Warum ist das alles teurer als geplant? Warum sind die Leute, die zugesagt wurden, nicht da?</p> <p>Und keiner sieht, dass die Ursache dafür nicht woanders liegt, sondern in jedem selbst.</p> <p>Wir alle sind für die großen Unzuverlässigkeitsprobleme mit verantwortlich, wenn wir uns schon im Kleinen gleichgültig verhalten, was unsere persönliche Zuverlässigkeit angeht.</p> <p>Wir haben verlernt, Zuverlässigkeit als Wert anzusehen. Pünktlichkeit war einmal ein Charaktermerkmal, an dem man gemessen wurde. Das ist wie andere auch in Ungnade gefallen. Pünktlichkeit ist heute keine Selbstverständlichkeit mehr. Und andere Zuverlässigkeit auch nicht. WTF!</p> <p>Wenn wir wollen, dass Kunden mehr Vertrauen in unserer Tätigkeit haben, dann müssen wir etwas dafür tun. Wir müssen die Zuverlässigkeit wieder kultivieren. Wir müssen anstreben, 100% zuverlässig zu sein. Ja, genau: 100% sind das Ziel. Nicht weniger.</p> <p>Wir müssen jedes, aber auch jedes Versprechen einhalten. Immer. Denn um nichts weniger geht es bei Zuverlässigkeit: Zuverlässig ist, wer Versprechen stets einhält.</p> <p>Wer unzuverlässig ist, bricht ein Versprechen - und irgendwo stirbt ein kleines Kätzchen einen grausamen Tod.</p> <p>Jedes gebrochene Versprechen hinterlässt einen Knacks bei dem, dem wir versprochen haben. Es mögen manchmal und zuerst nur Haarrisse sein. Doch je öfter wir nicht halten, was wir versprechen, desto weiter wird das Geflecht dieser Risse. Dann entstehen brüchige Stellen im Vertrauen. Und am Ende… da zerbricht es womöglich daran.</p> <p>Das ist ein schlimmer Effekt. Denn Vertrauen ist ein wesentliches <a href="http://www.amazon.de/Vertrauen-Mechanismus-Reduktion-sozialer-Komplexität-ebook/dp/B00NM86KME">Mittel zur Reduktion von Komplexität</a>. Fehlt das Vertrauen, zieht explizite Kontrolle ein. (Micro-)Management ist die Folge. Oder Rechtsanwälte übernehmen.</p> <p>Nach 100% Zuverlässigkeit zu streben, hat also nur positive Effekte. Warum tun wir es dann nicht?</p> <p>Weil unser Verständnis von Versprechen undifferenziert ist. Im Grunde ist uns meist nicht bewusst, was wir da eigentlich tun, wenn wir etwas versprechen. Oder wir ahnen nicht einmal, dass wir überhaupt etwas versprochen haben.</p> <p>Aber das lässt sich ändern. Hier einige Denkanstöße für Sie. Das Ziel 100% Verlässlichkeit ist erreichbar.</p> <h2>Verantwortung übernehmen</h2> <p>Zunächst einmal sollte jedem, der etwas verspricht bewusst sein, dass man nur für sich selbst etwas versprechen kann. Denn ein Versprechen abgeben, bedeutet, Verantwortung zu übernehmen. Wichtig ist dabei das <em>Übernehmen</em>. Verantwortung kann - entgegen dem Sprachgebrauch - nicht übertragen werden. Sie kann nur im vollen Besitz aller geistiger Kräfte <em>übernommen</em> werden.</p> <p>“Ich verspreche, dass ich Auftrag A wie gewünscht ausführe!”: Das ist ein gültiges Versprechen. Damit kann ein Auftraggeber etwas anfangen. Der Auftragnehmer wird damit verantwortlich; das Ergebnis wird zurechnungsfähig.</p> <p>“Ich verspreche, dass Mitarbeiter M den Auftrag A wie gewünscht ausführen wird!”: Das ist ein ungültiges Versprechen - zumindest solange die dritte Partei, der eigentliche Auftragnehmer, nicht selbst schon die Verantwortung übernommen hat. Wer diese Verantwortungsübernahme lediglich vermittelt, übernimmt sie dann nicht selbst.</p> <p>Leider grassiert die Unart, dass Versprechen im Namen Dritter ohne vorherige Rücksprache und Übernahme abgegeben werden. Da verspricht der Vertrieb, dass ein Feature bis zum Termin T eingebaut sein wird - ohne die Entwicklung vorher zu fragen. Der Support verspricht, dass ein Bug sofort gefixt wird - ohne den Product Owner zu konsultieren. Der Manager verspricht, dass das Release noch diese Woche live geht - ohne das mit der IT-Abteilung abgesprochen zu haben.</p> <p>All dieses und viele andere Versprechen mehr sind jedoch ungültig. Man kann ihnen nicht vertrauen. Ihr Bruch ist vorprogrammiert. Oder zumindest ist Stress vorprogrammiert. Die Gründe liegen auf der Hand:</p> <ul> <li>Wer im Namen Dritter verspricht (und nicht nur vermittelt) übernimmt selbst Verantwortung. Wenn er dann aber nicht an der Ausführung beteiligt ist, wird er dazu tendieren, Druck auf die Ausführung auszuüben, damit er sein ungültigerweise abgegebenes Versprechen auch hält. Das macht selten für die Ausführung etwas besser. <li>Wer im Namen Dritter ohne deren ausdrückliche Verantwortungsübername verspricht, also über deren Zeit und Arbeitsinhalte bestimmt, beschädigt die Motivation. Wer will schon keine Wahl haben bei der Verantwortnungsübernahme? <li>Ohne echte Verantwortungsübernahme sind die Bedingungen für die ausführenden Dritten selten so, wie sie sein müssten. Auch ohne Micro-Management entsteht dadurch sehr wahrscheinlich Stress, weil es an Budgets und/oder Ressourcen mangelt.</li></ul> <p><strong>Merke: Versprechen kann nur, wer selbst ausführt.</strong></p> <p>Und was kann einer versprechen, der etwas ausführt?</p> <h2>Ergebnisse versprechen</h2> <p>Üblicherweise werden Ergebnisse versprochen. Das wird auch erwartet.</p> <p>“Die Kosten der Wagenreparatur werden 1000€ sein. Sie können ihn übermorgen abholen.”, “Das Essen wird in einer halben Stunde auf dem Tisch stehen.”, “Das Release geht morgen früh raus.”, “Ich rufe dich um 9h an.”, “Meine Email-Adresse ist …” - so lauten größere und kleinere, bewusstere und unbewusstere Ergebnisversprechen, die wir jeden Tag abgeben.</p> <p>Das Dumme dabei: Ergebnisse zu versprechen, ist sehr risikoreich. Man muss die Ausführungsumstände schon sehr unter Kontrolle haben, um ein Ergebnis verlässlich zu erzielen. Für die Zubereitung des Mittagessens mag das noch der Fall sein. Wahrscheinlich auch bei der Wagenreparatur - immerhin hat der KFZ-Mechaniker sich für den Kostenvoranschlag Zeit genommen zu einer Begutachtung des Autos. Aber ob das Release wirklich morgen früh rausgeht?</p> <p>Selbst so simple Versprechen wie der Anruf am Morgen oder auf Emails in angemessener Zeitspanne zu antworten, sind risikoreich, wie es scheint. Denn wie oft werden sie gebrochen…<a id="fnref:1" class="footnote" title="see footnote" href="#fn:1">[1]</a></p> <p>Ein Ergebnis kann nur versprochen werden, wenn seine Herstellung eine “handwerkliche Tätigkeit” ist (vgl. “<a href="http://blog.ralfw.de/2015/04/unschatzbare-arbeitsweisen.html">Unschätzbare Arbeitsweisen</a>”). Handwerker sind die, die Ergebnisse verlässlich reproduzieren. Dafür bauen sie über Jahre Erfahrung auf. Diese Erwartung haben wir an sie - zurecht.</p> <p>Ein Mittagessen zuzubereiten sollte eine handwerkliche Tätigkeit sein. Auch den Anruf für den nächsten Tag sollte auf dem Niveau sein. Ebenso, sich zu einem Treffen einzustellen. Und nach Erforschung des Zustands eines Wagens erwarten wir auch, dass der KFZ-Mechaniker sich in einer Handwerkerzone befindet.</p> <p>Aber ist das Fixing eines Bugs handwerklich? Kaum. Dazu gehört eine unbestimmte Menge Forschung. Dito die Umsetzung eines neuen Features oder auch nur die Analyse von Anforderungen. Gerade in der Softwareentwicklung sind wir immer wieder erwartbar (oder auch überraschend) als Forscher und Ingenieure gefragt. Dann tun wir gut daran, keine Ergebnisse zu versprechen. Denn nichts anderes wollen Kunde und Management, wenn sie um eine Aufwandsschätzung bitten. Schlimmer noch, wenn z.B. das Marketing ungültig verspricht, “Das Feature haben wir bis zur Messe drin!”</p> <p>Widerstehen Sie in diesen Fällen! Lassen Sie sich auf kein Ergebnisversprechen ein - solange für Sie als Ausführender nicht sonnenklar ist, dass die Ausführung zu 80+% rein handwerkliche Tätigkeit ist.</p> <p>Und wie erkennen Sie ein Ergebnisversprechen? <strong>Ergebnisse sind Zielzustände, deren Erreichung an ein Budget geknüpft ist.</strong></p> <p>Budgets können finanziell sein, aber vor allem zeitlich. “Das Essen ist um 12h auf dem Tisch!” Wer dieses Ergebnis um 11h verspricht, hat ein Zeitbudget von 60 Minuten, um den Zustand “Essen auf dem Tisch” herzustellen.</p> <p>Wie gesagt: Es ist nicht unmöglich, Ergebnisse zu versprechen. Aber vermeiden Sie es oder seien Sie sich zumindest dessen sehr, sehr bewusst. Tun Sie es nur, wenn die Herstellung des Zielzustands quasi eine Reproduktion ist, wenn sie das schon oft unter gleichen Umständen getan haben.</p> <p><strong>Merke: Ergebnisversprechen sind riskant!</strong></p> <p>Eine Sonderform von Ergebnisversprechen sind die, bei denen die Budgetgröße nicht im Vordergrund steht, sondern der “Liefertermin” für den Zustand. Das ist der Fall, wenn das Ergebnis mit einem (unplanbaren?) Ereignis verknüpft wird. Beispiele: “Ich verspreche, dass ich bei jedem Anruf Name und Anliegen und Uhrzeit notiere.”, “Ich verspreche, dass ich keine Aufträge mehr annehme, die nicht schriftlich vorliegen.”</p> <p>Das Risiko besteht hier weniger in der Herstellbarkeit des Zielzustands, als vielmehr darin, ihn auch tatsächlich zu produzieren. Handwerkskunst ist in Bezug auf das Erinnerungsvermögen und den Willen gefragt. Erinnere ich mich im rechten Moment daran, was ich versprochen habe? Habe ich die Disziplin, das Versprochene zu tun? Der zu erreichende Zustand ist also vor allem “Bewusstsein und Energie”.</p> <h2>Verhalten versprechen</h2> <p>Sie werden nun wahrscheinlich denken: “Aber wenn ich keine Ergebnisse mehr versprechen darf… Was soll ich denn dann versprechen? Man verlangt von mir doch ein Commitment.”</p> <p>Sie haben Recht. Wir brauchen Commitments in der Zusammenarbeit, im Zusammenleben. Ohne Verlässlichkeit wird alles zäh, stressig, ärgerlich.</p> <p>Aber Sie können ja nicht nur riskante Ergebnisse versprechen, sondern auch Verhalten. Das ist viel weniger riskant.</p> <p>Ein plakativer Vergleich: Wenn Sie das Ergebnis “2020 habe ich den Welthunger besiegt!” versprechen, ist der Misserfolg vorprogrammiert. Versprechen Sie hingegen “Ab heute werde ich jeden Tag bis 2020 2 Stunden dem Sieg über den Welthunger widmen!”, dann ist ein Erfolg in Ihrer Reichweite.</p> <p>Ein Verhaltensversprechen verlangt Ihnen keine handwerkliche Erfahrung in Bezug auf den Tätigkeitsgegenstand ab. Sie müssen kein Budget für die Ergebniserreichung angeben. Verhaltensversprechen können Sie also auch immer dann guten Gewissens eingehen, wenn Sie noch forschen und planen müssen. Und das ist - zumindest in der Softwareentwicklung - meistens der Fall.</p> <p>Und wie erkennen Sie ein Verhaltensversprechen? <strong>Verhalten ist eine Tätigkeit unter festgelegtem Ressourceneinsatz.</strong></p> <p>Verhaltensversprechen versprechen also keinen Zustand (“Bug gefixt”, “Essen gekocht”), sondern eine Aktivität (“Bug fixing”, “Essen kochen”). Statt Futur II (“Ich werde geschafft haben.”) benutzen Sie Futur I (“Ich werde tun.”).</p> <p>Verhaltensversprechen haben allerdings nichts mit Versuchen zu tun, ein Ergebnis herzustellen. Sagen Sie also nicht “Ich werde versuchen, Zustand Z bis zum Termin T herzustellen.” Damit verleiten Sie den Auftraggeber, ein Ergebnisversprechen herauszuhören. Wenn Sie kein Ergebnis versprechen können oder wollen, dann tun Sie das auch nicht. Seien Sie mutig und klar in Ihrer Aussage.</p> <p>Ebenso wenig haben Verhaltensversprechen mit Mühe zu tun. Sagen Sie also auch nicht “Ich werde mich bemühen, Aktivität A zu tun.” Was Sie da nämlich versprechen, ist nicht die Aktivität A, sondern sich zu bemühen. Das will ein Auftraggeber jedoch nicht. Der möchte A und sonst nichts. Sagen Sie ihm also klar, ob ud wie Sie A leisten können.</p> <p>Warum hört man aber so oft, dass jemand nur Mühe verspricht? Weil es an handwerklichem Können fehlt. Denn auch für Verhaltensversprechen ist Handwerk grundlegend. Wir müssen nämlich in Bezug auf unsere Zeit Handwerker sein. Wir müssen unser Zeitmanagement im Griff haben. Der Umgang mit Kalender und Aufgabenliste ist zentral für jede Verlässlichkeit.</p> <p>Bei Ergebnisversprechen ist das selbstverständlich und offensichtlich. Da steht der Zustandslieferungstermin im Vordergrund.</p> <p>Verhaltensversprechen haben zwar keinen solchen Termin, dennoch braucht das Verhalten einen präzisen zeitlichen Rahmen.</p> <p>Das war mir lange nicht klar. So sinnig ich die <a href="https://jockeholm.wordpress.com/2014/05/11/promises-promises-2014/">Unterscheidung zwischen Ergebnis- und Verhaltensversprechen</a> fand, war mir doch manchmal beim Versuch, ein Verhalten zu versprechen, nicht ganz wohl. Oder es kam mir bei vermeintlichen Verhaltensversprechen anderer irgendetwas noch nicht stimmig vor. Der Grund dafür, wie ich nun herausgefunden habe, war ein Mangel an zeitlicher Präzision. Da war zwar eine Tätigkeit statt eines Ergebnisses im Gespräch, nur war die unverbindlich. Es fehlte das Commitment.</p> <p>Beim Ergebnisversprechen besteht das Commitment in der Verknüpfung von Zustand mit Budget. Ich formalisiere das mal als Tupel: (Zustand, Budget), z.B. (Repariertes Auto, 2 Stunden Aufwand).</p> <p>Das Commitment des Versprechens muss die Tätigkeit auch mit etwas verbinden. Es gibt zwar kein fixes Budget, aber eine Ressource muss eingesetzt werden. Da Ressourcen jedoch kaum vollständig zur Verfügung stehen, geht es allgemeiner um einen Ressourcenanteil, z.B. (Bug fixen, 10% meiner Arbeitszeit).</p> <p>So sieht das minimale Verhaltensversprechen aus: Sie versprechen, einen gewissen Prozentsatz Ihrer Zeit auf eine Aktivität zu konzentrieren. Das tun Sie so lange, bis das gewünschte Ergebnis erreicht ist - oder ein anderer Zustand, der eine Meldung und ggf. eine Neuorientierung erfordert.</p> <p>Wenn Sie dem Auftraggeber schon nicht sagen können, dass Sie das gewünschte Ergebnis mit einem Budget verlässlich herstellen können, dann sichern Sie zumindest zu, sich mit einer gewissen Kraft darum zu kümmern. Wie viel Kraft das ist, muss verhandelt werden.</p> <p>Sie haben natürlich mehr auf dem Zettel als einen Auftrag. Deshalb müssen Sie den Ressourceneinsatz genau formulieren. Wenn es um Zeit geht, sind drei Angaben nötig:</p> <ol> <li>Wann beginnen Sie mit der Tätigkeit? <li>Wie viel Prozent Ihrer Zeit widmen Sie der Tätigkeit? <li>Wie dicht ist Ihr Einsatz gepackt?</li></ol> <p>Auftraggeber wünschen sich natürlich, dass Sie sofort mit einer Tätigkeit beginnen. Sie wollen das Ergebnis schnellstmöglich. Kommt jedoch ein zweiter Auftrag herein, während der erste noch nicht abgeschlossen ist, führt dessen sofortiger Beginn zu einer Unterbrechung des ersten. Schädliches Multitasking nimmt seinen Lauf. Alles dauert länger, Ergebnisse werden später geliefert. Vermeiden Sie das! Staffeln Sie Aufträge, beginnen Sie sie nacheinander.</p> <p>Auftraggeber wünschen sich natürlich ebenfalls, dass Sie 100% Ihrer Zeit der gewünschten Tätigkeit widmen. Sie wollen das Ergebnis schnellstmöglich. Das ist nur möglich, wenn Sie immer nur einen Auftrag bearbeiten, bis das Ergebnis erzielt ist. Eine solche Staffelung ist jedoch nicht immer möglich und gelegentlich sogar unökonomisch. Immer wieder gibt es durch Abhängigkeiten Wartezeiten während der Bearbeitung eines Auftrags. Warum die nicht mit anderen Aufträgen füllen? Bis zu einem gewissen Grad ist solches Multitasking bekömmlich. Sie können Ihre Zeit also auch in Teilen versprechen. Aber Achtung: Zu klein sollten diese Teile nicht werden. Ich würde sagen, kürzer als 45–60 Minuten sollten Bearbeitungseinheiten nicht sein. Versprechen Sie also nicht weniger als 10% Ihrer Zeit.</p> <p>Weder bei 100%iger Auslastung mit einem Auftrag noch bei weniger können Sie sagen, wie lange es dauern wird, bis das gewünschte Ergebnis hergestellt ist. Deshalb geben Sie ja ein Verhaltensversprechen. Es kann daher sein, dass Sie nicht mit einem Zeitblock an einem Tag auskommen. Aber wann widmen Sie sich dann wieder dieser Tätigkeit? Das könnte morgen sein oder erst übermorgen oder nächste Woche. Das sollten Sie ebenfalls dem Auftraggeber kommunizieren.</p> <p>Beispiel 1, “Ich werde mich ab heute jeden Tag 2 Stunden mit dem Thema beschäftigen.”: Hier versprechen Sie 25% Ihrer Zeit einzusetzen. Die Dichte ist 100%, da das jeden Tag geschieht.</p> <p>Beispiel 2, “Ich werde jede Woche 4 Stunden X tun.”: Hier versprechen Sie 10% Ihrer Zeit für X aufzuwenden - allerdings nicht jeden Tag, sonder vielleicht einmal die Woche en bloc. Deshalb ist die Dichte in Bezug auf Tage nur 20%.</p> <p>Formal ist ein Verhaltensversprechen also ein 4-Tupel der Form <em>(Tätigkeit, Startzeitpunkt, Zeitanteil, Dichte)</em>, z.B. (Anforderungen analysieren, morgen 13:00h, 4 Stunden (50%), täglich (100%)).<a id="fnref:2" class="footnote" title="see footnote" href="#fn:2">[2]</a></p> <p>Für ein Versprechen auf dem Gang zwischen Tür und Angel ist das natürlich ein bisschen zu detailliert. Aber wenn Sie etwas mehr Zeit haben oder für die Reflexion ist solche Differenziertheit nützlich, finde ich.</p> <p>Wenn Ihnen jetzt etwas mulmig wird, kann ich das verstehen. Wie sollen Sie denn eine bestimmte Intensität der Beschäftigung mit einem Auftrag versprechen können. Was wissen Sie über Ihren Kalender morgen oder nächste Woche? Aber genau <em>das</em> ist die Handwerkskunst, die mindestens nötig ist, wenn wir vertrauensvoll und verlässlich zusammenarbeiten wollen. Als Wissensarbeiter müssen Sie Meister des Zeitmanagements sein. Nicht weniger. So sieht die Grundkompetenz für die Zusammenarbeit jenseits handwerklicher Arbeiten aus. Das kann ich nicht schonend formulieren. Wer seine Zeit, seinen Kalender nicht im Griff hat, hat schon verloren. Der ist verdammt zu nicht endendem Stress. </p> <p><strong>Merke: Verhaltensversprechen sind jederzeit möglich!</strong></p> <h2>Handfeste Prioritäten</h2> <p>Ständig konkurrieren mehrere Aufträge um eine Verarbeitungsressource. Das kann eine Person, ein Team, ein Unternehmen, eine Maschine sein. Es stellt sich daher die Frage, wie sich die Ressource diesen Aufträgen widmen sollte.</p> <p>Mit der differenzierten Sicht auf Verhaltensversprechen ist es möglich, darüber handfest mit den Auftraggebern zu sprechen. Die können sich nun entscheiden, in welchen Aspekt sie investieren wollen, um die Abarbeitung eines Auftrags zu beschleunigen, d.h. höher zu priorisieren:</p> <ol> <li>Der Auftraggeber kann Argumente liefern, warum ein Auftrag möglichst bald begonnen werden soll. Je früher, desto höher die Priorität. Insbesondere, wenn dadurch andere Aufträge unterbrochen werden müssten, sind gute Argumente nötig. <li>Der Auftraggeber kann Argumente liefern, warum für die Abarbeitung eines Auftrags ein möglichst großer Prozentsatz der Ressourcenzeit pro Zeiteinheit alloziert werden sollte. Mehr Anteil, desto höher die Priorität. Insbesondere, wenn dadurch der Anteil für andere schon begonnene Aufträge verringert werden soll, sind gute Argumente nötig. <li>Der Auftraggeber kann Argumente liefern, warum die Anteilsdichte möglichst hoch sein sollte. Je höher die Dichte, desto höher die Priorität. Insbesondere, wenn dadurch die Dichte für die Abarbeitung anderer Aufträge sinken würde, sind gute Argumente nötig.</li></ol> <p>Höchste Priorität hat, was sofort mit 100% der Zeit und 100% Dichte begonnen wird. Da gibt es kein Vertun. Das ist wünschenswert, um schnellstmögliche Ergebniserzielung zu erreichen. Das ist Work-in-Progress (WIP) = 1. Das ist erstrebenswert, weil nur so die Verschwendung minimal ist. Feedback wird maximal schnell generiert.</p> <p>Aus verschiedenen Gründen mag es aber doch sinnvoll sein, mehrere Aufträge quasi gleichzeitig zu bearbeiten, also Multitasking zuzulassen.</p> <p>Deshalb werden Sie Aufträgen eher selten 100% Anteil gewähren. Seien Sie jedoch vorsichtig! Erstens sollten Sie ohnehin nie 100% Ihrer Zeit verplanen; lassen Sie eher 30–40% Luft als Puffer für Unvorhergesehenes. Zweitens sollten Sie die Anteile nicht zu klein schneiden; unter 1 Stunde lohnen sich viele Tätigkeiten nicht. Sie brauchen zu lange, um (wieder) reinzukommen. Es ergibt sich, dass Sie pro Tag maximal 3–4 verschiedene Aufträge sinnvoll bearbeiten können.<a id="fnref:3" class="footnote" title="see footnote" href="#fn:3">[3]</a></p> <p>Dasselbe gilt für die Dichte. Eine zu geringe Dichte ist dem Fortkommen eines Auftrags und der Bearbeitungsqualität abträglich. Streben Sie eine Dichte von 100% an. Bringen Sie Aufträge jeden Tag bis zum Abschluss voran, wenn schon nicht mit 100% Anteil. Wenn die Dichte darunter sinkt, dann nur weil externe Abhängigkeiten das erfordern. Wenn Sie auf Zuarbeiten warten müssen, hilft es nichts, dass Sie schon morgen weitermachen wollen. Dann sichern Sie nur eine geringere Dichte zu. Aber vermeiden Sie, bei Eintreffen von Ergebnissen sofort zur unterbrochenen Aufgabe zurückzukehren. Tun Sie das erst, wenn sie laut Anteil und Dichte wieder in Ihrem Plan dran ist.</p> <h2>Teileweise arbeiten</h2> <p>Versprechen zu halten ist schon schwer genug, auch Verhaltensversprechen. Versprechen über lange, gar unbestimmt lange Zeit zu halten, ist aber noch schwerer. Versuchen Sie daher, Aufträge, deren Budget sie nicht kennen, aber deren Größenordnung Ihnen ungefähr klar ist und jenseits von 7–10 Tagen liegt, in kleinere Teilaufträge von max. einer Woche zu zerlegen.</p> <p>Große Aufträge liegen schwer in Ihrem Kalender. Sie wirken immobilisierend. Sie verlieren mit ihnen die Fähigkeit, auf Änderungen zu reagieren.</p> <p>Suchen Sie in großen Aufträgen daher “Sollbruchstellen”, die für den Auftraggeber Sinneinheiten darstellen. Statt einer langen Verhaltensstrecke mit Blick auf das ultimative Ergebnis stecken Sie lieber Teilstrecken für Teilverhalten mit Teilergebnissen ab.</p> <p>Das gibt nicht nur Ihnen Flexibilität und erhöht Ihre Verlässlichkeit. Auch Auftraggeber bekommen die Möglichkeit, sich nach der Erarbeitung von Teilergebnissen wieder neu zu entscheiden.</p> <h2>Pacta sunt servanda</h2> <p>“Versprochen ist versprochen!” Wenn Sie Ergebnisse oder Verhalten versprechen, dann müssen Sie wie versprochen leisten. Schon die Römer wussten, dass das ein Grundpfeiler für Zivilisation ist und sagten “pacta sund servanda”, Verträge müssen eingehalten werden.</p> <p>Solange Sie jedoch im Dialog mit dem Auftraggeber stehen, können Sie bei Bedarf nachverhandeln. Versprechen können verändert werden, wenn alle beteiligten Parteien dem zustimmen.</p> <p>So eine Nachverhandlung erhält die Verlässlichkeit allerdings nur, wenn Sie ein Nein akzeptieren können. Veränderungswünsche sind Bitten, die abgelehnt werden können.</p> <p>Beispiel: “Ich weiß, ich habe Ihnen den Bericht für 13:00h zugesagt - aber nun würde ich gern dem Kollegen bei einem dringenden Auftrag helfen. Dadurch würde sich die Berichtsabgabe bis 15:00h verzögern. Ist das ok?” Die Frage zu stellen, ist völlig legitim. Dadurch brechen Sie kein Versprechen. Doch wenn der Auftraggeber Nein sagt und sie nach 13:00h liefern, sind Sie unzuverlässig.</p> <p><strong>Merke: Ergebnisversprechen führen häufig zu Nachverhandlungen. Versprechen Sie daher lieber ein Verhalten.</strong></p> <p><strong>Merke: Alle Versprechen können im gegenseitigen Einvernehmen modifiziert werden.</strong></p> <p>Aber Vorsicht: Auch wenn Versprechen grundsätzlich nachverhandelt werden können, sollte das die Ausnahme sein. Wenn Sie ein Versprechen abgeben, versprechen Sie nämlich auf zwei Ebenen. Ebene 1 ist die offensichtliche; Sie versprechen z.B. etwas zu tun. Ebene 2 liegt unausgesprochen darunter. Auf der Versprechen Sie, das Versprechen genau so einzuhalten, also eben nicht ständig nachzuverhandeln. Denn ein Versprechen soll ja Ruhe in die Zusammenarbeit bringen. Es soll damit eine Sache vorläufig abgeschlossen werden. Mentale Ressourcen sollen frei werden. Dieser Zweck würde durch ständige Nachbesserungen torpediert.</p> <h2>Promise Like a Pro</h2> <p>Versprechen scheinen so einfach. Wir versprechen ja schon als Kinder. Formal sind sie auch einfach. Sogar so einfach, dass wir sie oft unbewusst und leichtfertig abgeben. Wir sind uns über die Tragweite nicht im Klaren. Und wir haben nicht gelernt, mit diesem wichtigen Werkzeug der Zusammenarbeit systematisch umzugehen. So interpretiere ich jedenfalls das, was ich in Unternehmen sehe: die Unzuverlässigkeit grassiert im Kleinen wie im Großen. Die Effekte: Stress, Demotivation, hohe Kosten.</p> <p>Wenn wir diese Effekte nicht wollen, dann müssen wir Zuverlässiger werden. 100% aller Versprechen müssen eingehalten werden. Ja, das ist möglich, wenn Sie bewusst und vorsichtig und manchmal mutig sind. Schauen Sie genau hin, ob Sie all die Ergebnisse wirklich versprechen wollen und können und müssen, zu denen Sie sich jeden Tag committen. Wählen Sie bewusst immer öfter Verhaltensversprechen. Und bekommen Sie Ihre Zeit in den Griff! Wenn Sie keine Hoheit über diese ultimativ knappe Ressource Ihres Lebens haben… dann sollten Sie das als erstes ändern.</p> <p>Für mehr Vertrauen, für mehr Zuverlässigkeit müssen wir Profis des Versprechens werden. Der Slogan für mich ist: <a href="https://jockeholm.wordpress.com/2014/05/11/promises-promises-2014/">Promise Like a Pro</a>. Das ist die Voraussetzung für “Gets things done”.</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Das ist natürlich eine Unart und darf nicht sein. So simple Dinge müssen wir 100% unter unserer Kontrolle haben. Wer einen Anruf verspricht, muss anrufen. Wer eine Email-Adresse herausgibt, muss antworten. <a class="reversefootnote" title="return to article" href="#fnref:1">↩</a></p> <li id="fn:2"> <p>Um genau zu sein, gehört zu einem Ergebnisversprechen auch ein Startzeitpunkt: (Zustand, Startzeitpunkt, Budget), z.B. “Ich werde für das Bug fixing 4 Stunden brauchen - und morgen um 8:00h damit beginnen.” Doch insbesondere bei ad hoc Versprechen ist der Startzeitpunk uninteressant. Dann geht es nur um den Liefertermin. Das Budget ist also der Zeitraum ab Versprechensabgabe bis dahin. Deshalb habe ich den Startzeitpunkt oben nicht aufgeführt. Für Verhaltensversprechen ist er wichtiger, da sie keinen Liefertermin haben. <a class="reversefootnote" title="return to article" href="#fnref:2">↩</a></p> <li id="fn:3"> <p>Ich spreche hier nicht über ein Call Center mit Anrufdauern von 3 Minuten. Das wäre auch handwerkliche Arbeit. Es geht um Wissensarbeit, zu deren Erledigung in den meisten Fällen mehrere Stunden, Tage, gar Wochen nötig sind. Dass Sie darüber hinaus noch eine Menge “Kleinscheiß” zu tun haben, ist klar. Damit müssen Sie gesondert umgehen. Die Tagesplanung ist aber nicht Thema dieses Artikels. <a class="reversefootnote" title="return to article" href="#fnref:3">↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com7tag:blogger.com,1999:blog-6090483181455953305.post-50654430799624048372015-04-11T19:01:00.001+02:002015-04-12T07:32:06.844+02:00Die IODA Architektur<p>Über die Jahre haben einige grundlegende Architektmodelle um unsere Gunst gekämpft. Mir fallen ein in chronologischer Reihenfolge ein:</p> <ul> <li><a href="http://en.wikipedia.org/wiki/Model–view–controller">MVC</a> (Ja, das rechne ich zu Architekturmodellen, weil es Leute gibt die sagen, "Unsere Software hat eine MVC-Architektur.)</li></ul> <ul> <li>das <a href="http://en.wikipedia.org/wiki/Multilayered_architecture">Schichtenmodell</a></li></ul> <ul> <li>Pat Hellands Executants, <a href="https://msdn.microsoft.com/en-us/magazine/cc164125.aspx">Emissaries und Fiefdoms</a> <li>Alistair Cockburnss <a href="http://alistair.cockburn.us/Hexagonal+architecture">Hexagonal Architecture</a> aka Ports-and-Adapters <li>Jeffrey Palermos <a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-1/">Onion Architecture</a> <li>Robert C. Martins <a href="http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html">Clean Architecture</a></li></ul> <p>Auch ich habe mir erlaubt, dieser Liste einen Eintrag hinzuzufügen. 2005 kam mit die Idee der Softwarezellen. Die habe ich <a href="http://weblogs.asp.net/ralfw/410417">in einigen englischen Blogartikeln</a> beschrieben - allerdings sind da über die Jahre die Bilder abhanden gekommen :-(</p> <p>Leider ist es über die Jahre mit der Wartbarkeit/Wandelbarkeit von Software trotz dieser schönen Architekturmodelle nicht wesentlich besser geworden. Auch Anwendungen, die sich einen Schichtenmodells rühmen, waten heute meist im tiefen Brownfield.</p> <p>Woran kann das liegen?</p> <p>Ich glaube nicht, dass die Architekturempfehlungen falsch sind. Es steckt eine Menge Beachtenswertes in ihnen. Doch es muss auch noch etwas fehlen. Sonst wäre die Situation der Codebasen nicht so, wie sie ist.</p> <h2>Gemeinsamkeiten</h2> <p>Ich versuche mal, die obige Vielfalt ein wenig zu ordnen. Dann wird klarer, was da ist. Immer eine gute Sache, bevor man etwas verbessert.</p> <h3>Verantwortungsstruktur</h3> <p>Die augenfälligste Gemeinsamkeit aller Architekturmodelle ist die Benennung und Trennung von Verantwortlichkeiten. MVC und Schichtenmodell z.B. sagen ganz klar: Es gibt drei wesentliche Aufgaben in (jeder) Software. Die sollten in unterschiedlichen Modulen<a id="fnref:1" class="footnote" title="see footnote" href="#fn:1">[1]</a> realisiert werden.</p> <p>Bemerkenswert ist, dass die Verantwortlichkeiten alle inhaltlicher Art sind. Sie beziehen sich auf die Herstellung von Verhalten zusammengesetzt aus unterschiedlichen Aspekten. So gehört zum Verhalten einer Software z.B. die Erzeugung von Seiteneffekten auf Bildschirm (Presentation Layer des Schichtenmodells oder View bei MVC) oder Festplatte (Data Access Layer des Schichtenmodells oder DB bei Clean Architecture) sowie ganz wesentlich die Domäne (Business Logic Layer des Schichtenmodells oder Entities bei Clean Architecture).</p> <h3>Beziehungsstruktur</h3> <p>Die identifizierten Verantwortlichkeiten setzen die Architekturmodelle in Beziehung. Sie definieren, welche Verantwortlichkeit mit welchen anderen in einem Abhängigkeitsverhältnis steht. Dabei geht es immer um funktionale Abhängigkeiten, d.h. Dienstleistungsbeziehungen.</p> <p>Beim Schichtenmododell ist das am einfachsten: jede Schicht ist nur von der darunterliegenden abhängig. Auch die Clean Architecture hält die Abhängigkeiten unidirektional: sie weisen von außen nach innen. Bei MVC und seinen Verwandten hingegen sieht es anders aus.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-SmdC94u7KdM/VSlTafea6AI/AAAAAAAAFEA/Xa_8fkGrvNY/image%25255B6%25255D.png?imgmax=800" width="362" height="195"></p> <h3>System-Umwelt-Trennung</h3> <p>Und schließlich geht es auch noch um eine deutliche Trennung von Softwaresystem und Umwelt. Den Verantwortlichkeiten an der Systemgrenze kommt eine besondere Bedeutung zu. Das stellen insb. die Hexagonale Architektur und Softwarezellen heraus.</p> <p>Bei den Softwarezellen nenne ich diese Schale deshalb ausdrücklich Membran. Über Adapter findet ein bidirektionaler Austausch der Domäne mit der Umwelt statt.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-ruGqHw6oa_s/VSlTa4jQG7I/AAAAAAAAFEE/t0pm4YakYZ8/image%25255B14%25255D.png?imgmax=800" width="349" height="349"></p> <p>Anders als die Hexagonalen Architektur unterscheiden Softwarezellen jedoch, wie sie mit der Umwelt in Verbindung stehen. Dass die Umwelt auf sie einwirkt, ist davon zu trennen, dass sie auf die Umwelt einwirken. Ersteres geschieht durch Portal-Adapter, Letzteres durch Provider-Adapter.</p> <h3>Holarchie</h3> <p>Nur die Softwarezellenarchitektur schlägt darüber hinaus noch vor, Softwaresysteme auf mehreren Abstraktionsebenen mit dem selben Mittel zu beschreiben. Die Softwarezelle selbst ist damit Modellierungselement.</p> <p>Mit dem Schichtenmodell kann man eine Software einmal in Schichten zerlegen. Mit der Onion Architektur kann man eine Software einmal aufgebaut aus Schalen beschreiben. Aber mit Softwarezellen kann eine Software nicht nur einmal in Portale, Provider und Domäne zerlegt werden, sondern auch noch in kleinere Softwarezellen.</p> <p>Das Softwarezellenmodell ist mithin selbstähnlich hierarchisch. Auf jeder Ebene der Hierarchie befinden sich Softwarezellen, die wiederum aus Softwarezellen zusammengesetzt sein können.<a id="fnref:2" class="footnote" title="see footnote" href="#fn:2">[2]</a></p> <p>Eine solche Hierarchie, bei der die Teile gleichzeitig Ganze sind, wird auch als <a href="http://en.wikipedia.org/wiki/Holarchy">Holarchie</a> bezeichnet.</p> <h2>Das gemeinsame Problem: Funktionale Abhängigkeiten</h2> <p>Das sieht doch alles ganz ordentlich aus, oder? Mehr oder weniger detailliert werden inhaltliche Verantwortlichkeiten in funktionale Abhängigkeit gesetzt. Mal laufen die in die eine Richtung, mal in die andere. Wenn es damit nicht funktioniert, dann wird man das Modell wohl noch nicht sauber oder fein genug angewandt haben. Was sollte man auch anders tun?</p> <p>Meine Vermutung ist, dass das Problem tiefer liegt, wenn trotz der Architekturmodelle die Software in die Unwartbarkeit rutscht. Nicht sauber mehr davon anwenden hilft dann, sondern aufhören und etwas anderes tun.</p> <p>Woran könnte es denn aber liegen, dass es nicht einfach klappt mit diesen Modellen?</p> <p>Ich denke, die Separierung von Verantwortlichkeitskategorien ist nicht das Problem. Sie ist dringend nötig. Zuviel davon kann es kaum geben. Lieber die Verantwortlichkeiten etwas differenzierter sehen, als zu viel davon in einem Modul zu versammeln. Das Single Responsibility Principle (SRP) und seine Verwandten (SoC, SLA, ISP) sind nicht umsonst eines der immer wieder beschworenen Fundamente der Softwareentwicklung.</p> <p>Auch die deutliche Trennung eines Softwaresystems von der Umwelt durch eine explizite Membran ist nicht das Problem. Sie dient dazu, dass Softwaresystem im Sinne des SRP zu fokussieren und von äußeren Einflüssen zu entkoppeln.</p> <p>An einer holarchischen Sicht, die ohnehin von den meisten Modellen nicht thematisiert wird, kann es auch nicht liegen. Im Gegenteil: Ich denke, mehr davon würde der Softwareentwicklung helfen. Sie macht die Zerlegung von Kompliziertem einfacher, weil die Zerlegungsebenen immer wieder mit denselben Mitteln beschrieben werden.</p> <p>Was bleibt sind also die Abhängigkeiten.</p> <p>Ja, ich denke, dass die funktionalen Abhängigkeiten zwischen inhaltlichen Verantwortlichkeiten das Problem sind. Logische Kopplung lässt sich nicht vermeiden. Die jedoch mit funktionaler Kopplung auszuweiten, öffnet der Ausbreitung von Veränderungen Tür und Tor.</p> <p>Alle Architekturmodelle kranken an funktionalen Abhängigkeiten. Dabei ist es egal, ob die von links nach rechts oder oben nach unten verlaufen. <em>Funktionale Abhängigkeiten sind böse!</em></p> <p>Das wissen Sie aus Ihrem täglichen Leben: Solange Sie eine Aufgabe allein erledigen können, ist alles gut. Die Schwierigkeiten explodieren, sobald Sie davon abhängig sind, dass Ihnen jemand etwas zuliefert. Sie verlieren damit die Hoheit über die Erledigung. Wenn etwas nicht klappt, interessiert es den Abnehmer Ihrer Leistung nicht, ob Sie das zu verschulden haben oder Ihr Zulieferer. Sie sind Verantwortlich für das Ergebnis. Und schon fängt das Micro-Management an. Und schon seufzen Sie unablässig, “Wenn man nicht alles selbst macht…”</p> <h2>Inhaltsunabhängige Verantwortlichkeiten</h2> <p>Um aus dem Problem der funktionalen Abhängigkeiten zwischen inhaltlichen Modulen herauszukommen, schlage ich nun ein neues Architekturmodell vor. Es unterscheidet sich sehr grundlegend von den vorgestellten - aber genau das macht seinen Charme aus, finde ich. Aber der Reihe nach…</p> <h3>Unabhängige Module</h3> <p>Aus den funktionalen Abhängigkeiten kann man sich nicht herausdefinieren. Schichtenmodell wie Clean Architecture leiden gleichermaßen unter ihnen. Da hilft keine Änderung der Ausrichtung der Abhängigkeiten. Nicht die Richtung ist entscheidend, sondern ihre schiere Existenz.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-k91ef5Whuj0/VSlTbTk_ubI/AAAAAAAAFEM/z-ebmb5mF_c/image%25255B21%25255D.png?imgmax=800" width="289" height="168"></p> <p>Das bedeutet, eine bessere Architektur muss funktionale Abhängigkeiten komplett abschaffen. Welche Verantwortlichkeiten man auch identifizieren mag, die Module, in die man sie kapselt, sollten unabhängig von einander sein.</p> <p>Auf das Schichtenmodell bezogen würde das bedeuten: Presentation Layer, Business Logic Layer und Data Access Layer haben keine funktionalen Beziehungen zu einander. Keine. Nicht direkt, nicht indirekt. Sie kennen sich nicht einmal.</p> <p>Solche Module nenne ich <em>Operationen</em>.</p> <h3>Verbindende Daten</h3> <p>Natürlich können Operationen nicht komplett unabhängig von einander sein. Dann könnte man aus ihnen ja nichts Größeres zusammensetzen. Aber funktionale Abhängigkeiten im Sinne von request/response Dienstleistungsaufrufen gibt es nicht.</p> <p>Stattdessen kommunizieren die Operationen mittels Nachrichten. Sie tauschen also Daten aus. Und sie können auch Zustand, sogar gemeinsamen haben. Das heißt, Operationen sind von <em>Daten</em> abhängig.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-44PgZ3mz1qA/VSlTcPOCyfI/AAAAAAAAFEU/_JA96Ys5ljE/image%25255B29%25255D.png?imgmax=800" width="463" height="142"></p> <p>In der Objektorientierung können Daten allerdings selbst wieder Funktionen anbieten. Sind Operationen dann nicht von diesen doch funktional abhängig?</p> <p>Technisch ist das richtig: Logik<a id="fnref:3" class="footnote" title="see footnote" href="#fn:3">[3]</a> in einer Operation ruft Logik in Daten auf.</p> <p>Doch “inhaltlich” ist das für mich nicht gravierend. Die Logik in Daten ist ja dünn. Sie bezieht sich nur auf die Daten selbst, dient nur der Strukturherstellung und Konsistenz. Domänenlogik hat nichts in Daten zu suchen.</p> <p>Daten sind für mich auf einer Stufe mit APIs. Die müssen Operationen ja auch benutzen können. Daran lässt sich nichts ändern. Am besten deshalb, wenn APIs Black Boxes sind. Dann können sich Operationen nicht an ihre Interna koppeln. Dasselbe gilt für Daten. Datenstrukturen sind selbstgeschriebene APIs zur Verwaltung von Speicher. Wie eine Liste oder Queue oder ein Baum aus einem Framework, den Operationen nutzen.</p> <h3>Angezogene APIs</h3> <p>Operationen können nicht funktional unabhängig sein. Sie können ja nicht alle Logik selbst schreiben, die nötig ist, um Verhalten zu erzeugen. Sie müssen auf die Schultern von Riesen steigen, um Daten zu persistieren, Grafiken zu animieren, zu drucken, zu komprimieren, zu verschlüsseln, zu kommunizieren usw.</p> <p>Die Logik von Operationen muss sich deshalb abhängig machen von _API_s aller Art, die solche Dienstleistungen anbieten.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-Pe4phq-K0vQ/VSlTcWDP8xI/AAAAAAAAFEc/xekLftZ4Eoc/image%25255B36%25255D.png?imgmax=800" width="407" height="149"></p> <p>APIs kapseln Logik, anderer Leute Logik ;-) Für die nutzenden Operationen sind sie Black Boxes des notwendigen Logik-Übels. Denn wenn sich an der Implementation von APIs etwas ändern, dann muss Operationslogik u.U. nachgezogen werden.</p> <h3>Integrierte Prozesse</h3> <p>Auch wenn Operationen von Daten abhängig sind, kennen sie einander nicht. Es fehlt ihnen der funktionale Zusammenhalt, der nötig für das Gesamtverhalten eines Softwaresystems ist.</p> <p>Den herzustellen ist nun eine ganz eigene Verantwortlichkeit. Die herauszustellen ist zentral für meinen Architekturmodellvorschlag.</p> <p>Es braucht eine Instanz, die unverbundene Einzelteile zu einem Ganzen zusammensetzt. Diese Leistung nenne ich <em>Integration</em>.<a id="fnref:4" class="footnote" title="see footnote" href="#fn:4">[4]</a> Einzelteile werden in und zu etwas größerem integriert.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-Iv4X3ukBLX8/VSlTc5R3MkI/AAAAAAAAFEk/4hwArYcr8uc/image%25255B68%25255D.png?imgmax=800" width="454" height="353"></p> <p>Für die Integration sind ebenfalls Module zuständig. Doch die enthalten keine Logik. Sie sollen nicht selbst mit Logik verhalten herstellen, sondern fügen andere Logik (Operationen) lediglich so zu Prozessen zusammen, dass in Summe Verhalten entsteht. Ohne Logik sind diese Prozesse nicht imperativ, sondern deklarativ; die Darstellung erfolgt in Form von Datenflüssen.</p> <p>Im Sinne des SRP halte ich das für sehr konsequent. Integration ist eine ganz eigene Verantwortlichkeit, wie Operation zu sein oder Daten zu strukturieren.</p> <p>Integrationsmodule sind zu diesem Zweck abhängig von Operationen, d.h. sie kennen sie, um sie “zusammenstecken” zu können. Doch eine funktionale Abhängigkeit besteht nicht. Denn Integrationen enthalten keine Logik.</p> <h2>Die IODA Architektur</h2> <p>Haben Sie es bemerkt? Die Module, von denen ich bisher gesprochen habe - Integration, Operation und auch Daten -, haben keinen inhaltlichen Bezug mehr. Das Architekturmodell, welches ich vorschlage, interessiert sich nicht dafür, ob sie ein Modul View nennen oder Business Logic oder Adapter oder Portal oder Use Case usw.</p> <p>Die Verantwortlichkeiten des Architekturmodells sind orthogonal dazu. Und sie sind viel universeller.</p> <p>Ich nenne es die <em>IODA Architektur</em>, weil damit seine Bestandteile in Richtung der Abhängigkeiten benannt sind.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-VN9jIkfjGwk/VSlTdR4lNkI/AAAAAAAAFEs/qFMekxNNpcQ/image%25255B50%25255D.png?imgmax=800" width="473" height="390"></p> <p>In dieser Architektur gibt es Abhängigkeiten. Ohne Kopplung kein Verhalten erzeugt durch mehrere Beteiligte. Aber die sind unterschiedlich stark funktional. Vor allem fehlen aber funktionale Abhängigkeiten zwischen den “Arbeitspferden”, den Operationen. Sie tragen die Logik-Last eines Softwaresystems.</p> <p>Auch diese Struktur ist wieder rekursiv zu verstehen. Jedes Modul kann, wenn seine Aufgabe zu umfangreich wird, wieder nach IODA zerlegt werden. Das gilt insbesondere für Operationen.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-SDrMSKFPpG8/VSoDVKrUh0I/AAAAAAAAFFM/8Pw2Ymo_exg/image%25255B14%25255D.png?imgmax=800" width="297" height="403"></p> <h3>Zusammenfassung</h3> <p>Das unausgesetzte Problem des unwartbaren Codes wird nicht gelöst, in dem wir inhaltliche Module immer wieder neu in funktionale Abhängigkeiten verstricken. Ich bin davon überzeugt, wie müssen diesen ausgetretenen Pfad verlassen. Das Pferd der funktionalen Abhängigkeitshierarchien ist totgeritten.</p> <p>Stattdessen müssen wir uns auf grundlegende und universelle Verantwortlichkeiten besinnen und die weitgehend unabhängig halten. Das geschieht durch “ausbluten” von Datenstrukturen, d.h. Modulen, die Daten <em>sind</em>. Sie dürfen nur minimale Logik enthalten. Und das geschieht durch die Konzentration von Logik in Operationen, die einander nicht kennen (vgl. <a href="http://blog.ralfw.de/2012/12/prinzip-der-gegenseitigen-nichtbeachtung.html">Prinzip der gegenseitigen Nichtbeachtung</a>).</p> <p>Dem Metamodell von Software muss das, was getan wird, egal sein. Welche Operationen, welche Daten es gibt, ist unwichtig. Aber dass es Operationen und Daten gibt, dass Operationen durch spezielle Instanzen zu einem Ganzen integriert werden, <em>das</em> kann dem Metamodell nicht egal sein.</p> <p>So entsteht <strong>Software als Summe von Prozessen, deren Schritte in Operationen implementiert sind, die Daten konsumieren und produzieren unter Zuhilfenahme von APIs.</strong></p> <p>Wenn das keine allgemeingültige Beschreibung jeder Art von Software ist, dann weiß ich auch nicht mehr ;-)</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Für mich sind Module Container für Code zur Entwicklungszeit zum Zwecke der Entkopplung. Logik in Modulen zusammenzufassen kapselt sie, um höhere Wandelbarkeit zu erzielen. Mit “Modul” meine ich kein Sprachkonstrukt einer speziellen Programmiersprache, sondern jedes Mittel, um Logik zu bündeln und Teile von ihr von außen unzugänglich zu machen. Unterprogramme sind insofern genauso Module wie Klassen oder Bibliotheken. <a class="reversefootnote" title="return to article" href="#fnref:1">↩</a></p> <li id="fn:2"> <p>Mit dem Schichtenmodell oder MVC ist eine solche Zerlegung nich möglich. Mit der Hexagonalen Architektur oder auch Onion/Clean Architecture wäre die selbstähnliche hierarchische Zerlegung jedoch denkbar - nur habe ich sie in der Literatur bisher nicht beschrieben gesehen. <a class="reversefootnote" title="return to article" href="#fnref:2">↩</a></p> <li id="fn:3"> <p>Logik sind für mich der Code, der Verhalten herstellt. Das sind Transformationen/Ausdrücke, Kontrollanweisungen und Hardware-/API-Zugriffe. <a class="reversefootnote" title="return to article" href="#fnref:3">↩</a></p> <li id="fn:4"> <p>Manchmal denke ich auch, es handelt sich um Komposition oder Koordination. Aber “Integration” war irgendwie zuerst als Begriff in meinem Kopf, so dass ich ihn nun stehenlasse. <a class="reversefootnote" title="return to article" href="#fnref:4">↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com40tag:blogger.com,1999:blog-6090483181455953305.post-16887475481612757412015-04-10T16:45:00.001+02:002015-04-10T16:45:06.549+02:00Die Selbstlern-Challenge - Retrospektive<p>Zehn Wochen sind wie im Flug vergangen, seit ich zur Teilnahme an einer <a href="http://blog.ralfw.de/2015/01/die-selbstlern-challenge-mitmachen-und.html">Selbstlern-Challenge</a> eingeladen hatte.</p> <h2>Das Angebot</h2> <p>Die Herausforderung war, sich selbstständig über einen Zeitraum von 10 Wochen in das Thema Flow Design & Co einzuarbeiten. Einzige Bedingung: Als Dokumentation des Dranbleibens am Thema sollte mir jede Woche eine Frage per Email geschickt werden - die ich dann selbstverständlich auch beantwortet habe.</p> <p>Zehn Teilnehmer hatte ich gesucht und in weniger als 24 Stunden auch gefunden. War das ernsthaftes Interesse am Thema? Oder vielleicht doch nur Interesse am “Preisgeld”? Jedem der durchhält, hatte ich einen 50€ Amazon-Gutschein versprochen. Wie sich herausstellte, waren solche Überlegungen unbegründet. Wer dabei geblieben ist, hat sich intensiv mit dem Thema auseinandergesetzt. Zwei Teilnehmer schrieben sogar, sie seien an dem Gutschein gar nicht interessiert.</p> <p><strong>Erkenntnis #1:</strong> Beim nächsten Mal werde ich zur Wahl stellen, das “Preisgeld” ausgezahlt zu bekommen oder es zu spenden.</p> <p>Warum hatte ich überhaupt ein “Preisgeld” ausgesetzt? Weil ich einen zusätzlichen Anreiz zum Mitmachen bieten wollte. Der sollte nämlich hoch sein, um meine Hypothese zu bestätigen. Bevor ich die aber erläutere hier erstmal die “Gewinner”…</p> <h2>Die “Gewinner”</h2> <p>Von 10 Teilnehmern haben 5 durchgehalten. Der Austausch mit ihnen war unterschiedlich intensiv. Beim einen waren es über 80 Emails, die zwischen uns hin und her gingen, beim anderen nur 4, dafür aber noch Chats in Slack.</p> <p><strong>Erkenntnis #2:</strong> Veränderungen während des Challenge vermeiden. Als ich nach einigen Wochen Slack als weiteres Kommunikationsmedium angeboten habe, kam es zu einigen Irritationen. Manche nahmen diesen neuen Kanal freudig auf und haben sich auch untereinander darüber ausgetauscht. Andere waren verwirrt bis verärgert und wähnten eine unlautere einseitige Vertragsänderung. Dabei wollte ich doch nur nett sein… Aber so kann es gehen. Deshalb: Wenn die Sache einmal läuft, Füße stillhalten.</p> <p>Ach, ja, die “Gewinner”. Die gab es natürlich nicht, weil es nichts zu gewinnen gab. Es war ja kein Wettbewerb. Eher sollte es wohl heißen, die “Durchhalter” oder “Finisher”. Gewinner waren alle inklusive mir. Denn wir haben einiges gelernt - auch die, die nicht durchgehalten haben. Hoffentlich.</p> <p>Über die Ziellinie haben sich diese 5 Teilnehmer gefragt:</p> <ul> <li>Manuel Beetz</li> <li>Benjamin Beisner</li> <li>Karsten Peiler</li> <li>Max Schmidt</li> <li>Benjamin Seblu</li></ul> <p>Herzlichen Glückwunsch! Die Gutscheine sind schon verschickt.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-8mFWzsEgkys/VSfh73j8o6I/AAAAAAAAFDs/5_SSJd054ZQ/image%25255B5%25255D.png?imgmax=800" width="380" height="254"></p> <p>Leider war die Auswertung nicht ganz so einfach, wie gedacht. Zuerst hatte ich mir noch aufgeschrieben, wer wann eine Frage gestellt hat. Doch im Eifer der Email-Kommunikation ist das dann nicht mehr so klar gewesen. Wann war eine Frage <em>die</em> Wochenfrage, wann nur eine weitere? Am Ende musste ich also die ganze Kommunikation nochmal durchsehen und habe sogar die Teilnehmer gebeten, das nochmal zu prüfen.</p> <p><strong>Erkenntnis #3:</strong> Zumindest die Einreichung der wöchentlichen Frage sollte stärker formalisiert sein. Solange die Erfolgsbedingungen so einfach sind und von normaler Kommunikation kaum unterscheidbar, braucht es dafür einen Rahmen. Es hätte gereicht zu fordern, dass die Wochenfrage in einer Email mit einem Betreff geschickt wird, in dem die Fragennummer steht, z.B. “Selbstlern-Challenge Frage #3”.</p> <h2>Die Hypothese</h2> <p>Die Teilnehmer haben immer wieder mal gefragt, was denn meine Hypothese gewesen sei. Und auch Sie mögen sich gefragt haben, warum da einer bereit ist, 500€ dafür zu bezahlen, dass man ihm 100 fragen stellt. Müsste es nicht umgekehrt sein? :-)</p> <p>Ja, als Geschäftsmodell taugt der Ansatz nicht wirklich. War ja aber auch so nicht gedacht. Ich habe vielmehr in Forschung investiert. Ich wollte herausfinden, ob meine Ansicht über das autodidaktische Lernen in unserer Branche “korrekt” ist.</p> <p>Eine wissenschaftliche Studie ist das nun zwar nicht geworden, aber ich denke, eine Antwort habe ich dennoch bekommen. Hier meine Ausgangshypothese:</p> <blockquote> <p>Ich glaube nicht daran, dass Entwickler autodidaktisch eine Methode wie Flow Design & Co neben ihrem Job lernen können.</p></blockquote> <p>Diese Hypothese hatte sich in mir über längere Zeit gebildet. Das wurde mir besonders bei einem Seminar Ende letzten Jahres bewusst. Da sagte ein Teilnehmer beim abschließenden Feedback, er fände den Ansatz gut, könne ihn aber frühestens in 2–3 Monaten in einem nächsten Projekt anbringen. Darauf erwiderte ich, er müsse schauen, dass er bis dahin im Thema drin bliebe, er müsse für sich weiter üben. Und der Teilnehmer sagte selbstgewiss, das würde er selbstverständlich. Damit hätte er Erfahrung.</p> <p>Das war zu schön zu hören, um wahr zu sein. Deshalb schlug ich vor, er könne mir doch jede Woche als Resultat seines Übens eine Frage schicken. Das Angebot nahm er allerdings nur halbherzig an. Und dann bin ich gemein geworden: Ich habe ihm 2 Monate lang alle 2 Wochen eine Email geschickt und freundlich nachgefragt. Darauf hat er einmal geantwortet - und dann nicht mehr. Für mich bedeutet das: Er hat nicht geübt. Er hatte sich schlicht überschätzt. Guten Willen möchte ich ihm nicht absprechen. Nur nützt der nichts, wenn er nicht umgesetzt wird.</p> <p>Als ich damit meine Hypothese als bestätigt zur Ruhe betten wollte, habe ich dann aber doch ein schlechtes Gewissen bekommen. Deshalb der Selbstlern-Challenge.</p> <p>Mit dem Challenge wollte ich herausfinden, ob nicht sogar unter günstigeren Bedingungen das autodidaktische Lernen fehlschlägt. Aber nochmal zur Präzisierung: Die Hypothese bezieht sich auf das Lernen einer Methode, d.h. von etwas, bei dem man, wenn man es anwendet, relativ schlecht Feedback bekommt.</p> <p>Wer sich autodidaktisch einen API beibringen will oder ein Tool lernt, der bekommt sofort bei der Anwendung Feedback. Was er tun will klappt oder nicht. Wenn es nicht klappt, kann das natürlich frustrierend sein. Aber meist klappt zumindest so viel, dass es relativ leicht ist, dran zu bleiben. Dann wird man besser und sucht nach Wegen, es in der Praxis anzuwenden.</p> <p>Bei Methoden wie TDD, agilem Vorgehen, einem neuen Sprachparadigma oder eben auch Entwurfsansätzen wie Flow Design (oder das gute alte OOD) ist das jedoch anders. Ob man es gut macht, lässt sich nicht sofort ablesen. Es braucht größere Übungen und mehr Zeit, um Effekte festzustellen. Zumindest, wenn man autodidaktisch lernt. Lernt man mit Trainer, bekommt man sofort Feedback.</p> <p>Dass es mit dem autodidaktischen Lernen nicht einfach ist, hatte ich ja schon <a href="http://blog.ralfw.de/2014/10/regelmaiges-lernen-meine-retrospektive.html">in einem Selbstversuch demonstriert</a>.</p> <p>Der Selbstlern-Challenge hat es den Teilnehmern jedoch einfacher machen wollen. So gemein bin ich also doch nicht, oder? ;-) Nicht nur habe ich ein “Preisgeld” ausgesetzt, ich habe mich auch als Accountability Partner zur Verfügung gestellt. Ich habe also meiner Hypothese quasi ein Bein gestellt.</p> <p>Dennoch war das Ergebnis offen…</p> <h2>Die Auswertung</h2> <p>Ist meine Hypothese nun falsifiziert worden? Hm… Um ehrlich zu sein, mit 50% “Gewinnern” hatte ich nicht gerechnet. 2–3 wären mir lieber für meine Hypothese gewesen ;-) Aber besser 50% als 90% sage ich mir nun.</p> <p>Man kann die 50% natürlich so oder so auslegen.</p> <p>a) Es haben mehr Teilnehmer durchgehalten als erwartet. Die Hypothese kann also nicht wahr sein. Autodidaktisches Lernen ist in der Branche kein Problem auch für Methoden. Hypothese falsifiziert. b) Es haben 50% der Teilnehmer nicht durchgehalten. Das ist ein großer Prozentsatz, der umso stärker zu bewerten ist, da es zusätzliche Anreize und Unterstützung gab. Im Grunde war das Lernen gar nicht ganz autodidaktisch. Echt autodidaktisches Lernen wird mit einer noch höheren Abbrecherquote belegt sein. Hypothese nicht falsifiziert.</p> <p>Hm… Was nun?</p> <p>Sie werden es mir nicht verdenken, ich tendiere zu Erklärung b). Meine Gründe:</p> <ol> <li>Die Teilnahme war echt freiwillig. Hier war also die intrinsische Motivation sehr hoch.</li> <li>Das Durchhalten wurde explizit belohnt. Der Effekt eines “Preisgeldes” mag nicht groß gewesen sein, aber ich würde ihn auch nicht ignorieren.</li> <li>Die Pflicht, mir jede Woche “Rechenschaft abzulegen” hat sicher einen Zug ausgeübt. Da war jemand, der sich erstens dafür interessiert, das man voranschreitet, und der zweitens enttäuscht werden konnte.</li> <li>Zu den Bedingungen gehörte, dass ich alle Teilnehmernahmen nennen darf. Es bestand also die Möglichkeit, als Abbrecher öffentlich gemacht zu werden.</li> <li>Es musste nicht nur aus Texten gelernt werden, sondern da war jemand, der einem über Verständnishürden hinweggeholfen hat. Das macht Lernen einfacher und somit motivierender.</li></ol> <p>In Summe sind das so viele “Hilfestellungen” für das autodidaktische Lernen, dass mir eine 50% Abbrecherquote hoch erscheint und ohne solche “Unterstützung” noch viel höher gelegen hätte.</p> <p>Bottom line: Autodidaktisches Lernen ohne Förderung und Forderung funktioniert nicht in unserer Branche. Mit Förderung meine ich, dass Unterstützung gegeben wird in Form von Zeit und anderen Ressourcen. Mit Forderung meine ich, dass die Nutzung der Förderung eingefordert werden muss. Jemand muss daran ziehen. Sonst vertrocknet die Förderung ungenutzt aus verschiedenen Gründen. Ohne Nachfragen wird anderes nach einer initialen Hochmotivationsphase schnell wichtiger. Damit bleibt das Lernen trotz der (passiven) Förderung auf der Strecke.</p> <p><strong>Erkenntnis #4:</strong> Wer sagt, “Ach, ich bleibe schon dran am Thema…” der überschätzt sich sehr wahrscheinlich. Es braucht einen echten Plan, wie man Lernstoff außerhalb einer Seminarumgebung tatsächlich weiter übt und dann in die Anwendung kommt. Ist der nicht kristallklar im Hinblick auf fördernde und fordernde Elemente, dann liegt Wunschdenken vor.<a id="fnref:1" class="footnote" title="see footnote" href="#fn:1">[1]</a></p> <h2>Fazit</h2> <p>Die 10 Wochen haben Spaß gemacht. Es war schön, mit motivierten Teilnehmern zu arbeiten. Das hat mich weitergebracht. Ich habe wieder etwas mehr über Flow Design gelernt. Aber ich habe auch etwas über <em>distance learning</em> gelernt.</p> <p><strong>Erkenntnis #5:</strong> Nur eine Frage als Zeichen des Fortschritts zu erwarten, ist zu wenig. Es braucht etwas mehr methodische Anleitung für die Teilnehmer. Ein “Challenge-Tagebuch” fällt mir da ein, ein Portfolio und zumindest für Meilensteine im Lernstoff konkrete Aufgaben.</p> <p>Auch wenn ich meine Hypothese bestätigt finde, bin ich nicht frustriert. Ich denke, es wurde etwas deutlicher, wie Angebote für das selbstständige Lernen aussehen müssen. Denn nur das skaliert am Ende. Wer möchte, dass sich eine Methode verbreitet, muss als Lehrer aus dem Weg treten, sonst ist er ein Nadelöhr.</p> <p>Aber wohin treten? Darüber habe ich etwas gelernt. Herzlichen Dank an alle Teilnehmer, dass sie dabei mitgeholfen haben!</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Das behaupte ich nun so apodiktisch, um die für mich deutliche Tendenz klar zu machen. Ich will nicht sagen, dass niemand so lernen kann. Sicher gibt es den einen oder anderen… nur habe ich von denen noch nicht viele gesehen. Und gerade die, die es von sich laut behauptet haben, sprangen eher zu kurz. Autodidaktisches Lernen einer Methode ist so gut oder schlecht möglich, wie als Kettenraucher ein hohes Alter zu erreichen. Es gibt Beispiele davon - nur würde ich die nicht zur Nachahmung bei der Lebensplanung oder Kompetenzausbildung empfehlen. <a class="reversefootnote" title="return to article" href="#fnref:1"> ↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com11tag:blogger.com,1999:blog-6090483181455953305.post-47665465708527637482015-04-06T16:23:00.001+02:002015-04-06T16:23:33.955+02:00Entwickeln im Uhrzeigersinn<p>Was ist der Unterschied zwischen Software Craftsman und Software Engineer? Darüber kann man natürlich lang und trefflich debattieren. Doch mit den <a href="http://blog.ralfw.de/2015/04/unschatzbare-arbeitsweisen.html">von mir vorgestellten Arbeitsweisen</a>, ist die Unterscheidung einfach und augenfällig, glaube ich.</p> <p>Wie beschrieben, arbeiten wir als Softwareentwickler sowohl als Handwerker (H) wie als Ingenieure (I) und auch als Forscher (F).</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-HcT4PGLviYM/VSKW15l_PoI/AAAAAAAAFCg/PEIGOm8FiAI/image%25255B4%25255D.png?imgmax=800" width="240" height="168"></p> <h2>Arbeitsweisenverhältnisse</h2> <p>Allerdings sind die Anteile der drei Arbeitsweisen nicht gleich. Für mich dominieren I und F; H macht den kleinsten Teil aus.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-wDv1an8uZLc/VSKW2QDQ84I/AAAAAAAAFCo/RLMDNMt6qCg/image%25255B9%25255D.png?imgmax=800" width="240" height="152"></p> <p>Der tapfere <strong>Software Engineer</strong> wird das aber noch etwas anders sehen. Für ihn wird der Entwurf eine größere Rolle spielen als Forschung oder Codierung. Codieren kann man lassen und Forschung, z.B. beim Bug Fixing, ist mit guter Entwurfsvorarbeit nicht so häufig nötig, oder?</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-yj8UYEMjwqg/VSKW2wMz0qI/AAAAAAAAFCw/L-PL1j8qiN8/image%25255B15%25255D.png?imgmax=800" width="156" height="159"></p> <p>Das steht im Gegensatz zur Sicht der eher haptisch veranlagten <strong>Software Craftsmen</strong>, denke ich. Den Löwenanteil der Arbeit hält man dort für handwerklich. Warum sollte man sich sonst “Craftsman” nennen?</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-PfVlp_49hHw/VSKW3VR5YtI/AAAAAAAAFC0/sCIh4Wls7DU/image%25255B21%25255D.png?imgmax=800" width="156" height="159"></p> <p>Forschung wird man auch noch groß schreiben (müssen), weil Anforderungsanalyse und Code-Analyse nicht zu läugnen sind. Doch der Entwurf, allemal der explizite, steht im Hintergrund. Am Ende spricht ohnehin nur der Code die Wahrheit, oder?</p> <p>Eine unterschiedliche Einschätzung des Mischungsverhältnisses scheint mir eine erste augenfällige Differenz zwischen den Lagern der Engineers und der Craftsmen.</p> <p>Ein anderer die bevorzugte Bewegungsrichtung durch die Arbeitsweisen.</p> <h2>Arbeitsweisenreihenfolge</h2> <p>Software Craftsmen favorisieren TDD, um nicht in die BDUF-Falle zu geraten. Das scheint handwerklicher als ein ingenieursmäßiger Entwurf vorab. Doch damit entkommen sie dem Thema Planung nicht. Sie verschieben es nur. Für mich bewegt sich der <strong>Software Craftsman</strong> bevorzug gegen den Uhrzeigersinn durch die Arbeitsweisen:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-KqnM0iy_Sdw/VSKW3-NObOI/AAAAAAAAFC8/W70XOXbtaHs/image%25255B27%25255D.png?imgmax=800" width="165" height="168"></p> <p>Am Anfang steht Forschung. Anforderungen müssen analysiert werden. Daraus ergeben sich Tests in rot (F). Die werden im nächsten Schritt handwerklich möglichst einfach (KISS) auf Grün gebracht (H). Und daran schließlich sich dann eine Refaktorisierung. Für die muss man jedoch einen Entwurf haben (I). Denn so handwerklich Refaktorisieren in einer IDE aussehen mag, ohne Vorstellung von einer Zielstruktur geht es nicht. Die aber ist Ingenieursarbeit.</p> <p>Der <strong>Software Engineer</strong> denkt da anders. Er bewegt sich mit dem Uhrzeigersinn durch die Arbeitsweisen:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-ajksvIkfU1I/VSKW4itOurI/AAAAAAAAFDI/E7dTfTQL_XU/image%25255B33%25255D.png?imgmax=800" width="173" height="177"></p> <p>Auch bei ihm steht die Forschung am Anfang. Anforderungen in Form eines Lastenheftes müssen analysiert werden. Das Ergebnis ist ein Pflichtenheft (F). Dafür wird im nächsten Schritt ein Lösungsentwurf erarbeitet (I); UML ist dafür als Werkzeug gedacht. Und erst am Ende steht eine Implementierung des Entwurfs (H).</p> <h2>Arbeitsweisenfrequenz</h2> <p>Ein weiteres Unterscheidungskriterium im Hinblick auf das “Arbeitsweisenrad” scheint mir die Geschwindigkeit, mit der Software Engineers und Software Craftsmen es drehen. Die Engineers drehen es langsamer als Craftsmen.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-wmr9nF7D6wY/VSKW5GsdwgI/AAAAAAAAFDM/letugPw4mgk/image%25255B40%25255D.png?imgmax=800" width="368" height="309"></p> <p>Nicht, dass Engineers keine Iterationen kennen würden. Aber Sie glauben daran, dass man durch Forschung und Entwurf ein größeres Rad drehen kann. Craftsmen hingegen sind erpicht auf Feedback vom Kunden. Deshalb favorisieren sie schnellere Drehungen.</p> <h2>Zusammenfassung</h2> <p>Kein Wunder, wenn sich Software Engineers und Software Craftsmen immer wieder sprachlos gegenüberstehen, oder? Das wussten Sie natürlich schon vorher ;-) Aber ich hoffe, durch die Brille der Arbeitsweisen HIF sehen Sie nun deutlicher, woran das liegt. So lassen sich die unterschiedlichen Positionen besser kommunizieren, finde ich. Der Blick ist differenzierter.</p> <p>Die genauen Prozentzahlen der Arbeitsweisen, sind dabei nicht so wichtig. Es geht um die groben Verhältnisse. Ohnehin verschieben die sich nach Projekt und Anforderungen auch immer wieder etwas. Deshalb zählt die Tendenz.</p> <p>Durch diese Aufschlüsselung habe ich für mich z.B. realisiert, dass ich weder Software Engineer noch Software Craftsman bin. Ich hänge irgendwo dazwischen:</p> <ul> <li>Für mich dominiert weder I noch F, aber H hat definitiv den kleinsten Anteil.</li> <li>Für mich dreht sich die Softwareentwicklung im Uhrzeigersinn.</li> <li>Für mich dreht sich das Rad im wesentlichen alle 4 bis 16 Stunden. Das ist der wichtigste Zyklus, um ein Inkrement herzustellen (d.h. einen feedbackfähigen Codezuwachs). Innerhalb dessen kann es kürzere TDD-Iterationen geben - muss es aber nicht. Oberhalb dessen kann es längere Release-Iterationen geben - muss es aber nicht.</li></ul> <p>Und wenn der nächste Selbstverständnis-Hype aufkommt… dann haben Sie nun ein kleines System, mit dem sie ihn analysieren können.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com2tag:blogger.com,1999:blog-6090483181455953305.post-83902780147705076952015-04-04T10:11:00.001+02:002015-04-04T10:11:30.582+02:00Unschätzbare Arbeitsweisen<p>Wer über das Thema Schätzen reden will, muss zunächst eine klare Vorstellung davon haben, was denn da eigentlich geschätzt werden soll. Das ist interessanterweise aber nicht der Fall.</p> <p>Viel wird über Anforderungen gesprochen. Aber wenig über die Arbeit, die die Anforderungen in lauffähigen Code transformieren soll. Das scheint nicht nötig, weil es doch sonnenklar ist: das ist Codierung. Und in der Codierung haben die Entwickler doch viel Erfahrung. Das ist ihr Job. Also sollten sie auch schätzen (oder eher berechnen) können, wie lange die Umsetzung der nächsten Anforderungen dauert.</p> <p>Nichts könnte jedoch weiter von der Realität entfernt sein. Es ist zwar richtig, dass Softwareentwickler “Männer, die auf Code starren” sind - doch deshalb ist Softwareentwicklung nicht gleichzusetzen mit Codierung, d.h. mit dem Schreiben von Code.</p> <p>Manager, Kunden, Laien, selbst Softwareentwickler haben ein zu simples Verständnis für das, was Softwareentwicklung ist. Kein Wunder, dass sich aus dem dann eine Forderung ableitet, die nicht zu erfüllen ist, nämlich die der Vorhersage von Aufwänden für die Umsetzung von Anforderungen.</p> <p>Und leider tut die Softwareentwicklung nicht viel dafür, ihr Bild zu korrigieren. Wer sich “Software Craftsman” nennt, darf sich nicht wundern, wenn man von ihm wie von jedem anderen Handwerker ein genaues Angebot haben will. Da nützt die ganze Beschwörung von Qualität und Berufsehre nichts. Selbstverständlich sollen Handwerker Qualität liefern - aber bitteschön zum vorher festgelegten Termin und fixen Kosten.</p> <p>Wenn das der Software-Handwerker nicht schafft… dann ist die Enttäuschung verständlicherweise groß. Dabei kann es nicht anders gehen. Der Software-Handwerker muss in dieser Hinsicht enttäuschen. Das liegt in der Natur seiner Arbeit. Er ist nämlich kein Handwerker. Das muss er nur selbst verstehen.</p> <h2>Weisen der Arbeit</h2> <p>Alle Arbeit ist nicht gleich. Nicht nur die Bandbreite ihrer Inhalte ist riesig. Sie unterscheidet sich auch noch fundamentaler in der Weise, wie sie verrichtet wird. Damit meine ich nicht schnell oder sorgfältig, sondern noch grundlegender eine Haltung, einen Anspruch, einen Zweck.</p> <p>Die uns vertrauteste Arbeitsweise ist die, bei der ein Auftrag zügig und geradlinig umgesetzt wird. Da gibt es kein Zögern, da ist alles klar, da wird zugepackt und das Ergebnis nach allen Regeln der Kunst hergestellt. So stellt ein Bäcker Brötchen her, so repariert ein Schuster Schuhe, ja, selbst ein Musiker spielt so ein Repertoirestück.</p> <p>Diese Arbeitsweise nenne ich handwerklich. Als <strong>Handwerker</strong> sind Vorgabe und Ziel klar. Ebenso klar ist es für den Handwerker, mit welchen Methoden, Materialien und Werkzeugen er sie umsetzt.</p> <p>Handwerker sind dabei für mich jedoch nicht nur Berufstätige mit einem Gesellen- oder Meisterbrief. Nein, jeder Mensch ist Handwerker. Immer wieder über den Tag verteilt. Wenn Sie morgens ein Brot schmieren, dann sind sie Handwerker. Wenn Sie Wäsche waschen, sind Sie Handwerker. Selbst wenn Sie Ihrem Kind etwas vorlesen, sind Sie Handwerker.</p> <p>Handwerker haben ein Handwerk gelernt. Sie haben im Umgang mit Methoden, Materialien und Werkzeugen in unterschiedlichsten Situationen Erfahrungen gesammelt. So ist die nächste Situation für sie kaum eine Überraschung. Sie wissen, was zu tun ist.</p> <p>Die Aufgabe des Handwerkers ist es, Vorgaben/Pläne/Entwürfe in nutzbare Ergebnisse zu überführen. Handwerker stellen her. Das sogar immer wieder. Sie sind grundlegend reproduzierend tätig. Sogar so sehr, dass sich ihre Arbeit erst taylorisieren und dann automatisieren lässt. Industrielle Fertigung ist Handwerk on steroids.</p> <p>Aber natürlich sind wir nicht den ganzen Tag Handwerker. Das können wir nämlich nur sein, wenn erstens die Vorgaben klar sind und wir zweitens für die Umsetzung viel Erfahrung haben. Insbesondere die Vorgaben fehlen jedoch oft. Es gibt keinen Plan.</p> <p>Planen ist jedoch eine andere Arbeitsweise als handwerkern. Sie ist fundamental kreativ. Denn planen, entwerfen, designen erschafft ein Bild von etwas Neuem. Einen Tisch nach Plan zu bauen, ist etwas anderes, als den Plan für einen Tisch zu entwerfen. Vorher war da keine Vorstellung von einem Tisch, jetzt ist sie da - zunächst nur auf Papier, aber immerhin.</p> <p>Es ist die Aufgabe von <strong>Ingenieuren</strong>, zu planen, zu entwerfen, zu konstruieren. Handwerker bauen, Ingenieure “erfinden” (vlg. dazu auch <a href="http://www.amazon.de/Discussion-Method-Conducting-Engineering-Technology/dp/0195155998">“Discussion of the Method” von B. V. Koen</a>).</p> <p>Und wieder meine ich damit nicht Berufsgruppen, sondern eben Arbeitsweisen, in denen jeder Mensch Tag für Tag tätig ist. Wenn Sie Ihren Tag planen, sind Sie Ingenieur. Wenn Sie sich überlegen, wie der Weihnachtsbaum in diesem Jahr geschmückt werden könnte, sind Sie Ingenieur. Genauso, wenn Sie sich Gedanken darüber machen, wie Sie am besten ein Bewerbungsschreiben strukturieren.</p> <p>Ingenieure erdenken Neues, Handwerker manifestieren Neues. So kurz kann man es fassen.</p> <p>Beide Arbeitsweisen brauchen jedoch ein Fundament. Das besteht aus Kenntnissen, Wissen, Erfahrung. Das zu erarbeiten, braucht wiederum eine andere Arbeitsweise: das Forschen.</p> <p>Es ist die Aufgabe von <strong>Forschern</strong>, Wissen zu produzieren. Damit bringen sie jedoch nichts Neues in die Welt, sondern beschreiben vielmehr “nur”, wie die Welt ist.</p> <p>Um Forscher zu sein, muss man freilich nicht studieren. Jeder Mensch ist Forscher. Wenn Sie die Bedienungsanleitung des neuen Fernsehers studieren, forschen Sie. Wenn Sie Tagebuch schreiben, erforschen Sie sich selbst. Wenn Sie Schlittschuhlaufen lernen, forschen Sie ebenfalls.</p> <p>Lernen ist Forschung. Analyse ist Forschung. Sie können es nicht vermeiden, jeden Tag aufs neue die Welt zu erforschen. Ganz grundsätzlich ist dafür kein spezielles Werkzeug und schon gar kein Doktorgrad nötig. Blindes <em>trial and error</em> reicht aus - aber mit etwas mehr Systematik mag es schneller gehen.</p> <p>Forscher liefern die Grundlagen, Ingenieure entwerfen darauf aufbauend Neues und Handwerker stellen es her.</p> <h2>Arbeitsweisenverhältnisse</h2> <p>Vielleicht gibt es noch weitere fundamentale Arbeitsweisen. Aber auch langes Nachdenken hat sie mir nicht entdeckt. Einstweilen fühle ich allerdings auch kein Defizit. Die drei Arbeitsweisen Handwerker (H), Ingenieur (I) und Forscher (F) machen es mir leicht, Berufe und Tätigkeiten ganz unterschiedlicher Art zu erklären. Es kommt nämlich auf das Mischungsverhältnis an.</p> <p>Jede Arbeit setzt sich aus H, I, F zusammen, wie Farben sich aus unterschiedlichen Anteilen von Rot (R), Grün (G) und Blau (B) ergeben.</p> <p>Zunächst die zu den Arbeitsweisen gehörenden Berufsgruppen:</p> <ul> <li><strong>Handwerksberufe</strong>: Als Handwerksberufe - Klempner, Tischler, Bäcker usw. - bezeichnen wir solche, bei denen die Arbeit einen überwiegenden Anteil von H hat. I und F kommen auch vor, aber definieren die Arbeit nicht; der HIF-Code ist für mich (80%/10%/10%). Beispiel 1: Natürlich muss ein Bäcker, wenn er eine Hochzeitstorte backen soll, zuerst die Wünsche des Hochzeitspaares erfahren (F). Dann muss er die eine oder andere Idee zu deren Erfüllung entwickeln (I). Letztlich jedoch wird der größte Teil der Arbeit in die Herstellung fließen (H). Beispiel 2: Der KfZ-Mechaniker muss bei einer Inspektion den Zustand eines Wagens prüfen (F). Eine Reparatur oder Wartungsarbeit (H) macht dann jedoch das aus, was wir mit diesem Beruf vor allem verbinden.</li> <li><strong>Ingenieursberufe</strong>: Wie die Bezeichnung sagt, liegt in Ingenieursberufen - Elektrotechniker, Maschinenbauer usw. - der Schwerpunkt auf I. Natürlich müssen Ingenieure auch forschen, z.B. wenn sie verstehen wollen, was eigentlich ihr Auftrag ist. Und Ingenieure legen auch Hand an, wenn sie z.B. Prototypen bauen (H). Letztlich geht es jedoch um den Entwurf des Neuen, die “Erfindung”. Es soll etwas erdacht werden, das es vorher noch nicht gab (I). HIF-Code (10/80/10).</li> <li><strong>Wissenschaftler</strong>: Wissenschaftler schaffen Wissen (F). Das ist ihr Auftrag. Dafür müssen sie natürlich auch einen Versuchsaufbau entwerfen (I) oder sogar Daten nach den Regeln der mathematischen Kunst auswerten (H). Doch unterm Strich ist das, was sie tun, ihr Zweck, die Ermittlung dessen, was schon ist. Das fassen sie in Worte - so dass andere Wissenschaftler, aber auch Ingenieure und Handwerker darauf aufbauen können. HIF-Code (10/10/80).</li></ul> <p>Das war einfach und naheliegend, oder? Die Berufsgruppen, von deren Namen die Arbeitsweisen abgeleitet sind (oder umgekehrt?), konzentrieren sich jeweils zu vielleicht 80% auf die sie bezeichnende Arbeitsweise. Wie ein RGB-Code eine Farbe, so bezeichnet die Mischung der HIF-Werte einen Beruf.</p> <p>Das lässt sich weiterspinnen. Hier die Mischungsverhältnisse für weitere “Berufsgruppen”, wie ich sie sehe:</p> <ul> <li><strong>Kunsthandwerker</strong>: Wenn der Handwerker-Code HIF(80/10/10) lautet, dann hat der Kunsthandwerker HIF(50/30/20). Er setzt nicht einfach nur einen Entwurf handwerklich um, sondern fertigt diesen Entwurf auch an (I). Außerdem muss er “die Welt” beobachten, um herauszufinden, was ihr gefallen könnte (F).</li> <li><strong>Künstler</strong>: Auch wenn es heißt “Kunst kommt von Können”, so ist der Künstler nicht vordringlich ein Handwerker. Ich sehe seinen HIF-Code eher bei (30/30/40). Der Künstler will die Welt darstellen, das Wahre herausarbeiten. Dazu muss er sie intensiv studieren (F) und dann eine geeignete Abbildung entwerfen (I). Die handwerkliche Umsetzung ist dann nur noch der kleinere Teil - den große Künstler immer wieder ihren Assistenten überlassen haben.</li> <li><strong>Virtuose</strong>: Den Virtuosen sehen wir als Künstler. Für mich ist er jedoch eher ein Handwerker. Er muss zwar das Material, das er darbietet, gründlich erforschen und dann seine Interpretation erarbeiten. Doch das, worauf es ankommt, ist am Ende die Reproduktion. Also sehe ich hier einen HIF-Code von (50/20/30).</li> <li><strong>Chirurg</strong>: Chirurgen sind weitestgehend Handwerker. Dass sie lange studiert haben und die Sache komplizierter ist als eine Autoreparatur, ändert daran nichts. Ich sehe das HIF-Verhältnis so: (70/20/10). Ein wenig Forschung ist noch nötig, um zu erkennen, was wirklich das Problem des Patienten ist (F) - manchmal auch noch während der OP. Dann wird die beste Herangehensweise entworfen (I). Die Operation schließlich besteht im Ausführen von lange geübten Handgriffen entlang anerkannter Pfade. Kaiserschnitt, Herzklappentransplantation, Billroth-II-Resektion, Staroperation, Hernienoperation… das alles tut man überall auf der Welt gleich. Und manches wird schon <a href="http://www.hernia.org/why-a-specialist-hernia-centre/">quasi am Fließband erledigt</a>.</li> <li><strong>Hausmeister</strong>: Der Hausmeister ist im Wesentlichen ein Handwerker. Er tut, was er kann, selbst. Aber er ist andererseits auch für Gebäude verantwortlich. Daher muss er zuvor analysieren/beobachten (F) und dann das richtige Vorgehen planen (I) - bei dem ihm Handwerker helfen. Ich sehe den HIF-Code bei vielleicht (60/20/20).</li> <li><strong>Sportler</strong>: Man könnte meinen, ein Sportler sei ein Handwerker. Im Wettkampf ist er das auch. Aber die meiste Zeit performt er nicht, sondern trainiert. Und dazu gehört viel Forschung und Entwurf. Strategien wollen erarbeitet werden (I), die eigenen Leistungsparameter müssen erkundet werden (F). Sportler lernen ständig. Für mich ist der HIF-Code bei (50/20/30) - und das passt schön zum Virtuosen. Der Sportler als Virtuose des Körpers.</li> <li><strong>Schüler</strong>: Schüler sind zuallererst Forscher. Ihre Aufgabe ist es, Wissen aufzubauen. Lernen bedeutet, das zu beherrschen, was schon in der Welt ist. Also ein HIF-Code von (10/10/80).</li> <li><strong>Lehrer</strong>: Lehrer hingegen sind eher Ingenieure. Ihre Aufgabe ist es, Pläne dafür zu entwickeln, wie Schüler am besten lernen. Das entspricht eher HIF(30/50/20).</li></ul> <p>Natürlich sind die HIF-Anteile ständig im Fluss. Mir geht es auch nicht um exakte HIF-Verhältnisse. Die Idee der Mischungsverhältnisse ist das Entscheidende. Dass eben Arbeit überhaupt durch unterschiedliche Anteile an H, I und F charakterisiert ist. Nicht nur die professionelle Arbeit, sondern auch das, was wir täglich tun. Jeder Tag zuhause ist eine neue Mischung aus H, I und F.</p> <p>Zum Abschluss nun das Mischungsverhältnis, das Sie wahrscheinlich am meisten interessiert. Wie sind H, I und F bei der Softwareentwicklung verteilt? Ich sehe das so:</p> <ul> <li><strong>Softwareentwickler</strong>: Softwareentwickler sind anders als andere. Als hätten wir das nicht immer gewusst ;-) Ich sehe einen HIF-Code von (20/40/40). Handwerker im Sinne der obigen Definition sind Softwareentwickler nur zu einem kleinen Teil. Der Schwerpunkt ihrer Arbeit liegt auf Forschung und Ingenieursarbeit. “Software Engineering” ist also treffender als “Software Craftsmanship” - und liegt trotzdem daneben. Denn anders als bei der Berufsgruppe Ingenieur besteht Softwareentwicklung nicht zu 80% aus Ingenieursarbeiten, sondern teilt sich die 80% mit der Forschung. Das eben macht den Charakter der Softwareentwicklung aus. Es ist viel zu forschen: Kundenwünsche müssen analysiert werden, Technologien müssen evaluiert und erlernt werden, dito Paradigmen und Methoden. Vor allem ist jedoch Quellcode ständig zu studieren, bevor daran Änderungen angebracht werden können. Nach der Forschung kommt der Entwurf. Der findet immer statt, auch wenn Sie nie am Flipchart stehen und UML-Diagramme malen. Softwareentwickler machen sich zunächst immer irgendwelche Gedanken darüber, wie der Code aussehen sollte, bevor sie ihn schreiben. Im Großen wie im Kleinen. Da werden APIs entworfen oder Testreihenfolgen bestimmt. Daten(bank)strukturen werden entworfen. Algorithmen und Lösungsansätze ebenso. Und erst ganz zum Schluss gießt die Softwareentwicklung diese Entwürfe in Code. Da ist dann Handwerk gefragt.</li></ul> <p>Das HIF-Mischverhältnis der Softwareentwickler ist dem der Künstler am nächsten. Künstler arbeiten sehr iterativ. Künstler machen Prototypen. Künstler können sehr detailverliebt sein. Künstler schauen genau hin. Der eine oder andere mag also ausrufen “Siehste! Das habe ich doch gewusst!” </p> <p>Dennoch sind Softwareentwickler keine Künstler. Ihre Aufgabe ist schlicht eine andere: Der Künstler soll Wahrheit ausdrücken, die Softwareentwicklung nützliche Werkzeuge herstellen. Das Produkt des Künstlers ist irgendwann fertig und wird nicht weiter verändert. Software hingegen kommt nie zur Ruhe. Von der Analogie “Softwareentwickler sind wie Künstler” halte ich unterm Strich also nichts.</p> <h2>(Un)Schätzbarkeit</h2> <p>So viel der Vorbereitung. Softwareentwicklung (wie auch alle anderen Arbeiten) ist eine Kombination aus drei grundsätzlichen Arbeitsweisen.</p> <p>Diese drei Arbeitsweisen sind nicht nur in ihren Ergebnissen sehr unterschiedlich, sie lassen sich auch unterschiedlich gut schätzen.</p> <p>Die handwerkliche Arbeitsweise lässt sich gut abschätzen. Sie ist wenig kreativ. Handwerk arbeitet reproduktiv. Das ist im Grunde sogar seine Definition. Deshalb gibt es auch so viel mehr berufliche Handwerker als Ingenieure und Wissenschaftler. Nicht umsonst ist der Anspruch an jeden Handwerker, einen treffenden Kostenvoranschlag machen zu können, wenn es um die Reparatur einer Heizung geht oder den Bau eines Wintergartens.</p> <p>Anders ist es für die Arbeitsweise Ingenieur. Die ist hochkreativ. Hier wird “erfunden”. Hier findet Problemlösung statt. Und niemand weiß, wie lange das dauert. Ingenieure entwickeln schließlich Neues. Das braucht Versuch und Irrtum. Dafür gibt es keine berechenbare Geschwindigkeit. Ingenieursarbeit lässt sich mithin nicht schätzen. Oder wenn, dann nur in sehr grobem Rahmen auf der Ebene von Größenordnungen.</p> <p>Dasselbe gilt für die Arbeitsweise Forschung. Wie lange die Analyse eines steinzeitlichen Grabes dauert, wie viel Aufwand die Erforschung der Kernfusion brauchen wird, wann man die Kundenanforderungen wirklich verstanden hat… das alles lässt sich nicht vorher abschätzen. Oder eben nur wieder auf der Ebene von Größenordnungen.</p> <p>Das bedeutet für die Softwareentwicklung:</p> <p><strong>Mit einem HIF-Code von (20/40/40), also 80% Ingenieurs- und Forschungstätigkeit, ist Softwareentwicklung nicht sinnvoll schätzbar.</strong></p> <p>Manager, Kunden, Laien und auch viele Softwareentwickler glauben, Softwareentwicklung sei vor allem Handwerksarbeit. Deshalb wird immer wieder ein “Kostenvoranschlag” gefordert. Für einen gegebenen Scope (Anforderungen an Funktionalität und Effizienz) soll berechnet werden, wie viel Zeit und damit Geld zur Umsetzung gebraucht werden.</p> <p>Für eine handwerkliche Leistung eine ganz selbstverständliche Frage. Nur leider ist Softwareentwicklung wenig handwerklich. Deshalb sind die Antworten unbefriedigend und immer wieder sehr weit von der Umsetzungsrealität entfernt. Das Resultat: Streit, Druck und mangelnde Qualität.</p> <p>Aufgrund einer falschen Prämisse entsteht eben kein korrektes Ergebnis.</p> <p>Kunden können nicht einschätzen, wie viel Analyse und Entwurf für die Umsetzung von Anforderungen nötig sind. Dass es sich um eine handwerkliche Tätigkeit handle, ist eine Annahme aus Unverständnis bis Ignoranz. Softwareentwickler können die Anteile auch nur sehr schwer abschätzen - und unterschätzen sie regelmäßig. Softwareentwickler sind übertrieben selbstbewusst oder naiv, was ihre Erfahrung in puncto Tools, Technologien, Paradigmen, Methoden oder schlicht das Verständnis des teameigenen Quellcodes angeht. Vom Verständnis der Anforderungen ganz zu schweigen.</p> <p>Hinzu kommt die Arbeitsatmosphäre in vielen Projekten. Sie ist geprägt von Unterbrechungen aller Art. Selbst bei halbwegs realistischer Einschätzung des Aufwandes kann kaum gesagt werden, wie lange es dauert, bis er erbracht ist. Dringendes aller Art schiebt sich ständig zwischen die konzentrierte Arbeit an einer abgeschätzten Aufgabe.</p> <p>Das bedeutet unterm Strich:</p> <p><strong>Abschätzungen von Softwareentwicklungsaufwänden funktionieren nicht - solange der handwerkliche Arbeitsanteil nicht klar erkennbar deutlich überwiegt und für die Dauer der Umsetzung Störungsfreiheit zugesichert werden kann.</strong></p> <p>Wie oft ist das aber der Fall? Ich halte das für eine Ausnahme. Es ist nicht unmöglich, doch so selten, dass darauf kein ethisches Geschäftsmodell aufgebaut werden kann.</p> <h2>Handlungsempfehlung</h2> <p>Für Ihre Entwicklungspraxis ergeben sich Konsequenzen aus dieser Analyse. Wenn Sie ehrlicher und ruhiger und mit höherer Qualität arbeiten wollen, dann sollten Sie bei der nächsten Aufforderung zur Abgabe einer Schätzung folgende Schritte durchlaufen:</p> <ol> <li>Machen Sie sich und dem Auftraggeber klar, dass keine Schätzung gefordert wird, sondern ein “Kostenvoranschlag”, d.h. eine Berechnung mit der Genauigkeit von 5–10% in Bezug auf Kosten und Termintreue. Man glaubt ja, Sie seien Handwerker.</li> <li>Werden Sie zum Forscher: Analysieren Sie die Anforderungen im Hinblick auf die für die Umsetzung wahrscheinlichen Aufwände an Forschung und Entwurf. Seien Sie schonungslos ehrlich zu sich und dem Auftraggeber. Vertuschen Sie keine Unsicherheiten. Legen Sie das bekannte Unbekannte (also zu Erforschende) auf den Tisch. Bemühen Sie sich außerdem, weiße Flecken, also das unbekannte Unbekannte zu identifizieren.</li> <li>Weisen Sie die Schätzung zurück, solange der Handwerksanteil bei der Umsetzung geringer als 80% ist.</li></ol> <p>Seien Sie transparent, was diese Schritte angeht. Erklären Sie dem Auftraggeber Ihre Haltung. Die ist differenziert und offen und realistisch - auch wenn sie ihm nicht gefällt. Geben Sie ihm womöglich diesen Artikel zu lesen. Er darf mich auch gern kontaktieren für Nachfragen :-)</p> <p>Ich behaupte nicht, dass diese Haltung einzunehmen leicht für Sie ist. Aber ich bin fest davon überzeugt, dass sie in Übereinstimmung mit der Natur von Softwareentwicklung und insofern ehrlich und ethisch ist.</p> <p>PS: Softwareentwicklung als Ganzes halte ich übrigens für eine Forschungstätigkeit. Der Zweck der ganzen Entwicklungsarbeit ist die Erforschung dessen, was den Kunden befriedigt. Das weiß der Kunden nämlich selbst nur sehr ungenau. Mit jedem Release lernt er sich besser kennen. Durch Versuch und Irrtum nähert er sich dem an, was wirklich hilft. Das ist Forschung. Um diesen Zweck zu erfüllen, arbeitet der Entwickler mit HIF(20/40/40).</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com5tag:blogger.com,1999:blog-6090483181455953305.post-39527215319085837722015-02-08T14:12:00.001+01:002015-02-09T13:06:44.682+01:00Co-location als kontraproduktiv erachtet<p>Wo ein Entwicklungsteam noch an einem Ort sitzt, sollte es verteilt werden. Entwicklungsteams, die gebildet werden sollen, fangen am besten gar nicht erst an, sich an einem Ort zu versammeln. Verteilte Teams sollten der Default sein.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="http://lh6.ggpht.com/-tAqe_uVjvMg/VNdg02SzQYI/AAAAAAAAE_k/sSWXPjWOAjw/image%25255B8%25255D.png?imgmax=800" width="232" height="416">Die Sonne lacht in Hamburg, ein frischer Wind weht an der Alster. Ein guter Tag, um sich unbeliebt zu machen :-) Deshalb diese Vorschläge. Irgendwann muss ich damit mal raus. Warum nicht heute?</p> <p>Ja, so denke ich inzwischen immer mehr. Co-location ist ein Problem.</p> <p>Aber der Reihe nach:</p> <p>Im Jahr 2001 wurde das <a href="http://www.agilemanifesto.org">Agile Manifest</a> unterzeichnet von 17 umtriebigen Geistern - alle weiß, männlich, vor allem Amerikaner und im Durchschnitt zu dem Zeitpunkt wohl um die 50 Jahre alt. Das sage ich so, weil ich glaube, dass wir Agilität wie sie seitdem von den Unterzeichnern gepredigt und von anderen übernommen wurde, davon nicht unabhängig sehen dürfen. Die Unterzeichner sind auch nur Menschen. Sie sind mithin Kinder ihrer Zeit und ihrer Erfahrung. Sie hatten und haben einen je eigenen Horizont, in dem sie denken und innovieren können. Genauso wie Sie und ich ebenfalls.</p> <p>Scrum wurde von Schaber/Sutherland Mitte der 1990er entwickelt. Da war Schwaber schon 50 und Sutherland wahrscheinlich auch. Sie haben sich darin eingebracht mit allem besten Willen und all ihrer Erfahrung. Nicht weniger - aber eben auch nicht mehr.</p> <p>Die Frage ist daher: Was war ihre Erfahrung? Und was für ein Ziel lässt sich daraus ableiten?</p> <p>Das Ziel beschreibt am Ende das Agile Manifest: Es geht um den Softwareproduktionsprozess. Der soll flüssiger werden, der soll näher am tatsächlichen Bedarf laufen. Die Softwareentwicklung soll sich nicht ablenken lassen durch eingefahrene Regularien, Werkzeuge, Dokumentationsanforderungen, Vertragsverhandlungen oder überdimensionierte, schnell veraltende Pläne.</p> <p>Gut so! Das Manifest enthält wunderbare vier Maximen.</p> <p>Und dennoch: Es geht um Produktivität. So sehen denn auch die Mittel aus, die zum Einsatz kommen:</p> <ul> <li>Statt einmaliger Großplanung lieber iteratives Vorgehen in Lernschleifen. <li>Statt technischer Meilensteine lieber inkrementelles Vorgehen für schnelleres Feedback. <li>Statt Abteilungsgerangel lieber cross-functional teams. <li>Statt langsamer indirekter Kommunikation über Hierarchieebenen hinweg lieber schnelle persönliche Kommunikation auf Augenhöhe durch co-location aller Teammitglieder.</li></ul> <p>Habe ich noch etwas vergessen? Bestimmt. Aber ich glaube, das sind die zentralen Mittel agiler Softwareentwicklung. Auf die sind 50jährige Männer nach intensiver Beobachtung und Diskussion gekommen.</p> <p>Das ist wunderbar - außer, wenn es nicht wunderbar ist ;-) Denn es steckt in diesen Mitteln Zeitgeist und technische Möglichkeit. Man wusste es halt nicht besser, man konnte nicht anders. Doch seitdem hat sich die Welt gedreht. Wir sind 20 Jahre nach Scrum, 14 Jahre nach dem Agilen Manifest.</p> <p>Innerhalb meines bescheidenen Horizonts halte ich das iterative/reflektierende Vorgehen für zeitlos. Auch am inkrementellen Vorgehen habe ich nichts auszusetzen. Außer, dass ich es oft noch für zu grobgranular halte und die Iterationen mir zu lange dauern. Aber grundsätzlich bin ich ganz dafür. Und auch die cross-functional teams sind für mich eine sine qua non. Nur so lassen sich Abhängigkeiten flüssig entschärfen.</p> <p>Bei der co-location hingegen bin ich nicht mehr dabei. Hier sehe ich die weithin real existierende agile Praxis in den 1990ern verharren. Schwaber, Jeffries, Martin & Co sind eben keine digital natives. Sie hatten Email, aber auch wenn Ward Cunningham mit von der agilen Partie war, waren Wikis kein für die Massen verfügbares Werkzeug. Social Media waren in den Kinderschuhen wenn überhaupt Smartphones gab es noch lange nicht. Verteilte Versionsverwaltung lag noch in der Zukunft. Infrastruktur in der Cloud zum kleinen Preis ließ sich noch nicht denken.</p> <p>Und so sah man sich außerstande, etwas anderes als co-location für die Zusammenarbeit zu empfehlen. Das war ja auch viel besser, als Leute auf office cubicles zu verteilen, oder?<a id="fnref:1" class="footnote" title="see footnote" href="#fn:1">[1]</a></p> <p>Irgendwie schon. Aber dann doch wieder nicht. Denn ich sehe durch die co-location drei fundamentale Probleme in der Praxis entstehen:</p> <ol> <li>Co-location öffnet Unterbrechungen Tür und Tor. Wer im <a href="http://martinfowler.com/bliki/TeamRoom.html">team room</a> nahe beieinander sitzt, kann die Kollegen schnell mal ansprechen. Das ist auch Sinn und Zweck. Fowler sagt: <em>“[I]t promotes lots of informal and deep communication between people on the team.”</em> Was für den, der einen anderen anspricht eine tolle Vereinfachung ist, ist für den Angesprochenen hingegen oft das Gegenteil, nämlich eine Erschwernis seiner Arbeit. Wer angesprochen wird, wird unterbrochen, d.h. aus seinen Gedanken gerissen, im Arbeitsfluss gestört. Da macht es auch nichts, dass der Ansprechende ganz wohlmeinend oder sehr bedürftig ist. Unterbrechungen stören die konzentrierte Herstellung von Resultaten. Das gilt für Unterbrechungen durch Manager, die plötzlich im Raum stehen, genauso wie für Unterbrechungen durch Teammitglieder - oder auch selbstverschuldete Unterbrechungen durch Social Media Benachrichtungen. <li>Co-location leistet unentdeckten Abhängigkeiten Vorschub. Wer im team room sitzt, muss sich tendenziell weniger Gedanken machen über das, was er braucht, um seine Resultate zu erzielen. Abhängigkeiten von Technologien oder Anforderungsverständnis müssen nicht vorher entdeckt und aus der Welt geschafft werden, sondern können ja im Zweifelsfall jederzeit durch Nachfrage bei einem Kollegen aufgelöst werden. Irgendwer weiß immer Bescheid, dafür ist das Team doch cross-functional. Daraus entstehen nicht nur Unterbrechungen für Kollegen, sondern auch geringere Produktivität. Denn so wie ein Koch produktiver ist, wenn er in Phasen arbeitet, also z.B. Gemüse erst komplett schneidet, so ist Softwareentwicklung auch produktiver, wenn sie in Phasen arbeitet; das sind mindestens Analyse, Entwurf, Implementation.<a id="fnref:2" class="footnote" title="see footnote" href="#fn:2">[2]</a> <li>Co-location fördert monolithischen Code. Wenn auch nur irgendetwas an <a href="http://de.wikipedia.org/wiki/Gesetz_von_Conway">Conways Gesetz</a> ist, dann dürfen wir uns nicht wundern, dass 14 Jahre Agilität den monolithischen Anwendungen nicht den Garaus gemacht haben.<a id="fnref:3" class="footnote" title="see footnote" href="#fn:3">[3]</a> <em>“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”</em> Und was für eine “communication structure” soll ein co-located team im team room haben? Eine sehr, sehr enge. Was bedeutet das für das “design”, d.h. die Struktur ihres Produktes Software? Es wird aus eng verbundenen Teilen bestehen.</li></ol> <p>Auch ich habe meinen Hintergrund. Vor dem sehe ich auf Agilität. Ich bin weniger am Prozess interessiert als am Code.<a id="fnref:4" class="footnote" title="see footnote" href="#fn:4">[4]</a> Der muss wandelbar, evolvierbar sein, sondern ist die Softwareentwicklung nicht zukunftsfähig.</p> <p>Ja, da sehe ich das große Problem unserer Tage in der Softwareentwicklung: Wandelbarkeit. Sogar nicht nur Code, sondern auch Teams (und Unternehmen) müssen wandelbar sein, sich also anpassen können. Dazu gehört natürlich Reflexion, wie sie in der Agilität drinsteckt. Doch es braucht noch mehr. Ohne passende Strukturen lassen sich Ergebnisse der Reflexion nur schwer oder gar nicht umsetzen.</p> <p>Die meisten Projekte leiden nicht unter technologischen Schwierigkeiten. Wir haben Hardware und Frameworks und Dienste, die leistungsfähig genug sind, um die Effizienzanforderungen an Software zu erfüllen. Das war bis vor 10 Jahren noch ganz anders. Deshalb war Wandelbarkeit für die Agilität auch kein großes Thema. Clean Code kam erst sieben Jahre nach dem Agilen Manifest und 13 Jahre nach Scrum.</p> <p>Doch nun haben sich die Zeiten gewandelt. Wandelbarkeit ist das zentrale Thema - wenn man nicht grad dem nächsten noch besseren Framework hinterherjagt. Auch die aktuelle µService-Bewegung ist ein Ausdruck des Leidens am Monolithen, an der Unwandelbarkeit.</p> <p>Und wodurch sind wandelbare Strukturen gekennzeichnet? Durch lose Kopplung. Ein älteres Prinzip gibt es wohl kaum in der Softwareentwicklung.</p> <p>Lose Kopplung entsteht durch Kapselung (klare Schnittstellen, Autonomie, geringe Abhängigkeiten) und asynchrone Kommunikation.</p> <p>Wenn man diese Eigenschaften für ein Softwaresystem will, wie ist das zu vereinbaren mit co-location im team room? Wie können lose Kopplung und auch wandelbare verteilte System einfach entstehen, wenn die, die sie herstellenn sollen, einander auf dem Schoß sitzen?</p> <p>Hier sehe ich die vorherrschende Implementation von Agilität gegen eine Wand laufen. Man macht es sich schwer bis unmöglich, das zentrale Problem der Softwareentwicklung unserer Zeit zu lösen, wenn man als Default für die Teamorganisation den team room setzt.</p> <p>Entwickler, die man im selben Raum zur selben Zeit sehen will, können eine Menge herstellen - aber entkoppelte Strukturen bzw. wandelbare Software ist sicherlich nicht das Produkt, was ihnen am leichtesten aus den Fingern fließt.</p> <p>Das Agile Manifest ist gut, wofür es gedacht ist: Produktivität. Es kommt aber an seine Grenzen, wenn es Mittel verschreibt, die der Erfüllung anderer Anforderungen im Wege stehen, hier der Wandelbarkeit.</p> <p>Deshalb mein radikaler Vorschlag: Geben wir die co-location auf! Setzen wir die Verteilung von Teams als Default. Befreien wir Teammitglieder von Bindungen an Raum und Zeit.</p> <p>Wir haben genügend Kommunikationsmittel und Tools, um jederzeit Kontakt aufzunehmen zu Kollegen, egal wo sie sich befinden. Chat, Telefon mit Anrufbeantworter, Diskussionsforen, Wikis, Issue Tracker, Repositories, Videokonferenzen, online Whiteboards und was es noch alles gibt in tausend und einer Ausprägung. Asynchrone Kommunikation in unterschiedlicher Geschwindigkeit ist kein Problem. Jeder ist immer erreichbar. Gut so! Wir können unsere Anliegen immer zustellen - ohne den anderen zu unterbrechen. Das sorgt für konzentrierte Arbeit. Das ist gelebte Autonomie: Ich bestimmte selbst über die Nutzung meiner Zeit.</p> <p>Wohlgemerkt schließt solcher Default der Verteilung nicht die synchrone Kommunikation aus. Zu einem Telefonat oder eine Videokonferenz kann man sich jederzeit verabreden. Das gilt sogar für persönliche Treffen, also Meetings. Niemandem wird verwehrt, sich eine Art der Zusammenarbeit zu wünschen, die für ihn und seine Resultate zuträglich ist. Nur muss das jeder mit den Kollegen verhandeln, denn die mögen andere Vorstellungen davon haben, wie sie ihre Ergebnisse am liebsten erzielen.</p> <p>Verteilte Arbeit macht es schwerer, dass lokale Resultatsoptima entstehen. Ein Resultat kann weniger einfach auf Kosten vieler anderer Resultate hergestellt werden. Das Ganze wird betont, optimiert - ja, auch wenn ein Einzelner, ein individuelles Resultat dabei einmal zu kurz kommen sollte.</p> <p>Dass man für verteiltes Arbeit ein paar andere oder gar mehr Soft Skills benötigt, als für die befohlene Arbeit am selben Ort zur selben Zeit wie andere, das mag sein. Man muss sich besser organisieren können, verantwortungsbewusster sein, expliziter und verlässlich kommunizieren… Aber nur weil das schwierig für manche sein mag (ja, auch und gerade für Manager), sollte das nicht bedeuten, dass verteilte Teams nicht anstrebenswert seien. Denn es steht viel auf dem Spiel. Es geht um nicht weniger als die verlässliche Herstellung von Wandelbarkeit. Ohne die gibt es nämlich keine Zukunftsfähigkeit. Sowohl für Code wie für Teams.</p> <p>Mit verteilten Teams entstehen nämlich nicht nur (einfacher) wandelbare Softwarestrukturen, sondern auch wandelbare Teams. Wo ein Team verteilt arbeitet, ist die Einbindung von neuen Kollegen an beliebigen Orten einfacher. Das ist doch eine gute Nachricht für das Recruiting, oder? Dadurch kommen leichter neue Impulse zu allerlei fachlichen Aspekten ins Team.</p> <p>Ganz davon abgesehen, dass verteilte Teams weniger hausinterne Infrastruktur brauchen. Heute gibt es alles, was das Entwicklerherz begehrt, in der Cloud. Wer wollte da auch nur einen Server kaufen? Was Entwickler brauchen, sind gute Laptops und viel Internetbandbreite. Gelegentlich noch ein Raum, um tatsächlich mal zusammenzukommen. Am besten mit Beamer/Smartboard und Flipchart. Und das Internet muss stets verlässlich da sein wie Strom aus der Steckdose. Ohne lästige Spezialfirewalls, die Superproxys brauchen, die den Zugriff auf ein DVCS behindern.</p> <p>Wohlgemerkt, ich rede hier über Entwickler, nicht über sonstige Mitarbeiter von Unternehmen. Was die brauchen, ist eine andere Sache. Aber nur weil die vielleicht etwas brauchen - zum Beispiel ein total supersicheres Firmennetz -, sollte das nicht bedeuten, dass die Softwareentwicklung sich aus Solidarität auch ein Bein hochbinden muss.</p> <p>Bottom line: Ich glaube, die Zeit der co-location als Default ist vorbei. Angesichts der Kommunikationsmöglichkeiten, die wir haben, hat sie den Punkt erreicht, wo sie kontraproduktiv wird.</p> <p>Ja, wir haben das Zusammenhocken lieb gewonnen. Irgendwie ist es auch kuschelig mit den Kollegen. Aber was wollen wir? Kuscheln oder wandelbare Software?</p> <p>Wer kuscheln will, kann z.B. per Chat im Team anfragen, wer mitmachen möchte. Dann kann ein Meeting vereinbart werden. Das sollte jedoch die Ausnahme sein. Synchrone persönliche Kommunikation vieler Teammitglieder macht vielleicht ein gutes Gefühl - aber es wird andererseits auch ganz schnell ganz viel Geld verbrannt.</p> <p>Die Väter der Agilität haben es gut gemeint. Doch sie waren eben auch begrenzt in ihrer Erfahrung mit Kommunikationstechnologie. Ken Schwaber konnte z.B. nicht anders, als lange Jahre seines Lebens mit Telefon ohne Anrufbeantworter zu leben und zu arbeiten. Dann mit Anrufbeantworter und gelegentlichem Fax. Dann irgendwann später mit Email usw. Kein Wunder, dass er und die anderen co-location als Wunderwaffe empfanden. Irgendwie liegt sie uns ja auch im Blut. Die Bandbreite der Kommunikation ist da so schön hoch.</p> <p>Aber kuschelige Bandbreite ist eben nicht alles. Wenn ungehinderte Kommunikation in hoher Bandbreite die Norm ist, ist irgendetwas optimiert – und irgendetwas bleibt auf der Strecke. Das ist die Wandelbarkeit.</p> <p>Drum sage ich: Vorsicht vor der co-location!</p> <p>So viel Verteilung und Autonomie und Entkopplung wie möglich, so wenig co-location wie nötig.</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Wir können spekulieren, wie das Agile Manifest ausgesehen hätte, wenn 50% der Unterzeichner Frauen gewesen wären. Oder das Durchschnittsalter 25 Jahre. Oder unterschiedliche Kulturen vertreten gewesen wären. <a class="reversefootnote" title="return to article" href="#fnref:1">↩</a></p> <li id="fn:2"> <p>Wer hier herauslesen will, dass ich für Big Design Up-Front (BDUF) wäre, liegt falsch. Diese Phasen können manchmal nur Minuten oder Stunden dauern. Selbst in der agile Praktik TDD stecken sie drin - ohne dass das betont würde. 30 Minuten Entwurf mit 2 Stunden folgender Implementation können 5 Stunden vermeintlich reiner Implementation ersetzen, in denen der Entwickler dauernd in unvermutete Abhängigkeiten läuft. Dass man durch beliebig lange Analyse- und Entwurfsphase alle Abhängigkeiten entdecken könnte, behaupte ich auch nicht. Aber ein gesundes Maß an Analyse und Entwurf ist nötig; mehr als oft aufgewandt wird in agilen, co-located Teams. <a class="reversefootnote" title="return to article" href="#fnref:2">↩</a></p> <li id="fn:3"> <p>Ganz davon abgesehen, dass Agilität ja nicht Wandelbarkeit als ausdrückliches Ziel hat. Wie man ganz deutlich an Scrum sehen kann, kümmert sich der agile Prozess gar nicht um die Sache - Code -, sondern nur um den Rahmen für die Produktion der Sache. Nicht umsonst hat Jeff Sutherland nun auch ein Buch geschrieben, das Scrum auf alle möglichen Arbeitsfelder anwendet (<a href="http://www.amazon.de/Scrum-Doing-Twice-Work-Half/dp/038534645X">“The Art of Doing Twice the Work in Half the Time”</a>). <a class="reversefootnote" title="return to article" href="#fnref:3">↩</a></p> <li id="fn:4"> <p>Allerdings verschiebt sich dieser Fokus notgedrungen in den letzten Jahren. Denn ich merke, dass ich die Verbesserungen, die mir für Code vorschweben, in Unternehmen nicht gut verankert bekomme, wenn mir der Prozess oder gar die Unternehmenskultur egal ist. Aber das ist ein Thema für einen anderen Artikel… ;-) <a class="reversefootnote" title="return to article" href="#fnref:4">↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com18tag:blogger.com,1999:blog-6090483181455953305.post-53215137698757503342015-02-05T08:09:00.001+01:002015-02-05T08:09:26.488+01:00Bessere Resultate ohne Abhängigkeit<p>Wie arbeiten Sie am liebsten, wenn Sie etwas schaffen wollen oder müssen? Was fördert Ihre Konzentration?</p> <p>Die Menschen sind ja verschieden. Der eine möchte Ruhe haben, die andere Musik hören, der nächste ein Räucherstäbchen anzünden… Fenster auf, Fenster zu, mehr Licht, weniger Licht… Man kann es kaum allen recht machen, oder?</p> <p>Eine Konstante gibt es jedoch hinter all dieser Verschiedenheit: den Wunsch nach <strong>Autonomie</strong>.</p> <p>Sie wie ich möchten die Umstände unserer Arbeit möglichst weitgehend selbst bestimmen. Umso mehr, je stärker wir unter Druck stehen. Wer von uns Resultate sehen will, der sollte uns möglichst freie Hand lassen, wie wir uns einrichten, um sie zu erzielen. Zumindest wenn man uns vertraut, dass wir uns redlich bemühen, diese Resultate auch zu erbringen.</p> <p>Ich als Freiberufler lebe und arbeite so. Meine “Resultatserzielungsumstände” kann ich zu 100% selbst bestimmen. Das macht mir Freude - und meinen Kunden auch. Verlässlichkeit und Qualität scheinen für sie zu stimmen.</p> <p>Anders ist das bei den Entwicklern, Testern, Supportern, POs, die ich bei meinen Kunden treffe. Deren Autonomie ist minimal. Sie können (in den allermeisten Fälle) nicht über Arbeitsort, Arbeitszeit, Arbeitsplatz, Arbeitsmittel bestimmen. Ja, sie können sogar nur begrenzt über die Arbeitszeitnutzung bestimmen.</p> <p>Das finde ich von Tag zu Tag kontraproduktiver. Je häufiger ich solche Umstände sehe und auf der anderen Seite Klagen darüber höre, was alles in Unternehmen nicht läuft, wie es laufen soll… desto mehr denke ich: Da gibt es einen Zusammenhang. Die Grundverhältnisse sind einfach so, dass es nicht besser klappen kann. Unternehmen wünschen sich also etwas, das sie nicht bekommen können, solange sie an ihren Glaubenssätzen festhalten, was die Einschränkung der Autonomie ihrer Mitarbeiter angeht.</p> <p>Was wollen Unternehmen auch erwarten von Menschen, die offiziell “abhängig beschäftigt” sind? Diese Formulierung müssen Sie sich auf der Zunge zergehen lassen:</p> <ul> <li>Wer angestellt ist, ist abhängig. Das Unternehmen bestimmt, der Angestellte wird bestimmt. Er ist auf die Gnade des Unternehmens angewiesen - sonst wäre er ja nicht in einem Abhängigkeitsverhältnis. Gleichberechtigung, Augenhöhe, Autonomie sind etwas anderes. Erwachsene sollten solche Beziehungen nicht eingehen wollen - sollte man meinen. Allemal ist zu fragen: Was kann ein Unternehmen erwarten von Abhängigen? Freiwilligkeit und Motivation? Kaum. <li>Wer angestellt ist, ist beschäftigt, nein, muss beschäftigt werden. Das hört sich an wie im Kindergarten, wo man Kinder beschäftigt, damit sie nicht auf dumme Gedanken kommen. “Beschäftigung” klingt auch nicht nach Motivation, Energie, Fokus. Wer beschäftigt wird, der tut auch eher nichts aus sich heraus, sondern braucht einen “Entertainer”. Sobald der nachlässt, kommt Langeweile auf.</li></ul> <p>“Abhängige Beschäftigung” soll etwas optimieren. Historisch gesehen ist sie eine große Leistung. Lieber abhängig beschäftigt im Schutz eines Unternehmens unter Aufsicht von Arbeits- und Sozialgesetzen, als frei, selbstständig, autonom - aber immer auch prekär am Rande des Existenzminimums.</p> <p>Die positiven Effekte der “abhängigen Beschäftigung” möchte ich nicht schmälern. Doch sie hat eben ihren Preis. Und den zahlen nicht nur Unternehmen, sondern auch die Abhängigen. Der Preis der Abhängigkeit ist die Unterkomplexität.</p> <p>Abhängigkeits- und Beschäftigungsverhältnisse sind immer hierarchisch. In Hierarchien fließen Segnungen von oben nach unten. Von unten nach oben wird geleistet und erbeten. Das ist klar, simpel, effizient. Das ist das Gegenteil von komplex. So soll es ja auch sein.</p> <p>Historisch hat das auch lange gereicht, nein, konnte sogar nicht anders sein. Was immer an Resultaten zu erzielen war, war sehr einfach zu erzielen: Wenige denken und planen, viele, viele führen mit einfachen Handgriffen aus. Der kulturelle und bildungsmäßige Unterschied zwischen den Hierarchieebenen war bis neulich noch gigantisch.</p> <p>In den letzten Jahrzehnten hat sich das nun radikal geändert. Ein Manager ist einem gemanageten Entwickler in nichts voraus. Sie sind in allem gleich - außer in ihrer Position in der Unternehmenshierarchie und damit im Gehalt und damit in den angehäuften materiellen Werten und damit in ihrem Anspruchsdenken. Allerdings leitet sich daraus kein Unterschied in der Angst ab. Angst ist auf jeder Ebene der Hierarchie gegenwärtig. Denn auf jeder Ebene ist man ja abhängig und will beschäftigt werden.</p> <p>Diese Angst kostet natürlich Energie. Die wird investiert in Handlungen, die höhere Hierarchieebenen gnädig stimmen sollen. Ob daraus jedoch dem Unternehmenszweck dienliche Resultate erwachsen, ist zweitrangig. So kann es dann zu keinen besseren Resultaten kommen. Dass Unternehmen klagen, ist also nicht verwunderlich. Ihr grundsätzlicher Glaubenssatz ist falsch. Der lautet: Weil Angestellte so glücklich über die abhängige Geborgenheit sind, die das Unternehmen ihnen gibt, beschäftigen sie sich konzentriert mit der Erzielung von Resultaten zum Wohle eben dieses gnädigen Unternehmens.</p> <p>Doch so funktioniert es eben nicht.</p> <p>Ich glaube zwar daran, dass die meisten Angestellten gute Resultate zuverlässig liefern <em>wollen</em> - nur <em>können</em> sie es nicht. Sie sind umstellt von organisatorischen Mauern. Ihre Freiheitsgrade sind mindestens aus zwei Gründen beschnitten:</p> <ul> <li>Das Unternehmen traut den Abhängigen nicht. Denn die haben ja eine Beschäftigungsmentalität. Falls man sie nicht konstant bespaßt und beaufsichtigt, langweilen sie sich und tun nichts. Nur wenn ein Regelkorsett eng geschnürt ist, bleibt den Abhängigen quasi nichts anderes übrig, als auch in der Langeweile irgendwie noch ein Resultat zu erzielen. <li>Unternehmen sind Zusammenschlüsse von Individuen, um durch ein engeres Verhältnis Energie zu sparen. Neben dem funktionalen Zweck (z.B. Software für Architekten) gibt es also auch einen nicht-funktionalen: Effizienzsteigerung. Der ist tief verankert und wird umso mehr beschworen, je enger der Markt wird. Im Verein mit der überkommenen Grundannahme, dass Abhängige, die beschäftigt werden müssen, weder rechte Motivation noch Kenntnis haben können, wie Ressourcen am besten eingesetzt werden, führt das zu weiteren Einschnürungen durch ein Regelkorsett. Vereinheitlichung, Standardisierung, Konsolidierung sind das Gegenteil von Autonomie.</li></ul> <p>Wenn ich “die Verhältnisse” so beschreibe, ist das natürlich überzeichnet. Doch nur durch die Überzeichnung wird die Grundhaltung erkennbar, die eben den meisten Unternehmen noch unterliegt. Es ist die der Hierarchie und der Unselbstständigkeit. Da helfen auch nicht 3 Monitore, der höhenverstellbare Schreibtisch oder die unternehmenseigene Kita. All das ist mit Hierarchie und Unselbstständigkeit vereinbar. Denn all das können einfach nur Geschenke und Zugeständnisse eben im Rahmen des überkommenden Paradigmas sein. Ein gelockertes Korsett ist immer noch ein Korsett - insbesondere, wenn man nicht wählen kann, ob man es auszieht.</p> <p>Das Büro kann eingerichtet sein, wie es will. Mit Tischkicker und Ruheraum. Solange die, die Resultate erzielen sollen und wollen, nicht wahrhaft die Wahl haben, ihre Umstände bestmöglich selbst zu bestimmen, um eben diese Resultate zu erzielen… solange müssen sich Unternehmen nicht wundern, dass es nicht wie gewünscht klappt.</p> <p>Je länger ich darüber nachdenke, desto mehr glaube ich, dass der Default für die Zusammenarbeit Unabhängigkeit sein sollte. Nur wenn Verlässlichkeit und/oder Resultat zu wünschen übrig lassen, sollte nachgebessert/optimiert werden. So wenig wie möglich.</p> <p>Unternehmen als Ganzes und Manager in Unternehmen in ihren Bereichen sollten also nicht Regeln einführen, sondern stets Ausschau halten nach Regeln, die entfernt werden können. Denn je weniger Regeln, desto größer die Autonomie der Mitarbeiter. Und je größer die Autonomie, desto eher kann die Konzentration entstehen, die dafür nötig ist, dass Resultate verlässlich in hoher Qualität entstehen.</p> <p>Wer Resultate sehen will, wer etwas bekommen will, sollte daher mit Geben beginnen. Das geschieht am besten mit einer simplen Frage: <strong>“Was brauchst du, um deine Resultate zu erzielen?”</strong></p> <p>Manchmal wünscht sich die Gefragte dann eine Regel; das ist nicht schlecht, denn dann kommt die Regel von unten, von dort, wo echter Bedarf ist.</p> <p>Es können jedoch auch Antworten kommen, die dem Paradigma widersprechen. Aber warum davor Angst haben? Kann denn wirklich etwas Katastrophales passieren, wenn man die Leine der Abhängigkeit und der Beschäftigung lockert? Alle Wünsche sind doch nur Hypothesen. Auch der wünschende Angestellte weiß nicht wirklich, ob es stimmt, dass es seinen Resultaten hilft, wenn er nur seinen Wunsch erfüllt bekommt. Deshalb sollte die Wunscherfüllung zunächst als Experiment gesehen werden.</p> <p>Auch hier gilt “Individuals and interactions over processes and tools” und “Responding to change over following a plan” und “Working software over comprehensive [rule set]” und “[…] collaboration over contract [adherence]”. Die Iterationen der Agilität helfen überall. Eine lernende Organisation gibt es nicht ohne Experimente. Die sollten nicht nur am Markt stattfinden, sondern eben auch intern. Viel mehr intern. Denn dort ist viel Potenzial für Kreativität, Motivation, gar Innovation hinter Mauern aus Regeln angestaut.</p> <p>Wenn es also im Unternehmen im Allgemeinen bzw. in der Softwareentwicklung im Speziellen nicht läuft, wie es laufen sollte, wenn es knirscht in der Zusammenarbeit, wenn die Unzuverlässigkeit grassiert… dann, so glaube ich, ist eine wesentliche Stellschraube die Autonomie jedes einzelnen Beteiligten. Mehr und mehr Freiheitsgrade helfen. Nicht nur für sauberen Code gilt also: Raus aus den Abhängigkeiten! ;-)</p> <p> </p> <p>PS: Dass Autonomie kein Garant für Erfolg ist, ist selbstverständlich. Sie ist keine hinreichende Voraussetzung. Aber ich halte sie für eine notwendige. Ohne Autonomie, ohne Augenhöhe, ohne Selbstbestimmung und damit einhergehend auch Selbstverantwortung keine wirklich dauerhaft guten Resultate. Autonomie ist insofern im eigenen Interesse jedes Unternehmens.</p> <p>PPS: Zur gewährten Freiheit muss auf der anderen Seite natürlich auch Fähigkeit treten, damit umzugehen. Die mag nicht bei jedem “Befreiten” in gleichem Maße vorhanden sein. Aber wer seine Aufgaben als Manager schwinden sieht, bekommt hier ein bedenkenswertes neues Betätigungsfeld: die Förderung von echten Mit-Arbeitern. Die Frage bleibt nämlich: “Was brauchst du?” Dieses mal jedoch Bezogen auf die Autonomie: “Was brauchst du, um mit der neu gewonnenen Autonomie zum Nutzen der Resultate am besten umzugehen?”</p> <p>PPS: Und wer nicht glaubt, dass man mit mehr Autonomie und Augenhöhe Erfolg haben kann, der schaue mal diesen Film: <a title="http://vimeo.com/118219210" href="http://vimeo.com/118219210">http://vimeo.com/118219210</a></p> <p><iframe height="281" src="//player.vimeo.com/video/118219210?byline=0&portrait=0" frameborder="0" width="500" allowfullscreen mozallowfullscreen webkitallowfullscreen></iframe> <p><a href="http://vimeo.com/118219210">AUGENHÖHE OmU (dt.)</a> from <a href="http://vimeo.com/danieltrebien">Daniel Trebien</a> on <a href="https://vimeo.com">Vimeo</a>.</p> <p>Die meisten, die darin zu Wort kommen, sind zwar formal noch “abhängig beschäftigt”, doch ihre Berichte machen deutlich, dass auch in Angestelltenverhältnissen Autonomie und echte Mit-Arbeit möglich ist. Und das ist nur der Anfang.</p> <p>Die Frage ist daher nicht, ob mehr Autonomie in Ihrem Unternehmen sein sollte, sondern wann das der Fall ist und unter wie großen Schmerzen es dazu kommen wird. Meine Empfehlung: Lieber bald mit der “Entkopplung” beginnen, um mehr Zeit zum Lernen und Anpassen zu haben.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com3tag:blogger.com,1999:blog-6090483181455953305.post-16398053016491042602015-01-27T08:51:00.001+01:002015-01-28T11:57:58.104+01:00Die Selbstlern-Challenge - Mitmachen und gewinnen!<p>500€ gibt es zu gewinnen. Ingesamt jedenfalls. Die bin ich bereit, als “Preisgeld” auszusetzen für diejenigen, die erfolgreich mitmachen.</p> <h3>Die Herausforderung</h3> <p>Ich suche 10 Freiwillige, die bereit sind, 10 Wochen lang sich im Selbststudium mit Flow Design auseinanderzusetzen. Das habe ich in einigen Büchern und vielen Blog-Artikeln ausführlich beschrieben. Dazu gehören Themen wie:</p> <ul> <li>Radikale Objektorientierung / OOP as if you meant it <li>Agile Architektur / Die Anforderung-Logik-Lücke <li>Softwarezellen</li></ul> <p>Über die 10 Wochen ist nicht viel zu leisten. Es gibt nur drei Bedingungen:</p> <ol> <li>Wer teilnimmt, stellt mir <em>jede Woche mindestens eine ernstgemeinte und nicht triviale Frage</em> zu den obigen Themen. Diese Frage soll als minimale Dokumentation der kontinuierlichen und fortschreitenden Auseinandersetzung mit dem Stoff dienen. “Fragen auf Vorrat” sind nicht erlaubt, ebensowenig “aufholende Fragen”, die eine Woche ohne Frage kompensieren sollen. <li>Wer teilnimmt, <em>reagiert auf Emails von mir zum Lernstoff innerhalb von max. 24h.</em> Dies dient der Sicherung einer verlässlichen, flüssigen Kommunikation zur Beförderung des Lernens. <li>Wer teilnimmt, stimmt zu, dass sein/ihr Name veröffentlicht wird. Außerdem behalte ich mir vor, die Abschnitte zum Lernstoff aus der sich ergebenden Email-Konversation zu veröffentlichen.</li></ol> <p>Das ist alles. Es gibt keine Prüfung, es gibt überhaupt nichts, das am Ende abzuliefern wäre. Der Weg ist das Ziel :-)</p> <p>Dieses Angebot gilt vom 27.1.2015 bis zum 17.5.2015 (oder anders: ab 5. KW bis inklusive 20. KW 2015). In der Zeit muss die 10-Wochen-Teilnahme abgeschlossen sein.</p> <p><font style="background-color: #ffff00">Update: Seit 28.1.2015 sind alle Teilnehmerplätze vergeben!</font></p> <h3>Die Teilnahme</h3> <p>Wer teilnehmen möchte, schreibt mir einfach eine Email. Dann beginnen die 10 Wochen zu laufen. Ich stelle daraufhin Lernmaterialien in Form von Links und Büchern zur Verfügung. Teilnehmer müssen also keinen Cent ausgeben.</p> <p>Auf Wunsch stelle ich auch Aufgaben, an denen sich Teilnehmer versuchen können.</p> <h3>Der Gewinn</h3> <p>Der Gewinn der Teilnahme besteht natürlich vor allem in Wissens- und Erfahrungszuwachs. Darüber hinaus erhält aber auch jeder erfolgreiche Teilnehmer am Ende noch einen Amazon-Gutschein in Höhe von 50€.</p> <p>Erfolgreich ist, wer die obigen Bedinungen erfüllt. Mehr ist nicht nötig, weniger allerdings auch nicht.</p> <h3>Die Hypothese</h3> <p>Mit dieser Herausforderung möchte ich eine Hypothese überprüfen, die ich zum autodidaktischen Lernen habe. Welche das ist, kann ich vorher nicht verraten. Damit würde ich die Durchführung des Experiments beeinflussen. Aber ich verspreche, dass ich am Ende der Herausforderung darüber berichte.</p> <p> </p> <p>Und nun: Lasst das Selbstlernen beginnen!</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com3tag:blogger.com,1999:blog-6090483181455953305.post-50490775101950158552014-11-29T11:10:00.001+01:002014-11-29T11:10:19.970+01:00Die Nachwuchskatastrophe - 0% der Mädchen wollen in die Softwareentwicklung<p>Der Nachwuchs für die Softwareentwicklung ist männlich. Zu 100%. So scheint es derzeit nach einer <a href="http://www.spiegel.de/schulspiegel/berufseinstieg-schueler-mit-berufswahl-ueberfordert-a-1004735.html">Umfrage des Allensbach-Instituts</a>.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-UAI71GWQ_2U/VHmbiUepPvI/AAAAAAAAEFo/1ApVMgL2XqI/image%25255B4%25255D.png?imgmax=800" width="505" height="484"></p> <p>0% der befragten Mädchen zeigte Interesse daran, einen Beruf im “Computer, IT-Bereich” zu wählen. Das betrifft auch die Softwareentwicklung.</p> <p>Das ist eine Katastrophe!</p> <h3>Gründe zur Sorge</h3> <p>Warum ist das eine Katastrophe? Ich sehe da mindestens zwei Gründe:</p> <ul> <li>Software ist der “Treibstoff” der Zukunft. Ohne Software geht nichts mehr und zukünftig noch weniger. Wir haben heute schon zu wenige Softwareentwickler. Das Verhältnis kann dann nur noch schlechter werden, wenn morgen der Bedarf an Software weiter steigt und gleichzeitig - zumindest in Deutschland - der Arbeitskräftemarkt in den nächsten 10 Jahren um bis zu 15% schrumpft. Offshoring ist doch keine wirkliche Lösung. Auch Flüchtlinge der einen oder anderen Art zu Softwareentwicklern fürs homeland umzuschmieden, ist doch auch keine Lösung. Wir brauchen schlicht mehr an dieser Arbeit interessierte Menschen beiderlei Geschlechts aus und in unserer Gesellschaft. Das ist schwierig genug. Wenn sich jetzt aber herausstellt, dass 50% des Potenzials schlicht verloren ist… Dann ist das eine Katastrophe. Uns geht der “Treibstoff” für unsere Unternehmen aus.<a id="fnref:1" class="footnote" title="see footnote" href="#fn:1">[1]</a></li> <li>Softwareentwicklung ist schon lange keine Sache mehr für einsame (männliche) Hacker. Jedenfalls nicht, wenn man nachhaltig Software bauen will. Softwareentwicklung braucht ein Team. Und Team braucht Vielfalt. Mehr Vielfalt als ein Fußballteam. Denn die Sache, um die es geht, ist komplexer und es hängt mehr von ihr ab. Zu Vielfalt gehört selbstverständlich, dass beide Geschlechter vertreten sind. Manager rufen gern Kriegsmetaphern auf, um ihre Arbeit zu beschreiben und sich zu rechtfertigen. Doch schon lange ist klar, dass der Erfolg für alle größer ist, wenn man nicht im Kampf miteinander steht, sondern kooperiert. Kooperation, gemeinschaftliches Schaffen, d.h. auch Empathie sind jedoch eher mit einer weiblichen Sicht der Dinge verbunden als mit der männlichen. Bei aller Gleichberechtigung, die wir schon erreicht haben mögen, ist eine Ungleichheit in der Herangehensweise ans Leben zwischen Frauen und Männern nicht wegzudiskutieren. Und warum auch? Warum soll alles gleich sein, nur weil alle gleichberechtigt sind? Lassen wir zu, dass Frauen und Männer unterschiedlich sind - und zusammen ein Ganzes ergeben.<a id="fnref:2" class="footnote" title="see footnote" href="#fn:2">[2]</a> Softwareentwicklung ist eine Arbeit, die solches Ganzes braucht. Denn es geht nicht um Maschinen, die nach Plan von muskelbepackten Männern im Schweiße ihres Angesichts zusammengeschraubt werden müssen. Es geht um sich ständig ändernde Prozesse, es geht um Komplexität, es geht um Verständnis (mindestens des Kunden) uvm. Das alles profitiert davon, Weiblichkeit im Team zu haben. Mehr Weiblichkeit als bisher jedenfalls. Wenn sich 0% der Weiblichkeit für die Softwareentwicklung interessieren, dann ist das also eine Katastrophe.</li></ul> <h3>Was tun?</h3> <p>Die Katastrophe hat natürlich schon begonnen. Eine Generation ist bereits verloren. Und kein Wunder: Wenn ich mir das Gymnasium meiner Tochter ansehe, dann weiß ich, warum weder sie noch ihre Freundinnen für Softwareentwicklung interessieren. Es wird nichts dafür oder sogar alles was möglich ist, dagegen getan. Fächerkanon wie vor 50 Jahren. Bis zu diesem Jahr keine Erlaubnis, den <a href="http://www.girls-day.de">Girls Day</a> zu besuchen. Da hilft auch kein Studiensaal mit Laptops und Powerpoint-Präsentation in Geografie. <em>Verständnis</em> für den “Treibstoff” wird nicht geweckt. Nirgends.</p> <p>Dabei ist dort mit Sicherheit Potenzial. Neulich habe ich meiner Tochter mal <a href="https://itunes.apple.com/de/app/lightbot-programming-puzzles/id657638474?mt=8">Lightbot</a> aufs iPad geladen. Das hat sie besser gespielt als ich. Man(n) muss halt Angebote machen… Aber das ist natürlich schwer, wenn schon männliche Lehrer sich vom normalen Curriculum überfordert fühlen und ansonsten mindestens 7 Jahren Bildungsvermittlung in formativen Jahren (Kindergarten und Grundschule) <a href="http://www.bmfsfj.de/doku/Publikationen/genderreport/1-Bildung-ausbildung-und-weiterbildung/1-4-Schulische-bildung/1-4-4-lehrkraefte.html">zu min. 85% durch Frauen stattfindet.</a></p> <p>Aber genug der Klage. Was könnten wir denn tun, um Mädchen für die Softwareentwicklung zu begeistern?</p> <p>Am besten beginnen wir mit dem Verstehen. Quasi Anforderungsanalyse. Das können wir doch, oder? ;-)</p> <p>Laut Studie ist es</p> <blockquote> <p><em>[f]ür fast die Hälfte der befragten Mädchen […] wichtig, anderen Menschen zu helfen […]</em></p></blockquote> <p>Außerdem</p> <blockquote> <p><em>[…] wollen [Schüler] sich in ihrem späteren Beruf vor allem selbst verwirklichen (87 Prozent), das steht noch vor dem Wunsch nach einem gut bezahlten (75 Prozent) und sicheren (71 Prozent) Arbeitsplatz.</em></p></blockquote> <p>Das wollen Mädchen? Anderen helfen und sich selbst verwirklich bei ordentlicher Bezahlung in realistischer Arbeitsplatzsicherheit?</p> <p>WTF! Das können sie doch in der Softwareentwicklung haben. Oder nicht?</p> <p>“Anderen Menschen helfen” bedeutet für Mädchen offensichtlich nicht, dass sie alle Krankenschwestern und Pflegerinnen werden. Sonst hätten wir da keine Nachwuchsprobleme. Sie ergreifen also andere Berufe. Sie werden Verkäuferin, Bankangestellte, Busfahrerin, Steuerberaterin usw. usf.</p> <p>Aber, Leute, ehrlich, das sind doch keine Berufe, in denen man sehr speziell “Menschen hilft”. Klar, Frauen gehen in solche Berufe. Lehrkräfte sind zu 67% Frauen. Sie sind auch Sozialarbeiterinnen und Hebammen. Doch sie arbeiten eben auch in ganz anderen Berufen. Das Motiv “Menschen helfen” zieht für mich also nicht so ganz. Denn dann müssten viel mehr Mädchen auch Bestatterinnen werden wie meine Ex-Frau. Da kann man Menschen sehr unmittelbar helfen.</p> <p>Oder es müssten mehr Mädchen Softwareentwicklerinnen werden. Denn da können sie auch Menschen helfen. Da sind Kollegen, denen immer wieder geholfen werden muss. Gerade in cross-functional Teams. Da sind Kunden, denen man im unmittelbaren Kontakt helfen kann, indem man sich um Verständnis bemüht und dann auch noch nützliche Software herstellt. Und da sind Anwendungen in der Medizintechnik oder für Behörden, die den Menschen helfen, für die die Anwender da sind.</p> <p>Und wie steht es mit der Selbstverwirklichung, den Verdientschancen und der Arbeitsplatzsicherheit? Angesichts der Automatisierungsrevolution die in den nächsten 10 Jahren anrollt, sollte klar sein, dass Softwareentwicklung ein relativ sicherer Hafen sein wird. Es geht nicht mehr nur um Roboter, es geht um Expertensysteme aller Art. Die bringen Berufe in allen Teilen des Spektrums unter Beschuss: vom Taxifahrer bis zum Bankangestellten und darüber hinaus.</p> <p>Bei der Softwareentwicklung hingegen sehe ich da noch keine große Gefahr. Auch neue Tools werden unsere Köpfe nicht ersetzen. Der Bedarf an Software wird den Produktivitätsgewinn mehr als auffressen. Die Softwarekrise ist nicht vorbei. Sie fängt womöglich sogar erst an.</p> <p>Das kann sich auch nur positiv auf Gehälter und “Selbstverwirklichungsmöglichkeiten” auswirken, würde ich sagen.</p> <p>Wo ist also das Problem? Softwareentwicklerin ist ein für Mädchen attraktiver Beruf. Jedenfalls, wenn man die angegebenen Motive für die Berufswahl ernst nimmt. Wir müssen nur lernen, das darzustellen. Wir müssen uns bemühen, an die Vorstellungen von Mädchen anzuschließen. Es braucht Rollenmodelle, es braucht eine Imagekampagne.</p> <p>Da muss man sich ein bisschen Mühe geben. Mehr als bei dem grauslichen <a href="http://pamie.com/2014/11/barbie-fucks-it-up-again/">Barbie-Comic</a>, der gerade durch die Medien geistert. Aber das sollte doch zu machen sein, oder? Warum nicht die Frauen fragen, die schon Softwareentwicklerinnen sind?</p> <p>Nur wer ist für soetwas der Ansprechpartner? Große Firmen - aber nur in einem Zusammenschluss, sonst kommt etwas zu sehr auf ein Unternehmen Zugeschnittenes heraus. Ein Verband fehlt leider bisher. Medien? Ein Ministerium? Am besten wohl alle zusammen.</p> <h3>Was Mädchen wollen - Ein Versuch</h3> <p>Aber vorher müssen wir wohl noch besser verstehen, was Mädchen wirklich, wirklich wollen. Denn ich glaube, das drücken die genannten Motivbeschreibungen nur ungenügend aus.</p> <p>Ich versuche mal, hinter die Begründungen zu schauen und spekuliere auf der Basis dessen, was ich so von außen in der Welt erkennen kann:</p> <ul> <li>Mit “anderen Menschen helfen” ist nicht gemeint, echt Bedürftigen zu helfen. Ich glaube, es geht um etwas viel Allgemeineres: Beziehungen. Mädchen ist der direkte Umgang mit etwas Lebendigem (Mensch, Tier, Pflanze) wichtig. Ihr Interesse ist insofern eher nach außen gewandt, umweltbezogen. Männer die auf Maschinen starren, Frauen die mit Menschen reden. So könnte man es vielleicht überspitzt ausdrücken. “Helfen” ist also nicht so wichtig wie Dialog.</li> <li>Mit “sich selbst verwirklichen” ist gemeint, sich immer wieder neu zu entscheiden. Mädchen wollen sich nicht auf eine Berufskarriere festlegen. Sie sind natürlich nicht mehr zufrieden mit “Hausfrauendasein”. Aber sie möchten die Idee einer Familie auch nicht dem Beruf opfern. Dazu braucht es Flexibilität: Der Beruf muss ermöglichen, eine Zeit lang zu arbeiten und dann zu pausieren und dann auch wieder anzufangen, womöglich in Teilzeit. Arbeitgeber und Metier müssen das hergeben.</li></ul> <p>In “manifest speak” ließe sich das vielleicht so zusammenfassen:</p> <ul> <li>Communication over technology</li> <li>Flexibility over career</li></ul> <p>Ha! Das ist knackig.</p> <p>Und ließe sich das denn nicht einrichten? Keine Chance, dass sich Softwareentwicklung so darstellen bzw. sich dahin entwickeln ließe?</p> <p>Wenn es da Schwierigkeiten geben sollte, dann nicht, weil die Softwareentwicklung so nicht sein kann. Nein, Schwierigkeiten sehe ich nicht im Metier, sondern nur im Willen von Unternehmen (und vielleicht einzelner Entwickler, die um einen Nimbus fürchten).</p> <p>Die Nachwuchskatastrophe lässt sich also abwenden - wenn wir wollen. Ich denke, die Softwareentwicklung kann für Mädchen mindestens so attraktiv sein wie das Bankenwesen oder die Betriebswirtschaft oder das Behördenwesen. Wenn nicht sogar attraktiver, oder? Das können wir doch hinkriegen, my fellow men.</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Unternehmen mögen noch nicht glauben, dass Software so wichtig ist. Aber das wird sich noch verändern. Selbst der letzte mittelständische Maschinenbauer wird verstehen, dass der Milliardenumsatz seines 700 Mitarbeiter Unternehmens von den 15 Leuten in der ungeliebten Softwareabteilung abhängig ist. Man könnte fasst revolutionspoetisch werden: “Alle Räder stehen still, wenn der Programmierer es so will.” Der Hebel, den die Softwareentwicklung hat, ist sehr lang. <a class="reversefootnote" title="return to article" href="#fnref:1"> ↩</a></p></li> <li id="fn:2"> <p>Was nicht bedeuten soll, dass irgendwelche Attribute zwanghaft irgendeinem biologischen Geschlecht zugeordnet werden sollen. Männer dürfen, nein, sollen natürlich auch empathisch sein und Frauen tough. Je nach Neigung und Situation. Das ändert jedoch nichts daran, dass <em>im Durchschnitt</em> gewisse Eigenschaften eben doch nach biologischem Geschlecht unterschiedlich verteilt sind. (Womit ich keinen Kausalzusammenhang unterstellen will, sondern nur beschreibe, was ich sehe. In die <em>nature vs nurture</em> Debatte möchte ich hier nicht einsteigen.) <a class="reversefootnote" title="return to article" href="#fnref:2"> ↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com9tag:blogger.com,1999:blog-6090483181455953305.post-34955433747638314142014-11-23T10:36:00.001+01:002014-11-23T10:36:46.909+01:00Praktische Führung<p>Es wird ja viel über Führung und Management geschrieben. Die einen sind dafür, die anderen dagegen. Aber was ist eigentlich die Aufgabe von Führungspersonen?</p> <p>Eine sehr gute Erklärung liefert aus meiner Sicht Reinhard K. Sprengers Buch “<a href="http://www.amazon.de/Radikal-führen-Reinhard-K-Sprenger-ebook/dp/B0093UKC38">Radikal führen</a>”. Danach hat Führung fünf Kernaufgaben:</p> <ul> <li>Zusammenarbeit organisieren - Klar, das ist der Ausgangspunkt. Verschiedene Aktivitäten müssen so “verdrahtet” werden, dass ein Gesamtergebnis entsteht. Dazu gehört natürlich auch die Zielsetzung.</li> <li>Transaktionskosten senken - Für die Zusammenarbeit müssen günstige Rahmenbedingungen geschaffen werden. “Irgendwie” kann man sich auch ohne Führung zusammenraufen. Mit Führung soll es ökonomischer sein.</li> <li>Konflikte auflösen helfen - Irgendwas ist immer. Dann muss Führung helfen, wieder Kohärenz herzustellen.</li> <li>Zukunftsfähigkeit sichern - Heute gut zusammenarbeiten, bedeutet nicht, dass das auch noch morgen funktioniert. Innen wie außen können sich Verhältnisse verändern; darauf muss Führung (proaktiv) reagieren.</li> <li>Mitarbeiter führen - Nicht nur die Zusammenarbeit will geführt werden, auch der Einzelne. Immer geht es ja um Ziele, die erreicht werden sollen. Hilfe kann da nicht schaden. Und schließlich müssen auch noch Stellen in der Zusammenarbeit geeignet besetzt werden, damit es bei guter “Verdrahtung” auch wirklich fließen kann.</li></ul> <p>Wenn ich durch diese Brille auf Unternehmen schaue, dann verstehe ich sehr gut, was funktioniert und was nicht - und warum. Ein Schema, das mir schon sehr geholfen hat.</p> <p>Aber trotzdem: Irgendwas hat mir noch gefehlt beim Verständnis. Und das ist mir heute klar geworden, als ich mit meiner Tochter einen Nähkurs bei <a href="http://www.zickundzack.com/">Zick und Zack</a> in Hamburg besucht habe.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-KnXgZspxBrk/VHGqoI3LLxI/AAAAAAAAEEo/rRQ0t3-mm00/image%25255B6%25255D.png?imgmax=800" width="368" height="281"></p> <p>Dort wurde uns nämlich gesagt, dass eine Nähmaschine Führung brauche.</p> <p>Der zu nähende Stoff muss unter der stationären automatischen Nadel entlangbewegt werden, um eine Naht zu produzieren. Das übernimmt der <em>Transporteur</em> unterhalb der Nadel.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-Nu0VqO6f_1g/VHGqpJt0x_I/AAAAAAAAEEs/p_ND_76ohIc/image%25255B12%25255D.png?imgmax=800" width="374" height="283"></p> <p>Er zieht den Stoff, den der <em>Nähfuß</em> auf ihn drückt, an der Nadel vorbei. Die Richtung ist einstellbar; normalerweise bewegt sich der Stoff weg vom Näher, aber der kann ihn auch zu sich hin wandern lassen.</p> <p>Der Stoff ist also grundsätzlich in Bewegung, die Naht entsteht von allein. Irgendwie. Denn bisher ist da sozusagen nur “rohe Kraft am walten”.</p> <p>Was jetzt noch fehlt, das ist… Führung.</p> <p>Die “rohe Kraft” des Transporteurs muss auf ein Ziel ausgerichtet werden. Und zwar immer wieder.</p> <p>Hier sehen Sie, wie ich zur Übung entlang auf den Stoff gezeichneter Linien nähe. Der Stoff bewegt sich zwar von allein - nur nicht unbedingt “linientreu”. Ich muss ihn immer wieder nach-führen.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-GbCozZqjzKo/VHGqp0LwyJI/AAAAAAAAEE4/AvMuLkKJhRg/image%25255B19%25255D.png?imgmax=800" width="367" height="379"></p> <p>Dazu gehört, dass ich die Richtung korrigiere, indem ich den Stoff unter der Nadel drehe. Wenn die Richtungsänderung zu krass ist wie bei einer Zickzack-Linie, muss ich den Nähvorgang dafür sogar unterbrechen.</p> <p>Darüber hinaus muss ich die “globale” Geschwindigkeit regulieren. Das tue ich über einen Fußschalter. Der bestimmt, wieviel “Input” sich die Maschine zum Nähen holt. Der Transporteur zieht sich ja den Stoff selbst.</p> <p>Das ist aber noch nicht alles. Mein Aha-Moment bestand darin, dass ich <em>fühlen</em> konnte, was Micro-Management bedeutet.</p> <p>Micro-Management entsteht nämlich immer dann, wenn zusätzlich zum allgemeinen Arbeitsfluss noch versucht wird, im Detail zu optimieren. Man überlässt das Resultat nicht dem Prozess, sondern greift lokal immer wieder ein.</p> <p>Das führt bei Menschen zu Unmut. Die fühlen sich bevormundet; man lässt sie ja nicht die Arbeit tun, für die sie einmal kompetent gehalten wurden, sondern greift ein. Wer micro-managet, der vertraut nicht.</p> <p>Daraus resultieren in Bezug auf den Produktionsfluss Stockungung und Qualitätsverlust.</p> <p>Und genau das habe ich eben spüren können: Sobald ich anfing, den Stoff in Transportrichtung auf die Nadel <em>noch zusätzlich</em> zu zu schieben (Druck, push), war das Ergebnis schlechter. Dito, wenn ich anfing, den Stoff in Transportrichtung <em>noch zusätzlich</em> hinter der Nadel zu ziehen (pull).</p> <p>Die Naht war sofort ungleichmäßig und die Ausrichtung entlang einer Linie fiel sofort schwerer.</p> <p>Führung bedeutet mithin, einen Prozess aufzusetzen - und sich dann weitgehend rauszuhalten. Wer über die im Prozess wirkenden Kräfte noch drückt oder zieht… der betreibt Micro-Management. Das Ergebnis sind Stauungen oder Risse. In jedem Fall gerät etwas aus dem Gleichgewicht und der Arbeitsfluss wird gestört.</p> <p>Führung bedeutet, in Kontakt bleiben mit dem Prozess. Immer wieder schauen, ob der noch fließt und auch noch auf das Ziel ausgerichtet ist. Falls nicht, muss nachjustiert werden - aber vorsichtig. Und eher nicht an den einzelnen Prozesselementen (lokale Optimierung), sondern am Ganzen (globale Optimierung).</p> <p>Wenn es mit der Naht bei mir nicht geklappt hat, dann aufgrund von Micro-Management und zu wenig Blick auf das Ganze. Schlechte Führung also.</p> <p>Es schien einfacher, nah an der Nadel den Stoff zu ziehen/drücken, als die Gesamtgeschwindigkeit zu regulieren. Und es war attraktiver, überhaupt mit der Maschine zu nähen, statt das Nähen vorzubereiten. So habe ich zum Beispiel ein Band, das ich auf eine Tasche nähen wollte, nicht vorher mit Nadeln ausreichend fixiert. Ich dachte, ich kriege es durch Eingriffe nahe an der Nadel während des Stoffdurchlaufs hin, das Band gerade drauf zu nähen. So musste ich auf die harte Tour lernen, dass gute Vorbereitung hilft, den Durchsatz zu erhöhen.</p> <p>Auch das gehört zu Führung: Bewusstsein dafür vermitteln, dass zu guter Zusammenarbeit auch darin besteht, auf Qualität von Input und Output zu achten. Systeme definieren sich ja durch das, was zwischen ihren Bestandteilen fließt.</p> <p>Aber auch das ist eine Sache, die eben nicht während der Produktion geschehen sollte. Da müssen die Prozessschritte schon gut “verdrahtet” sein. Führung ist eine Sache des Rahmens, <em>in dem</em> Produktion stattfindet.</p> <p>An der Nähmaschine habe ich ja auch nicht selbst die Naht hergestellt. Dazu greifen die Teile der Nähmaschine ineinander. Vielmehr habe ich in guten Moment einfach nur “sanft” geführt.</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-By-n6zuzxJE/VHGqrDnnroI/AAAAAAAAEFA/swCdatr0xhI/image%25255B25%25255D.png?imgmax=800" width="367" height="372"></p> <p>Das Ergebnis war dann doch passable und nützlich. Ich habe bei der Führung die Kurve gekriegt. Aber wie ist das im Tagesgeschäft? Kriegt Management da auch immer die Führungskurve? Das scheint mir nicht der Fall zu sein.</p> <p>Da ist Micro-Management an der Tagesordnung - insbesondere, wenn irgendetwas sowieso nicht rund läuft. Da wird gedrückt und gezogen, statt auf den Gesamtprozess zu schauen. Wie sind die Prozessbeteiligten eigentlich grundsätzlich zueinander angeordnet? Wie ist die Qualität des Input? Wo gibt es einen Engpass?</p> <p>Vielleicht würde ja mal ein Nähkurs für Führungskräfte helfen? Da kann man eine Menge lernen, nicht nur über Führung. Und Spaß macht es obendrein, mal wieder etwas Anfassbares mit den Händen hergestellt zu haben.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-35865850024166613522014-11-21T16:13:00.001+01:002014-11-21T16:17:19.719+01:00Hacker-Tool für Gedanken<p>Wie soll ich wissen, was ich denke, solange ich es nicht aufgeschrieben habe? So geht es mir oft. Deshalb schreibe ich Blog-Postings und Zeitschriftenartikel und auch Bücher. Das Schreiben hilft mir beim Denken.</p> <p>Aber welches Werkzeug benutzen für das Schreiben? Für den Zeitschriftenartikel ist MS Word der Standard. Aber muss das so sein? Wie könnten Redaktion und Autor vielleicht noch besser zusammenarbeiten? Oder was ist “Gedankensammlungen” in Unternehmen? Oder mit selbstverlegten Büchern oder eben Blog-Artikeln, wo noch mehr Feedback gewünscht ist?</p> <p>Für manches haben sich Wikis sehr empfohlen. Die Materialsammlung für <a href="http://www.clean-code-developer.de" target="_blank">Clean Code Developer</a> haben wir auch in einem Wiki vorgenommen. Für ein Buchmanuskript schien mir das bisher jedoch nicht passend. Da setze ich auf Markdown-Texte, die ich in meiner Dropbox verwalte und per <a href="https://leanpub.com/u/ralfw" target="_blank">Leanpub</a> veröffentliche. Alternativ könnte ich aber auch ein Git-Repository benutzen. Nur für Kommentare von Lesern nah am Text ist das noch nicht das Richtige.</p> <p>Aber jetzt bin ich auf <a href="http://hackpad.com" target="_blank">hackpad.com</a> gestoßen. Das sieht irgendwie cool aus. Artikel, genannt Pads, lassen sich dort so einfach wie in einem Wiki bearbeiten und verlinken. Man kann sie mittels Tags und sog. Collections organisieren und unter dem Dach eines Workspace veröffentlichen.</p> <p>Einfache Refaktorisierung wird unterstützt (“extract pad”), Verlinkungen wie in Wikis sind mühelos, Medien können eingebettet werden. Und: Mehrere Benutzer können am selben Text arbeiten. Gleichzeitig. Man sieht, welche Teile von wem stammen. Explizite Kommentare sind auch möglich. Das finde ich cool für Texte, die “work in progress” sind oder eben das Werk einer Gruppe.</p> <p>Aufsetzen lässt sich ein Workspace bei Hackpad leichter als ein Wiki, finde ich. Deshalb überlege ich mit Stefan Lieser, ob wir unsere nächste Initiative nach Clean Code Developer dort hosten. Zu klären ist dafür jedoch noch, ob Google die Pads von öffentlichen Workspaces ordentlich indexiert.</p> <p>Allemal, so glaube ich, lohnt Hackpad aber einen Blick für alle, die ein Unternehmenswiki einrichten wollen.</p> <p>Hier als Beispiel eines Pads ein <a href="http://geekswithblogs.net/theArchitectsNapkin/archive/2014/11/16/feedback-centric-development---the-one-hacker-way.aspx" target="_blank">Text aus meinem englischen Blog</a>. In dem Pad hier können Sie auch schreiben. Mit “//” beginnen Sie eine Kommentarzeile.</p> <p>Viel Spaß beim einhacken von Gedanken! :-) Hackpad sozusagen als “thought IDE”.</p><script src="https://ralfw.hackpad.com/fOCLNpwNYlW.js"></script><noscript> <div>View <a href="https://ralfw.hackpad.com/fOCLNpwNYlW">Feedback-Centric Development - The One Hacker Way</a> on Hackpad.</noscript></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com0tag:blogger.com,1999:blog-6090483181455953305.post-33044054366436435652014-11-14T14:54:00.001+01:002014-11-14T15:02:30.144+01:00Wunderlist für Personal Kanban<p>Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden.</p> <p>Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen.</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-tf3RMn3Obwg/VGYJc3BSzMI/AAAAAAAAEDM/by436PZ7nDA/image%25255B19%25255D.png?imgmax=800" width="529" height="143"></p> <p>Das funktioniert - aber irgendwie, irgendwie fand ich es zu aufwändig. Die Software <a href="https://kanbanflow.com">KanbanFlow</a> stand mir im Weg. Es fühlte sich umständlich an. Und so schlief die Methode immer wieder ein.</p> <p>Doch nun bin ich wieder dabei. Neues Tool, neues Glück. Hier fühle ich mich freier. Irgendwie. Und das eherne Gesetz des Personal Kanban “Transparenz” wird immer noch erfüllt.</p> <p>Mein neues Tool heißt <a href="https://www.wunderlist.com">Wunderlist</a>. Das gibt es auf allen Geräten und im Browser, selbstverständlich synchronisiert.</p> <p>Es ist viel einfacher. Nix Kanbanbrettspalten. Keine Kärtchen. Einfach nur Listen.</p> <p>Aber genau das macht den Unterschied für mich. Die Bedienung ist mehr auf den Punkt, finde ich.</p> <p>Mein “Backlog”, das, was zu tun ist, pflege ich in verschiedenen Listen. Hier eine als Beispiel geöffnet, weitere sind darunter links zu sehen:</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-z-7tCSddSoA/VGYJdmEyaoI/AAAAAAAAEDU/vE-4ft5hetk/image%25255B20%25255D.png?imgmax=800" width="544" height="163"></p> <p>Das, was ich gerade tue, markiere ich als wichtig, so dass es herausgestellt in einer eigenen Liste steht:</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-66q6pS4T2Jc/VGYJebfO9VI/AAAAAAAAEDc/2i9dqXIDsc8/image%25255B35%25255D.png?imgmax=800" width="543" height="191"></p> <p>Das ist mein WIP (work in progress). Wunderlist bietet da zwar keine WIP-Begrenzung, aber das ist auch nicht so wichtig. Es ist halt meine Verantwortung, nicht mehr als 1–2 Einträge über die Listen hinweg jeweils bis zur Erledigung als wichtig zu markieren.</p> <p>Und am Ende kommen alle Aufgaben ins Archiv. Sie sind dann done:</p> <p><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh5.ggpht.com/-BLL9fW_IHrQ/VGYJfHFCByI/AAAAAAAAEDk/ts9Z_aRuhFo/image%25255B28%25255D.png?imgmax=800" width="545" height="372"></p> <p>Termine, Notizen, Teilaufgaben, Kommentare… das alles gibt es auch. Gelegentlich nutze ich es. Für den häufigsten Fall jedoch, die Abarbeitung von ständig einfließenden Aufgaben, reicht es mir völlig, schnell einen Eintrag in einer Liste machen zu können.</p> <p>Wer sich noch überwältigt fühlt von zu erfüllenden Wünschen, der kann ja mal versuchen, mit Wunderlist etwas Systematik reinzubringen.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com2tag:blogger.com,1999:blog-6090483181455953305.post-89651704068268348852014-11-11T10:58:00.001+01:002014-11-11T10:58:58.923+01:00Die vielen Gesichter des Product Ownership<p>Wie sollte, wie kann Product Ownership aussehen? Stefan Rook hat dazu einen <a href="http://www.scrumexpert.com/videos/product-ownership-as-if-you-meant-it/" target="_blank">Vortrag</a> gehalten:</p> <p><iframe height="281" src="http://player.vimeo.com/video/80135461" frameborder="0" width="500" allowfullscreen mozallowfullscreen webkitallowfullscreen></iframe></p> <p>Product Ownership hat also viele Gesichter. Diese Botschaft hat mir an dem Vortrag gefallen. Mir hat allerdings auch etwas gefehlt. Nämlich die Abstraktion. Was ist das Muster? Worum geht es im Kern?</p> <p>Mag sein, dass das schon allen klar ist. Meine Erfahrung ist jedoch, dass die meisten Unternehmen genau da jedoch herumeiern. Denn wäre es ihnen klar, würde sich die Ermunterung von Stefan Rook, Product Ownership durchaus unterschiedlich zu leben, erübrigen.</p> <p>Hier mein Versuch einer Abstraktion:</p> <p><strong>Die Hauptaufgabe des Product Owners (PO) nach Anschauen des Vortrags ist… die Priorisierung von Anforderungen.</strong></p> <p>Bei Wooga haben die Teams in einem Rahmen alle Freiheit und tun das selbst; in den Teams ist es der Product Lead, denke ich mal, der dafür verantwortlich ist, aber wohl sehr eng mit seinen wenigen Teamkollegen in dieser Hinsicht zusammenarbeitet.</p> <p>Bei Jimdo ist es der Manager mit dem PO-Hut auf.</p> <p>Bei der Zeitung gibt es dafür die Berechnungsvorschrift im Tagesgeschäft, die vom PO verwaltet wird.</p> <p>Immer gibt es eine Reihe von Stakeholdern mit Wünschen; immer müssen diese Wünsche mit begrenzten Ressourcen erfüllt werden; also muss immer priorisiert werden. Ohne Priorisierung gibt es keine geordnete, verlässliche Umsetzung.</p> <h3>Ziele</h3> <p>Die besprochenen Szenarien unterscheiden sich darin nicht, sondern in der Zahl der Ziele, auf die hin die Wunscherfüllung priorisiert werden muss. Bei Wooga gibt es viele gleichzeitige Ziele; jedes Projekt hat seines. Bei Jimdo und der Zeitung hingegen gibt es nur eines.</p> <p>Jedes Ziel hat viele Stakeholder und braucht daher einen PO der deren Wünsche auf die eine Umsetzungsressource hin priorisiert.</p> <p>Wenn Sie Ihre PO-Strategie nun überdenken wollen, dann fragen Sie sich: Welche Ziele gibt es? Jedes verdient einen PO.</p> <h3>Gewichtung</h3> <p>Der PO hat in Bezug auf ein Ziel hin die Kompetenz (und Erlaubnis) zur Priorisierung. Und wie macht er das? Bei Wooga und Jimdo erfahren wir nichts darüber. Das kann “nach Gefühl und Wellenschlag” gehen. Bei der Zeitung hingegen, wird eine Formalisierung angedeutet. Dort wird “ohne Zorn und Eifer” priorisiert; alle Stakeholder stehen “im fairen Wettstreit”. Solange sie ihre Wünsche ehrlich in verschiedenen Kategorien bewerten, ergibt sich eine vorteilhafte Hitliste von Wünschen.</p> <p>Dieser Unterschied ist für mich deutlich genug herausgekommen: Priorisierung kann mehr oder weniger formal geschehen. Jedes Unternehmen muss sich also fragen, wie nachvollziehbar die Priorisierung sein soll (oder auch kann).</p> <p>Noch betrüblicher fand ich dann, dass die Bewertung bei der Zeitung so stehengelassen wurde. Als seien die Bewertungen gleichzeitig die Prioritäten.</p> <p>Der PO als Herr über den ROI. Das wurde schon am Anfang gesagt. Kann er diese Aufgabe mit den Bewertungen in der Hand aber erfüllen? Nein.</p> <p>Die Bewertungen, also Wertzuschreibungen die mehr oder weniger direkt auf erwartete verringerte Verluste oder vergrößerte Umsätze/Gewinne verweisen, sind nur ein erster Input für die Priorisierung. Schön, wenn Anforderung A bei Umsetzung 100.000 EUR einbrächte. Aber über welchen Zeitraum – und vor allem: mit welchem Aufwand?</p> <p>Leistung ist nicht Arbeit und auch nicht Arbeit mal Zeit, sondern Arbeit pro Zeit. Die Aufgabe des PO bei der Priorisierung ist es, die Leistung zu optimieren. Die besteht darin, möglichst viel Wert mit möglichst wenig Aufwand zu schaffen.</p> <p>Dieser Gedanke steckt auch in der Priorisierung mit “<a href="http://agile102.blogspot.de/2013/01/weighted-shortest-job-first-bit-of-safe.html" target="_blank">Weighted Shortest Job First</a>” (WSJF). Einem Wert wird dort ein Aufwand gegenübergestellt, so dass sich ein Gewicht ergibt. Je gewichtiger dann ein Wunsch, desto eher sollte er umgesetzt werden.</p> <p>Ein Wert von 100, der mit einem Aufwand von 10 realisiert werden kann (Gewicht: 100/10=10), hat ein geringeres Gewicht, als ein Wert von 50, der mit einem Aufwand von 4 realisierbar ist (Gewicht: 50/4=12,5).</p> <p>Wie Wert und Aufwand ermittelt werden, ist von Ziel zu Ziel verschieden. Das finde ich wichtig herauszustellen. <strong>Um die Priorisierung gewissenhaft vornehmen zu können, muss ein PO also Wertmaßstäbe und Aufwandsmaßstäbe definieren.</strong></p> <p>Wer dann entscheidet, “das mache ich aus dem Bauch heraus”, muss nicht falsch liegen. Nachvollziehbar ist das jedoch kaum. Und was das für flüssige Kommunikation und Vertrauensaufbau bedeutet, kann man sich denken.</p> <p>Aber… warum soll es nicht Situationen geben, wo das (zunächst) ausreicht? Entscheidend ist, dass man sich einmal dazu Gedanken gemacht hat – und in Retrospektiven die Annahmen immer wieder überprüft.</p> <h3>Abnahme</h3> <p>Am bedauerlichsten fand ich, dass der Vortrag nichts über die Aufgabe des POs als schließende Klammer der “Wertproduktion” gesagt hat. Es wurden nur Varianten der öffnenden Klammer gezeigt. (Was allerdings in der Tradition der Scrum-Darstellungen ist, die vor allem Backlog und Planning betonen – das Review bzw. die Abnahme demgegenüber jedoch vergleichsweise schwach ausleuchten.)</p> <p>Das halte ich für einen Kardinalfehler, weil sich genau hier nämlich immer wieder das größte Problem von POs zeigt: Sie glauben, sie könnten Anforderungen “über den Zaun kippen” und bekommen dann “wie versprochen” Wert geliefert.</p> <p>Das ist der Ansatz “Stopfgans”. Da hilft auch nicht, am Anfang in schönem Einvernehmen mit Entwicklern über User Stories zu diskutieren.</p> <p>Wenn der PO nicht an der “Wertschöpfung” zieht, entsteht kein rechter Fluss.</p> <p>Hier spekuliere ich mal in Bezug auf die vorgestellten Szenarien: Bei Wooga und Jimdo ist das kein Problem, weil der PO besonders eng-agiert an den Entwicklern dran ist. Abnahme passiert hier ständig. Das große Ziel ist auch allen klar. Hohe Kohärenz der Energie aller Beteiligten. Bei Wooga nehme ich sogar an, dass die Entwickler wie bei Open Source Projekten z.T. ihre eigenen Kunden sind.</p> <p>Schön, wenn das so ist – nur muss man eben wissen, warum es funktioniert. Co-location reicht da nicht aus. Es kommt auf den <em>Willen</em> des PO an.</p> <p>Wie es bei der Zeitung ist, kann ich nur ahnen. Die Priorisierung ist explizit. Schön. Aber wie ist die Abnahme? Zieht da jemand an Wert? Wie groß sind die Brocken, die in die Entwicklung hineingekippt werden? Nach meiner Erfahrung mit größeren Unternehmen vermute ich, dass das nicht so einfach fließt wie bei Wooga und Jimdo. Man glaubt eher, dass “Reinkippen” schon ein Garant dafür ist, dass auch etwas rauskommt.</p> <p>Aber ich kann nicht beurteilen, wie es dort ist. Ich kann nur betonen, wie wichtig eben die schließende Klammer Abnahme bei der Softwareentwicklung ist. Automatisierte Akzeptanztests sind nicht genug. Ein Mensch auf 2 Beinen erzeugt viel mehr Zug als ein paar Tests, die auf grün gehen müssen.</p> <p>Der PO ist für mich <a href="http://blog.ralfw.de/2014/06/die-wichtigste-rolle-in-der.html" target="_blank">die wichtigste Rolle in der Softwareentwicklung</a>. Angesichts dessen, welch feste Strukturen in der Codierung entstehen und wie schwer es ist, dafür gute Leute zu finden, ist die Qualitätssicherung bei den Anforderungen immens wichtig. Vor der Codierung und nach der Codierung. Einen PO einzusetzen ist eine Maßnahme im Sinne des 3. Fokussierungsschritts der <a href="http://de.wikipedia.org/wiki/Theory_of_Constraints" target="_blank">Theory of Constraints</a> (TOC).</p> <p>Ohne PO ist die Codierung der Engpass der Softwareproduktion. Mit PO… wird allerdings schnell der PO zum Engpass. Daher bin ich nicht überzeugt, dass das Jimdo-Modell oben auf der Liste zur Nachahmung stehen sollte. PO sein ist ein Vollzeitjob (außer bei trivialen Zielen). PO+Entwickler oder PO+Geschäftsführer sind für mich Anti-Patterns.</p> <h3>Bottom line</h3> <p>Ich stimme Stefan Rook zu, dass Product Ownership viele Gesichter haben kann. Welches zu einem Unternehmen passt, muss sich jedoch aus der Beachtung von Prinzipien ergeben:</p> <ul> <li>Anforderungen im Rahmen eines Ziels müssen auf dem Weg zu den “Transformatoren” durch 1 Instanz gehen, den PO. Er ist die “single source of truth”.</li> <li>Der PO priorisiert durch Gewichtung in angemessener Nachvollziehbarkeit. Er stellt dafür Wert und Aufwand gegenüber.</li> <li>Was im System zur Umsetzung ist, muss möglichst schnell aus dem System herausgezogen werden. Erst dann entsteht Wert. Die vornehmste Aufgabe des PO ist daher der Zug am Ende der Produktionskette, die Abnahme. <a href="http://geekswithblogs.net/theArchitectsNapkin/archive/2014/10/27/software-development-must-deliver-on-budget---always.aspx" target="_blank">Die muss ab-so-lut verlässlich geschehen.</a></li></ul> <p>Im Rahmen dieser Prinzipien können Sie jede Form des Product Ownership wählen. Form Follows Function. Oder sie fragen sie mit diesen Prinzipien in der Hand, was Ihrem heutigen Product Ownership womöglich noch fehlt.</p> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com2tag:blogger.com,1999:blog-6090483181455953305.post-58082830839391136472014-10-03T21:52:00.001+02:002014-10-03T21:52:07.892+02:00Regelmäßiges Lernen - Meine Retrospektive<p>Ende Juni 2014 hatte ich versprochen, ich würde nun auch noch expliziter das Lernen in meine Arbeitszeit einbauen. Zwar besteht mein Job als Berater, Trainer, Autor zu einem großen Teil ohnehin aus Lernen, doch das hat eine andere Qualität als das, was ich meinen Seminarteilnehmern und Kunden nahelege. Mein Job ist Lernen, deren Job ist es nicht.<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup></p> <p>Wenn ich Softwareentwickler empfehle, in der Arbeitszeit zu lernen, dann bürde ich ihnen scheinbar eine extra Aufgabe auf. Das war bei meinem Lernen bisher nicht der Fall gewesen. Deshalb wollte ich mein Lernen noch expliziter machen; es sollte auch für mich eine zusätzliche Aufgabe im Tagesgeschäft werden, damit ich einmal fühle, wie es meinen Kunden geht.</p> <p><a href="http://blog.ralfw.de/2014/06/regelmaiges-lernen-mein-commitment.html">Mein Commitment</a> war, dass ich wöchentlich während der Arbeitszeit 2+ Stunden mich auf diese Aufgaben konzentriere:</p> <ul> <li>Französisch lernen</li> <li>Bücher zu Sachthemen außerhalb normaler Lernthemen lese</li> <li>Meditiere, d.h. "Ruhe und Fokus lernen"</li></ul> <p>Und ich hatte versprochen, über meine Erfahrung mit solchem extra Lernen nach drei Monaten zu berichten. Hier nun meine Beobachtungen:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-0ztxcVLxCsI/VC7-ZYsHNHI/AAAAAAAAEBY/doiDRynEZ-Y/image%25255B6%25255D.png?imgmax=800" width="575" height="437"></p> <p>Das sind zwei Auszüge aus meinem Lernprotokoll, das ich mit <a href="https://www.lift.do">Lift</a> geführt habe.</p> <p>Sie sehen, lückenlos ist das nicht. Meine erste Beobachtung also: Es ist nicht leicht. Es ist nicht leicht, an jedem Arbeitstag die 15-30 Minuten aufzuwänden. Irgendetwas anderes schien oft dringender und so war das Lernen dann verschoben auf später und dann auf den nächsten Tag.<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup></p> <p>Gelegentliche "Planübererfüllung" hat das zum Teil wett gemacht, ist langfristig aber keine erfolgversprechende Strategie, würde ich sagen. Das ist wie mit dem Refactoring: wenn man es länger und länger nicht tut, dann ist der Berg am Ende so groß, dass man es auch nicht nachholen kann.</p> <p>Außerdem ist der mentale "Umschaltaufwand" gerade beim Französich Lernen für mich teilweise so hoch, dass in der kurzen Zeit die echte Lernaufmerksamkeit dann noch kürzer ist. Das fühlt sich ineffizient an.</p> <p>Die Lehre, die ich daraus ziehe: <strong>Extra Lernen macht in so kleinen Tageshappen nur sehr bedingt Sinn. Besser scheint mir ein wöchentlicher Lernblock von 2+ Stunden.</strong></p> <p>Manchmal habe ich mir aber auch selbst ein Bein gestellt. Die beste Zeit für Französisch und Sachbuch war der Vormittag - ebenso jedoch auch fürs Schreiben. Welcher Tätigkeit dann den Vorzug geben? Die Entscheidung fiel mir leichter fürs Schreiben.</p> <p>Die nächste Lehre daher: <strong>Der Zeitpunkt für Lernen will gut gewählt sein. Und wenn er einmal gewählt ist, sollte die Entscheidung nicht immer wieder neu getroffen werden müssen.</strong> Da geht Kraft verloren. Da zieht Lernen allzu schnell den Kürzeren. Vertagen scheint so einfach, so schmerzfrei. Doch in Wirklichkeit wird nicht vertagt, sondern gestrichen.</p> <p>Aber auch von solchen Äußerlichkeiten unabhängig fiel mir das Lernen nicht immer leicht. Ich habe Wellen der Motivation gespürt. Manchmal klappte es besser, dann war ich für den nächsten Tag motivierter; manchmal klappe es nicht so gut, dann hatte ich am nächsten Tag nicht soviel Lust, mich weiterem Frust auszusetzen.</p> <p>Solche <em>ups and downs</em> lassen sich wohl nicht vermeiden. Aber ich denke, man kann sie mildern. Das ist wie beim Fitnesstraining. Die Lust am Morgen (oder Abend) sich aufzumachen, ist unterschiedlich - da hilft es, wenn jemand auf einen wartet.</p> <p>Ich habe (wieder einmal) übers Lernen gelernt: <strong>Lernen macht mehr Spaß und funktioniert verlässlicher, wenn man es nicht allein machen muss.</strong> Das Mindeste ist ein <a href="http://blog.ralfw.de/2012/06/der-accountability-partner-als.html">Accountability Partner</a>, d.h. eine Person, der man direkt in die Augen blicken und gegenüber Rechenschaft ablegen muss. Eine Person, die den Lerner zieht. Die ihn an seinen Vorsatz erinnert, ihn fordert (aber auch durchaus fördert).</p> <p>Damit meine ich nicht unbedingt einen Lehrer, aber der kann es natürlich auch sein.</p> <p>Ein Mitlerner ist genauso gut. Oder einfach nur jemand, der eben zieht und sonst nichts.</p> <p>Lernen in Teams sollte deshalb nicht Sache der Einzelnen sein, sondern der Gruppe. Gemeinsam Lernzeit einrichten, gemeinsam lernen. Das hilft ungemein.</p> <p>Unterschätzt habe ich am Ende allerdings vor allem einen Aspekt: Relevanz. Nach einer initialen Phase hoher Motivation bin ich beim Französisch Lernen in den Morast gekommen. Es ging nur zäh voran. Nicht, weil es besonders schwierig gewesen wäre. Es lag vielmehr an einer fehlenden Bedeutung des Französischen für mein sonstiges Leben.</p> <p>Ich mag Französisch. Ich würde es gern lesen und auch sprechen können. Doch am Ende ist das nicht jeden Tag wieder genug Antrieb gewesen, um dauerhaft dabei ins Lernen zu kommen. Anders wäre es wahrscheinlich gewesen, hätte ich schon mehr Vokabular drauf gehabt und mit dem Lesen von spannenderer Lektüre anfangen können. So aber war dieses Thema sehr abstrakt.</p> <p>Das bedeutet: <strong>Lernen funktioniert umso besser, je relevanter es für das sonstige Leben (hier: Arbeitsalltag) ist.</strong> Je kleiner der Sprung vom Lernen ins Tagesgeschäft, desto besser. Das muss nicht bedeuten, dass man alles anwenden kann oder Großartiges leisten muss. Aber immer wieder sollte im Arbeitsalltag etwas ein Stückchen leichter fallen, besser werden.</p> <p>Das habe ich bei der Lernaufgabe "Sachbuch lesen" positiv gemerkt. Dort habe häufiger Impulse für die Arbeit bekommen.</p> <p>Diese Retrospektive zu meinem Lern-Commitment mag ernüchternd klingen. Es hat nicht so einfach geklappt, wie gedacht. Auch die Öffentlichkeit, in die ich mich mit dem Commitment begeben hatte, hat daran nicht viel geändert.</p> <p>Doch ich sehe es positiv: Immerhin habe ich dabei etwas gelernt. Auf der Meta-Ebene. Für mich selbst, für meine Kunden oder für Sie braucht es neben der Erkenntnis, dass Lernen wichtig ist, und dem guten Willen einfach noch ein paar Rahmenbedindungen:</p> <ol> <li>Wenn es um echten Lernstoff geht, dann besser jede Woche eine längere Lernzeit einplanen (2+ Stunden).<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup></li> <li>Einen Lernpartner oder zumindest einen Accountability Partner suchen.</li> <li>Immer wieder probieren, den Lernstoff im Alltag anzuwenden. Sozusagen inkrementelles Lernen à la Agilität, d.h. es entsteht sofort Nutzen.</li></ol> <p>Das mögen jetzt keine weltbewegenden Einsichten sein. Irgendwie klingt das doch selbstverständlich. Und doch ist es nochmal etwas anderes, diese Einsichten durch Erfahrung gewonnen zu haben.</p> <p>Angesichts der Wichtigkeit des Lernens und auch des Lernens während der Arbeitszeit, in sich immer wieder etwas anderes dazwischen drängt, ist jeder Gewinn an Klarheit jedoch ein Fortschritt, finde ich. Mit dem falschen Fuß loszugehen, sich Illusionen hinzugeben, enttäuscht nur. Besser ist es, von Anfang an ein realistisches Rahmenwerk aufzubauen.</p> <p>In diesem Sinn ist auch die <a href="http://ccd-school.de">CCD School</a> gedacht. Sie bietet nicht nur Input fürs Lernen, sondern auch eine Form der Begleitung, der Accountability Partnerschaft. Offline geht das im Monatsrhythmus, online auch häufiger.</p> <p>Zu guter Letzt aber doch noch ein Trost: Ich habe auch festgestellt, dass sich manches verselbstständigt. Ich mag mich schließlich nicht so regelmäßig und dauerhaft zur Meditation hingesetzt haben, wie geplant - doch das, was ich damit erreichen wollte, hat sich auf anderem Wege in mein Leben eingeschlichen. Die Fokussierung und das Konzentrieren auf "Innen" finden inzwischen "einfach so" immer wieder statt.</p> <p>Manchmal wird aus extra Lernen also neue Gewohnheit. Dann macht das Thema keine Last mehr, sondern ist Alltag, gar Lust.</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Ob das wirklich eine günstige Sichtweise ist, die Arbeit von Softwareentwickler als nicht (oder nur wenig) lernend anzusehen, lasse ich hier einmal dahingestellt.<a href="#fnref:1" rev="footnote">↩</a></p></li> <li id="fn:2"> <p>Dazu kam, dass ich nicht jeden Tag meine Arbeitszeit einteilen konnte, wie ich wollte, weil ich in Trainings- und Beratungen beim Kunden war.<a href="#fnref:2" rev="footnote">↩</a></p></li> <li id="fn:3"> <p>Anders ist es mit Gewohnheiten oder einzelnen Handlungen. Meditation lässt sich nicht auf einmal pro Woche konzentrieren. Genauso wenig eine tägliche Reflexion, wie sie der <a href="http://www.clean-code-developer.de/Roter-Grad.ashx">Rote Grad</a> des Clean Code Development empfiehlt.<a href="#fnref:3" rev="footnote">↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com2tag:blogger.com,1999:blog-6090483181455953305.post-86416532825282692552014-10-02T08:35:00.001+02:002014-10-02T08:35:24.964+02:00Responsibilities zählen<p>Das <em>Single Responsibility Principle</em> (SRP) ist eine Säule sauberer Softwareentwicklung für hohe Wandelbarkeit. Nicht umsonst macht es auch den Anfang bei den <em>SOLID</em> Prinzipien, würde ich sagen.</p> <p>Aber: Wie finden Sie denn heraus, wieviele Responsibilities (Verantwortlichkeiten) eine Methode oder Klasse hat? "Naja, das sieht man halt", scheint mir ein zu schwammiges Kriterium für ein so zentrales Prinzip.</p> <h3>Was ist eine Verantwortlichkeit?</h3> <p>Bevor es mit dem Zählen losgehen kann, muss natürlich klar sein, was da überhaupt entdeckt und gezählt wird. Was ist eine Verantwortlichkeit?</p> <p>Die Literatur spricht von "only one reason to change". Das finde ich leider nicht wirklich hilfreich. Denn um welche Gründe geht es, worauf beziehen die sich?</p> <p>Ich versuche es daher einmal so:</p> <blockquote> <p>Jede Methode soll nur Anweisungen enthalten, die Anforderungen eines Aspekts erfüllen.</p></blockquote> <p>Diese Definition ist knackiger, erfordert jedoch die Klärung zweier Begriffe:</p> <ul> <li><strong>Aspekt</strong>: Ein Aspekt ist eine Menge von zusammengehörigen Merkmalen, die sich unabhängig von anderen Merkmalen ändern können. Man könnte einen Aspekt auch eine Dimension nennen. Beispiele für Aspekte in der realen Welt sind z.B. Frisur, Kleidung, Bildung. Sie können die Merkmale Ihrer Frisur (Haarfarbe, Haarlänge, Schnitt) unabhängig von Merkmalen Ihrer Kleidung (Stoff, Jahreszeitlichkeit, Stil) oder Bildung (Dauer, Inhalt, Ort) ändern.</li> <li><strong>Anweisung</strong>: Anweisungen sind Sprachkonstrukte, die definieren, was eine Software tun soll. Sie fallen für mich in zwei Kategorien: Logik und Integration. <ul> <li><strong>Logik</strong>: Mit Logik bezeichne ich die essenziellen Anweisung von Programmiersprachen, die der Erfüllung von funktionalen wie qualitativen Anforderungen dienen. Das sind Operatoren, die Daten transformieren, Kontrollstrukturen (z.B. <em>if</em>, <em>while</em>), die den Verarbeitungsfortgang steuern, und Hardwarezugriffe (vermittels API-Aufrufen). Logik beschreibt Algorithmen.</li> <li><strong>Integration</strong>: Integration bindet mehrere Methoden zu einem Datenfluss zusammen.</li></ul></li></ul> <p>Ich denke, jetzt wird auch verständlicher, was "only one reason to change" bedeutet: Methoden sollen nur geändert werden müssen, wenn sich an einem Anforderungsaspekt etwas verändert hat.</p> <p>Methoden sind die kleinsten Container von Programmiersprachen. Darüber liegen für mich in wachsender Größe Klassen, Bibliothekn, Komponenten und µServices. Für die muss das SRP natürlich auch gelten. Also lautet es ganz allgemein:</p> <blockquote> <p>Jeder Container soll nur Anweisungen enthalten, die Anforderungen eines Aspekts erfüllen.</p></blockquote> <p>So zumindest das Ideal. In der Praxis kann und muss sogar davon temporär oder in überschaubarem Maße abgewichten werden. Ziel sollte jedoch ein einziger Aspekt pro Container sein.</p> <p>Außerdem ist zu bedenken, dass Aspekte in Hierarchien existieren. Zum Aspekt der Kleidung mögen die Merkmale Stoff, Jahreszeitlichkeit und Stil gehören. Nur zum Stoff z.B. gehören dann jedoch weitere Sub-Aspekte wie Farbe, Material, Haptik. Kleidung kann aus grobem roten Leinen oder feiner grüner Seide oder rauer gelber Wolle oder feinem gelbem Leinen usw. bestehen.</p> <p>Ein Container auf höherer Abstraktionsebene (z.B. Klasse) kann dann für einen Dachaspekt stehen, der Container von Sub-Aspekten (z.B. Funktionen) zusammenfasst.</p> <h3>Härtegrade</h3> <p>Für mich gibt es Aspekte in unterschiedlichen Härtegraden. Hart sind Aspekte, die man an der Form erkennt. Man muss die Anforderungen nicht verstehen, die Anweisungen erfüllen, sondern nur die Programmiersprache/Plattform.</p> <p>Beispiele hierfür sind die Anweisungsaspekte Logik und Integration sowie der Aspekt Datenstruktur.</p> <p>Innerhalb der Logik können dann jedoch weitere verschiedene Hardwarezugriffe unterschieden werden, z.B. Tastatureingabe, Bildschirmausgabe, Dateisystemzugriff, Datenbankzugriff. Und sogar den Zugriff auf den Heap würde ich dazurechnen, also den Umgang mit Hauptspeicher. Dazu ist zwar kein spezieller API nötig, doch Zugriffe aus globale Daten (statische Felder oder Felder von Objektinstanzen) sind klar erkennbar.</p> <p>Weich hingegen sind Aspekte, bei denen man verstehen muss, worum es geht. Es geht um das <em>Was</em>, wohingegen harte Aspekte das <em>Wie</em> betreffen.</p> <p>Schon die Unterscheidung zwischen lesender und schreibender Logik setzt Interpretation voraus. Es ist daher kein Wunder, dass bei weichen Aspekten schnell Diskussionen entstehen. Der eine empfindet Lesen und Schreiben als Merkmale des selben Aspekts, der andere empfindet sie als getrennt - was sich dann jeweils in unterschiedlicher Aufteilung in Container ausdrückt.</p> <p>Auch hier wieder eine Hierarchie: Lesen und Schreiben sind z.B. Sub-Aspekte von Objektpersistenz (zu der auch z.B. Serialisierung gehört). Und Objektpersistenz ist ein weicher Aspekt von z.B. Personalisierung. Die wiederum ein Aspekt des Anforderungsaspektes Usability ist - welche zur Anforderungskategorie Qualität gehört.</p> <p>Und was folgt aus der Unterscheidung zwischen harten und weichen Aspekten? Halten Sie sich so lange wie möglich bei der Strukturierung von Code an harte Aspekte. Darüber gibt es viel weniger Diskussion. Das macht Ihre Codierung schneller, das macht Reviews konfliktfreier.</p> <p>Am Ende jedoch können Sie natürlich den weichen Aspekten nicht ausweichen. Üben Sie also immer wieder Ihre Sensibilität in der Unterscheidung und Zusammenfassung von weichen, inhaltlichen Merkmalen.</p> <p>Apropos Üben...</p> <h3>Angewandte Aspekterkennung</h3> <p>Zum Abschluss ein Codebeispiel, an dem ich Ihnen die Identifikation von Aspekten praktisch demonstrieren möchte. Ich entnehme es dem Buch <a href="beispielcode%20aus%20http://www.amazon.de/Head-First-C-Jennifer-Greene-ebook/dp/B00ERG0H7E">"Head First C#"</a>.</p> <p><a href="http://lh3.ggpht.com/-EW9V6dYEO1Q/VCzyFkPYyrI/AAAAAAAAEAI/ZlQkaUTyz4k/s1600-h/image%25255B19%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-uf8el-TF2mw/VCzyGkk4ADI/AAAAAAAAEAM/EsbDhHNW5SQ/image_thumb%25255B15%25255D.png?imgmax=800" width="538" height="721"></a></p> <p>Das Szenario? Versuchen Sie es doch einmal dem Code zu entnehmen. Wie Sie feststellen werden, ist das jedoch schwierig. Weil er nicht integriert und kein Titel sichtbar ist. Die Methode <em>Main()</em> enthält ausschließlich Logik. Und die hat ihrer Natur nach denkbar wenig Dokumentationsqualität. Reine Logik muss immer entziffert werden. Hobbyarchäologen sind klar im Vorteil ;-)</p> <p>Aber ich verrate Ihnen das Szenario: Es handelt sich um eine Anwendung zur Darstellung von Dateiinhalten in hexadezimaler Form.</p> <p>Hier nun der von mir mit Aspekten kommentierte Quellcode:</p> <p><a href="http://lh4.ggpht.com/-R41ApclVLaA/VCzyHa2WIFI/AAAAAAAAEAU/DwhmJZocTr8/s1600-h/image%25255B18%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-_1k9wnew-aI/VCzyIPzp50I/AAAAAAAAEAc/h5tsVPpUS3o/image_thumb%25255B14%25255D.png?imgmax=800" width="531" height="531"></a></p> <p>Das Kapitel im Buch heißt "Dateien lesen und schreiben" - aber wie das geht, muss der Leser sich mühsam im ganzen Code zusammensuchen. Nicht nur wie das Problem ganz allgemein gelöst wird, wie der Prozess aussieht, der das gewünschte Verhalten herstellt, ist also unklar. Es wird auch dem technologisch Interessierten schwer gemacht, sich zu informieren.</p> <p>Das ist Bullshit. Das ist dirty code par excellance. Niemandem ist mit soetwas gedient. Und das in deinem Lehrbuch...! Erschreckend.</p> <p>Ich habe vier Aspekte identifiziert, die über den Code verstreut und auch noch geschachtelt sind. Das ist das Gegenteil von Entkopplung.</p> <p>Die Domäne ist die Formatierung von Bytes in hexadezimale und ASCII Darstellung. Aber weder ist diese Domäne als ein für sich stehendes Stück Logik herausgearbeitet, noch die anderen Aspekte.</p> <p>Aber ich will Goethes "Besser machen, nicht nur tadeln, soll den rechten Meister adeln" folgen und Ihnen nicht vorenthalten, wie ich meine, das der Code aussehen sollte.</p> <p>In der reinen Logik unterscheidet sich meine Lösung nur unwesentlich von der im Buch. Doch ich habe die Logik anders (bzw. überhaupt) in Container verpackt. <a href="https://gist.github.com/ralfw/92fe361fdbacc459656a#file-hexdmperv1-cs">Zunächst nur in Funktionen</a>:</p> <p><a href="https://gist.github.com/ralfw/92fe361fdbacc459656a#file-hexdmperv1-cs" target="_blank"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-UMUiCNE4FkQ/VCzyItT_uUI/AAAAAAAAEAk/Q9jb2_egUhQ/image%25255B45%25255D.png?imgmax=800" width="571" height="336"></a></p> <p>Das ist ein erster Schritt. In <em>Main()</em> ist der Prozess nun deutlich sichtbar. Außerdem ist klar, wo welche APIs benutzt werden. Wer sich zum Thema "Dateien lesen und schreiben" informieren will, schaut einfach bei <em>Check_if_file_exists()</em> und <em>Read_blocks_from_file()</em> rein; den Rest kann man dann ignorieren.</p> <p>Wem das nun jedoch zu wenig objektorientiert ist, wer gern noch eine deutlichere Zusammenfassung der Subaspekte sehen möchte, der findet hier <a href="https://gist.github.com/ralfw/92fe361fdbacc459656a#file-hexdmperv2-cs">eine Lösung mit Klassen</a>:</p> <p><a href="https://gist.github.com/ralfw/92fe361fdbacc459656a#file-hexdmperv2-cs" target="_blank"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-jPL-sLEn9yI/VCzyJGaxI7I/AAAAAAAAEAs/IhtKXtFyBDA/image%25255B46%25255D.png?imgmax=800" width="570" height="444"></a></p> <p>Zum Beispiel bündelt die Klasse <em>FileSystemProvider</em> die Methoden, in denen sich Logik befindet, die den API <em>System.IO</em> benutzt.</p> <p>Die Aspekttrennug ist damit deutlicher. Der Preis dafür ist etwas Rauschen: in <em>Main()</em> müssen nun Klassen instanziert werden und Methodenaufrufe haben Objektnamen als Präfix.</p> <p>Überhaupt haben meine Lösungen doppelt oder gar mehr als doppelt so viele LOC (lines of code). Ist das gut? Sollte Code nicht immer so kurz und knapp wie möglich sein? Trägt Knappheit nicht zur Lesbarkeit bei?</p> <p>Klar, wenige Zeilen Code lassen sich leichter überschauen, sozusagen physisch. Aber inhaltlich ist das nicht unbedingt der Fall, nämlich wenn es sich um reine Logik handelt. Das war ja das Problem des ursprünglichen Codes. 40-50 LOC, also rund eine Bildschirmseite, das war nicht viel - und doch war es nur schwer verständlich.</p> <p>Da bezahle ich gern den Preis von etwas Rauschen und mehr LOC, wenn ich dafür Verständlichkeit bekomme. Und die ist nun vorhanden, würde ich sagen.</p> <p>Der Einstieg ins Programm ist sonnenklar. Er beschreibt lesbar, wie das Verhalten "Dateiinhalt als Hex Dump anzeigen" hergestellt wird:</p> <p><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.ggpht.com/-Fgtuyjm-mLc/VCzyJgP0JxI/AAAAAAAAEA0/c0g1KFLMyaQ/image%25255B44%25255D.png?imgmax=800" width="567" height="304"></p> <p><em>Main()</em> hat nun eine einzige, harte Verantwortlichkeit: Integration.</p> <p>Und jede Klasse hat wiederum nur eine einzige Verantwortlichkeit, z.B. <em>FilesystemProvider</em>:</p> <p><a href="http://lh6.ggpht.com/-1CF-_NKoqDw/VCzyKJ29ycI/AAAAAAAAEBA/v2hCk6O0fHg/s1600-h/image%25255B43%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-IhPTPggzCiw/VCzyKiBt5NI/AAAAAAAAEBE/cflOfZIdhtY/image_thumb%25255B31%25255D.png?imgmax=800" width="562" height="401"></a></p> <p>Sie kapselt die Nutzung des <em>System.IO</em> API. Dieser Aspekt zerfällt jedoch in zwei weiche: Prüfen, ob eine Datei existiert, und blockweises Lesen der Bytes aus einer Datei.<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup></p> <h3>Fazit</h3> <p>Das <em>Single Responsibility Principle</em> ist zentral für saubere Softwareentwicklung. Um es anwenden zu können, muss man allerdings wissen, was denn eine <em>Responsibility</em> eigentlich ist.</p> <p>Mit der Definition, die ich gegeben habe, fällt es Ihnen hoffentlich leichter, die Verteilung von Responsibilities in Ihrem Code zu überschauen - und sie dann mit Refaktorisierung zu entzerren.</p> <div class="footnotes"> <hr> <ol> <li id="fn:1"> <p>Ok, ich gebe zu, ein kleinwenig unsauber ist der Code noch. Denn sowohl in <em>Check_if_file_exists()</em> wie in <em>Get_filename()</em> nutze ich zwei APIs. Zum einen den eigentlichen, um den es dort geht (Dateisystem- bzw. Kommandozeilenzugriff), zum anderen jedoch auch den für die Ausgabe auf der Konsole zur Fehlermeldung. Konsequenterweise müsste ich die Fehlermeldung in eine eigene Methode verpacken und z.B. in den <em>ConsoleProvider</em> verschieben. Eigentlich - denn hier lasse ich das mal so stehen. Es ist eine vergleichsweise kleine Sünde. Und wer will schon Perfektion? :-) Wenigstens bin ich mir der “Schmutzrückstände” bewusst.<a href="#fnref:1" rev="footnote">↩</a></p></li></ol></div> Ralf Westphal - One Man Think Tankhttp://www.blogger.com/profile/05225416366856069349noreply@blogger.com6