In diesem Artikel erkläre ich, wie man mit einer Variante von Delegation Poker dem Team mehr Sicherheit bei technischen Entscheidungen geben kann.
Entwickler:innen in einem Team treffen ständig Entscheidungen: „Wie soll die Variable heißen?“, „Sollte ich die Signatur der Methode anpassen, damit es klarer wird?“, „Mmmh, verwende ich hier besser eine Factory?“, „Ziehe ich dafür einen eigenen Micro-Service hoch?“.
Gewisse Richtlinien, was das Team unter gutem und richtigem Code versteht, sind vielleicht dokumentiert, aber dies wird niemals alle Fälle abdecken, in denen Entscheidungen getroffen werden müssen.
Code Reviews helfen dabei, Entscheidungen im Team zu diskutieren, sind aber häufig auf zwei bis drei Mitglieder beschränkt. Im Team werden vielleicht nur die wichtigsten Teile eines Systems gemeinsam im Review betrachtet.
Um den Teammitgliedern Sicherheit zu geben, wer für eine Entscheidung involviert werden sollte, nutzen wir eine Variante von Delegation Poker. Dabei richten wir die zwei Hauptfaktoren der Methode auf die Software-Architektur und technische Entscheidungsstufen aus:
Anstatt konkreter Situationen verwenden wir verschiedene Architekturebenen, um Verantwortung an die Architektur unserer Software zu koppeln. Dies kann mehr Sicherheit in Alltagsentscheidungen geben. Natürlich könnt ihr so auch konkrete Fragestellungen diskutieren, wie z. B. „Wer muss involviert werden, um ein neues Framework in unsere Codebasis einzuführen?“.
Anstatt der sieben Delegationsstufen verwenden wir verschiedene Gruppierungen von Menschen, die in eine Entscheidung involviert sein müssen.
Welche Kategorien verwenden?
Für beide Faktoren bringe ich konkrete Stufen als Beispiele und einfacheren Einstieg mit. Durch die Diskussion mit dem Team können natürlich neue Kategorien entstehen.
Beispiele für den Faktor Architektur:
- Codezeile
- Methode
- Klasse
- Komponente
- Modul
- Service
- System
Beispiele für Entscheidungsstufen:
- 1 Teammitglied (also jede:r darf alleine entscheiden)
- 2 Teammitglieder (z. B. im Code Review)
- Einfache Mehrheit im Team
- 2/3 Mehrheit im Team
- Team-übergreifende Abstimmung, z. B. eine Community of Practice
- Mehrheitsentscheidung aller Mitglieder aller Teams
Anstatt fertige Karten wie bei Delegation Poker zu verwenden, schreibt sich jede:r die eigenen Entscheidungskarten auf einen Satz Papierkarten. Das sieht vielleicht weniger hübsch aus, ermöglicht aber, die Stufen gezielt mit dem Team anzupassen – auch während der Diskussion.
Um Transparenz über das Ergebnis zu erzielen, bereite ich ein Board mit den Architekturstufen auf der senkrechten Achse und den Entscheidungsstufen auf der waagerechten Achse vor.
Verdecktes Einschätzen deckt verschiedene Meinungen auf
Wir beginnen mit der einfachsten Architekturstufe. Jedes Teammitglied wählt verdeckt die niedrigste Entscheidungsstufe, die aus eigener Sicht Entscheidungen auf dieser Architekturebene treffen darf. Alle zeigen gleichzeitig ihre Karten. Sind alle der gleichen Meinung, markiere ich das Ergebnis auf dem Board (z. B. „Klassen“ und „2 Teammitglieder„), ggfs. mit Kommentaren zum Vorgehen („Code Review“).
Gibt es unterschiedliche Meinungen, diskutiert das Team darüber. Hierfür könnt ihr gerne die Mechanismen nutzen, die ihr auch beim Planning Poker verwendet. Aus den Diskussionen können sich neue Stufen ergeben, z. B. könntet ihr „Services“ in „interne Services“ und „externe Services“ aufteilen. Dies macht nur Sinn, wenn sich daraus andere Entscheidungsstufen ergeben, sonst könnt ihr sie wieder zusammenfassen.
Die getroffenen Entscheidungen solltet ihr als Teamregeln dokumentieren. Sie beseitigen Unsicherheit, wenn es darum geht, welche Personengruppen in eine (weitreichendere) Codeentscheidung eingebunden werden müssen.
