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

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

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. YES, BUT…
    Tobias Voß
    viadee Unternehmensberatung
    Joris Wachter
    andrena objects
    (un-)konstruktive Feedbackkultur in Code-
    Reviews

    View full-size slide

  2. ANTIPATTERN 1
    QUICK AND DIRTY
    Photo by NeONBRAND on Unsplash

    View full-size slide

  3. 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

    View full-size slide

  4. 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

    View full-size slide

  5. IN DER DEFINITION OF DONE?

    View full-size slide

  6. ANTIPATTERN 2
    SCHLOSSBAU-SYNDROM

    View full-size slide

  7. 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“)

    View full-size slide

  8. 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

    View full-size slide

  9. ANTIPATTERN 3
    DAS UNBEKANNTE VERMEIDEN
    Bildquelle: unknown / Nicolas Toper / CC-BY 2.0

    View full-size slide

  10. 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

    View full-size slide

  11. 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“

    View full-size slide

  12. ANTIPATTERN 4
    JA, ABER…
    Bildquelle: But ! / Xavier / CC BY 2.0

    View full-size slide

  13. 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

    View full-size slide

  14. 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

    View full-size slide

  15. FEEDBACK
    Photo by Ryan McGuire on stocksnap

    View full-size slide

  16. Photos from Unsplash
    BEOBACHTUNG
    REAKTION
    IMPULS

    View full-size slide

  17. FEEDBACK
    DIMENSIONEN
    • Lösungsweg und Alternativen
    • Programmierstil, Standards und Clean Code, Tests
    • Persönliches Feedback

    View full-size slide

  18. FAZIT
    • Nehmt euch Zeit, setzt euch (virtuell) zusammen und redet miteinander
    • Vermeidet Kopfmonopole
    • Guckt über den Tellerrand, bindet verschiedene Perspektiven ein
    • Nutzt konstruktives Feedback

    View full-size slide

  19. DANKE FÜR DIE
    AUFMERKSAMKEIT
    [email protected]
    Tobias Voß
    @tobiaslvoss
    [email protected]
    Joris Wachter
    @joriswachter

    View full-size slide