CCR in der Praxis: Wie „Collaborate Constructive Review“ Teams besser macht – Einsichten aus „CCR“ von Richard Draxelmayr (FREQUENTIS)

Warum dieser Talk für Engineering-Teams relevant ist

Im Talk „CCR“ von Richard Draxelmayr (FREQUENTIS) geht es nicht um die Band, sondern um „Collaborate Constructive Review“. Der Software- und Systemingenieur arbeitet seit 2015 bei FREQUENTIS, einem Unternehmen für sicherheitskritische Kommunikationslösungen. Aus dieser Praxis heraus beschreibt er, was gute Reviews ausmacht, wie man den Prozess technisch und organisatorisch aufsetzt und welche Stolpersteine Teams bewusst adressieren sollten.

Von Haus aus Entwickler, bringt Draxelmayr eine softwarezentrierte Denkweise in ein eher softwarearmes Umfeld – und verankert dabei automatische Qualitätsprüfungen, wo immer es geht. Seine Bandbreite reicht von Web-UIs über automatisiertes Lasttesten und Trainings bis hin zu einem Spring-Boot-basierten REST-Backend. Hauptsächlich arbeitet er an einem automatisierten Deployment-Tool mit Ansible. Genau diese operative Nähe macht seinen Erfahrungsbericht besonders nützlich: kein abstrakter Leitfaden, sondern ein auf das Wesentliche verdichteter Werkzeugkasten.

Wir von DevJobs.at haben aufmerksam zugehört und die wesentlichen Punkte strukturiert: Was ist der Wert von Reviews? Wie setzen Teams den Prozess so auf, dass er skaliert? Welche Tools und Automatismen helfen, und welche Etikette sorgt dafür, dass die Sache konstruktiv bleibt?

Der Mehrwert von Reviews: Fünf Gründe, die tragen

Richard beginnt eindeutig: Reviews sind großartig. Die Gründe sind handfest und praxisnah:

• Ownership-Transfer: Verantwortung wandert vom Individuum ins Team. Die Beiträge einzelner bleiben sichtbar, aber die Verantwortung wird geteilt. Aus „mein Code, mein Risiko“ wird „unser Code, unser Standard“ – konkret: „es erlaubt, die Verantwortung von einer Person auf das Team zu verlagern“.
• Know-how-Transfer in alle Richtungen: Reviews sind Lernräume – sowohl für Einsteiger als auch für Erfahrene. Ob clevere Generatorfunktionen in JavaScript oder der Hinweis auf Pythons Deep-Copy-Funktionen: „Reviews sind ein großartiger Ort zum Lernen – und das in alle Richtungen.“
• Teamphilosophie schärfen und bewahren: Unterschiedliche Meinungen sind natürlich. Reviews sind der Ort, an dem daraus eine gemeinsame, gelebte Linie wird. Entscheidungen bleiben nachverfolgbar und lassen sich in künftigen Reviews verankern.
• Aktivitätsstrom der Codebasis: Man kann nicht jeden Commit im Detail kennen. Aber über Reviews bleiben Kolleginnen und Kollegen an entscheidenden Änderungen dran. Das schlägt das böse Erwachen, wenn man nach Monaten in unbekanntes, „unwiedererkennbares“ Territorium zurückkehrt.
• Mehr Augen sehen mehr: Reviews finden nicht jeden Fehler – aber jene, die in Reviews auffindbar sind, werden so entdeckt. Oder wie er es sinngemäß zusammenfasst: „Mehr Augen sehen mehr Defizite.“

Diese Punkte sind besonders in sicherheitskritischen Domänen entscheidend. Doch der Nutzen gilt universell: Qualität, Teamverständnis und Transparenz steigen, wenn man Reviews richtig aufsetzt.

Gegenargumente ernst nehmen – und entschärfen

Richard blendet Gegenargumente nicht aus. Drei Risiken benennt er ausdrücklich:

• Zeitaufwand: Reviews kosten Zeit, die anderswo fehlt. Sein Konter: In sicherheitskritischen Kontexten lohnt es sich doppelt. Und generell ist eine zweite Perspektive – gerade bei „gnarly“ Implementierungsproblemen – den Aufwand wert.
• Kreativitätshemmung durch Peer Pressure: Starke, erfahrene Stimmen können Ideen dämpfen. Er empfiehlt bewusst Räume für Exploration: etwa Spikes, um neue Technologien zu erkunden, oder sogar einen „Charisma-Sprint“, in dem „Leute machen können, was sie wollen“ – also explizit Zeit für Experiment und Neugier.
• Unausgewogene Review-Last: Nichts frustriert mehr, als wochenlang nur Reviews zu machen und beim eigenen Workstream abgehängt zu werden. Sein Rat: Solche Muster früh erkennen und adressieren, bevor sie Teamklima und Review-Qualität abstumpfen lassen.

Kurz: Risiken sind real, aber mit klaren Regeln und Transparenz gut beherrschbar.

Drei Säulen eines starken Review-Prozesses

Richard destilliert den Review-Erfolg auf drei Grundlagen: Tooling, Automation und Etikette. Oder in seinen Worten: „Tooling ist dein Brot und Butter“, Automation fokussiert auf das Wichtige, und Etikette entscheidet, ob Inhalte ankommen.

1) Tooling: Diff, Kommentare, Aufgaben, Navigation, Historie

Wer einmal versucht hat, Word-Dokumente über mehrere Review-Runden zu tracken, kennt das Problem: „Nach der zweiten Runde hat niemand mehr eine Ahnung, was los ist.“ Für Code gibt es hingegen ausgereifte Tools.

Worauf er achtet:

• Gute Diff-Ansicht: Änderungen müssen klar sichtbar sein.
• Kommentare: Kontext geben, Fragen stellen, Missverständnisse klären.
• Aufgaben (Tasks): Verbindlich festhalten, was noch zu ändern ist – idealerweise auf Codezeilen-Ebene.
• Schnelle Navigation: Große Changes effizient durchgehen.
• Rückverfolgbarkeit in die Vergangenheit: Entscheidungen und Diskussionen müssen in Monaten und Jahren nachvollziehbar sein.

Bei FREQUENTIS nutzt das Team Bitbucket On-Premise, Crucible und ein proprietäres Tool. Entscheidend ist nicht der Markenname, sondern die Fähigkeit, oben genannte Merkmale sauber zu unterstützen: Von der visuellen Aufbereitung über Aufgabenmanagement bis zur Langzeit-Historie.

Nicht-Text-Artefakte textfähig machen

Nicht alle Deliverables sind textbasiert. Richards praktischer Ansatz: Intermediate Steps in Text umwandeln, wenn irgend möglich. Bei FREQUENTIS wird die vertragliche API-Dokumentation samt Glossar in Markdown und PlantUML gepflegt und anschließend nach HTML für die breite Nutzung transformiert. Der Vorteil: Man kann die gesamte Stärke der Code-Review-Tools nutzen – inklusive Diffs, Inline-Kommentaren und Tasks – und am Ende dennoch ein konsumierbares Endprodukt ausrollen.

2) Automation: Maschinenarbeit der Maschine überlassen

„Wenn du es automatisieren kannst, dann automatisiere es – besonders im Review-Kontext.“ So lässt sich Richards Haltung zusammenfassen. Der Gewinn: Reviewer fokussieren auf das Wesentliche statt auf Fleißarbeit.

Konkret heißt das:

• Stil und Konventionen durch Tools prüfen lassen: Whitespaces vs. Tabs, Newline am Dateiende, Copyright-Header am richtigen Ort. Das sind Regeln, die Maschinen zuverlässig und konsistent prüfen – Reviewer müssen es nicht ständig wiederholen.
• Automatisierte Qualitätstests: Unit-Tests und generelle Basismetriken gehören nicht in die manuelle Checkliste, sondern in die Pipeline.
• Builds bei jedem Commit: Bei FREQUENTIS werden mit jedem Commit Builds getriggert – sichtbar pro Commit. „Wenn ich etwas falsch mache, sagt mir das System, dass ich es anders machen muss.“
• Quality Gates für Mainline-Branches: Änderungen, die bestimmte Qualitätskriterien nicht erfüllen, werden nicht in Mainline integriert. Richards zugespitzte Formel: „Es gibt keine Diskussion mit der Maschine.“ Die Regeln sind transparent; man kann sie anpassen, aber nicht im Einzelfall „überreden“.
• Vollständiges Deployment auf Testsystem: Für das automatisierte Deployment-Tool, das Richard verantwortet, wird bei jedem Commit auf den Mainline-Developer-Branch ein Full Deployment auf einen Tester ausgelöst – ein Stück Automationspraxis, auf das er „stolz“ ist.

Die Summe dieser Maßnahmen stärkt Konsistenz und Zuverlässigkeit. Zudem befreien sie das Team von Wiederholungen, sodass Reviews die wirklich interessanten Teile betreffen: Architekturentscheidungen, Lesbarkeit, Robustheit, Sicherheitsaspekte.

3) Etikette: Inhalt hoch, Emotion niedrig

Technik allein reicht nicht. „Etikette zählt. Wirklich.“ Richards Kernpunkte zur Kommunikation:

• Feedback in Ich-Form: Statt „Das funktioniert nicht“ lieber „Ich habe das durchdacht und glaube, dass es so nicht wie intendiert funktioniert“. So bleibt Raum für Dialog, statt eine objektive Wahrheit zu reklamieren, die Gegenwehr provoziert.
• Vorschläge mitliefern: Kritik ohne Richtung erzeugt Extra-Arbeit beim Gegenüber. Besser: klar benennen, was geändert werden sollte, und einen konkreten Vorschlag anbieten.
• Diskussionsraum lassen: Kategorien wie „objektive Wahrheit“ sind im Review fehl am Platz. Mehr Deutungsspielraum bedeutet mehr Miteinander.
• Schriftliche Kommunikation ist „kälter“: Intonation und Mimik fehlen. Darum Formulierungen bewusst setzen – kleine Tonverschiebungen („keep your tone changes small“) können große Wirkungen haben.

Diese Haltung ist gerade für Einsteiger wichtig – und genauso für Erfahrene. Sie bestimmt, ob Reviews als Wachstumsraum wahrgenommen werden oder als Hürde.

Umsetzungsschritte: Wie Teams CCR in den Alltag bringen

Aus Richards Talk lassen sich klare Handlungsschritte ableiten, die wir in unserer Redaktion praxisnah zusammenfassen:

1) Tool auswählen, das Kernfunktionen zuverlässig liefert

• Diff-Ansicht, Inline-Kommentare, Aufgaben, schnelle Navigation, Historie.
• On-Premise oder Cloud ist sekundär – entscheidend ist, dass das Team es liebt zu benutzen.

2) Review-Policy definieren

• Welche Änderungen brauchen Review? Wer reviewed wen? Wann ist ein Review „grün“? Wie gehen wir mit Blockern um?
• Notiere Gründe für getroffene Entscheidungen – die Historie ist ein Asset.

3) Stil- und License-Checks automatisieren

• Whitespaces/Tabs, End-of-File-Newline, Copyright-Header.
• So ersparen sich Reviewer den immergleichen Hinweis.

4) Testautomatisierung und Builds pro Commit

• Jede Änderung triggert einen Build – sichtbar und nachvollziehbar.
• Fehlende Tests/Fehler sind zuerst Maschinenthema, nicht Review-Thema.

5) Quality Gates für Mainline aktivieren

• Keine Änderungen, die die Kriterien nicht erfüllen – „keine Diskussion mit der Maschine“.
• Kriterien können und sollen sich entwickeln – aber als Regelwerk, nicht ad hoc.

6) Intermediate Steps für nicht-textuelle Deliverables

• Wo möglich in Markdown/PlantUML oder ähnliche textuelle Formate überführen.
• Danach generieren, was gebraucht wird (z. B. HTML) – Review findet am Textartefakt statt.

7) Review-Last balancieren

• Metriken müssen nicht komplex sein; wichtig ist Sichtbarkeit: Wer reviewed viel, wer kommt zu wenig zum eigenen Arbeiten?
• Früh ansprechen und Workload anpassen.

8) Räume für Exploration schaffen

• Spikes oder ein „Charisma-Sprint“ geben Ideen Raum und mindern Peer-Pressure-Effekte.

9) Etikette explizit machen

• Beispiele für gute Formulierungen teilen: „Ich glaube …“, „Könnten wir …“, „Mein Vorschlag wäre …“.
• Hinweise darauf, wie man Vorschläge statt nackter Kritik liefert.

Praxisdetails aus dem Talk: Was wir uns merken

Einige Aussagen und Bilder aus Richards Vortrag bleiben hängen und helfen beim internen Buy-in:

• „Reviews sind großartig“ – weil sie Verantwortung teilen, Wissen zirkulieren lassen und Teamphilosophie formen.
• „Mehr Augen sehen mehr Defizite“ – der Shorthand für Qualitätsgewinn ohne Überhöhung.
• „Keine Diskussion mit der Maschine“ – Quality Gates beenden Debatten über objektive Mindeststandards.
• „Haltet Ton-Änderungen klein“ – denn schriftliche Kommunikation lädt zu Fehlinterpretation ein.
• „Intermediate Steps textuell“ – Markdown und PlantUML ermöglichen, auch Nicht-Code professionell zu reviewen.
• „Builds mit jedem Commit“ – Transparenz und unmittelbares Feedback sind Gold wert.

Etikette konkret: Formulierungsleitfaden für Reviews

Richard zeigt am Beispiel, wie stark Sprache wirkt. Ein kurzer Leitfaden, der direkt aus seinen Prinzipien ableitbar ist:

• Nicht: „Das funktioniert nicht.“
• Besser: „Ich habe das durchdacht und glaube, dass es so nicht wie intendiert funktioniert.“
• Nicht: „Das ist einfach falsch.“
• Besser: „Mir fällt auf, dass X in Szenario Y problematisch sein könnte. Mein Vorschlag: Z.“
• Nicht: „Mach das anders.“
• Besser: „Könnten wir hier …? Alternativ wäre … denkbar, weil …“
• Always-on: Vorschläge liefern. Der Review-Empfänger sollte klar verstehen, was erwartet wird – und warum.

Dieser Ton schafft Diskussionsraum statt Rechthaberei. Gerade über Textkanäle ist das die halbe Miete.

Häufige Spannungsfelder – und wie sie moderiert werden können

• Es dauert zu lange: Review-Scope bewusst halten. Maschinen prüfen das Standardisierte; Menschen begutachten Logik, Lesbarkeit, Risiken, Architektur.
• Wir wiederholen uns: Linter-Regeln und Formatierung automatisieren, damit Reviewer nicht zum Checkerboard für Whitespaces werden.
• Zu viel Meinung, zu wenig Fakten: Teamphilosophie schriftlich festhalten. Auf vergangene Entscheidungen verweisen („in der Historie verankern“), statt jede Debatte neu zu führen.
• Innovation kommt zu kurz: Spikes und Charisma-Sprints geben neuen Ideen legitime Zeitfenster.
• Review-Burnout: Review-Last sichtbar machen und rotieren.

All diese Punkte sind im Talk angelegt und lassen sich ohne spekulative Zusatzregeln ausrollen.

Fazit: CCR ist eine Haltung – Tooling und Automation machen sie skalierbar

„Reviews sind großartig.“ Nach dem Talk „CCR“ von Richard Draxelmayr (FREQUENTIS) wirkt das nicht wie ein Slogan, sondern wie ein Betriebssystem für Teamarbeit: Verantwortung teilen, Wissen verbreiten, Philosophie schärfen, Änderungen sichtbar machen, Fehler früh finden. Damit das funktioniert, müssen die Maschinen Standardprüfungen übernehmen, Tools Diffs, Kommentare und Aufgaben erstklassig unterstützen und Menschen respektvoll kommunizieren.

Unser Eindruck: Wer Tooling, Automation und Etikette als zusammengehöriges System begreift, schafft es, Reviews vom Pflichtprogramm zum Wettbewerbsvorteil zu machen. Und wer – wie im FREQUENTIS-Setup – Builds bei jedem Commit, Quality Gates für Mainline und sogar automatische Test-Deployments nutzt, verankert Qualität dort, wo sie entstehen muss: in jedem einzelnen Change.

Die einfache Handlungsaufforderung, die bleibt: Wählt euer Review-Tool bewusst, automatisiert alles, was die Maschine besser kann, und sprecht im Review so, dass die Information lauter ist als die Emotion. Dann wird „Collaborate Constructive Review“ nicht nur ein Akronym – sondern gelebte Praxis.

• 

  

  Safety-critical Software Solutions

  Djamel Sahnine von Frequentis zeigt in seinem devjobs.at TechTalk mit welchen Herausforderungen sich die Software Entwicklung im Unternehmen auseinandersetzt.

  Jetzt ansehen
• 

  

  Drones Swim

  Thomas Lutz von Frequentis zeigt in seinem devjobs.at TechTalk welche Rahmenbedingungen geschaffen werden, um in Zukunft mit einer hohen Zahl an Drohnen umgehen zu können.

  Jetzt ansehen

• 

  

  Günter Graf, VP New Business Development von Frequentis

  Der VP New Business Development von Frequentis Günter Graf umreißt im Interview die Inhalte des Unternehmens, was der Fokus bei New Business Development ist und erläutert auch, warum gutes Domain Knowledge den Unterschied macht.

  Jetzt ansehen
• 

  

  Karl Wannenmacher, Head of Public Safety Products von Frequentis

  Der Head of Public Safety Products von Frequentis Karl Wannenmacher erzählt im Interview über die Organisation des Devteams der Abteilung Public Safety, wie dort das Recruiting geschieht und welche technischen Challenges es gibt.

  Jetzt ansehen