Paarungsmechanik
Beim Pairing arbeiten zwei Programmierer an einem einzigen Arbeitsplatz. Ein Programmierer „fährt“, bedient die Tastatur, während der andere „navigiert“, zusieht, lernt, fragt, spricht und Vorschläge macht. Theoretisch konzentriert sich der Treiber auf den vorliegenden Code: die Syntax, Semantik und den Algorithmus. Der Navigator konzentriert sich weniger darauf, sondern mehr auf eine höhere Abstraktionsebene: den Test, den er bestehen möchte, die als nächstes zu erledigende technische Aufgabe, die seit der Ausführung aller Tests verstrichene Zeit, die seit dem letzten verstrichene Zeit Repository-Commit und die Qualität des Gesamtdesigns. Die Theorie besagt, dass die Paarung zu besseren Designs, weniger Fehlern und einer viel besseren Wissensverteilung innerhalb eines Entwicklungsteams und damit langfristig gemessen zu mehr Funktionalität pro Zeiteinheit führt.
Wissen verbreiten
Als Mentoring-Mechanismus ist die Paarbildung sicherlich kaum zu übertreffen. Wenn Paare regelmäßig abschalten (wie sie sollten), verteilt die Paarung mehrere Arten von Wissen mit großer Effizienz im Team: Codebasis-Wissen, Design- und Architekturwissen, Feature- und Problemdomänenwissen, Sprachkenntnisse, Wissen über Entwicklungsplattformen, Framework- und Tool-Wissen, Refactoring-Wissenund Wissen testen. Es gibt keine große Debatte darüber, dass Pairing diese Art von Wissen besser verbreitet als herkömmliche Codeüberprüfungen und weniger formale Methoden. Welchen Produktivitätsverlust zahlen Sie, wenn überhaupt, für eine so gute Wissensverbreitung?
Paarung und Produktivität
Forschungsergebnisse und Einzelberichte scheinen zu zeigen, dass die kurzfristige Produktivität leicht sinken kann (etwa 15 %), aber weil der erzeugte Code so viel besser ist, steigt die langfristige Produktivität. Und sicherlich hängt es davon ab, wie und über welchen Zeitraum Sie die Produktivität messen. In einem agilen Kontext wird die Produktivität häufig an der Ausführung getesteter Funktionen gemessen, die pro Iteration und pro tatsächlich bereitgestellt werden release. Wenn ein Team die Produktivität in Codezeilen pro Woche misst, stellt es möglicherweise tatsächlich fest, dass die Paarung zu einem Rückgang führt (und wenn das bedeutet, dass pro ausgeführter, getesteter Funktion weniger Codezeilen benötigt werden, ist das eine gute Sache!).
Produktivität und Personalfluktuation
Befürworter des Pairings behaupten, dass das Pairing sogar noch mehr Wert zeigt, wenn man die Produktivität über einen ausreichend langen Zeitraum misst, um die Einstellung und das Ausscheiden von Mitarbeitern einzubeziehen. In vielen Mainstream-Projekten sammelt sich Fachwissen tendenziell auf „Wissensinseln“ an. Einzelne Programmierer neigen dazu, viele wichtige Dinge zu wissen, die die anderen Programmierer nicht so gut wissen. Wenn eine dieser Inseln das Team verlässt, könnte sich das Projekt erheblich oder noch schlimmer verzögern. Ein Teil der Pairing-Theorie besteht darin, dass das Management durch die weite Verbreitung vieler Arten von Wissen innerhalb eines Teams die Gefährdung durch die ständige Gefahr der Personalfluktuation verringert. Beim Extreme Programming (XP) spricht man von der LKW-Nummer: der Anzahl der Teammitglieder, die von einem LKW angefahren werden müssten, um das Projekt zu beenden. XP-Projekte streben danach, die LKW-Nummer so nah wie möglich an der Gesamtteamgröße zu halten. Wenn jemand geht, treten in der Regel mehrere andere an seine Stelle. Es ist nicht so, dass es keine Spezialisierung gibt, aber sicherlich weiß jeder mehr über alles, was vor sich geht. Wenn Sie die Produktivität anhand der über mehrere hinweg bereitgestellten Funktionen messen releases durch ein solches Team, sollte es höher sein, als wenn keine Paarung stattfindet.
Paarungsstrategien
In XP wird der gesamte Produktionscode paarweise geschrieben. Viele agile Teams ohne XP verwenden überhaupt kein Pairing. Aber es gibt einen großen Mittelweg zwischen keiner Paarung und jeder ständigen Paarung. Versuchen Sie die Paarbildung bei der Betreuung neuer Mitarbeiter, bei Aufgaben mit extrem hohem Risiko, zu Beginn eines neuen Projekts, wenn das Design neu ist, bei der Einführung einer neuen Technologie oder auf monatlicher oder wöchentlicher Basis. Programmierern, die das Pairing bevorzugen, ist dies möglicherweise gestattet, während diejenigen, die dies nicht tun, dies nicht tun dürfen. Die Entscheidung, Codeüberprüfungen statt überhaupt einer Paarung zu verwenden, ist beliebt, aber wir kennen keinen Grund, nicht zumindest mit der Paarung zu experimentieren. Es gibt keine vernünftigen Beweise dafür, dass es einem Team oder einem Projekt schadet, und es mehren sich die Beweise dafür, dass es sich um eine hilfreiche Best Practice handelt.
