In seinem Buch „The Psychology of Computer Programming“ schrieb Gerald M. Weinberg bereits 1971 über die Psychologie hinter Softwareentwicklung und die Zusammenarbeit von Entwicklern.
Trotz des hohen Alters des Buches ist dessen Inhalt nach wie vor relevant und in vielen Fällen auch heute noch zu großen Teilen anwendbar.
Ein Teil des Buches umfasst das Thema der 10 Gebote egoloser Softwareentwicklung, dessen Werte und Aussagen eine sehr schöne Grundlage für eine Retrospektive in Entwicklungsteams bietet.
Die 10 Gebote egoloser Softwareentwicklung (frei Übersetzt):
1. Respektiere und Akzeptiere, dass du Fehler machen wirst
Wichtig ist, dass du sie früh findest, bevor Sie es in die produktive Umgebung schaffen. Glücklicherweise, ausgenommen von den wenigen unter uns, welche Raketenlenksysteme bei JPL bauen, sind Fehler nur selten verheerend für das Produkt. Also können und sollten wir über diese lachen, aus Ihnen lernen und weiter machen.
2. Du bist nicht dein Code
Denk daran, dass die Grundidee von Code Reviews ist, Probleme zu finden. Und Probleme werden gefunden. Nimm es nicht persönlich wenn Jemand einen Fehler entdeckt.
3. Egal wie viel „Karate“ du weißt, es gibt immer Jemanden, der mehr weiß
Und genau diese Person kann dir helfen neue Fähigkeiten zu entwickeln, wenn du sie fragst! Suche aktiv und akzeptiere Input von Anderen, besonders dann wenn du denkst, dass es nicht benötigt wird.
4. Refactor Code nicht ohne Konsultation
Es gibt eine dünne Linie zwischen dem beheben von Fehlern und dem Refactoring von Code. Kenne den Unterschied und verfolge stilistische Veränderungen im Rahmen eines Code Review, nicht als alleiniger Vollstrecker.
5. Behandle Menschen welche weniger wissen als du mit Respekt, Ehrerbietung und Geduld
„Nichttechniker“ welche mit Entwicklern täglich zusammenarbeiten müssen, sind fast immer der Meinung, dass Wir (bestenfalls) Diven sind oder schlechtesten falls Heulsusen. Verstärke dieses Klischee nicht durch Wut oder Ungeduld.
6. Die einzige Konstante auf der Welt ist die Veränderung
Sei offen für Diese und akzeptiere sie mit einem Lächeln. Nimm jede Änderung der Anforderungen, Plattform oder Werkzeuge als neue Herausforderung und nicht als ernste Unannehmlichkeit welche es zu bekämpfen gilt.
7. Die einzigst wahre Autorität entsteht aus Wissen, nicht aus der hierarchischen Position
Wissen erzeugt Autorität und Autorität erzeugt Respekt – wenn Sie also Respekt in einer egolosen Umgebung haben wollen, kultivieren Sie Wissen.
8. Kämpfe für Das woran du glaubst, aber akzeptiere Niederlagen würdevoll
Akzeptiere, dass deine Ideen manchmal überstimmt werden. Selbst wenn sich Deine Idee im Nachgang als richtig herausstellt, versuche keine Rache zu nehmen oder „Hab ich doch gesagt“ zu sagen und erkläre deine Idee nicht zu einem Martyrium.
9. Sei nicht „Der Typ da im Raum“
Sei nicht der Typ der im dunklen Keller kodiert und nur kurzfristig auftaucht um neue Cola zu kaufen. Der Typ in dem Raum da, ist nicht kontaktierbar, außerhalb des Sichtweite und außer Kontrolle und hat keinen Platz in einer offenen, kollaborativen Umgebung.
10. Kritisiere Code und nicht die Menschen dahinter – Sei nett zum Coder nicht zum Code
Versuche so oft wie möglich, Kommentare positiv und Codequalitätsorientiert zu kommunizieren. Beziehe Kommentare auf lokale Standards, Programmspezifikationen, erhöhte Perofrmance usw.
Obwowhl diese Zeilen über 45 Jahre alt sind, müsste man nur Kleinigkeiten anpassen um diese unterstreichen zu können. Die Angst Fehler auf produktiven Systemen zu haben muss man von Fall zu Fall betrachten, Code Reviews sind nicht nur zur Fehlererkennung da und eine „Collective Code Ownership“ wird durch das vierte Gebot nicht unbedingt vereinfacht.
In Form einer Retrospektive kann man diese Gebote benutzen um die Bedürfnisse des Teams zu offenbaren und einen neuen Gesprächsfaden zu eröffnen.
In einer von mir gern gewählten Form, bekommt jeder im „Round Robin“ Verfahren je eines der Gebote und liest dieses in der Runde vor. Das Team bekommt dann die Aufgabe, diese Gebote nacheinander in eigenen Worten zusammenzufassen und neu zu formulieren.
Im Anschluss bitte ich jedes Teammitglied eine Zahl von 1-10 aufzuschreiben, welche ihr am wichtigsten ist und diese im Anschluss dem Team vorzustellen.
Oft passiert es hier, dass Teammitglieder ganz neue Seiten von Kollegen kennen lernen und tauschen sich über diese auch nach der Retrospektive regelmäßig aus.
Hast du diese Methode schon mal ausprobiert und ähnliche oder andere Reaktionen bekommen? Ich freue mich auf deinen Kommentar!