Was quer zur Hierarchie zusammenhängt: Verknüpfungen und Blocker

Die Hierarchie in GODAV Pro ist ein Baum: Jeder Vorgang hat genau einen Platz unter genau einem Elternteil. Damit lässt sich gut ausdrücken, wozu etwas gehört. Vieles im Alltag hängt aber anders zusammen: Eine Aufgabe wartet auf eine andere aus einem ganz anderen Zweig, ein Fehler wurde zweimal gemeldet, zwei Stories sollte man besser gemeinsam angehen. Für diese Fälle gibt es seit 0.3.0 die Verknüpfungen in einem eigenen Reiter an jedem Vorgang.

Drei Arten, aber nur eine mit Richtung

Zur Wahl stehen Blocker, Dublette und Abhängigkeit. Nur beim Blocker kommt es auf die Richtung an. Ursprünglich war noch eine vierte Art vorgesehen, einfach „Verknüpfung“. Ich habe sie gestrichen, weil sie neben Dublette und Abhängigkeit nichts Neues ausgesagt hätte.

Dieselbe Verknüpfung heißt hier „wird blockiert von“ und auf der anderen Karte „blockiert“.

Eine Zeile, zwei Blickrichtungen

Gespeichert wird jede Verknüpfung genau einmal, als Paar aus Quelle und Ziel. Beide Karten lesen dieselbe Zeile und drehen sie sich zurecht: Die eine sagt „blockiert“, die andere „wird blockiert von“. Zwei Zeilen je Verknüpfung wären einfacher abzufragen gewesen, aber dann gäbe es zwei Wahrheiten. Beim Entfernen der einen bliebe irgendwann die andere stehen.

Aus demselben Gedanken folgt: Zwischen zwei Vorgängen steht höchstens eine Aussage. Das erzwingt die Datenbank selbst, unabhängig von Richtung und Art. Wer aus einer Dublette einen Blocker machen will, entfernt die alte Verknüpfung und legt eine neue an. Bearbeiten gibt es nicht, denn eine andere Art ist auch eine andere Aussage.

Beim Blocker prüft GODAV außerdem, dass keine Kette einen Kreis bildet. Diese Prüfung läuft in derselben Transaktion wie das Speichern. Sonst könnten zwei Leute gleichzeitig je eine harmlose Verknüpfung anlegen, die zusammen den Kreis schließen.

Wer verknüpfen darf, und was nicht geht

Ich habe dafür kein eigenes Recht eingeführt. Wer einen Vorgang ändern darf, darf ihn auch verknüpfen. Ein neues Recht hätte anfangs keine Rolle gehabt, und bis jemand eine einrichtet, hätte niemand verknüpfen können. Geprüft wird das Recht nur an der Karte, von der aus man verknüpft. Die andere Seite muss man aber sehen dürfen, sonst ließe sich über die Fehlermeldung herausfinden, welche Vorgänge in fremden Projekten existieren.

Zwei Grenzen gibt es bewusst:

• Nur innerhalb eines Projekts. Ein Blocker aus einem fremden Projekt stünde in einer Liste, deren Leser das andere Projekt womöglich nie zu sehen bekommt.
• Keine Sonderaufgaben. Sie laufen neben der Planung, etwa als wöchentliche Abstimmung. „Die Abstimmung wartet auf Aufgabe 42“ stimmt nie.

Was das Board daraus macht

Auf den Kanbanboards trägt jede Karte ein Zeichen mit Anzahl, wenn sie blockiert ist, selbst blockiert oder eine Dublette hat. Eine Regel war mir dabei besonders wichtig: Es zählt nur, was gerade wirklich aufhält. Sobald der blockierende Vorgang erledigt oder verworfen ist, verschwindet das Zeichen. Die Verknüpfung selbst bleibt stehen, weil sie als Aussage über die Vergangenheit weiterhin stimmt.

Diese Story ist erledigt. Die Verknüpfung bleibt im Reiter stehen, auf dem Board hält sie niemanden mehr auf.

Im Änderungsprotokoll landet jede Verknüpfung an beiden Vorgängen, und zwar mit der Kennung des anderen Vorgangs, etwa „BC-3“, und nicht mit der internen ID. Die Kennung erkennt ein Mensch wieder, und sie bleibt auch dann lesbar, wenn der andere Vorgang längst gelöscht ist. Gerade dann ist das Protokoll die einzige Stelle, die noch von ihm weiß.

Kein Blocker, der blockiert, und das steht auch da

In diesem Stand hält ein Blocker niemanden auf. Der Status lässt sich trotzdem ändern. Ich wollte erst die Beziehung sauber festhalten und die Logik danach bauen, statt beides halb fertig zu haben. Damit niemand eine Sperre erwartet, die es nicht gibt, steht unter jeder Liste ein Satz, der genau das sagt. Eine echte Wirkung bekamen die Blocker später im Gantt: Dort lässt sich ein blockierter Vorgang nicht vor das Ende seines Blockers planen.