Der Einarbeitungspfad: In 80 Tagen durch den Code

Wie flach oder steil der Einarbeitungspfad ist, ist ein Kostenfaktor.  Dazu werden im schlimmsten Falle in Form der zurecht gehassten „hast du mal kurz“-Unterbrechungen den Kollegen Energien abgezogen. Für die oder den Neuen fühlt sich der Prozess zudem manchmal an wie ein schmerzliches ungelenkes Eintauchen ins kalte Wasser, wenn man im Schwimmbad vom Einmeter-Brett abrutscht. Unbefriedigend.

Das Problem

Die Frage nach dem optimalen Einarbeitungspfad ist in vielen Unternehmen zunächst eher eine theoretische als eine praktische. Da gab es mal ein Management-Meeting dazu und es gibt drei Checklisten. Der Chef hat auch kurz im Vorbeigehen Jens angesprochen und ihn gebeten, sich für die neue Kollegin Nova Zeit zu nehmen.

Sobald die Person dann da ist, ändert sich der Ansatz und es gewinnen holterdipolter die „praktischen“ Gesichtspunkte über die theoretischen:

Kollege Jens löscht gerade Feuer und muss dringend ein Feature für das Marketing umsetzen. Kollegin Norma hat sich angeboten. Sie machen viel zusammen. Nova schaut oft so lange auf Normas Bildschirm bis ihr die Augen zufallen. Dann hat Nova frustriert etwas Schnippisches gesagt, es gab ein kurzes Scharmützel und nun schaut die neue Kollegin allein die Sourcen durch.

Der Chef hat ihr geraten, sie könne ja mal schauen, ob ihr technische Schulden auffallen. Seit Nova einige Sachen neulich vorgestellt hat, die sie für technische Schulden hält, ist die Stimmung im Team noch ein bisschen schlechter. Süffisant merken die Kollegen an, dass es neulich selbst mit einer einfachen Aufgabe nicht geklappt hat. Warum fragt denn Nova auch nicht?

Ganz reale Worst-Case-Alpträume aus der Software-Entwicklungsabteilung.

Das Ziel

Ziel ist es, einen Einarbeitungspfad quer durch die Build-Umgebung, die Komponenten-Landschaft und die Sourcen zu legen und sich dabei an den UseCases zu orientieren. Auf diese Weise können neue Kolleg*innen schnell einen Überblick gewinnen (1) und so früh wie möglich Aufgaben übernehmen (2/3). Sie sind dann aber auch gleichzeitig schon früher in der Lage, größere Zusammenhänge zu verstehen (4/5). Und mit etwas Glück beteiligen sie sich sogar bereits wesentlich früher an architektonischen Fragen (6).Stufen der Verständnistiefe

In diesem Modul geht es NICHT um das organisatorische Onboarding (Ist ein Rechner da? Ist der eingerichtet? Gibt es einen VPN-Zugang? Sind die Logins fürs Wiki angelegt? …).

Es geht auch NICHT um den psychologischen Teil, obwohl der entscheidend ist. Es macht einen riesigen Unterschied, ob das Team dank einer agilen Ausrichtung selbst merkt, dass es Verstärkung braucht oder ob der Wunsch von ganz weit oben aus einem Strategie-Papier in der Hierarchie kommt. Siehe dazu auch das Modul „Agile“.

Vorbedingungen

  • Fand das Modul „Organisationskultur – Team – Code“ vorher statt, so kann der Block „Vertiefung der Code-Kenntnis (4d)“ gestrichen werden.
  • Die Mitarbeit eines Architekten / Seniors am Einarbeitungsprogramm ist notwendige Voraussetzung, um die erarbeiteten Hilfsmittel dann später auch erfolgreich zum Einsatz bringen zu können.

Zu veranschlagende Zeit: ~18d

Die Zeitkalkulation geht aus von

  • Vertiefung der Code-Kenntnis (4d)
  • 1 Komponente (0,5h)
  • 1 technischen und 1 fachlichen UseCase (1h + 2h)
  • 1 leichte und 2 normal schwere Basis-Technologien (4d + 0,5d)
  • 2 Oberflächentests und 2 Lasttests (4d + 1d)
  • 2 Übungen (2d)
  • 5 Unit-Tests, davon 2 Adaptationen (1d + 1d + 2h)

1) Vertiefung der Code-Kenntnis (4d)

2) Identifikation von Komponenten (je 0,5h)

Identifikation der Komponenten, Module und Services, die für die Einarbeitung im konkreten Fall relevant sind

  • Die Reihenfolge ist durch die Relevanz bestimmt

3) Identifikation von Anwendungsfällen (je 0,5h)

Es geht um UseCases, die mit besagter Komponente in Zusammenhang stehen.

3a) fachlicher Natur

  • funktionale Anforderungen
  • Reihenfolge bedingt durch Relevanz und technische Komplexität

3b) technischer Natur

  • nicht-funktionale Anforderungen, spezifisch für die Komponente
  • Reihenfolge bedingt durch die Frage „Ist das jetzt schon wichtig zu wissen?“

4) Grundlagen legen für Domänensprache, je UseCase (1h)

5) Spielen mit Basistechnologie

Deployment, Versionsverwaltung, Build-Prozess, IDE,…

  • Komplex , je (2d)
  • Leicht, je (0,5d)

6) Grundlagen legen für Oberflächentests, Integrationstests, Last-/Performance-Tests, notfalls manuelle Tests

  • Erster Test (2d)
  • Jeder weitere (0,5d)

7) Grundlagen legen für Unit-Ebene/Funktion

7a) Level „Beginner“

Didaktische Abfolge von Code-Bereichen samt Übungsszenarien; Übungsszenarien sind jeweils auf Branches (notfalls: isolierte Projekt-Kopie)

  •   Je Szenario (1d)

7b) Level „Pro“

Didaktische Abfolge von Unit-Tests

  • Erster Test (1d)
  •  Jeder weitere (0,5d)
  • Adaptation vorhandener Tests, soweit geeignet (1h)

Nebenbemerkung:
Die beste Code-Dokumentation geschieht nicht durch Handbücher, Wiki-Seiten oder Kommentare. Sie geschieht durch Unit-Tests auf allen Ebenen bis hin zum Integrationstest, die mit griffigen Namen und plausiblen Datenstrukturen arbeiten.

Dadurch, dass der Test fehlschlägt, sobald der Code abweicht, hat man zudem eine sehr lebendige und aktuelle Variante der Dokumentation dadurch geschaffen.
Siehe auch: Modul „Testgetriebene Entwicklung“


Ergebnisartefakte

  • Rumpf für
    • ein Glossar
    • BigPicture-Diagramme (mit PlantUML)
    • automatisiertes Testen
    • Unit-Tests
    • „Fingerübungen“
  • Eine genaue Vorstellung davon, wie es jetzt weitergehen muss
  • Eine Praktik, wie jeder „Neuzugang“ das vorhandene Portfolio anreichern kann (Glossare und manuelle Tests können auch Projektmanager und Marketing-Kollegen; manche von ihnen können sogar automatisierte Tests erweitern)

Mögliche Nachfolge-Module

 

 

Kommentar verfassen