Gantt und Jira: Plan und Umsetzung im Einklang halten

In vielen Unternehmen gibt es das Projekt zweimal. Der Plan mit Phasen, Abhängigkeiten und Lieferterminen liegt in einem Gantt-Diagramm, das die Projektleitung erstellt hat. Die Arbeit mit Tickets, Sprints und Zuweisungen liegt in Jira. Solange beides getrennt bleibt, muss jemand den Fortschritt von Hand übertragen, und die Termine im Plan veralten schnell.

Dieser Artikel erklärt, warum Jira allein für die Terminplanung nicht genügt, wie die bidirektionale Synchronisierung zwischen Planitude und Jira Cloud funktioniert und welche Grenzen Sie vor dem Einschalten kennen sollten.

Zwei Tools, zwei verschiedene Fragen#

Jira beantwortet die Frage: Woran arbeitet das Team gerade? Backlogs, Boards und Sprints sind genau dafür gebaut. Ein Terminplan beantwortet eine andere Frage: Wann sind wir fertig, und welche Aufgaben vertragen keine Verzögerung?

Für die zweite Frage braucht es Dauern, Abhängigkeiten mit Vorlauf und Verzögerung, Kalender mit Feiertagen, Einschränkungen und eine Berechnung, die jede Verschiebung an die Nachfolger weitergibt. Verzögert sich die Installation des neuen Servers um drei Tage, müssen sich Test, Schulung und Go-live von selbst verschieben, und die Projektleitung muss sofort wissen, ob der Liefertermin noch hält.

Was Jira für die Terminplanung fehlt#

Jira hat durchaus Planungsfunktionen. Die Zeitachse zeigt Abhängigkeiten zwischen verknüpften Elementen mit dem Linktyp „Blocks“, und wenn sich die Termine zweier verknüpfter Elemente überschneiden, wird die Abhängigkeitslinie rot, um auf eine mögliche Verzögerung hinzuweisen^[1]. Laut der Preisseite von Atlassian werden Abhängigkeiten in den Tarifen Free und Standard innerhalb eines Projekts verwaltet, im Tarif Premium projektübergreifend^[2].

Ein Warnhinweis ist jedoch keine Neuberechnung: Die Termine bleiben so, wie sie eingegeben wurden, und der kritische Pfad gehört nicht zu den beschriebenen Funktionen. Die Folge: Der Plan lebt woanders, in einer Datei oder einem anderen Tool, und läuft auseinander. Einen vollständigen Vergleich beider Tools finden Sie im Artikel Planitude vs Jira.

So funktioniert die bidirektionale Synchronisierung#

Die Integration verbindet ein Planitude-Projekt mit einem Jira-Cloud-Projekt. Die Anmeldung erfolgt über OAuth 2.0 von Atlassian: Planitude kennt Ihr Passwort nicht, speichert die Tokens verschlüsselt und erneuert sie mit den rotierenden Refresh-Tokens von Atlassian, die nach 90 Tagen Inaktivität ablaufen^[3].

Bei der ersten Verbindung wählen Sie den Erstabgleich:

1. Plan an Jira senden: Für jede Aufgabe entsteht ein Vorgang und für jede Abhängigkeit ein „Blocks“-Link;
2. Aus Jira importieren: Jeder bestehende Vorgang wird zu einer Aufgabe am Ende des Plans, mit Starttermin, Dauer, Fortschritt und Bearbeiter;
3. Beides: zuerst der Import, dann werden die Aufgaben gesendet, die es in Jira noch nicht gibt.

Ab dann fließen Änderungen in beide Richtungen. Von Planitude nach Jira wird jede Planänderung erkannt und innerhalb weniger Sekunden übertragen, egal woher sie stammt: Tabelle, Gantt-Diagramm, Import oder KI-Assistent. Von Jira nach Planitude kommen Änderungen über die von der Integration registrierten Webhooks, die Planitude vor dem von Atlassian vorgesehenen Ablauf nach 30 Tagen erneuert^[4]; eine Prüfung alle fünf Minuten holt verpasste Ereignisse nach.

Sammelvorgänge können nur in Planitude bleiben oder zu Epics werden, mit den darunterliegenden Aufgaben als untergeordnete Vorgänge.

Wer was bestimmt: die Feldregel#

Eine zuverlässige Synchronisierung braucht für jedes Feld eine einfache Regel. In Planitude lautet sie:

Die Logik folgt der echten Arbeit: Der Plan bestimmt, wann, das Team bestimmt, wie weit eine Aufgabe ist und wer sie erledigt. Der Status wird über eine anpassbare Zuordnung in Prozent übersetzt: je Kategorie „zu erledigen“ 0 %, „in Arbeit“ 50 %, „erledigt“ 100 %. Steht eine Aufgabe bereits bei 30 % und wechselt der Vorgang auf „In Arbeit“, wird der Fortschritt nicht mit pauschal 50 % überschrieben.

Personen werden automatisch über die E-Mail-Adresse zugeordnet, wenn der Jira-Nutzer sie sichtbar macht; andernfalls wählen Sie die Zuordnung auf der Integrationsseite von Hand.

Abhängigkeiten, Konflikte und Löschungen#

Abhängigkeiten. Ende-Anfang-Verknüpfungen werden zu „Blocks“-Links: Der Vorgänger blockiert den Nachfolger. Anfang-Anfang, Ende-Ende und Anfang-Ende haben in Jira keine Entsprechung und bleiben nur in Planitude. Von Hand in Jira angelegte „Blocks“-Links werden weder importiert noch gelöscht.

In Jira geänderte Termine. Da die Termine vom Plan berechnet werden, wird ein in Jira geänderter Termin auf den Wert des Plans zurückgesetzt, und die abgelehnte Änderung erscheint im Protokoll der Integration. Um eine Aufgabe zu verschieben, verschieben Sie sie im Plan: Die Engine berechnet dann auch alle abhängigen Aufgaben neu.

Konflikte. Für jedes Feld vergleicht Planitude drei Werte: den zuletzt abgestimmten Wert, den aktuellen Wert im Plan und den aktuellen Wert in Jira. Hat sich nur eine Seite geändert, geht die Änderung an die andere. Haben sich beide auf unterschiedliche Werte geändert, gewinnt die bestimmende Seite, und der Konflikt wird mit beiden Werten protokolliert. Die Regel hängt nur von den Daten ab, nicht von den Uhren der beiden Server.

Löschungen. Keine Seite löscht etwas auf der anderen. Eine in Planitude gelöschte Aufgabe lässt den Vorgang in Jira mit dem Label planitude-unlinked stehen; ein in Jira gelöschter Vorgang lässt die Aufgabe im Plan, und die Seite bietet zwei Aktionen: in Jira neu anlegen oder nicht mehr synchronisieren.

Jira Schritt für Schritt verbinden#

1. Öffnen Sie das Projekt in Planitude und wählen Sie ⋯ › Integrationen › Jira.
2. Klicken Sie auf Jira verbinden und erteilen Sie im Zustimmungsdialog von Atlassian den Zugriff.
3. Sieht Ihr Konto mehrere Sites, wählen Sie die richtige und dann das Jira-Projekt.
4. Prüfen Sie die Optionen: Standard-Vorgangstyp, Sammelvorgänge als Epics oder nicht, Feld für den Starttermin, Label für von Planitude angelegte Vorgänge.
5. Wählen Sie den Erstabgleich: senden, importieren oder beides.
6. Prüfen Sie den Bereich Personen und ergänzen Sie Zuordnungen, die nicht per E-Mail gefunden wurden.

Planitude schreibt in Jira mit der Identität der Person, die das Projekt verbunden hat. Diese Person braucht in Jira die Berechtigungen, das Projekt zu durchsuchen, Vorgänge anzulegen, zu bearbeiten, zuzuweisen und zu verknüpfen sowie Transitionen auszuführen. Eigentümer und Bearbeiter des Planitude-Projekts können die Integration konfigurieren; Personen mit Lesezugriff sehen nur den Status. Die übrigen Integrationen beschreibt die Seite Integrationen.

Bekannte Grenzen#

• Nur Jira Cloud: Jira Data Center und Server werden nicht unterstützt.
• Nur Ende-Anfang-Abhängigkeiten; ein Bearbeiter pro Vorgang (die Person mit den meisten Einheiten an der Aufgabe).
• Termine auf den Tag genau: Uhrzeiten bleiben in Planitude.
• Atlassian erlaubt einer OAuth-App 5 Webhooks pro Nutzer und Site^[4]: Ab dem sechsten Projekt, das dieselbe Person auf derselben Site verbindet, kommen Änderungen aus Jira über die Prüfung alle fünf Minuten.
• Mit der Option „nur Blattaufgaben“ wird eine Aufgabe, die zum Sammelvorgang wird, als entfernt behandelt, und ihr Vorgang erhält das Label planitude-unlinked.

Häufige Fragen#