Wiederkehrende Aufgaben: ein Kalender, der selbst Arbeit anlegt

„Jeden Montag das Backup prüfen”, „am Monatsersten die Zugänge kontrollieren”: Solche Aufgaben vergisst niemand absichtlich, sie gehen einfach unter. Mit den wiederkehrenden Aufgaben legt GODAV Pro sie selbst an. Eine Serie trägt einen Takt und ein Ziel-Feature, und zum richtigen Zeitpunkt entsteht darunter eine ganz normale User Story. Die Serie ist dabei eine Vorschrift, die nie fertig wird. Was sie erzeugt, ist echte Arbeit mit eigenem Status, eigener Zuweisung und einem Platz in der Iteration. Und sie läuft nicht mit einem allmächtigen Systembenutzer, sondern mit den Rechten ihres Eigentümers, die bei jedem Lauf neu geprüft werden. Hier geht es vor allem um den Teil darunter: den Kalender.

Oben steht, wann etwas entsteht, darunter, was entsteht. Diese Serie hat sich selbst angehalten und sagt auch, warum.

Der Erzeuger ist ein ganz normaler Benutzer

Die wichtigste Entscheidung war, dass der Hintergrunddienst eine Story auf demselben Weg anlegt, auf dem auch ein Mensch das tut. Er ruft denselben Dienst auf, nur eben im Namen des Eigentümers der Serie. Damit gelten Rechte, laufende Nummer, Startstatus, Zuweisungen und Änderungsprotokoll, ohne dass ich eine einzige dieser Regeln ein zweites Mal schreiben musste. Ein eigener Schreibweg für die Automatik hätte dieselben Prüfungen gebraucht, und irgendwann wäre er abgewichen.

Daraus ergab sich etwas Schönes: Die Gründe, aus denen eine Serie anhält, sind gar keine eigenen Prüfungen. Es sind die Antworten des Dienstes, übersetzt. „Gibt es nicht” heißt, das Ziel-Feature fehlt. „Nicht erlaubt” heißt, die Rechte des Eigentümers reichen nicht mehr. „Termin passt nicht” heißt, die Story läge hinter dem Zieltermin des Features. Nur einen Grund musste ich ausdrücklich ergänzen: Ein erledigtes Feature lehnt keine Termine mehr ab, und ohne diese Prüfung würde ein abgeschlossenes Feature Monat für Monat weiter wachsen.

Termine werden immer von vorne gezählt

Die Terminrechnung steht an einer einzigen Stelle, die Server und Oberfläche gemeinsam nutzen. Das Formular zeigt beim Einrichten die nächsten Termine als Vorschau, und der Erzeuger legt später genau an diesen Tagen an. Zwei getrennte Fassungen wären zwei Kalender, und der Unterschied fiele erst auf, wenn eine Story an einem Tag entsteht, den niemand angekündigt hat.

Die Rechnung merkt sich nichts, sie zählt jedes Mal von Beginn an. Ich hätte einen Zähler speichern können, welcher Termin als Nächstes dran ist. Dann hätte aber ein einziger verpasster Lauf den Takt dauerhaft verschoben. Von vorne gezählt ist der zwanzigste Termin der zwanzigste, egal wie oft der Server zwischendurch stand.

Kalender sind voller Stolperfallen, und ein paar davon haben die Tests gefunden:

• „Am 31.” trifft im Februar den 28. Gemeint ist der Monatsabschluss. Ein übersprungener Februar wäre ein Monat ohne Abschluss, und es würde niemandem auffallen.
• „Am letzten Freitag” ist ein eigener Wert und nicht „am fünften Freitag”, denn nicht jeder Monat hat einen.
• „Alle zwei Wochen montags”, an einem Donnerstag angelegt, ließ in einer frühen Fassung gleich am Anfang einen Durchlauf aus. Genau das hat ein Test aufgedeckt, bevor es jemand im Alltag gemerkt hätte.

Vorlauf, und warum er Pflicht ist

Eine erzeugte Story wandert absichtlich nicht von selbst in eine Iteration. Das soll ein Mensch entscheiden. Deshalb muss jede Serie einen Vorlauf haben: Würde die Story erst am Tag ihres Termins entstehen, wäre die Planung längst gelaufen. Der Vorlauf zählt dabei vom Wiederholungstermin, nicht vom Zieltermin. Bei „am Monatsersten, zu erledigen bis zum Siebten, sieben Tage Vorlauf” entsteht die Story also am 25. des Vormonats.

Keine Story doppelt, keine nachträglich

Der Erzeuger legt eine Story an und vermerkt danach, dass der Termin erledigt ist. Stürzt er genau dazwischen ab, hält er den Termin beim nächsten Lauf für offen. Damit dann nicht dieselbe Story zweimal entsteht, sorgt die Datenbank selbst dafür, dass es je Serie und Termin nur eine Story geben kann. Der Vermerk ist Buchführung, die Datenbankregel ist die eigentliche Zusicherung.

Zwei weitere Grenzen halten die Serie im Zaum: Vergangene Termine werden nie nachgeholt, sonst kämen nach einem längeren Stillstand zwölf überfällige Stories auf einmal. Und je Serie und Lauf entstehen höchstens drei, falls eine Regel unerwartet viele Treffer liefert.

Angehaltene Serien fallen in der Liste über das rote Abzeichen auf.

Anhalten ist nicht Beenden

Eine angehaltene Serie sollte eigentlich weiterlaufen, kann aber gerade nicht. Deshalb gibt es dafür eine Mail und eine Karte auf dem Dashboard. Beendet ist eine Serie, wenn jemand ihren Status auf „Erledigt” oder „Verworfen” setzt. Dann hat ein Mensch das ausdrücklich so entschieden, und es gibt niemanden, den man benachrichtigen müsste. Die Mails zum Anhalten werden außerdem gebündelt: Scheidet ein Eigentümer mit zwölf Serien aus, bekommt der Empfänger eine Mail und nicht zwölf, die sein Postfach als Werbung einsortiert.

Die bereits erzeugten Stories bleiben übrigens in jedem Fall stehen, auch wenn die Serie gelöscht wird. Sie sind echte Arbeit mit echten Zeitbuchungen und haben mit dem Ende der Vorschrift nichts zu tun.