Wenn es um Teamarbeit geht, habt ihr bestimmt schon den Begriff „Knowledge Sharing“ gehört. Knowledge Sharing bedeutet nichts anderes als das vorhandene Wissen mit seinen Kollegen zu teilen. Gerade in agilen Projekten und kurzen Iterationen kommt diesem Punkt eine wesentlich größere Bedeutung zu, als in „klassischen“ Projekten.
Häufig wird teilen von Wissen als Dokumentation verstanden. Leider führt dies dazu, dass das Wissen nicht direkt auf andere Kollegen übergeht. Die Kollegen müssen die Dokumentation lesen und vor allem verstehen können. Die Erfahrung zeigt, dass hier häufig viel Spielraum für Interpretation besteht und trotz allem gewisse Lücken vorhanden sind. Dies bedeutet nicht, dass Dokumentation nicht wichtig ist! Es braucht Dokumentation in geeigneter Form. Sie darf aber nicht das einzige Werkzeug und Mittel zur Vermittlung von Wissen sein.
Um den Austausch von Wissen zu fördern setzen wir stark auf die Methode des „Pair Programming“. Hierbei arbeiten 2 Kollegen an nur einem Rechner. Jeder Kollege nimmt abwechselnd nach einer gewissen Zeit die Rolle des „Drivers“ und des „Navigators“ ein. Ähnlich wie im Rennsport gibt der Navigator dem Driver Anweisungen welcher Code geschrieben werden soll, der Driver befolgt diese Anweisungen aber hat auch die Möglichkeit seine eigenen Sichtweisen mit einzubringen. Nach Ablauf von z.B. 10 Minuten werden die Rollen gewechselt.
Dieses Konzept führt dazu, dass beide Beteiligten sowohl den Code schreiben, als ihn auch verstehen. Besonders geht es hier nicht nur um die konkrete Zeile Code, sondern auch um das „große Ganze“ und die dahinterstehenden Konzepte und die zu Grunde liegenden Guidelines und Coding Styles. So können auch neue Mitarbeiter schnell in neue Projekte einsteigen.
Neben dem vermittelten Fachwissen, führt diese Art und Weise ebenfalls dazu, dass ausländische Kollegen so die Möglichkeit haben Ihre Sprachfertigkeiten zu verbessern.
Anfangs stellte sich häufig die Frage wie wir rechtfertigen, dass 2 Leute an einer Aufgabe arbeiten. Wir sehen Pair Programming als ein starkes Investment in die Zukunft unserer Mitarbeiter und damit auch in uns als Unternehmen. So hat dieses Modell schon in vielen Projekten dazu geführt, dass wir Themen wie Testing, Dokumentation und auch die Coding Styles auf Basis des Feedbacks aus den Sessions anpassen konnten.
Das beschriebene ist eine weit verbreitete Methode, du kennst andere? Dann her damit: blog@valiton.com