Aktuelle Artikel

Was können wir tun, um Besprechungen effektiver zu gestalten?

Oft haben wir mit den folgenden Problemen zu kämpfen:

• Zu viele Besprechungen reihen sich aneinander und man kommt gar nicht mehr zum Arbeiten.
• Man / Frau nimmt an einer Besprechung teil und weiß gar nicht warum.
• Es gibt keine klare Agenda.
• Das Ergebnis ist unklar.
• "Die Besprechung hätten wir auch mit einer E-Mail erledigen können."
• Wie gestalte ich eine Besprechung, bei der ein Teil der Teilnehmer remote und der andere im Büro teilnimmt?

Größere Aufgaben lassen sich effizient nur dann erledigen, wenn man die Aufgabenlast auf mehrere Schultern gleichzeitig verteilt. Ein synergetischer Effekt stellt sich dann ein, wenn die involvierten Personen in einem Team zusammen arbeiten. Davon profitieren nicht nur die Auftraggeber, sondern auch die Teammitglieder, weil in der Regel die Motivation und der Spaß an der Aufgabe zunimmt. 

In dem folgenden Artikel beleuchte ich die Teamarbeit aus der Sicht eines Teamleiters. Dabei befinden sich die folgenden Punkte im Focus:

• Das Team organisiert sich selbst.
• Die Rolle des Teamleiters.
• Kommunikation
• Äußere Einflüsse
• Transparenz

Ich habe seit rund zwei Jahren die Rolle eines Teamleiters für ein Team von Software-Entwicklern, das neben verschiedenen Web-Projekten auch mit dem Tagesgeschäft und der Pflege von Websites beauftragt ist. Ich habe eine Ausbildung als Scrummaster und bin zertifizierter Software-Architekt. Seit Jahren bin ich in der Rolle eines tech leads und begleite bei Projekt-Spezifikationen. Natürlich war ich vor meiner Tätigkeit als Teamleiter auch Mitglied eines Teams, dennoch sollte der Leser berücksichtigen, dass dieser Artikel subjektiv aus der Sicht eines Teamleiters geschrieben ist. Aber vielleicht gerade deswegen kann ich sagen, dass bei der Teamarbeit das Team und damit jeder Einzelne im Team im Mittelpunkt steht.

Schnaps-Brennen setzt Kunst und Handwerk voraus. Ergänzen sich beide optimal, dann entstehen im Fall der Obstbrennerei vom Schuasdahof Schnäpse und andere Produkte, bei denen man diese Symbiose schmecken kann. Das Brennrecht liegt auf dem Schuasdahof seit 1887, und vor 15 Jahren habe ich schon einmal von der Schnapsproduktion nach altem Vorbild von Johann Astner (Senior) berichtet. Nach etlichen Preisen, die die Schnäpse in der Zwischenzeit eingefahren haben, ist letztes Jahr das Wasserbad um die Brennblase des alten Ofens undicht geworden, und es stand eine Entscheidung an.

Die 30. OOP war die erste, bei der die Teilnehmer Vorträge per Streaming sehen konnten und und dann gleich alle 1541 Teilnehmer alle 164 Vorträge. Die Konferenz für Software Architekten und agile Projektmanager hat Jahrzehnte lang Agilität und Changemanagement im Programm und unterliegt aufgrund der Corona-Situation selbst dem größten Change in ihrer 30 jährigen Geschichte.

Der Responsibility Process lässt sich in sehr vielen verschiedenen Situationen und Bereichen anwenden. Diese beinhalten private wie berufliche Aufgaben bzw. Verantwortungsbereiche. Oft merken wir gar nicht, dass es sich um Verantwortung handelt, oder es eine sein könnte. Viel zu oft finden wir uns in der Situation von Verpflichtung, Rechtfertigen, Schämen, Beschuldigen oder Leugnen -- auch wenn wir uns dessen nicht bewußt sind. Manchmal schiebt man auch eine Verpflichtung von sich weg und dennoch (oder gerade deshalb) belastet sie einen.

Der klassische Workflow eines Software Entwicklers hat sich verändert. Der Entwickler muss selbständiger arbeiten muss kommunikativ sein, Verantwortung zeigen und für den fun-Faktor sorgen. Wie das geht, zeige ich im folgenden Artikel.

Jetzt habe ich schon das dritte Paar Vivobarefoot Schuhe innerhalb von einem halben Jahr und ich bin begeistert. Vom Allrounder Primus Trek über den Motus II hin zum warmen Tracker Firm Ground habe ich für jede Witterung und Gelegenheit den passenden Schuh.

Warum Domain Driven Design (DDD)?

Ein großes Problem in der Software Entwicklung ist die Kommunikation. Durch die hohe Spezialisierung, die aufgrund der vielfältigen Aufgabenstellungen notwendig ist, sprechen Entwickler, Projektmanager, Grafiker, Tester und je nachdem, wer noch in einem Projekt involviert ist, unterschiedliche Sprachen. Das kann zu Verständigungsproblemen führen und manchmal sogar zu Fehlern. Die Konsequenz sind verlängerte Entwicklungszeiten und Motivationsprobleme im Team.

Die Alternative zu gutem Design ist schlechtes Design, nicht überhaupt kein Design. (Douglas Martin)

Die meisten Menschen machen den Fehler zu denken, dass es bei Design nur darum geht, wie es aussieht. ... Es geht nicht nur darum, wie etwas aussieht und sich anfühlt. Design ist, wie etwas funktioniert. (Steve Jobs)

Seit rund 70 Jahren gibt es Software Programmierer. In dieser Zeit sind viele Computer Sprachen und Frameworks entstanden, einen wirklichen Fortschritt haben sie aber nicht gebracht. Oft brachten sie Einschränkungen um vermeintlich bessere Software zu erzwingen. Tatsache ist aber, dass wir heute immer noch mit denselben Problemen zu kämpfen haben, wie vor zig Jahren: Die Software verkommt, kann immer schwerer gepflegt werden und muss ab einem gewissen Zeitpunkt durch komplett neue Software ersetzt werden, obwohl sich die fachlichen Anforderungen kaum verändert haben. Warum haben wir es nicht geschafft, uns in dieser Hinsicht weiter zu entwickeln? Aufgrund der Veränderungen, mit denen wir in unserem direkten Umfeld konfrontiert sind, scheint dies gerade zu grotesk. Wir, die Software Entwickler, haben es nicht geschafft, die Zeit zu nutzen und das Problem zu lösen. Auf die Gründe hierfür aber auch auf mögliche Lösungen möchte ich in diesem folgenden Artikel eingehen.

Die folgenden Erkenntnisse sind nicht auf meinem Erfahrungsschatz gewachsen, noch konnte ich sie im vollen Umfang über die Zeit beobachten. Vielmehr gewinne ich sie über Vorträge Bücher und Online Seminare. Die Quellen Angabe hierzu befindet sich am Ende des Artikels, aber die Namen der der Personen, die mich am meisten beeinflusst haben, kann ich hier schon einmal aufzählen: Robert 'Uncle Bob' Martin, Kevlin Henney, Peter Hruschka, Gernot Starke, Frank Buschmann und einige mehr. Maßgeblich sind aber einige talks von Uncle Bob. Weil diese aber naturgemäß in Englischer Sprache gehalten wurden und einige Kollegen das Deutsche besser konsumieren können, habe ich es mir zur Aufgabe gemacht, dieses Thema mit eigenen Worten auf einer fremden Grundlage zu erörtern. Gegenüber dem Original von Uncle Bob kann ich dabei also nur verlieren.

Uncle Bob

• Robert C. Martin (1952)
• Books
  • Agile Software Development: Principles, Patterns and Practices (2002)
  • Clean Code: A Handbook of Agile Software Craftsmanship (2009)
  • The Clean Coder: A Code of Cunduct for Professional Programmers (2011)
  • Clean Architecture: A Craftsman's Guide to Software Structure and Design (2017)
• Co-Author of Agile Manifesto

In der Software-Entwicklung wird aus Wissen ein Produkt, das Programm, das es den Nutzern leichter macht, Dinge zu tun, ohne das dabei verwendete Wissen vollständig zu besitzen. Je mehr und je effektiver Wissen in die Software fließt, desto besser ist die Software, und desto zufriedener sind die Nutzer. Wissen, die Verteilung des Wissens und die Anwendung sind entscheidende Faktoren für den Erfolg von Software. Im folgenden Artikel geht es um die Verteilung des Wissens, wer dafür gerade steht und wie man das effizient anstellt.

Wie ist Verantwortung auf Management und Team aufgeteilt? Was kann der einzelne dazu beitragen, der Verantwortung gerecht zu werden? Welche Rolle spielen Hormone dabei? Wie kann der einzelne im Team für eine bessere Zusammenarbeit sorgen? Diese Fragen versuche ich in diesem Artikel zu beantworten.

Warum ist feedback wichtig für die persönliche Weiterentwicklung und das Miteinander in der Gruppe? Was hat feedback mit einer guten Lernkultur zu tun? Antworten hierzu soll der folgende Artikel liefern.

Jede Software hat eine Architektur. Nur ist sie nicht immer (sofort) erkennbar. Auf die Frage "Was ist Software-Architektur?" gibt es als Antwort zahlreiche und unterschiedliche Definitionen. Die Frage hat meiner Meinung nach nur akademische Bedeutung.

Viel wichtiger ist die Frage "Welche Bedeutung hat die Architektur für das System?". Ist das System aufgrund der Architektur leicht zu pflegen und zu erweitern, ist es performant und skalierbar, ist es leicht für neue Mitarbeiter zu begreifen, ist es zukunftsfähig. Eine schlechte Architektur kann all diese Punkte zunichte machen.

Die entscheidenden Fragen bezüglich der Software-Architektur fangen also nicht mit 'was' an, sonder mit 'wie'.

Es kamen ein paar Suchende zu einem alten Zenmeister.

„Herr“, fragten sie „was tust du, um glu?cklich und zufrieden zu sein? Wir wa?ren auch gerne so glu?cklich wie du.“ Der Alte antwortete mit mildem La?cheln: „Wenn ich liege, dann liege ich. Wenn ich aufstehe, dann stehe ich auf. Wenn ich gehe, dann gehe ich und wenn ich esse, dann esse ich.“ Die Fragenden schauten etwas betreten in die Runde. Einer platzte heraus: „Bitte, treibe keinen Spott mit uns. Was du sagst, tun wir auch. Wir schlafen, essen und gehen. Aber wir sind nicht glu?cklich. Was ist also dein Geheimnis?“ Es kam die glei- che Antwort: „Wenn ich liege, dann liege ich. Wenn ich aufstehe, dann stehe ich auf. Wenn ich gehe, dann gehe ich und wenn ich esse, dann esse ich.“

Die Unruhe und den Unmut der Suchenden spu?rend, fu?gte der Meister nach einer Weile hinzu: „Sicher liegt auch Ihr und Ihr geht auch und Ihr esst. Aber wa?hrend Ihr liegt, denkt Ihr schon ans Aufstehen. Wa?hrend Ihr aufsteht, u?berlegt Ihr wohin Ihr geht und wa?hrend Ihr geht, fragt Ihr Euch, was Ihr essen werdet. So sind Eure Gedanken sta?ndig woanders und nicht da, wo Ihr gerade seid. In dem Schnittpunkt zwischen Vergan- genheit und Zukunft  ndet das eigentliche Leben statt. Lasst Euch auf diesen nicht messbaren Augenblick ganz ein und Ihr habt die Chance, wirklich glu?cklich und zufrieden zu sein.“

Architektur Antipattern passieren. Software Entwickler erzeugen sie nicht (absichtlich). Antipattern werden in vorhandener Software gefunden, bestaunt und beschimpft. Man kann ihnen auf zwei verschiedenen Wegen begegnen: Zum einen kann man versuchen, sie in Zukunft zu vermeiden. Zum anderen kann man dagegen angehen und beginnen sie aufzulösen.

Im Folgenden werde ich auf einige bekannte Antipattern in der Software-Architektur eingehen und sie hinsichtlich dieser zwei Herangehensweisen untersuchen.

Als Software-Entwickler oder Software-Designer steht man vor der Aufgabe, mit Code zu arbeiten, der von möglichst vielen anderen Entwicklern und Designern verstanden werden können soll. Das schließt den ursprünglichen Autor mit ein, wenn er unter Umständen Jahre danach den Code wieder selbst bearbeitet. Zu rund 80% arbeiten Entwickler mit bestehendem Code und stehen oft vor dem Problem, dass sie ihn nicht (auf Anhieb) verstehen. Das hat unterschiedliche Ursachen:

• Der Quellcode wurde über die Zeit immer wieder unter Umständen von unterschiedlichen Entwicklern ergänzt,
• und er hat unter Umständen unter den vielen verschiedenen Stilen gelitten.
• Durch debugfixing wurde der Code immer nur an lokal mit geringem scope gefixt, ohne das große Ganze zu sehen.

Das realisiert sich dann durch unleserlichen Code oder in einer Software-Architektur, die beide als Vorlage für sogenannte Antipatterns dienen können. Antipattern begegnen uns in zweierlei Hinsicht: Im Kleinen im Code in Form von unverständlichen Bezeichnern, Sprach-Konstrukten oder Code-Strukturen. Im Großen in einer Architektur, die schwer zu verstehen ist und aber auch eine Pflege, Ergänzung oder Fehlerbeseitigung erheblich erschwert.

Egal ob zu Schulzeiten oder später im Berufsalltag, in jeder Lebensphase lernen wir dazu. Dem Schulalltag Entflohene haben oft das Gefühl, das Lernen fällt schwerer als in jungen Jahren. Aufgrund von ständigen Veränderungen im Berufsleben und in der Umwelt wächst der Druck dazu zu lernen. Um dieser Situation besser gerecht werden zu können, macht es Sinn, das Lernen möglichst effektiv zu gestalten.

Im Folgenden gehe ich auf die Motivation zum Lernen, auf die Medien, die eingesetzt werden, auf die Prinzipien beim Lernen und auf effektive Lernmethoden ein.

Rezension über ein Buch von Harald Philipp und Simon Sirch; Flow macht glücklich; das ist zumindest eine plausible Erklärung für das Grinsen, das den meisten Mountainbikern im Gesicht steht, wenn sie auf den Trails entgegenkommen. Dieses Phänomen untersuchen die beiden Autoren Harald Philipp aus der Sicht als bikender Bergsteiger und Simon Sirch aus der Sicht als Sportwissenschaftler, Coach und Erlebnispädagoge. Außerdem gibt es da noch sehr viele sehr schöne Bilder von namhaften Fotografen wie Manfred Stromberg, Tom Brause, Colin Stewart und Sebastian Doerk. Ich sehe das Buch aus der Sicht eines Mountainbikers, der das erzählte nachempfinden kann und nun eine Erklärung bekommt. Ich denke mir aber, dass das Buch auch für nicht-Mountainbiker erklärt, was so faszinierend am Mountainbiken und am Flow ist.

Mit platten Reifen stand es jahrelang in verschiedenen Kellern. Ich kann mich gar nicht mehr erinnern, wann ich das letzte Mal damit gefahren bin. Allerdings habe ich in jungen Jahren einige tausend Kilometer darauf abgespult. Nicht weil es das einzige damals war, oder weil es das Rad war, das ich von meinem Vater geerbt habe. Wahrscheinlich hat es genau aus diesem Grund all die Jahre in den Kellern überlebt. Zumindest waren die Keller trocken und der Stahlrahmen hat nicht zu sehr gelitten. 

Kreativität und logisch denkende Entwickler - passt das zusammen?

Kreativ, wie ein Künstler, Maler? Kreativ wie ein Handwerker oder Tüftler?

Welcher Software-Entwickler glaubt, dass er so kreativ wie ein Künstler arbeitet? Wie ein Handwerker? Wer glaubt, dass ein Entwickler nicht kreativ ist?

Warum schon wieder ein Vortrag über refactoring?

Wie ist das Verhältnis bei den Tätigkeiten eines Entwicklers zwischen neuen Code erstellen und Code warten? Wie viele von den anwesenden Entwicklern haben so angefangen zu Coden in der letzten Woche? Laut Nicholas Zakas kann man von neuen Code erstellen sprechen, wenn ein Entwickler mit einem leeren Editor-Fenster beginnt. (Bücher von Nicholas Zarkas)

Folge: Die meiste Zeit verbringt ein Entwickler damit, Code zu warten. Jedes Mal, wenn Code gewartet wird, stellt sich implizit die Frage, kann soll darf ich diesen Code einem refactoring unterziehen?

Wo lernt man refactoring? Nicht in der Ausbildung, nicht in der Schule nicht im Studium¹. - In der Praxis. daraus kann man ableiten:

• refactoring hat mit Erfahrung zu tun.
• refactoring wird unter anderem von dem Team beeinflusst, in dessen Umfeld der Entwickler arbeitet.

Deshalb kann auf dieses Thema nicht oft genug eingegangen werden, und zwar an der (Arbeits-)Stelle, an der es passiert.

Was ist der größte Feind von refactoring? Rockstar Mentalität - ‘Das ist mein Code und der ist so genial und kunstvoll, so dass niemand daran etwas ändern darf.’ Welcher Entwickler produziert den wertvolleren Code? Der Rockstar oder der Teamplayer? sicherlich der Teamplayer, denn was nützt der genialste Code, wenn er nicht gepflegt werden kann, weil keiner ihn versteht.

Oft haben Entwickler das Gefühl, wenn sie refactoring betreiben, dass sie sich freien Fall befinden, und sie wissen nicht, ob am Ende der Fallschirm aufgeht. Ziel ist es nun, dieses Gefühl gar nicht erst aufkommen zu lassen, beziehungsweise mehr Vertrauen in das gear und die eigenen Fähigkeiten zu bringen.

1. Ein Kollege hat mich auf ein Skript der Fernuniversität Hagen aufmerksam gemacht, welches anscheinend als Grundlage für einen Studiengang dient, und in welchem detailliert mit speziellen Methoden auf Techniken des refactoring eingegangen wird. ?

Gerade lief im österreichischen Free-TV der Film "The Social Network", ein Film über die Gründung von Facebook und seinen Gründer Mark Zuckerberg. Ich glaube, dass der Film von Nerds anders gesehen wird als von nicht-Nerds. Das ist sicher so gewollt. Die Nerds schauen zu ihm auf, weil er als ein genialer Programmierer dargestellt wird, der den Durchbruch geschafft hat. Die nicht-Nerds sehen das gleiche nur auf einer komplett anderen Basis. Welche der beiden Gruppen kann nun besser beurteilen, was da eigentlich passiert ist?

Ich habe letztens ein Buch gelesen, das könnte Dich auch interessieren. Ich kann es Dir ja einmal ausleihen - äh geht ja gar nicht, ist ein E-Book. Konnte man die gedruckten Bücher noch ohne weiteres verleihen, so geht das mit E-Books bis dato überhaupt nicht. Gibt es überhaupt einen technisch organisatorische Möglichkeit E-Books zu verleihen?

Eine Intelligenz 'des Gelingens' fordert Gunter Dueck in seinem Buch 'Professionelle Intelligenz'. Schon fast über zwei Jahre verfolge ich seine Vorträge und das Buch scheint die logische Konsequenz aus seinen bisherigen Reden zu sein, in denen er mahnt, dass vom normalen, arbeitenden Menschen in Zukunft mehr verlangt wird, als dieser in den meisten Fällen gemeinhin angenommen hat. Neben meiner Empfehlung, dieses Buch unbedingt zu lesen, möchte ich aber auch noch der Frage nachgehen, wie wir diesen Forderungen begegnen und sie befriedigen können.

Wer kennt es nicht? Die Vorsätze sind hoch, die Motivation anfangs auch, das Thema ist interessant und wichtig, die Geschichten sind gut und kurzweilig erzählt, das Buch: Clean Code von Robert C. Martin. 

Aber wir kennen den Punkt: früher oder später verliert sich die Motivation und wir verlagern bei der Hälfte des Buches unsere Prioritäten. 

Als großer Fan von den TED Talks bin ich immer wieder begeistert, wie sich die unterschiedlichsten Leute dort auf die Bühne stellen und scheinbar von der Leber weg über Themen referieren, die Ihnen am Herzen liegen. Ein gutes Beispiel ist der Vortrag von Chip Conley zu dem Thema “Measuring what makes life worthwhile”.

Conley untersucht die Frage, wie wir das messen können, worauf es im Leben wirklich ankommt.

Manchmal beneidet man die Menschen aus einer früheren Zeit. Scheinbar war das Leben damals einfacher. Bei einem Besuch des Oberpfälzer Freilandmuseums am 17.06.2007 wurden wir für ein paar Stunden in eine Zeit versetzt, die zwar einfacher als heute erscheint, die aber auch hart war. In meinen Bildern habe ich versucht auf der einen Seite die Nostalgie einzufangen, aber auf den zweiten Blick auch die Demut und Härte des damaligen Alltags - sofern es die wunderbaren Vorgaben des Museums es hergaben.