Entwicklungsaufgabe unterbrechen: Arbeitsstand sichern

Du ergänzt in einem internen Rechnungsmodul einen Exportfilter. Die Abfrage steht, ein Test schlägt noch fehl, dann landet ein dringender Supportfall auf dem Tisch. Zwei Tage später ist der Branch noch da – aber warum der Test rot war, welche Beispieldaten du verwendet hast und was du als Nächstes ändern wolltest, lässt sich nur noch durch erneute Analyse rekonstruieren.

Genau dafür lohnt sich ein kleiner Unterbrechungs-Workflow. Sein Ergebnis ist eine Wiederaufnahme-Notiz: eine kurze, überprüfbare Beschreibung des Zwischenstands. Sie sichert nicht nur Gedanken, sondern verbindet Quellcode, beobachtetes Verhalten und den nächsten Arbeitsschritt.

Hinterlasse einen ausführbaren Wiedereinstieg

Eine Entwicklungsaufgabe muss vor der Unterbrechung nicht fertig oder fehlerfrei sein. Sie braucht jedoch einen Zustand, den du später reproduzieren kannst. Dafür müssen fünf Fragen beantwortet sein:

• Welches konkrete Ergebnis soll die Aufgabe erreichen?
• Wo liegt der aktuelle Quellcode?
• Was funktioniert bereits?
• Welches Verhalten ist gerade noch falsch oder ungeklärt?
• Welche konkrete Aktion folgt als Nächstes?

Die letzte Frage ist besonders wichtig. „Export fertigstellen“ beschreibt ein Ziel, aber keinen Einstieg. „Testdaten um eine freigegebene Rechnung ergänzen und anschließend den Export-Test erneut ausführen“ ist direkt umsetzbar. Du musst die Aufgabe beim Wiedereinstieg nicht erneut zerlegen.

Bringe den Code in einen sicheren Zwischenzustand

Speichere zunächst alle relevanten Dateien und prüfe den Git-Status. Achte dabei auch auf neue, noch nicht versionierte Dateien. Gerade Test-Fixtures, Konfigurationsbeispiele oder neu angelegte Klassen bleiben sonst leicht außerhalb des gesicherten Zwischenstands.

Wie du den Code sicherst, hängt von seinem Zustand und euren Teamregeln ab:

• Ein regulärer Zwischen-Commit passt, wenn der aktuelle Stand fachlich verständlich ist und keine unnötig kaputten Teile enthält.
• Ein klar markierter WIP-Commit eignet sich für unvollständigen Code auf einem eigenen Arbeits-Branch. WIP steht für „Work in Progress“. Ein solcher Commit darf nicht versehentlich in die produktive Version gelangen und sollte später aufgeräumt werden.
• Ein benannter Git-Stash kann für eine kurze, persönliche Unterbrechung genügen. Für längere Pausen oder Übergaben ist er ungeeignet: Er bleibt üblicherweise lokal und erklärt den fachlichen Zustand nicht.

Ein Commit sichert Dateien, ersetzt aber keine Wiederaufnahme-Notiz. Aus dem Diff geht vielleicht hervor, dass du eine Abfrage geändert hast. Es erklärt selten, warum du bei einer bestimmten Bedingung unsicher warst oder welcher Test das Problem reproduziert.

Prüfe außerdem, ob der Zwischenstand von lokalen Nebeneffekten abhängt. Dazu gehören manuell veränderte Datenbankeinträge, nur lokal vorhandene Beispieldateien, laufende Hintergrundprozesse oder eine noch nicht dokumentierte Umgebungsvariable. Du musst nicht die ganze Entwicklungsumgebung beschreiben. Halte nur fest, was zum Wiederherstellen dieses konkreten Zustands erforderlich ist.

Schreibe eine kompakte Wiederaufnahme-Notiz

Die Notiz sollte kurz genug sein, dass du sie tatsächlich anlegst, und präzise genug, dass sie eine erneute Analyse verhindert. Dieses Schema deckt die wesentlichen Informationen ab:

• Ziel: Welches überprüfbare Ergebnis soll entstehen?
• Erledigt: Welche Änderungen sind bereits umgesetzt oder geprüft?
• Aktueller Zustand: Was passiert momentan, einschließlich relevanter Fehlermeldungen?
• Code-Stand: Auf welchem Branch, Commit oder Stash liegt die Arbeit?
• Nächster Schritt: Welche einzelne Aktion soll zuerst ausgeführt werden?
• Offene Entscheidung: Welche fachliche oder technische Frage blockiert den Abschluss?

Vermeide Fortschrittsangaben wie „fast fertig“ oder „nur noch testen“. Sie vermitteln Aktivität, liefern aber keinen Einstieg. Eine gute Notiz beschreibt beobachtbare Zustände: welcher Test erfolgreich ist, welcher Fall noch fehlt und welche Annahme überprüft werden muss.

Lege Belege direkt neben den Zwischenstand

Wenn ein Fehler oder eine offene Abweichung die Aufgabe prägt, sichere die wichtigsten Belege. Geeignet sind der genaue Name eines fehlschlagenden Tests, die relevante Fehlermeldung, ein bereinigter Request oder ein Screenshot der betroffenen Oberfläche. Bei langen Ausgaben reicht der aussagekräftige Ausschnitt zusammen mit dem Befehl oder Ablauf, der die vollständige Ausgabe erzeugt.

Entferne Zugangsdaten, Tokens und personenbezogene Kundendaten. Ein echter Datensatz ist selten erforderlich, um einen technischen Zustand zu dokumentieren. Ein anonymisiertes Beispiel mit derselben Struktur ist für die spätere Analyse meist brauchbarer.

Wenn aus der Unterbrechung ein eigenständiger Fehlerfall wird, sollte die Notiz zu einem reproduzierbaren Bugreport ausgebaut werden. Der Artikel Fehlermeldung mit KI analysieren: So entsteht ein guter Bugreport zeigt, welche Angaben dafür benötigt werden und welche Informationen du vor einer KI-Auswertung bereinigen solltest.

Speichere die Notiz am richtigen Ort

Der Ablageort richtet sich danach, wer die Aufgabe später fortsetzt. Für eine kurze Unterbrechung am selben Arbeitstag kann eine persönliche Aufgabennotiz ausreichen. Sobald die Pause länger dauern könnte, die Aufgabe projektkritisch ist oder eine Übergabe möglich wird, gehört der Zwischenstand in das gemeinsame Ticket- oder Projektverwaltungssystem.

Eine Chatnachricht ist als alleinige Ablage ungünstig. Sie rutscht aus dem sichtbaren Verlauf und trennt die Erklärung vom eigentlichen Vorgang. Im Ticket bleiben Ziel, Code-Referenz, aktueller Zustand und offene Fragen zusammen. Im Chat kannst du anschließend auf diesen Eintrag verweisen.

Bei einer tatsächlichen Übergabe ergänzt du einen verantwortlichen Empfänger und klärst, ob die Person die Aufgabe übernehmen kann. Das bloße Erwähnen eines Namens erzeugt noch keine Übergabe. Die andere Person sollte Branch, Testfall und nächsten Schritt finden können, ohne zuerst den gesamten Nachrichtenverlauf zu lesen.

Setze die Aufgabe in einer festen Reihenfolge fort

Beim Wiedereinstieg beginnt die Arbeit mit dem dokumentierten Zustand. Widerstehe dem Impuls, sofort Code zu ändern. Prüfe zuerst, ob die alten Annahmen noch gelten:

1. Lies die Wiederaufnahme-Notiz vollständig und prüfe offene Entscheidungen oder neue Kommentare.
2. Stelle den genannten Branch, Commit oder Stash wieder her.
3. Reproduziere den dokumentierten Zustand mit dem angegebenen Test oder Ablauf.
4. Vergleiche das Ergebnis mit der Notiz. Abweichungen können durch zwischenzeitliche Änderungen entstanden sein.
5. Führe den festgehaltenen nächsten Schritt aus und aktualisiere die Notiz, falls eine weitere Unterbrechung absehbar ist.

Diese Reihenfolge schützt vor Änderungen auf einer falschen Grundlage. Wenn der zuvor fehlschlagende Test inzwischen erfolgreich ist, hat sich die Ausgangslage verändert. Dann ist eine kurze Prüfung sinnvoller als das mechanische Abarbeiten einer inzwischen überholten Idee.

So sieht ein brauchbarer Zwischenstand aus

Für den eingangs beschriebenen Exportfilter könnte die Wiederaufnahme-Notiz so aussehen:

• Ziel: Der CSV-Export enthält im gewählten Zeitraum ausschließlich freigegebene Rechnungen.
• Erledigt: Statusfilter in der Exportabfrage ergänzt; Testfälle für freigegebene und stornierte Rechnungen angelegt.
• Aktueller Zustand: Der Test für den Datumsbereich schlägt fehl, weil die Testrechnung außerhalb des gesetzten Zeitraums erzeugt wird.
• Code-Stand: Arbeits-Branch und WIP-Commit im Ticket vermerkt.
• Nächster Schritt: Datum der Testrechnung explizit innerhalb des Filterzeitraums setzen und den Export-Test erneut ausführen.
• Offen: Klären, welche Zeitzone für den Tageswechsel im Export maßgeblich ist.

Mit dieser Notiz lässt sich der Arbeitsstand ohne Rätselrunde wiederherstellen. Sie behauptet nicht, die Funktion sei „fast fertig“, sondern trennt den bekannten Fehler von der noch offenen fachlichen Entscheidung.

Vermeide Dokumentation, die nur vollständig aussieht

Ein großer Diff, ein langer Terminal-Verlauf oder eine Sammlung von Screenshots kann viel Material enthalten und trotzdem wenig erklären. Entscheidend ist die Verbindung zwischen Beobachtung und nächster Aktion. Anhänge sind Belege; die Notiz liefert ihre Einordnung.

Auch ein aufgeräumter Commit-Verlauf löst das Kontextproblem nur teilweise. Commits dokumentieren Änderungen am Code. Fachliche Rückfragen, verworfene Ansätze und lokale Voraussetzungen gehören in das Ticket oder die Wiederaufnahme-Notiz, sofern sie für die Fortsetzung relevant sind.

Bei einem akuten Produktionsvorfall darf der Dokumentationsprozess die Fehlerbegrenzung nicht verzögern. Sichere in diesem Fall nur das Nötigste, übernimm den Supportfall und ergänze den Zwischenstand, sobald die Lage stabil ist. Der Workflow soll Aufgabenwechsel beherrschbar machen, keine neue Zeremonie erfinden.

Fazit: Sichere den nächsten Schritt, nicht nur den Code

Eine unterbrochene Entwicklungsaufgabe bleibt fortsetzbar, wenn du drei Dinge zusammenhältst: den gesicherten Code-Stand, das aktuell beobachtete Verhalten und eine direkt ausführbare nächste Aktion. Die Wiederaufnahme-Notiz schafft diese Verbindung.

Für kurze Unterbrechungen darf sie knapp sein. Bei längeren Pausen oder Übergaben braucht sie zusätzlich Belege, offene Entscheidungen und einen gemeinsamen Ablageort. Der Aufwand bleibt überschaubar – und dein zukünftiges Ich muss nicht aus einem WIP-Commit herauslesen, was dein vergangenes Ich wohl gemeint haben könnte.