Tagesberichte in der Softwareentwicklung schreiben – über das Arbeitsprotokoll hinaus Schätzabweichungen und Blockaden in den nächsten Schritt überführen

Tagesberichte von Entwicklerinnen, Entwicklern und Entwicklungsteams werden leicht zu einer Liste der Aufgaben, die man an diesem Tag angefasst hat.

Beispiele sind „Suchfunktion umgesetzt“, „Review-Anmerkungen bearbeitet“, „Besprechung“. Die Arbeit festzuhalten ist wichtig.

Doch allein daraus geht nicht hervor, warum etwas länger dauerte als geschätzt, wo man feststeckte und wie sich das beim nächsten Mal vermeiden lässt.

Hinzu kommt, dass Entwicklungsteams bereits viele Orte haben, an denen etwas festgehalten wird.

Das sind Aufgaben im Ticketsystem, Codeänderungen im Verlauf der Versionsverwaltung und der tägliche Austausch im Chat.

Der Tagesbericht wirkt dann schnell wie die Aufgabe, denselben Inhalt noch einmal abzuschreiben.

Zum Beispiel wird er nach Stunden konzentrierter Arbeit kurz vor Feierabend in Eile geschrieben. Und niemand, der ihn liest, antwortet.

Wenn das so ist, begnügen sich die Schreibenden nach und nach mit einer Zeile wie „Fortschritt gemacht“.

In PDCA-Begriffen bleibt der Bericht beim Do stehen, also bei der Aufzeichnung dessen, was geschah, während Check und Act wegfallen.

Dieser Artikel zeigt, wie sich der Tagesbericht neu ausrichten lässt.

Es geht weg von der Kopie des Arbeitsprotokolls, hin zu einem Werkzeug, mit dem man auf die Schätzabweichungen und Blockaden des Tages zurückblickt.

Man überführt sie in einen nächsten Schritt und in Lernen für das Team.

Bitte lesen Sie ihn als Betrachtung des Systems, nicht als Schuldzuweisung an irgendjemanden.

Der Tagesbericht in der Entwicklung lässt sich leichter durchhalten, wenn die Felder ungefähr auf Folgendes beschränkt werden.

(1) Das heutige Ziel, also welche Aufgabe man wie weit voranbringt.

(2) Die Abweichung zwischen Schätzung und tatsächlicher Zeit, mit einem Wort zum Grund statt nur zur Größe der Abweichung.

Gründe sind etwa das Warten auf die Bestätigung einer Spezifikation, unerwarteter bestehender Code oder eine streikende Umgebung.

(3) Woran man feststeckt und wen man was fragen möchte. (4) Was man beim Ausprobieren herausgefunden oder gelernt hat.

(5) Entscheidungen aus Reviews oder Besprechungen, die die eigene Arbeit betreffen. (6) Der erste Schritt für morgen.

Entscheidend ist, nicht zu wiederholen, „was man gemacht hat“. Das steht bereits in den Tickets und im Änderungsverlauf.

Entscheidend ist, den Bericht auf die Abweichung und ihren Grund, die Blockaden und das Gelernte zu konzentrieren.

Umgekehrt gibt es Beobachtungen wie „ich habe ohne Klärung der Entwurfsannahmen angefangen und musste einen Teil neu machen“.

Ein weiteres Beispiel ist „als ich eine erfahrene Kollegin fragte, wie man die Logs liest, war der Fehler in zehn Minuten gelöst“.

Sie tauchen weder in den Tickets noch im Änderungsverlauf auf und lassen sich nur im Tagesbericht festhalten.

Zu viele Felder verlängern die Schreibzeit und führen zu mehr leeren Feldern.

Beginnen Sie mit etwa fünf und passen Sie sie an, während Sie dem Team zuhören.

Das Format von norolu PDCA hat fünf Teile.

Das sind P (das heutige Ziel), D (was tatsächlich getan wurde), C (was aufgefallen ist), A (was als Nächstes getan wird) und das P des nächsten Tages.

Hier ein Beispiel eines Entwicklers, der an einer neuen Funktion arbeitet (ein erfundenes Beispiel zur Veranschaulichung).

P: „Die Filterfunktion der Suchseite bis zur Review-Reife bringen.“ D: „Die Umsetzung ist fertig, aber die Sortierreihenfolge passte nicht zur Spezifikation der bestehenden Listenansicht; Prüfen und Korrigieren dauerte zwei Stunden länger als geplant. Ins Review konnte ich sie nicht mehr geben.“ C: „Ich hatte die Spezifikation der Sortierung vor dem Schreiben nicht geklärt. Ursache war, nur nach der Ticketbeschreibung vorzugehen.“ A: „Bei Arbeiten an Bildschirmen vor dem Start drei Punkte notieren, bei denen ich wahrscheinlich unsicher sein werde, und sie zuerst mit der zuständigen Person klären.“ P des nächsten Tages: „Am Vormittag ins Review geben. Die nächste Aufgabe erst beginnen, nachdem die zu klärenden Punkte notiert sind.“ Der Kniff für die Verbindung zum P des nächsten Tages besteht darin, A als eine einzige konkrete nächste Handlung zu formulieren.

Statt „gründlicher prüfen“ schreiben Sie „vor dem Start drei Punkte notieren, bei denen ich wahrscheinlich unsicher sein werde“.

Dann kann der Bericht des nächsten Tages prüfen, ob es geschehen ist. Ein bis drei Zeilen pro Feld genügen.

Der Tagesbericht kann auch ein Ort sein, Blockaden früh anzusprechen, statt sie allein mit sich herumzutragen.

Das gilt für neu eingestiegene Entwicklerinnen und Entwickler oder weniger erfahrene Mitglieder. (Ein erfundenes Beispiel zur Veranschaulichung).

P: „Die Ursache eines Fehlers finden, der sich in der Testumgebung reproduzieren lässt.“ D: „Ich habe den ganzen Vormittag nach der Ursache gesucht, ohne sie einzugrenzen. Als ich am Nachmittag die Teamleitung fragte, stellte sich heraus, dass die Einstellungen in der falschen Reihenfolge geladen wurden.“ C: „Ich hatte mir kein Zeitlimit für die eigene Suche gesetzt. Obwohl ich wusste, dass Fragen schneller wäre, dachte ich, ich sei kurz davor, und habe den Moment zum Ansprechen verpasst.“ A: „Wenn ich eine Stunde nach Beginn der Suche keinen Anhaltspunkt habe, notiere ich, was ich ausprobiert habe, und bitte um Hilfe.“ Über Blockaden zu schreiben dient nicht dazu, zu melden, was man nicht kann, sondern dazu, dass das Team früher helfen kann.

Zum Beispiel erkennen die Teamleitung oder erfahrene Kolleginnen und Kollegen zuerst in einem Satz an, dass um Hilfe gebeten wurde.

Dann antworten sie mit nur einem Hinweis für die nächste Suche. Wenn das so ist, fühlen sich Mitglieder sicher, aufzuschreiben, wo sie feststecken.

Vermeiden Sie Antworten, die jemandem vorwerfen, über seine Stolpersteine geschrieben zu haben.

Entwicklungsteams haben bereits feste Aufzeichnungen.

Dazu gehören Tickets, die den Fortschritt der Aufgaben verfolgen, der Änderungsverlauf des Codes und die Review-Aufzeichnungen.

Dazu kommen Protokolle darüber, wie Störungen und Fehler bearbeitet wurden, sowie Arbeitszeitaufzeichnungen.

Sie werden jeweils an ihrem Ort geführt, auf Grundlage der Regeln des Unternehmens und der festgelegten Abläufe. Der Tagesbericht ersetzt sie nicht.

Gehen Sie davon aus, dass der Verlauf einer Störung, nur weil er in einem Tagesbericht steht, noch kein offizielles Störungsprotokoll ist.

Die grundlegende Aufteilung lautet so.

Fakten zu jeder Aufgabe oder jedem Fehler gehören gemäß den festgelegten Abläufen in die festen Aufzeichnungen wie die Tickets.

Der Tagesbericht dagegen enthält die eigenen Handlungen, Beobachtungen und nächsten Schritte des Teams.

Erwähnt der Tagesbericht diese Aufzeichnungen, genügt die Ticketnummer oder ein kurzer Vermerk wie „im Störungsprotokoll eingetragen“.

Wer diese Grenze von Anfang an zieht, verringert den Aufwand, dasselbe doppelt zu schreiben.

Er erhält den Tagesbericht als Ort der Reflexion statt als doppelten Fortschrittsbericht.

Welche Aufzeichnungen wo geführt werden, richtet sich nach den Regeln Ihres Unternehmens und der Einschätzung der verantwortlichen Person.

Im Feld C tauchen manchmal Notizen auf wie „die Produktivumgebung wirkte langsamer als sonst“ oder „ich habe Zugangsdaten im Klartext in einer Konfigurationsdatei gefunden“.

Lassen Sie solche Punkte nicht im Tagesbericht enden, sondern verbinden Sie sie mit den Abläufen, die das Unternehmen oder das Team dafür festgelegt hat.

Wenn Sie eine mögliche Störung oder etwas Sicherheitsrelevantes bemerken, warten Sie nicht bis zum Tagesbericht.

Informieren Sie in diesem Fall sofort die Teamleitung oder die verantwortliche Person.

Folgen Sie den Abläufen Ihres Unternehmens und der Einschätzung dieser Person.

Wichtig ist auch, Ursache oder Ausmaß der Auswirkungen nicht im Tagesbericht festzulegen.

Beruhigend ist es außerdem, folgende Daten gar nicht erst in den Tagesbericht zu schreiben. Das sind Passwörter, Schlüssel und Zugangsinformationen.

Dazu kommen personenbezogene Daten von Nutzerinnen und Nutzern oder von Geschäftspartnern anvertraute Daten.

Der Tagesbericht ist der Punkt, an dem etwas bemerkt wird; er ist nicht die Bearbeitung selbst.

Eine kurze Zeile wie „an die Teamleitung gemeldet“ lässt die Lesenden prüfen, ob es in der offiziellen Bearbeitung angekommen ist.

Die Teamleitung liest jeden Tag die Berichte der Mitglieder. Alle gründlich lesen zu wollen, ist auf Dauer nicht durchzuhalten.

Beginnen Sie deshalb mit A (was als Nächstes getan wird).

Prüfen Sie dann C (was aufgefallen ist) und die Blockaden darauf, wo Sie helfen sollten oder was heute noch entschieden werden muss.

Kommentare lassen sich leichter durchhalten, wenn sie eine Tatsache anerkennen und eine einzige Frage oder einen nächsten Schritt ergänzen.

Zum Beispiel: „Gute Idee, vor dem Start die Punkte zu notieren, bei denen Unsicherheit entstehen könnte. Sag mir, wie viele es bei der Aufgabe morgen waren.“ In Teams, die viel aus der Ferne arbeiten, gibt es eine Voraussetzung für ehrliches Schreiben.

Man behandelt den Tagesbericht als Werkzeug, mit dem Blockaden früh erkannt werden, und nicht zur Überwachung der Arbeitszeit.

Einmal pro Woche legen Sie die Berichte der Woche nebeneinander und blicken zurück.

Wer sie im KPT-Format (Keep, Problem, Try) bespricht, macht aus der Beobachtung eines Einzelnen eine Verbesserung der Arbeitsweise des Teams.

Dabei sieht er, ob sich dieselbe Art von Nacharbeit oder Schätzabweichung wiederholt und wie sich ausprobierte Ideen bewährt haben.

Mit der Wochenzusammenfassung von norolu PDCA lässt sich eine Woche an Beobachtungen auch auf einen Blick durchgehen.

Fehlt an einem Tag ein Bericht, fragen Sie zuerst nach dem Grund, statt Vorwürfe zu machen.

Prüfen Sie in diesem Fall auch, ob die Felder und der Zeitpunkt des Schreibens zur Arbeitsweise des Teams passen.

In norolu PDCA ist die KI eine Assistenz, die beim Entwerfen von Berichten, bei Fragen zur Reflexion und bei Wochenzusammenfassungen hilft.

Diese Grenze gilt auch in einem Entwicklungsteam.

Die KI kann kurze Notizen von Mitgliedern ordnen oder Blockaden und Nacharbeit herausgreifen, die sich über eine Woche an Berichten wiederholen.

Aber Entscheidungen treffen die Teamleitung oder die verantwortliche Person.

Dazu gehört etwa, wie die Prioritäten der Aufgaben geändert, wie Schätzungen angepasst oder wem welche Arbeit übertragen wird.

Beruhigend ist es, Informationen, die das Unternehmen nicht verlassen dürfen, gar nicht erst in den Tagesbericht zu schreiben.

Dazu gehören etwa Passwörter, Schlüssel und Angaben über Nutzerinnen und Nutzer oder Geschäftspartner.

Zudem ist norolu PDCA so gestaltet, dass die Daten der Tagesberichte im eigenen Google Drive (Tabelle) des nutzenden Unternehmens gespeichert werden.

Gemeint ist also Ihr eigenes. Es geht um einen Ansatz minimaler Datenspeicherung, der auf unserer Seite keine Informationen anhäuft.

Es geht um eine beständige Gewohnheit: getrennt von den festen Aufzeichnungen, in einem kurzen Format und mit Berichten, auf die eine Antwort kommt.

Wir glauben, dass diese Gewohnheit die Grundlage dafür ist, die kleinen Blockaden und Lernerfahrungen jedes Tages in den nächsten Schritt zu verwandeln.

Wir glauben auch, dass sie die Grundlage dafür ist, sie in eine bessere Arbeitsweise des Teams zu verwandeln.