Wissenstransfer durch Review?

Es gibt ja diverse Ideen, Wissen über ein laufendes System und dessen Kontext von einem Wissenden zu einem Unwissenden zu übertragen. Dokumentationen zu schreiben ist sicherlich nicht die Lieblingsaufgabe eines Softwareentwicklers; aber es gehört dazu. Diese als Softwareentwickler auch zu lesen, ist meist ebenfalls wenig spannend, wenn man ein System kennen lernen möchte; nsbesondere wenn diese dann auch noch veraltet ist und die Wahrheit sowieso im Code steht. Eine Dokumentation zu lesen ist also eher wenig geeignet. Es geht auch nicht in kurzer Zeit, sondern ist ein Prozess. Hier möchte ich einmal veranschaulichen, wie man Schritt für Schritt jemanden ein System näher bringen kann. Dabei soll darauf geachtet werden, dass beide Seiten nicht frustriert werden und für beide (gern auch für Dritte) ein Mehrwert entsteht.

Der fachliche Kontext eines Systems ist in der Regel schnell erklärt durch Fragen wie:

Wie etwas umgesetzt ist und warum interessiert an dieser Stelle nicht; das ist zuviel Detail für jemanden, der das System kennenlernen soll. Das langweilt in der Regel und die Aufnahmefähigkeit des Menschen ist eben auch nur begrenzt. Ein Wissender kann hier schnell über das Ziel hinausschießen. Natürlich sollen aber auch die Fragen der Unwissenden berücksichtigt und beantwortet werden. Der nächste Schritt ist dann, den Unwissenden die Tücken des Systems entdecken zu lassen - selbstständig; ab ins kalte Wasser! Angenommen es gibt rund um das System wiederkehrende Aufgaben zu erledigen. Dann lässt man den Unwissenden diese erledigen. Er wird einen Teil vielleicht schon allein durch die beantworteten Fragen alleine lösen können. Für den anderen Teil wird er auf den Wissenden zugehen. So entdeckt der Unwissende nach und nach das System und kann vielleicht auch die ersten Zusammenhänge erkennen. Das Ganze immer zusammen mit dem Wissenden. Es ist also wichtig, dass sch der Unwissende traut, bei ihm im Zweifelsfall nachzufragen. Dazu sollte man abhängig vom System einen Zeitraum absprechen, der die Tücken auch erkennen lässt. Bei einem System, das jeden Tag läuft könnte das eine Woche sein.

Sollten die Tücken gar nicht oder nicht vollständig dokumentiert sein, wird der Unwissende in der Regel von sich aus dies nachholen. Dies dann für alle zugreifbar zu machen, ist anschließend nur noch ein kleiner Schritt. Im nächsten Schritt geht es dann in den Code. Pair-Programming macht in einem solchen Fall keinen Sinn, da der Wissensstand einfach viel zu unterschiedlich ist. Der Wissende wird für den Unwissenden zu schnell zwischen den Klassen hin- und herspringen und der Unwissende fühlt sich unsicher, weil der Wissende ihm zeigt, wie es gehen muss; auf beiden Seiten Frust!

Der Unwissende soll also sein Tempo selbst bestimmen und seine eigenen Ideen entwickeln können. Dazu sollte er eine Aufgabe bekommen, die in sich abgeschlossen ist und in wenigen Stunden erledigt werden kann. Der Wissende sollte dann bereit sein, eine Einstiegshilfe zu geben; also Klassen nennen, die mit der Aufgabe zu tun haben. Anschließend kann der Unwissende den Kontext der Klassen analysieren und die Aufgabe lösen.

Anschließend legt der Unwissende die Lösung dem Wissenden zum Review vor. Dafür gibt es sehr gute Tools wie Atlassian Crucible. Am Anfang wird es unter Umständen viele Anmerkungen geben. Aber der Unwissende wird immer mehr zum Wissenden, je mehr Aufgaben er löst. Wenn es viele Aufgaben in kurzer Zeit gibt, ist es sehr schnell soweit, dass der zunächst Unwissende mit dem Wissenden über Lösungen diskutieren kann. Dann ist auch die Zeit für Pair-Programming gekommen.

Speziell die Reviews sind eine sehr gute Unterstützung für Feedback und bieten die Möglichkeit für Diskussionen fokussiert auf den Code; nur von Änderungen betroffene Klassen werden betrachtet.

Die beschriebenen Schritte werden nicht unter allen Umständen funktionieren. Aber wenn beide Seiten motiviert sind, das Wissen zu teilen und auch Neues aufzunehmen (beides gilt für beide Seiten), profitieren beide Seiten und am Ende natürlich auch der Arbeitgeber oder Kunde.