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.

Transcript

1. YES, BUT… Tobias Voß viadee Unternehmensberatung Joris Wachter andrena objects (un-)konstruktive Feedbackkultur in Code- Reviews
2. ANTIPATTERN 1 QUICK AND DIRTY Photo by NeONBRAND on Unsplash
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
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
5. IN DER DEFINITION OF DONE?
11. ANTIPATTERN 2 SCHLOSSBAU-SYNDROM
12. 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“)
13. 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
15. ANTIPATTERN 3 DAS UNBEKANNTE VERMEIDEN Bildquelle: unknown / Nicolas Toper / CC-BY 2.0
16. 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
17. 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“
19. ANTIPATTERN 4 JA, ABER… Bildquelle: But ! / Xavier / CC BY 2.0
20. 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
21. 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
23. FEEDBACK Photo by Ryan McGuire on stocksnap
24. Photos from Unsplash BEOBACHTUNG REAKTION IMPULS
25. FEEDBACK DIMENSIONEN • Lösungsweg und Alternativen • Programmierstil, Standards und Clean Code, Tests • Persönliches Feedback
26. FAZIT • Nehmt euch Zeit, setzt euch (virtuell) zusammen und redet miteinander • Vermeidet Kopfmonopole • Guckt über den Tellerrand, bindet verschiedene Perspektiven ein • Nutzt konstruktives Feedback
29. DANKE FÜR DIE AUFMERKSAMKEIT tobias.voss@viadee.de Tobias Voß @tobiaslvoss joris.wachter@andrena.de Joris Wachter @joriswachter