Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Yes, but …“ — (un-)konstruktive Feedbackkultur ...

Tobias Voß
September 08, 2020

Yes, but …“ — (un-)konstruktive Feedbackkultur in Code Reviews

Code Reviews sind ein häufiger Bestandteil der Definition of Done agiler Teams. Doch Feedback geben und annehmen will gelernt sein und muss für eine lösungsorientierte Teamkultur geübt werden, um konstruktiv mit Konflikten umgehen zu können. "Ja, aber" ist ein typisches Beispiel für einen Kommunikations-Fallstrick und schlechte Feedbackkultur, das sich In Code Reviews gerne in Dialogen der Art "Ja, aber ich hätte es anders gemacht oder fände es eleganter, wenn..." manifestiert. Wir wollen anhand konkreter Beispiele aus unserer Praxis aufzeigen, was gute Code Reviews ausmacht und an welchen Stellen ein moderierender oder vermittelnder Eingriff durch den Scrum Master notwendig ist. Dabei betrachten wir auch die psychologischen und gruppendynamischen Faktoren wie wertschätzendes Feedback oder das Johari-Fenster. Damit erklären wir, warum Reviews ein sensibles Thema sind und wie man die Effizienz von Reviews steigern und gleichzeitig die Teamkultur stetig weiterentwickeln kann.

Tobias Voß

September 08, 2020
Tweet

More Decks by Tobias Voß

Other Decks in Programming

Transcript

  1. WAS IST AUFGEFALLEN? • Code Review als lästige Tätigkeit, die

    man noch machen „muss“ • Keine Erklärungen durch den Entwickler • Keine Nachfragen des Reviewers • Keine Diskussionen • Man nimmt sich nicht die Zeit, den Code zu verstehen
  2. ANTIPATTERN 1 QUICK & DIRTY • Hauptsache, das Code-Review ist

    abgehakt • Möglichst wenig Zeit investieren, denn die Zeit im Review ist völlig unnütz vertan • Bloß keine Lösungswege erklären • Unit-Tests bitte nicht reviewen, das ist ja kein Anwendungscode
  3. WAS IST AUFGEFALLEN? • Guter Start, Erklärung des Hintergrunds und

    Bezug zur Story • Die einfachen Teile wurden besprochen, die komplizierten nicht • Abblocken durch den Entwickler („das versteht sonst eh keiner“)
  4. ANTIPATTERN 2 SCHLOSSBAU-SYNDROM • Komplexe Logiken am besten nicht von

    mehr als einer Person entwickeln lassen • Hinterfrage nie, was sich der Meister gedacht hat • Der Code gehört dem Entwickler, der ihn geschrieben hat • Nutze Code-Reviews nicht, um Wissen zu verteilen • Baue ein Schloss, das gut geschützt ist
  5. WAS IST AUFGEFALLEN? • Das Wissen endet an den Schnittstellen

    – kein Blick über den Tellerrand • Magische Konstanten (wie 404) werden verwendet, ohne die Bedeutung zu verstehen • Kein Interesse an Nachbarsystemen oder –schichten • Reviewer und Autor haben gleichen Wissensbereich und damit eine hohe gemeinsame „Unbekannte“ • Die Verantwortung endet an den Schnittstellen – keine Ende-zu-Ende-Sicht
  6. ANTIPATTERN 3 DAS UNBEKANNTE VERMEIDEN • Bloß keinen Code angucken,

    den man nicht direkt versteht • Ich brauche doch eine API, die ich benutze, nicht verstehen • Ich muss doch nicht wissen, was meine Aufrufer mit den Ergebnissen anfangen • Code-Review in immer denselben Konstellationen • Code-Review nur innerhalb eines Skills und einer Schicht / technischen Expertise • „Das wird schon so stimmen, wenn Olli das sagt“
  7. WAS IST AUFGEFALLEN? • Reviewer kontrolliert, ist abfällig, besserwisserisch •

    Reviewer droht und wertet ab • Reviewer erklärt nicht oder bietet Hilfe an, sondern verlangt Lösungen • Reviewer setzt Frist • Reviewer akzeptiert keine Fehler
  8. ANTIPATTERN 4 JA, ABER • Bloß nichts erklären, der andere

    wird es schon selbst herausfinden • Wertschätzender Umgang ist etwas für Weicheier • Unter Druck entstehen Diamanten • Andere kleiner machen, lässt mich größer wirken • Fehler dulde ich nicht • Alles, was ich nicht selbst mache, wird eh nur Mist • Mehr reden als zuhören
  9. FAZIT • Nehmt euch Zeit, setzt euch (virtuell) zusammen und

    redet miteinander • Vermeidet Kopfmonopole • Guckt über den Tellerrand, bindet verschiedene Perspektiven ein • Nutzt konstruktives Feedback