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 Produktivität kurzfristig leicht sinken kann (etwa 15 %), aber weil der produzierte Code so viel besser ist, steigt die Produktivität langfristig. Und natürlich hängt es davon ab, wie und über welchen Zeitraum Sie die Produktivität messen. In einem agilen Kontext wird die Produktivität oft in laufenden, getesteten Funktionen gemessen, die tatsächlich pro Iteration und pro Release bereitgestellt werden. Wenn ein Team die Produktivität in Codezeilen pro Woche misst, stellt es möglicherweise tatsächlich fest, dass diese durch die Paarung sinkt (und wenn das weniger Codezeilen pro laufendem, getestetem Feature bedeutet, ist das eine gute Sache!).
Produktivität und Personalfluktuation
Befürworter des Pairing behaupten, dass Pairing noch wertvoller wird, wenn man die Produktivität über einen ausreichend langen Zeitraum misst, der auch die Einstellung und das Ausscheiden von Mitarbeitern einschließt. In vielen Mainstream-Projekten neigt das Fachwissen dazu, sich in „Wissensinseln“ anzusammeln. Einzelne Programmierer wissen oft viele wichtige Dinge, die die anderen Programmierer nicht so gut wissen. Wenn eine dieser Inseln das Team verlässt, kann sich das Projekt stark verzögern oder schlimmeres. Ein Teil der Pairing-Theorie besteht darin, dass das Management durch die weitreichende Verbreitung vieler Arten von Wissen innerhalb eines Teams weniger der ständigen Gefahr der Personalfluktuation ausgesetzt ist. Beim Extreme Programming (XP) spricht man von der LKW-Anzahl: der Anzahl der Teammitglieder, die von einem LKW angefahren werden müssten, um das Projekt zunichte zu machen. XP-Projekte streben danach, die LKW-Anzahl so nah wie möglich an der Gesamtgröße des Teams zu halten. Wenn jemand geht, gibt es normalerweise mehrere andere, die seinen oder ihren Platz einnehmen. 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 Funktionen messen, die ein solches Team über mehrere Versionen hinweg ausliefert, sollte sie höher ausfallen, 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.
