Meilensteine: Rauten, die mit der Planung wandern

„Beta-Freigabe“, „Vertrag unterschrieben“, „Schulung der Fachbereiche“: In jedem Projekt gibt es Tage, an denen etwas erreicht sein soll. Sie haben keine Dauer, sie sind einfach ein Punkt im Kalender. Mit dem Gantt hatte GODAV Pro zwar Balken für Epics, Features und Storys, aber keinen Ort für diese Punkte. Den gibt es jetzt: Meilensteine, mit einem eigenen Menüpunkt und als Raute im Gantt.

Ein Meilenstein besteht aus wenig: Name, Beschreibung, Fälligkeitsdatum, Status. Dazu kann er einen Vorgang tragen, der seine Voraussetzung ist. Genau dieser eine Verweis macht den Bereich interessant.

Zwei Daten, und nur eins davon ist gespeichert

Ein Meilenstein hat bei mir zwei Tage. Das Fälligkeitsdatum ist die Zusage, also der Tag, den jemand genannt hat. Der zweite Tag ist der, an dem die Raute im Gantt tatsächlich steht. Hängt am Meilenstein ein Vorgang mit geplantem Ende, ist es dieses Ende. Zieht jemand den Balken der Story nach hinten, wandert die Raute mit.

Ich hätte den wirksamen Tag auch als eigenes Feld speichern können, das bei jeder Planänderung nachgezogen wird. Das hätte bedeutet, an jeder Stelle, die ein geplantes Ende verändert, daran zu denken, auch den Meilenstein zu aktualisieren. Irgendwann vergisst man eine, und dann stehen zwei verschiedene Wahrheiten nebeneinander. Deshalb wird der Tag bei jeder Anzeige aus dem Vorgang berechnet. Er kann gar nicht veralten.

Zwei Datumsspalten mit Absicht: links die Zusage, rechts, wo die Raute gerade steht.

Im Register sieht man deshalb beide Spalten nebeneinander. „Zahlungsverkehr produktiv“ war für Mitte April zugesagt, die Planung der Story dahinter endet aber erst im September. Genau dieser Abstand ist die Auskunft, für die man Meilensteine überhaupt führt. Hätte ich nur einen der beiden Tage gezeigt, hätte ich entweder die Zusage oder die Wirklichkeit verschwiegen.

Das Fälligkeitsdatum ist trotzdem Pflicht, auch wenn ein Vorgang zugewiesen ist. Es ist der Rückfall: Leert jemand das geplante Ende der Story, hätte die Raute sonst keine Position mehr und würde aus dem Gantt verschwinden. Ein Meilenstein am falschen Tag ist ärgerlich, ein verschwundener ist gefährlich. Im Gantt erkennt man den Rückfall an einer hohlen statt einer gefüllten Raute.

Ein Vorgang je Meilenstein, nicht mehrere

Ein Meilenstein trägt höchstens einen Vorgang, und zwar ein Epic, ein Feature oder eine Story, also die Arten mit geplanten Daten. Umgekehrt darf ein Vorgang Voraussetzung für mehrere Meilensteine sein: „Story X muss für die Beta und für den Go-live fertig sein“ ist ein ganz normaler Fall.

Die andere Richtung habe ich bewusst nicht gebaut. Hinge die Beta an drei Storys, welche davon würde die Raute verschieben? Die späteste? Das wäre eine Regel, die niemand sieht und die im Alltag niemand pflegt. Wer wirklich auf mehrere Dinge wartet, hängt den Meilenstein an das Feature darüber.

Die Voraussetzung wird in drei Stufen gewählt: erst das Epic, dann das Feature, dann die Story.

Die Auswahl im Dialog war zuerst ein einziges Feld mit allen Epics, Features und Storys darin. Bei vierzig Features und zweihundert Storys war das keine Auswahl mehr, sondern eine Suchaufgabe. Jetzt sind es drei Felder untereinander, und jedes schaltet das nächste frei. Gewählt ist am Ende die tiefste gefüllte Ebene. Wer nur ein Epic angibt, bekommt das Epic als Voraussetzung.

Die Raute im Gantt

Hängt ein Meilenstein an einem Vorgang, sitzt seine Raute in dessen Zeile, am Ende des Balkens. Während man einen Balken zieht, wandert sie in Echtzeit mit, nicht erst nach dem Loslassen. Meilensteine ohne Vorgang bekommen eigene Zeilen ganz oben im Diagramm.

Oben ein freier Meilenstein, darunter eine Raute am Ende ihrer Story.

In die oberen Zeilen kommen auch Meilensteine, deren Vorgang gerade ausgeblendet ist. Nimmt jemand den Haken bei „Stories“ weg, verschwinden sonst mit den Zeilen auch die Rauten, und das Diagramm sieht trotzdem vollständig aus. Ein Zeitplan, der Termine stillschweigend verschluckt, meldet niemand als Fehler, und genau deshalb habe ich darauf geachtet.

Außerdem

• An der Vorgangskarte steht ein Hinweis, wenn der Vorgang Voraussetzung für einen Meilenstein ist. Wer dort umplant, soll das lesen, bevor er die Daten anfasst.
• Meilensteine haben eigene Rechte zum Anlegen, Ändern und Löschen. „Projekt bearbeiten“ heißt also nicht automatisch „Termine zusagen“.
• Ob ein Meilenstein erreicht ist, entscheidet ein Mensch. Dass die Story erledigt ist, heißt noch nicht, dass jemand das Ergebnis abgenommen hat.

Als Nächstes sollen Meilensteine und Releases zusammenfinden. Ein Auslieferungsstand ist am Ende auch nur ein Tag, an dem etwas erreicht sein soll.