Releases: Was ist schon draußen, was kommt noch?

Bis Ende August konnte GODAV gut sagen, woran gerade gearbeitet wird. Eine Frage blieb offen, die in jeder Abstimmung mit einem Fachbereich früher oder später fällt: Was davon ist eigentlich schon ausgeliefert, und was kommt mit dem nächsten Stand? Dafür gibt es jetzt Releases, einen eigenen Reiter an der Projektkarte.

Ein Release ist schlicht ein Auslieferungsstand: ein kurzer Name wie „1.0“ oder „Herbstlieferung“, optional ein Tag, eine Beschreibung und ein Haken für „veröffentlicht“.

Veröffentlichte Stände stehen oben, mit Zeitpunkt und Person. Darunter wartet die Herbstlieferung.

Kein Meilenstein mit anderem Namen

Auf den ersten Blick ähneln sich Release und Meilenstein: Beide gehören zu einem Projekt, beide haben einen Tag. Ich habe sie trotzdem bewusst getrennt gehalten. Ein Meilenstein sagt, was bis wann erreicht sein soll, ein Release, was ausgeliefert wird. Daraus folgt der wichtigste Unterschied: Beim Meilenstein ist der Tag Pflicht, weil er sonst keinen Platz im Gantt hätte. Beim Release ist er freiwillig. „1.1, Termin noch offen“ ist eine ehrliche Auskunft, und ein erzwungenes Datum wäre an dieser Stelle nur geraten.

Auch sonst ist das Release bewusst schlank: ein Haken statt eines Statusmodells, keine Vorlagen aus einer zentralen Verwaltung und keine Zuständigen. Eine Person, die an einem Release eingetragen ist, aber nichts auslöst, ist genau die Art Angabe, die nach dem dritten Mal niemand mehr pflegt. Der Name ist auf dreißig Zeichen begrenzt, weil er als kleine Pille auf jeder Boardkarte und in den Vorgangslisten steht. Wer mehr erzählen will, hat dafür die Beschreibung.

Die Zuordnung fließt nach unten

Spannend wurde es bei der Frage, wie ein Vorgang zu seinem Release kommt. Epics, Features und Storys können eines tragen, Aufgaben nicht. Eine Aufgabe wird nie allein ausgeliefert, ihr Release wäre ohnehin immer das ihrer Story.

Setzt du am Epic „2.0“, bekommen alle Features und Storys darunter automatisch dasselbe. Das Fenster sagt dir vorher, wie viele Vorgänge es betrifft, fragt aber nicht, ob du es anders möchtest. Ein Kind darf kein anderes Release tragen als sein Elternvorgang, und auch gar keines ist ein anderes. Sonst wäre die Zusage „alles unter diesem Epic geht in 2.0“ mit einem Klick ausgehebelt. Am Kind steht das Feld dann nur lesend da, mit einem Satz, woher der Wert kommt.

Beim Leeren dagegen gibt es eine echte Wahl. Gibt das Epic seine Bindung auf, können die Kinder ihr Release behalten oder es mit verlieren. Beide Ausgänge sind sinnvoll, und keiner ist so naheliegend, dass ich ihn als Vorgabe hätte festlegen wollen. Deshalb hat dieses Fenster drei Knöpfe statt zwei.

Ich hätte die Vererbung auch nur beim Lesen ausrechnen können, also jedes Mal die Kette nach oben verfolgen. Das hätte eine Spalte gespart, aber jedes Board mit zweitausend Karten teurer gemacht. Deshalb steht das Release an jeder Ebene direkt am Vorgang, und die Vererbung schreibt es beim Setzen, beim Anlegen und beim Umhängen mit.

Nur Storys zählen

Eine Folge der Vererbung ist leicht zu übersehen: Wenn Epic, Feature und Story dasselbe Release tragen, steckt dieselbe Arbeit dreimal darin. Jede Releasezeile zeigt, wie viele Storys abgeschlossen sind und wie viel Aufwand schon gebucht ist. Gezählt werden dabei ausschließlich Storys. Die dreifache Summe wäre plausibel gewesen, und genau deshalb wäre es niemandem aufgefallen.

Dieselbe Überlegung steckt in der neuen Releaseansicht des Gantt. Sie ordnet die Storys nach ihrem Auslieferungsstand statt nach Hierarchie. Epics und Features fehlen dort, sonst stünde jede Gruppe dreimal gefüllt da. Jedes Release bekommt einen Kopf, auch ein leeres, und am Ende steht die Gruppe „Ohne Release“, sobald sie etwas enthält.

Dieselben Balken, dieselben Gesten, nur nach Auslieferungsstand gruppiert.

In beiden Ansichten markiert eine gestrichelte Linie den Auslieferungstag. Sie ist cyan und nicht blau, weil Blau schon die Heute-Linie ist, und gestrichelt, weil ein Auslieferungstag ein Plan ist und kein Tatbestand.

Außerdem

• Boards und Vorgangslisten lassen sich nach Release filtern. Der Filter ist gesperrt, bis ein Projekt gewählt ist, denn ein Release gehört immer genau einem Projekt.
• Die Datenhygiene meldet Storys ohne Release, allerdings nur in Projekten, die überhaupt Releases führen.
• Anlegen, Ändern und Löschen sind drei eigene Berechtigungen. „Projekt ändern“ soll nicht heimlich auch „Releases löschen“ bedeuten.

Ein Register über alle Projekte gibt es bewusst nicht. Ein Release liest man an seinem Projekt, und eine Gesamtliste aller „1.0“ aller Projekte beantwortet keine Frage, die heute jemand stellt.