Gemeinsam stark: Unsere Reise ins Extreme Programming bei der SWE Zentrale
Zwei Köpfe, ein Code – eine scheinbar einfache Idee, die unsere Art zu arbeiten völlig umkrempeln könnte. Das zumindest ist der Claim, den Kent Beck schon vor über 20 Jahren in seinem Buch Extreme Programming vorgestellt hat.
- Zwei Entwickler, Ein Arbeitsplatz: Zwei Programmierer teilen sich einen Computer, eine Tastatur und eine Maus.
- Rollenverteilung: Es gibt den „Driver“, der den Code schreibt, und den „Navigator“, der den Überblick behält, strategisch denkt und Vorschläge macht.
- Kontinuierliche Kommunikation: Ständiger Austausch von Ideen, Lösungsansätzen und Feedback zwischen den beiden Entwicklern.
- Qualitätsverbesserung: Das gemeinsame Arbeiten führt zu höherer Codequalität durch sofortiges Peer-Review.
- Wissensaustausch: Förderung des Wissenstransfers und des gegenseitigen Lernens innerhalb des Teams.
- Problemprävention: Frühzeitiges Erkennen und Lösen von Problemen durch die gemeinsame Betrachtung des Codes.
- Flexibilität in der Rollenverteilung: Wechsel zwischen Driver und Navigator, um einseitige Arbeitsbelastungen zu vermeiden.
- Einsatz für komplexere Aufgaben: Besonders geeignet für schwierige oder kritische Programmieraufgaben.
- Soziale Komponente: Förderung der Teamdynamik und Verbesserung der Kommunikationsfähigkeiten.
- Anpassungsfähigkeit: Pair Programming ist flexibel und kann an die spezifischen Bedürfnisse des Teams und des Projekts angepasst werden.
Tatsächlich haben wir im Team schon oft Pair-Programming-Sessions gemacht, um Probleme zu lösen und auch bereits Remote experimentiert (z.B. mit Code-With-Me von jetbrains). Dies waren jedoch immer wieder sporadische Ereignisse und wenig formalisiert.
Ein ganzes Team auf Pair-Programming umzustellen ist, so glaube ich eine größere Herausforderung und so habe ich mich entschlossen, mir zwei Verbündete im Team zu holen und das Ganze zuerst für 1 Monat zu testen, bevor wir weitere Personen im Team dazuholen.
Folgende Rahmenbedingungen wurden für den Start festgelegt, sollen aber im Laufe des Experiments angepasst werden, wenn es sinnvoll erscheint
- Dauer: 1 Monat
- Wenn Remote, dann mit Code With Me
- 5x 1h pro Tag
- 45 Minuten Work, 15 Minuten Pause. → Timer nutzen
- Planning:
Am Anfang der Woche (Montag)- Gemeinsames Aussuchen eines Zieles, was erreicht werden soll (Story / Task)
- Gemeinsames Commitment und Fokus auf das Ziel
- Test First
Begonnen wird zuerst mit einem Test und dann dem „Test-First“-Prinzip folgend iterative Weiterentwicklung - „Keyboard“-Wechsel jede Stunde
dadurch wird eventuelle „Langeweile“ vermieden. - Small (Daily) Commits
Commits sollten thematisch immer ein Thema haben, falls sich z.B. Refactorings ergeben, ist es sinnvoll, diese in eigene Commits auszulagern, so dass es einfacher ist zwischen Funktionsentwicklung und Code-Verbesserung zu unterscheiden. Spätestens am Ende des Tages sollte jede Änderung commited sein, besser mehrmals täglich. - Continuous Integration (CI)
mehrmals täglich sollten alle Tests ausgeführt werden, um sicherzustellen, dass auch andere Bereiche, als die, die man gerade bearbeitet, nicht (zufällig) betroffen sind - No broken Merges
Der master/main Branch sollte immer ein lauffähiges Artefakt erzeugen können
Ich bin auf jeden Fall gespannt, wie unser Experiment laufen wird und ob wir das Prinzip im Team weiter ausbauen.