Ein Takt für mehrere Projekte

Viele Teams arbeiten an drei oder vier Projekten gleichzeitig, und trotzdem im selben Zweiwochenrhythmus: Der Sprint beginnt montags für alle. Genau das bildet der Iterationsplan in GODAV Pro ab: Er ist der Takt, und Projekte schließen sich ihm an. In diesem Beitrag geht es um den Plan selbst. Die einzelnen Abschnitte und ihr Board bekommen einen eigenen Beitrag, ebenso der Abschluss einer Iteration.

Der Plan gehört keinem Projekt

Ein Projekt folgt höchstens einem Plan, ein Plan trägt beliebig viele Projekte. Der Plan steht also nicht unter einem Projekt, sondern daneben, und die Projekte zeigen auf ihn. Zugeordnet wird im Reiter „Projekte“ des Plans. Wer zehn Projekte in einen Takt holen will, macht das an einer Stelle und muss nicht zehn Projektkarten nacheinander öffnen.

Der Demoplan „CRM-Bereinigung“ mit seinem einen Projekt. Über „Projekte zuordnen“ kommen weitere dazu.

Die Projektkarte zeigt ihren Plan deshalb nur als Verweis an, nicht als Auswahlfeld. Ein zweites Feld dort wäre ein zweiter Weg zum selben Ziel, mit denselben Regeln, und früher oder später würden die beiden Wege sich unterschiedlich verhalten.

Ist ein Projekt schon in einem anderen Plan, wird es nicht still umgehängt. Die Meldung nennt den Plan, in dem es steckt, und in der Auswahlliste steht das Projekt gesperrt mit genau diesem Grund. Ausgeblendet hätte es gewirkt, als sei die Liste kaputt.

Wer darf zuordnen, wer sieht den Plan?

Hier steckt die Entscheidung, über die ich am längsten nachgedacht habe. Für Iterationspläne gibt es eigene Rechte zum Anlegen, Ändern und Löschen. Naheliegend wäre gewesen, damit auch das Zuordnen von Projekten zu regeln. Ich habe mich dagegen entschieden: Wer ein Projekt in einen Plan setzt, braucht das Recht, dieses Projekt zu ändern. Sonst wäre „Pläne verwalten“ der kürzeste Weg, fremde Projekte in den eigenen Takt zu ziehen. Man legt einen Plan an, setzt die Projekte hinein, fertig. Beim Anlegen gelten deshalb beide Rechte: das für den Plan und das für jedes genannte Projekt.

Sichtbar ist ein Plan für jeden, der mindestens eines seiner Projekte sehen darf. Ohne diese Regel würde die Planliste Projektnamen aus Bereichen verraten, mit denen der Leser nichts zu tun hat. Auch die Projektliste im Plan ist gefiltert: Wer in einem von fünf Projekten mitarbeitet, sieht den Plan und genau sein eigenes Projekt. Die Zahl daneben zählt dieselbe Menge. Eine „5“ über einer Liste mit einer einzigen Zeile würde nur Fragen aufwerfen.

Daraus folgt eine weitere Regel: Ein Plan braucht mindestens ein Projekt, beim Anlegen und auf Dauer. Ein Plan ohne Projekt wäre für niemanden außer dem Administrator sichtbar, er stünde in keiner Liste, in der ihn jemand sucht. Deshalb lässt sich auch das letzte Projekt nicht aus einem Plan entfernen.

Pflicht ist nur der Name

Ein Takt wird oft benannt, bevor sein Start feststeht. Deshalb muss beim Anlegen nur der Name stehen, Startdatum und Länge lassen sich nachtragen. Hätte ich beides zur Pflicht gemacht, stünde dort ein geratenes Datum, und geraten sieht später aus wie beschlossen. Solange etwas fehlt, trägt der Plan in der Liste das Kennzeichen „Unvollständig“, denn ohne beide Angaben lässt sich keine Iteration daraus berechnen.

Sobald die erste Iteration besteht, ändert sich das. Das Startdatum ist dann festgelegt, die Dauer je Iteration nicht. Der Unterschied liegt darin, wohin eine Änderung wirkt. Das Startdatum kommt genau einmal vor, und die ganze Kette der Abschnitte hängt daran. Es nachträglich zu verschieben hieße, längst gelaufenen Iterationen andere Termine zu geben, als sie hatten. Die Dauer dagegen wird beim Anlegen jeder Iteration kopiert. Wer sie von 14 auf 21 Tage stellt, meint die künftigen Abschnitte, und genau dort wirkt sie auch.

Das Startdatum ist gesperrt. Der Hinweis nennt die Zahl der Iterationen, denn eine versehentlich angelegte ist etwas anderes als ein halbes Jahr Planung.

Der Status hat kein Feld

Anfangs hatte der Plan ein Statusfeld mit „Neu“, „In Bearbeitung“ und „Erledigt“. Damit konnte man einen Plan auf „Erledigt“ setzen, während eine seiner Iterationen noch lief. Zwei Stellen beschrieben dasselbe und konnten sich widersprechen. Heute folgt der Status den Iterationen: Mit der ersten Iteration wechselt der Plan von selbst auf „In Bearbeitung“, und im Protokoll steht dafür „System“ als Handelnder. Erledigt wird er erst, wenn jemand die letzte Iteration abschließt und keinen weiteren Abschnitt will.

Außerdem

• Der Plan hat einen Reiter „Log“, in dem jede Änderung mit Datum und Person steht.
• Wird ein Plan gelöscht, verlieren seine Projekte die Zuordnung, und jedes Projekt bekommt dazu eine eigene Zeile im Protokoll.

Mit Plan und Projekten steht der Rahmen. Was in den einzelnen Abschnitten passiert, erzähle ich im nächsten Beitrag über die Iterationen und ihr Board.