Wissensaustausch zwischen verteilten Teams

Einer der wichtigsten USPs der Paarprogrammierung ist, dass sie einen Mehrwert bietet, der über das bloße Tippen hinausgeht. Dazu gehört die AKTIVE Teilnahme an der Code-Überprüfung, der kontinuierliche Wissensaustausch, häufige Design-Diskussionen mit minimaler Ablenkung usw. Wenn Sie sich in erster Linie auf den Wissensaustausch konzentrieren, bietet das Pair-Programming eine echte Form des Wissensaustauschs, denn anstatt sich sperrige, herzlose Dokumente anzusehen, sitzen Sie mit einer Person zusammen, die bereits an dem Thema gearbeitet hat, und können Gespräche und Designdiskussionen führen. Es funktioniert sehr gut, wenn das Team an einem Ort zusammenarbeitet, da Pair-Switching, der Wechsel der Fahrer-Navigator-Rolle und persönliche Design-Diskussionen in einer zusammenarbeitenden Umgebung ziemlich nahtlos sind. Was ist, wenn Sie Teil eines verteilten Teams sind? Die Entwickler bilden immer noch Paare, aber nicht unbedingt mit Teammitgliedern, die an einem anderen Ort arbeiten. Viele Teams haben zwar damit begonnen, das Konzept der verteilten Paarprogrammierung mit Hilfe neu verfügbarer Kommunikationstools (Skype für Sprachunterhaltungen und Skype Mikogo Plugin für die gemeinsame Nutzung des Desktops, um nur einige zu nennen) recht erfolgreich umzusetzen, bei dem sich Entwickler an verteilten Standorten zusammenschließen. Bei der Arbeit an einem solchen verteilten Projekt stellten wir fest, dass Wissensbereiche lokalisiert wurden, da die verteilten Teams an unterschiedlichen Themen arbeiteten. Standups sind von Natur aus kurz und enthalten nicht viele genaue Implementierungsdetails. Planning-2-Meetings helfen bei der Definition von Low-Level-Design und -Schritten, aber während der Implementierung ändern sich diese Schritte zwangsläufig auch manchmal. Aus den oben genannten Gründen sahen wir die Notwendigkeit, ein Forum für den Wissensaustausch zwischen verteilten Teams einzurichten.Wir begannen mit verteilten Wissensaustausch-Sitzungen, bei denen wir die Sprachkommunikation über Skype und das Desktop-Sharing-Tool Mikogo nutzten, und sie waren recht effektiv. Auch wenn es schwierig sein mag, den gesamten Ablauf in einer Sitzung zu erfassen, so verschafften wir uns doch einen guten Überblick über Implementierungsprobleme, was bei der Implementierung zukünftiger Stories oder der schnellen Behebung von Wartungsproblemen hilfreich ist. Während dieser Diskussionen erhielten wir auch Design-Feedback innerhalb des Teams, das uns half, Designfehler, Verbesserungspunkte, Refactoring-Bereiche usw. zu identifizieren.