OpenProject: Eine Alternative zu Jira?

Ich habe mir einige Wochen Zeit genommen, um OpenProject gründlich zu testen. Dafür entwarf ich Beispielszenarien, mit denen ich die Funktionen der Software zeige. In Anlehnung an den Jira-Artikel meines Kollegen gehe ich später auch darauf ein, wie ich OpenProject in Verbindung mit einem eigenen KI-Modell nutze.

‍

Der Artikel ist lang geworden. Ich verstehe deshalb gut, wenn Sie ihn eventuell nicht komplett lesen möchten. Da aber nicht alle Teile für alle gleich interessant sind, wollte ich nichts streichen. Vielleicht wäre genau dieser Abschnitt für Sie wichtig gewesen.

‍
Suchen Sie sich deshalb gern die Themen heraus, die Sie interessieren. Im Fazit am Ende des Artikels fasse ich meine wichtigsten Erkenntnisse noch einmal zusammen. Wenn Sie den gesamten Artikel lesen, freue ich mich sehr — und danke Ihnen für Ihre Aufmerksamkeit.

‍

Im Rahmen unserer Artikelserie zum Digital Independence Day wollte ich eine datensouveräne Alternative zu Jira finden. Dieser Artikel vergleicht OpenProject und Jira nicht bis ins Detail und arbeitet keine einzelnen Funktionen ab. Stattdessen beantwortet er eine praktische Frage:

‍

Wenn ich heute Jira ablösen möchte – ist OpenProject dafür eine brauchbare Alternative?

‍

Beim Kennenlernen von OpenProject stellte ich schnell fest, dass die Software nicht nur mithalten kann. Der Gedanke lag nahe, dass sie in manchen Bereichen sogar besser sein könnte als Jira. Aber zunächst erläutere ich die Bewertungskriterien, die ich angelegt habe.

‍

Unterschiedliche Perspektiven auf Jira

‍

Die möglichen Perspektiven auf Jira sind vielfältig, da jede Nutzergruppe unterschiedliche Ziele mit der Nutzung von Jira verbindet. Grundsätzlich habe ich mir zwei Perspektiven genauer angeschaut:

‍

• Die Perspektive eines agilen Entwicklungsteams mit den Rollen Entwickler:innen, Product Owner, Scrum Master usw.
• Die Perspektive eines:einer Projektleiter:in. Diese Perspektive repräsentiert für mich die Perspektive der Organisation.

‍

Die Perspektive eines agilen Entwicklungsteams

‍

Ich selbst habe Jira viel in unterschiedlichen Kundenprojekten als Entwickler in agilen Software-Entwicklungsteams genutzt. Jira hat meine Erwartungen bezüglich einer Projektmanagement-Software sehr stark geprägt. Das habe ich immer dann gemerkt, wenn ich zeitweise in Projekten etwas anderes verwenden musste. Aus der agilen Perspektive sind mir deshalb folgende Dinge, die Jira mitbringt, ganz besonders wichtig:

‍

Es gibt einen Planungsmodus

‍

Wenn mein Projektteam nach Scrum arbeitet, dann möchte ich eine klare Unterscheidung von Tickets, die im Sprint liegen und denen, die noch im Backlog sind. Wenn Projektmanagement-Tools diese klare Unterscheidung nicht machen, dann ist das Backlog eine Spalte im Board. Das führt zu einer großen Unübersichtlichkeit, weil im Board dann einfach viel zu viele Tickets liegen. Jira trennt ja den Bereich des Backlogs sehr deutlich vom aktuellen Sprint, d. h., während eines Plannings kann ich Tickets im Backlog auswählen und in den aktuellen Sprint ziehen. So einen Planungsmodus wünsche ich mir auch für jede akzeptable Jira-Alternative.

‍

Aufgaben-Typen unterschiedlicher Hierarchiestufen

‍

Manche Aufgaben sind zu groß für einen Sprint. Deshalb möchte ich sie in Unteraufgaben aufteilen und getrennt bearbeiten. In Jira geschieht das meist über Epics. Ein Epic bündelt mehrere User Stories und hilft dabei, User Stories inhaltlich durch einen gemeinsamen Rahmen miteinander zu verbinden. Wie wichtig das ist, merkt man, wenn einem das Feature nicht mehr zur Verfügung steht.

‍

Es werden unterschiedliche agile Vorgehensweisen unterstützt

‍

Ich möchte nicht, dass mein Projektmanagement-Tool bestimmt, nach welcher agilen Vorgehensweise ich arbeiten kann, d.h. ich erwarte, dass zumindest Scrum und Kanban unterstützt werden. Unterstützung von Scrum ist für mich dann gegeben, wenn der oben genannte Planungsmodus Backlog und Sprint klar voneinander trennt. Um Kanban vernünftig zu unterstützen, wünsche ich mir, dass ich Limits für die jeweiligen Spalten definieren kann. Das bedeutet, dass ich eine visuelle Rückmeldung darüber bekomme, ob ich mein Work-in-Progress-Limit in einer Spalte überschritten habe.

‍

Kriterien für die Organisation/Projektleitung

‍

Ich selbst habe Jira primär aus Entwicklersicht kennengelernt. Ich habe allerdings in Kundenprojekten auch gelernt, dass es Features in Jira gibt, die ich für meinen Entwickler-Alltag nicht benötigt habe, bei denen ich aber verstehen kann, dass sie für eine Organisation wichtig sind. Ich habe mir Jira Alternativen deshalb auch unter der Perspektive angeschaut, ob sie den von mir wahrgenommenen Bedürfnissen einer Organisation entsprechen.

‍

Folgende Bedürfnisse habe ich dabei wahrgenommen:

‍

Darstellung von Projekten unterschiedlicher Hierarchiestufen: Auf Ebene des Top-Managements entstehen oft strategische Initiativen, die mehrere Unternehmensbereiche umfassen können. Das bedeutet, dass auch mehrere Unternehmensteile bzw. unterschiedliche Teilprojekte an der Erreichung dieser strategischen Ziele mitwirken. Das bedingt fast zwangsläufig, dass ich eine Organisations-Hierarchie benötige. Es muss eine Steuerungsebene geben, auf der die Aktivitäten unterschiedlicher Unternehmensbereiche, Projekte zusammenlaufen und gesteuert bzw. koordiniert werden können.

‍
Die eigentliche Umsetzungsarbeit findet dabei in spezialisierten Projekten statt, die möglichst wenig voneinander wissen müssen. Idealerweise kann ich meine Projekthierarchie auch in der von mir genutzten Projektmanagement-Software abbilden. Dabei möchte ich in der Lage sein, auf der obersten Ebene Aufgaben anzulegen. Diese möchte ich dann in Unteraufgaben zerlegen und unterschiedlichen Teilprojekten zuweisen können.

‍

Überblick über den Gesamt-Projektstatus erhalten: Auch wenn die Arbeit über mehrere Teilprojekte verteilt ist, möchte ich mir als Projektleiter:in leicht einen Überblick über den Status des Gesamtprojektes verschaffen können. Dabei gehe ich davon aus, dass es auf dieser Ebene wirklich nur darum geht, den Gesamtstatus zu erfassen und nicht in einer Wasserfall-Art das Projekt zu steuern.

‍

Rechtliche Rahmenbedingungen umsetzen und digitale Souveränität unterstützen: Dieser Punkt ist Anlass dieses Artikels. Als Unternehmen möchte ich auf rechtlich stabilem Fundament stehen. In Deutschland bedeutet das, dass ich alle Regelungen der DSGVO umsetze. Strategisch möchte ich mich als Unternehmen aber auch nicht zu stark von einem Anbieter abhängig machen. Das bedeutet, dass ich abschätzen kann, ob die Einführung eines neuen Projektmanagement-Tools mich in eine Sackgasse führt, aus der ich vielleicht nicht wieder leicht herauskomme. Über diese Kriterien habe ich mir im Vorfeld der Begutachtung unterschiedlicher Tools Gedanken gemacht. Kriterien sind aber auch durch das Kennenlernen spezifischer Tools dazu gekommen. Das betrifft vor allem die Organisationsperspektive. Die Entwicklerperspektive wurde primär durch meine eigene praktische Arbeit geformt.

‍

Warum habe ich mich auf OpenProject fokussiert?

‍

Ich habe mich auf die Suche nach einer Jira-Alternative gemacht, in dem ich zunächst online recherchiert habe. Die Alternativen habe ich mir angeschaut und mit meinem Kriterien-Katalog abgeglichen. OpenProject hat mich sofort angesprochen. Deshalb habe ich mich darauf konzentriert und andere Lösungen nur oberflächlich geprüft. Wer mehr über die anderen Kandidaten wissen will, findet dazu Erläuterungen im Anhang zu diesem Artikel.

‍

Wenn man die OpenProject-Website besucht, fallen drei Produkteigenschaften auf:

‍

• Datensouveränität und Datensicherheit
• Unterstützung für Klassisches, Agiles und hybrides Projektmanagement
• tarke Referenzen: Siemens, Deutsche Bahn, Fraunhofer, Greenpeace, The Linux Foundation, AMG und weitere bekannte Kunden.

‍

Datensouveränität

‍

OpenProject ist Open Source. Ich kann es selbst hosten oder eine Cloud-Variante von OpenProject wählen. Besonders attraktiv bei der Cloud-Variante: Ich entscheide selbst, bei welchem Cloud-Provider meine Instanz läuft. Zur Auswahl stehen AWS Europe und Scaleway, ein französisches Angebot.

‍
Auch der Preis überzeugt: Die Cloud-Lizenz kostet genauso viel wie die Lizenz für den Selbstbetrieb, d. h., die Entscheidung für die Cloudvariante ist nicht mit Mehrkosten verbunden, spart aber Administrationskosten.

‍
Ich vergleiche die Cloud-Variante und On-Premise-Variante hier nicht im Detail. Wichtig ist: OpenProject bietet mehrere Optionen. Das stärkt die Datensouveränität, weil ich selbst festlege, wie viel Kontrolle ich über Betrieb und Daten behalten will.

‍

Klassisches, Agiles und Hybrides Projektmanagement

‍

OpenProject verbindet die Perspektiven von Entwicklungsteam und Organisation. Die Software unterstützt verschiedene Formen des Projektmanagements. Teams wählen ihre bevorzugte agile Methode und arbeiten damit eigenständig. Das Management kann den Rahmen der Projekte gleichzeitig klassisch nach dem Wasserfallmodell planen und den Überblick über das Gesamtprojekt behalten. Das schauen wir uns später genauer an.

‍

Namenhafte Referenzkunden und Stakeholder

‍

Die Referenzkunden zeigen: Auch sehr große Unternehmen haben sich für OpenProject entschieden. Darüber hinaus ist OpenProject ein Modul von openDesk. openDesk ist eine souveräne Office- und Kollaborationssuite für die öffentliche Verwaltung. ZenDiS stellt sie zusammen und bereit. ZenDiS ist das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung. Alleinige Gesellschafterin ist die Bundesrepublik Deutschland. Die Referenzen und die Verbindung zu ZenDiS zeigen: Viele namhafte Stakeholder haben ein Interesse daran, OpenProject dauerhaft einzusetzen. Deshalb halte ich die Entscheidung für OpenProject für eine vergleichsweise sichere Investition. Eine ausführliche Kundenliste gibt es hier.

‍

OpenProject im Detail

‍

Nach diesem ersten Überblick schauen wir uns jetzt gemeinsam OpenProject im Detail an.

‍

Lizenzmodell

‍

Wer sich einen Überblick über OpenProject verschaffen möchte, kann das in einer 14-tägigen Probephase tun. Die ist kostenlos und enthält alle Enterprise-Features.
Es gibt unterschiedliche Enterprise-Pakete:

‍

• Basic
• Professional
• Premium
• Corporate

‍

Die Tarife unterscheiden sich in drei Punkten:

‍

• freigeschaltete Funktionen
• Mindestanzahl Benutzer:innen
• Supportleistungen

‍

Die Community Edition steht unter der GNU General Public License v3. Damit bleibt OpenProject dauerhaft Open Source.

‍

Wichtige Enterprise-Funktionen

‍

Enterprise-Funktionen werden durch ein Enterprise-Token freigeschaltet. Administrator:innen erhalten ihn mit dem Kauf einer Lizenz. OpenProject prüft den Token kryptografisch und aktiviert danach die gebuchten Funktionen.
‍

Mit der Community Edition kommt man weit — solange man keine ausgeprägte Unterstützung für agiles Arbeiten braucht. In der Praxis wünschen sich viele Teams jedoch die agilen Action Boards. Sie gehören zu allen Enterprise-Tarifen. Unternehmen benötigen oft zusätzlich Single Sign-on. Die Unterstützung für OpenID Connect bzw. SAML/SCIM gibt es ab dem Professional-Tarif.
‍

Die Tarifübersicht auf der OpenProject-Website überzeugt mich allerdings nicht. Es fällt schwer zu erkennen, welcher Tarif welche Funktionen enthält. Die Action Boards fehlen zum Beispiel in der Vergleichstabelle. Gut gelöst ist dagegen der Hinweis innerhalb der Community Edition: Nicht verfügbare Funktionen zeigen direkt an, welcher Tarif sie freischaltet.
‍

Für den professionellen Einsatz braucht man aus meiner Sicht meist eine Enterprise-Lizenz.

‍

Unterschiede zwischen Cloud und On-Premise

‍

Die Tarife für Cloud und On-Premise bieten grundsätzlich dieselben Funktionen und unterscheiden sich nicht im Preis. Unterschiede gibt es vor allem bei der Mindestanzahl der User. Den Basic-Enterprise-Tarif erhält man in der Cloud bereits ab fünf User. On-Premise muss man dagegen mindestens 25 Benutzerlizenzen kaufen. Zusätzlich bietet OpenProject ein kostenpflichtiges Modul für das Management von Bauprojekten an. Dieses Zusatzmodul berücksichtige ich in diesem Artikel nicht.

‍

Keine Marketplace Apps

‍

Positiv finde ich, dass alle Funktionen Teil des Kernprodukts sind. Bei Jira schaltet man zusätzliche Funktionen über Marketplace-Apps frei. Das verursacht weitere Kosten und wirft oft Datenschutzfragen auf, weil Drittanbieter auf Jira-Daten zugreifen. Deshalb gehe ich davon aus, dass OpenProject langfristig besser kalkulierbare Lizenzkosten bietet.

‍

Kostenvergleich

‍

Der Jira-Premium-Tarif kostet 14,54 US-Dollar pro User und Monat, also etwa 13,60 Euro. Der Professional-Tarif von OpenProject kostet 10,95 Euro pro User und Monat. Diese Preise gelten für die Cloud-Versionen. Noch deutlicher wird der Unterschied bei Jira Data Center. Dort liegt die Mindestanzahl bei 500 Usern. Für diesen Artikel gehe ich von etwa 100 Usern aus. Das entspricht den Projektgrößen, in denen ich häufig gearbeitet habe. Unter diesen Voraussetzungen wirkt Jira für mich deutlich teurer als OpenProject. Wer die Lizenzkosten für die eigene Organisation berechnen möchte, findet die Preise hier.

‍

Hybrides Projektmanagement in OpenProject

‍

Ich habe hybrides Projektmanagement erst durch die Beschäftigung mit OpenProject kennengelernt. Deshalb möchte ich zunächst erklären, was das ist.

‍

Was ist hybrides Projektmanagement? Hybrides Projektmanagement ruht auf zwei Säulen:

‍

• agil
• klassisch, d.h. Wasserfallmodell

‍

Dabei trennt man klar zwischen der strategischen und der operativen Projektmanagement-Ebene.

‍

Planung auf der strategischen Projektmanagement-Ebene: Die grobe Rahmenplanung erfolgt klassisch, d.h. auf einer hohen Managementebene wird definiert, was im Rahmen eines großen, teamübergreifenden Projektes geliefert werden soll. Es werden grobe Aufgabenpakete inkl. ihrer Deadlines definiert. Das setzt einen klaren Rahmen und eine klare Erwartungshaltung, an dem sich die Teams orientieren können.

‍

Planung auf der operativen Team-Ebene: Die einzelnen Entwicklungs-Teams bekommen von der strategischen Projektmanagement-Ebene die definierten groben Aufgabenpakete zugewiesen und können diese nun in umsetzbare Aufgabenprojekte herunterbrechen. Auf dieser Basis können die Teams die Umsetzung dann agil planen, d.h. sie bestimmen selbst was sie in welchem Sprint wie umsetzen. Da sie die Erwartungshaltung des Managements kennen, können sie das in ihrer eigenen Planung berücksichtigen.

‍

Überwachung der Ziele auf der operativen Team-Ebene:

‍

Das Team hat sich selbst die Sprintziele im Sprint-Planning gesetzt und behält die im Rahmen ihrer Dailies und täglichen Arbeit im Blick.

‍‍

Überwachung der Ziele auf der strategischen Projektmanagement-Ebene:

‍

Da die Projektmanagement-Ebene Deadlines auf der Basis grober Aufgabenblöcke gesetzt hat, ist es interessiert über den Fortschritt auf der Basis dieser Aufgabenblöcke informiert zu werden. Im schlechtesten Fall müssen die einzelnen Entwicklungsteam Berichte verfassen, um über ihren Fortschritt zu berichten. Im Idealfall unterstützt mich mein Projekt-Management-Tool dabei, die Aktivitäten auf die Aufgabenblöcke auf Projektmanagement-Ebene zu projizieren, so dass in meinem Team dadurch kein zusätzlicher Aufwand verursacht wird.

‍

Wie unterstützt OpenProject hybrides Project-Management?

‍

Ich zeige Ihnen Schritt für Schritt, wie Sie mit OpenProject ein hybrides Projektmanagement aufsetzen. Dazu nutze ich typische Szenarien. Ihre eigenen Anforderungen können davon abweichen. Trotzdem sehen Sie dadurch, ob und wie Sie Ihre eigenen Szenarien mit OpenProject umsetzen können.

‍

OpenProject kann sehr flexibel unterschiedliche Hierarchien von Projekten und Arbeitspaketen abbilden

‍

Theoretisch können Sie Projekte und Arbeitspakete in OpenProject beliebig tief verschachteln. Trotzdem sollten Sie festlegen, welche Struktur in Ihrem Kontext sinnvoll ist. Für mein Beispiel nutze ich ein Projekt mit zwei Unterprojekten. Die Struktur bleibt übersichtlich und zeigt trotzdem die wichtigsten Funktionen. Das oberste Projekt steht für die strategische Projektplanung. Die beiden Unterprojekte bilden die operative Team-Ebene ab.

‍

Bei Bedarf können Sie die Unterprojekte weiter unterteilen und zusätzliche Ebenen anlegen.

‍

‍

Planung einer Initiative

‍

In meinem Beispiel lege ich jetzt eine Projektübergreifende Initiative auf Ebene der Strategischen Projektplanung an. Dann lege ich zwei Epics für die Unterprojekte an. Zusätzlich lege ich noch einen Meilenstein an, der mir später helfen soll, eine wichtige Deadline für das Gesamtprojekt im Blick zu halten.

‍

‍

Die Epics weise ich dann den Unterprojekten zu. Der folgende Screenshot zeigt jetzt die Arbeitspakete-Ansicht in Unterprojekt 1. Hier habe ich das Epic schon in 5 User Stories herunter gebrochen.

‍

‍

Umsetzung der Arbeit in den Projekt-Teams

‍

Innerhalb des Unterprojektes kann ich den Kontext des Gesamtprojektes ausblenden und mich auf den Projektkontext meines Teams konzentrieren. Der folgende Screenshot zeigt das Board des Teams von Unterprojekt1. Wie Openproject agile Arbeit unterstützt, erläutere ich weiter unten im Detail.

‍

‍

Überblick auf Ebene des Gesamtprojektes

‍

Auf Ebene des Gesamtprojekts können Sie ein Gantt-Diagramm für das gesamte Projekt anzeigen. Die Ansicht steht auch in den Unterprojekten zur Verfügung. Da die strategische Steuerung jedoch auf Ebene des Gesamtprojekts erfolgt, konzentriere ich mich hier auf diese Ansicht.

‍

Damit das Gantt-Diagramm aussagekräftig bleibt, müssen die Teams in den Unterprojekten ihre Arbeitspakete sauber pflegen. Dazu gehören vor allem Vorgänger- und Nachfolgerbeziehungen sowie die Start- und Enddaten der Arbeitspakete auf der untersten Ebene.

‍

Wenn Sie Arbeitspakete auf höheren Hierarchieebenen auf „Automatic Scheduling“ setzen, übernimmt OpenProject Änderungen aus den unteren Ebenen automatisch. Verschiebt sich dort ein Termin, aktualisiert sich der übergeordnete Termin ebenfalls.

‍

Der Meilenstein ist hier als Nachfolger der Epics definiert. Ändert sich das Enddatum eines Epics, verschiebt OpenProject den Meilenstein automatisch mit.

‍

‍

Meine Bewertung des hybriden Projekt-Managements in OpenProject

‍

Ich habe persönlich nie in Projekten gearbeitet, die erkennbar hybrid gemanagt wurden. Stattdessen habe ich erlebt, dass Teams agil arbeiteten, während das Management feste Deadlines vorgab. In solchen Szenarien hätte ein Projekt-Setup in OpenProject wie das gezeigte für mehr Transparenz und besseres Verständnis gesorgt. Ich kann hier nur bewerten, was ich beim Erstellen meines Beispielszenarios erlebt habe. Besonders gut gefällt mir, dass sich Hierarchien für Projekte und Arbeitspakete in OpenProject sehr flexibel anlegen lassen. Für aussagekräftige Gantt-Diagramme verlässt man auf Team-Ebene allerdings schnell den Rahmen agilen Arbeitens. Die Beziehungen zwischen den Arbeitspaketen müssen die Realität abbilden. Außerdem müssen Start- und Enddaten gepflegt werden. Hier habe ich eine Funktion vermisst, die Start- und Enddaten automatisch aus dem Sprint übernimmt, dem das Arbeitspaket zugeordnet ist. Hilfreich wäre auch, laufende Sprints direkt im Gantt-Diagramm sichtbar zu machen. Insgesamt überzeugt mich der Ansatz dennoch: Teams können agil arbeiten, während die Projektsteuerung den Überblick behält – ohne zusätzliche Statusberichte.

‍

Agiles Projekt-Management in OpenProject

‍

Agile Entwicklungsteams interessiert vor allem eine Frage: Wie unterstützt OpenProject sie im Alltag?

‍

Ich schaue vor allem auf Scrum und Kanban. Jira setzt ebenfalls auf diese beiden Frameworks. Zunächst geht es um Scrum. Kanban fließt punktuell ein, denn OpenProject bietet für Scrum nach meinem Eindruck mehr Funktionen als für Kanban.

‍

Wie unterstützt OpenProject ein Sprint-Planning?

‍

Tickets legt man grundsätzlich im Modul Arbeitspakete an. Dort beschreiben Teams Aufgaben, zerlegen sie in Unteraufgaben und pflegen Abhängigkeiten zwischen den Arbeitspaketen.

‍

Die eigentliche Planung läuft im Modul Backlogs. OpenProject hat diesen Bereich in den vergangenen Versionen deutlich ausgebaut. Früher verwaltete das Modul vor allem generische Versionszuordnungen. Heute kennt OpenProject Sprints als klar definierte Container für Tickets. Teams vergeben für jeden Sprint ein Start- und Enddatum. Sobald ein Sprint startet, erstellt OpenProject automatisch ein Board mit allen Tickets des aktuellen Sprints. Während des Sprints zeigt das System zudem einen aktuellen Burndown-Chart an.

‍

Der Screenshot zeigt den Planungsmodus von OpenProject. Links stehen alle Tickets im Backlog. Dort liegen sämtliche Arbeitspakete, die noch offen sind und keinem Sprint zugeordnet wurden. Rechts erscheinen die angelegten Sprints. In der Kopfzeile summiert OpenProject die Story Points aller enthaltenen Tickets.

‍

Besonders gelungen finde ich die Darstellung von Backlogs und Sprints nebeneinander. Beide Bereiche lassen sich unabhängig scrollen. Das schafft Übersicht. In Jira liegen beide Bereiche untereinander. Beim Scrollen verliert man dort schnell die Orientierung.

‍

Etwas versteckt ist die Möglichkeit, während der Planung spontan neue Arbeitspakete anzulegen. Sie steckt im Drei-Punkte-Menü in der Kopfzeile des Sprints.

‍

‍

Unterschiedliche Arten von Boards

‍

Sobald man mit dem Planning fertig ist, ist es interessant wie OpenProject die Organisation der Team-Zusammenarbeit unterstützt. Dafür gibt es unterschiedliche Arten von Boards, die ich Ihnen kurz im Überblick vorstellen möchte.

‍

Grundsätzlich gibt es zwei Arten von Boards:

‍

• ‍Basic Boards gehören zur Community Edition. Sie funktionieren einfach, haben aber klare Einschränkungen: Sie müssen diese Boards manuell füllen. Jedes Ticket, das auf dem Board erscheinen soll, müssen Sie selbst einzeln manuell hinzufügen. Tickets landen also nicht automatisch auf dem Board, nur weil sie zu einem bestimmten Sprint gehören. Auch das Verschieben von Tickets hat keine Auswirkungen auf deren Felder. Ziehen Sie ein Ticket in eine andere Spalte, ändert sich zum Beispiel der Bearbeitungsstatus nicht automatisch. Steht eine Spalte etwa für den Status „In Bearbeitung“, bleibt der Ticketstatus trotz Verschiebens unverändert. Sie müssen den Status danach zusätzlich manuell auf „In Bearbeitung“ setzen.
• Action Boards zeigen das Verhalten, das viele von uns wahrscheinlich erwarten, wenn sie von Jira kommen, d.h. hier landen die Tickets automatisch auf dem Board, wenn die Tickets im aktuellen Sprint enthalten sind und ich den Board-Filter entsprechend gesetzt habe. Auch ändern sich die korrespondierende Felder automatisch, wenn ich ein Ticket auf die entsprechende Spalte verschiebe. Zunächst war ich etwas enttäuscht als ich feststellte dass Action-Boards nur zur Verfügung stehen, wenn man eine Enterprise-Lizenz gekauft hat. Mittlerweile kann ich die Entscheidung aber nachvollziehen, weil Action-Boards ein starkes Argument für das Buchen einer Enterprise-Lizenz sind und das ja gleichzeitig gewährleistet, dass OpenProject eine Zukunft hat und eine sichere Investitionsentscheidung für seine Kund:innen ist.

‍

Unterschiedliche Arten von Action Boards:

‍

OpenProject bietet viele interessante Action Boards. Sie lösen typische Anwendungsszenarien klar und direkt. Dafür musste ich mich in Jira früher oft mühsam durch Tickets auf vielen unterschiedlichen Seiten klicken. Mir ist nicht bekannt, ob Jira ähnliche Lösungen bietet.

Ich möchte einen kurzen Überblick über die Action Boards geben, die OpenProject anbietet:

‍

• Das Kanban Board entspricht dem klassischen Board aus Jira. Die Spalten zeigen den jeweiligen Bearbeitungsstatus. Damit eignet sich das Board gut für den Alltag in der agilen Softwareentwicklung. Auch wenn der Name es nicht vermuten lässt, ist das Kanban-Board auch die Grundlage der täglichen Arbeitsorganisation, wenn man nach Scrum arbeitet. Irritierend ist allerdings: Es gibt grundsätzlich keine WIP-Limits. Dabei gehören Begrenzungen für parallele Aufgaben zu den Grundprinzipien von Kanban. Ohne solche Limits verlieren Teams schnell den Überblick und Engpässe bleiben länger unbemerkt.
• Das Assignee Board organisiert Tickets nach zuständigen Team-Mitgliedern. Es zeigt schnell, wie stark das Team ausgelastet ist. So erkennt man sofort: Häufen sich bei einzelnen Teammitgliedern Aufgaben? Wer hat noch freie Kapazitäten?
• Im Version Board steht jede Spalte für eine Produktversion. Das Board hilft Product Owner:innen, Releasepläne zu erstellen und Features geplanten Softwareversionen zuzuordnen.
• Das Subproject-Board funktioniert ähnlich wie das Assignee-Board. Die Spalten sind jedoch nach Unterprojekten organisiert. So sieht man auf einen Blick, welche Aufgaben zu welchem Unterprojekt gehören. Unterprojekte haben einen funktionalen Fokus. Ihnen kann man nicht spontan beliebige Aufgaben zuweisen. Deshalb nutzt man das Board nicht, um freie Kapazitäten zu entdecken, es geht eher um die Frage: Welches Team arbeitet gerade an welchem Thema?
• Im Parent-Child-Board spiegeln die Spalten die übergeordneten Arbeitspakete wider. Das Board hilft dabei, einen Projektstrukturplan oder eine Work Breakdown Structure (WBS) zu erstellen. Sie sehen schnell, ob die Unteraufgaben den richtigen Arbeitspaketen zugeordnet sind. Bei Bedarf können Sie die Struktur einfach anpassen.

‍

Unterstützt mich OpenProject auch im Rahmen von skalierten agilen Frameworks?

‍

Ich kenne mich mit skalierten agilen Frameworks nicht gut aus, deshalb traue ich mir ehrlich gesagt kein qualifiziertes Urteil zur Unterstützung von skalierten agilen Frameworks zu. Aus meiner Sicht bietet OpenProject allerdings durch die Möglichkeit, Projekte ineinander zu verschachteln sehr viel Flexibilität unterschiedliche organisatorische Strukturen abzubilden. Zusätzlich möchte ich Ihnen gerne noch zwei Features vorstellen, die ich bis jetzt noch nicht erwähnt habe.

‍

Man kann Sprints teilen:

‍

Wenn man Sprints über mehrere Projekte hinweg synchronisieren möchte, gibt es die Möglichkeit, in einem Oberprojekt einen geteilten Sprint anzulegen. Dieser Sprint ist dann in allen Unterprojekten, mit denen er geteilt wird, sichtbar. Geteilt wird nur der Zeitraum. Die Inhalte des Sprints auf Teamebene werden weiterhin auf Teamebene entschieden. Der Gesamtsprint wird aber auf Oberprojekt-Ebene gestartet und gestoppt.

‍

Roadmaps und Versionen:

‍

Seitdem OpenProject echte Sprint-Container implementiert hat, muss man nach dem Anlegen von Versionen beim ersten Mal ein bisschen suchen. Die Versionsverwaltung findet man in den Project Settings des jeweiligen Projekts. Sobald man eine erste Version eingerichtet hat, ist das Roadmap-Modul von OpenProject freigeschaltet. Im Beispiel habe ich die Versionen im Oberprojekt angelegt und mit den Unterprojekten geteilt. Wenn man mit SAFe arbeitet, könnte man so beispielsweise ein Program Increment abbilden. Versionen kann man ein Start- und Enddatum zuweisen.

‍

‍

Wie bewerte ich agiles Projekt-Management in OpenProject?

‍

Insgesamt halte ich das agile Projektmanagement in OpenProject für gelungen. Zunächst war ich enttäuscht: Mit dem Basic Board kommt man kaum weit. Wer OpenProject sinnvoll nutzen will, braucht mindestens die Basic-Enterprise-Lizenz. Erst dann stehen die Action Boards zur Verfügung. Damit lässt sich aus meiner Sicht vernünftig agil arbeiten. Die Benutzeroberfläche wirkt auf mich allerdings nicht besonders modern. Das liegt nicht an einzelnen Funktionen, sondern am Gesamteindruck.
Positiv fand ich den Planning-Modus: Dort lassen sich Backlog und Sprints nebeneinander anzeigen. Tickets zu verschieben ist dadurch einfacher als in Jira.
Wirklich stört mich jedoch, dass sich keine WIP-Limits pro Spalte festlegen lassen. Damit unterstützt OpenProject Kanban aus meiner Sicht nur unzureichend. Wer hauptsächlich Scrum nutzt, wird damit vermutlich kein Problem haben. Hier hat Jira derzeit für mich noch die Nase vorn. Zur Unterstützung skalierter agiler Frameworks kann ich kein fundiertes Urteil abgeben. Dafür kenne ich die entsprechenden Funktionen in Jira zu wenig. Ich habe Ihnen jedoch gezeigt, was sich mit OpenProject umsetzen lässt. Ich hoffe, das hilft Ihnen dabei, sich ein eigenes Urteil zu bilden.

‍

Klassisches Projektmanagement in OpenProject

‍

Unter dem Blickwinkel des klassischen Projektmanagements habe ich mir OpenProject nicht genauer angesehen. Es ist lange her, dass ich zuletzt ein Projekt nach dem Wasserfallmodell erlebt habe. In meinem Arbeitsalltag spielt dieses Modell keine Rolle mehr. Einige Funktionen für klassisches Projektmanagement sind uns dennoch schon begegnet:

‍

• Arbeitspakete lassen sich in eine logische Reihenfolge bringen.
• Arbeitspakete können ein Start- und Enddatum haben.
• Meilensteine lassen sich unabhängig von Arbeitspaketen anlegen und in die Reihenfolge einordnen.
• Projekte und Arbeitspakete können hierarchisch verschachtelt werden.
• Projektübergreifende Gantt-Diagramme sind möglich.

‍

Einige weitere Funktionen ordne ich ebenfalls dem klassischen Projektmanagement zu. Sie können aber auch in agileren Projekten nützlich sein. Ich habe sie nicht im Detail geprüft und stütze mich hier auf die offizielle Dokumentation.

‍

Budgetplanung und Budgetüberwachung

‍

In OpenProject lassen sich Projektbudgets anlegen. Sie umfassen geplante Personalkosten sowie Sachkosten wie Material oder Reisekosten. Die Personalkosten berechnet das System anhand der hinterlegten Stundensätze der Benutzer:innen. Für Sachkosten können Teams eigene Kostenarten mit individuellen Einheiten und Sätzen definieren.

‍

Zeiterfassung und Verbrauchskontrolle

‍

Arbeitspakete lassen sich einem Budget zuordnen. Zeiten und Sachkosten, die Mitarbeiter:innen auf diese Arbeitspakete buchen, verrechnet OpenProject automatisch mit dem Budget. Die Budgetübersicht und Projekt-Widgets zeigen jederzeit den Plan-Ist-Vergleich und das verbleibende Budget.

‍

Änderungsverfolgung mit Baseline

‍

OpenProject bietet keine klassische Baseline-Funktion wie Microsoft Project, bei der ein Projektplan als feste Momentaufnahme gespeichert wird. Stattdessen vergleicht die Baseline-Funktion Tabellenansichten von Arbeitspaketen mit einem früheren Stand, etwa von gestern, letzter Woche oder einem bestimmten Datum.

‍

Das System markiert geänderte, hinzugefügte und entfernte Arbeitspakete. Alte und neue Werte stehen direkt nebeneinander. Eine Darstellung im Gantt-Diagramm gibt es bisher nicht. Mit Ausnahme des Vergleichs zum Vortag gehört die Baseline-Funktion zur Enterprise-Version.

‍

Der KI das Sprechen mit OpenProject beibringen

‍

Wenn man KI in Verbindung mit OpenProject nutzen will, dann geht auch hier - wie in unserem Jira-Beispiel - der Weg über einen MCP-Server. Dafür gibt es mehrere Optionen.

‍

OpenProject bringt bereits einen eigenen MCP-Server mit

‍

Wenn man OpenProject mit einer Enterprise-Lizenz nutzt, dann kann man den in OpenProject integrierten MCP-Server nutzen. Dieser hat bisher allerdings noch keine Schreiboperationen. Das reicht aber, wenn ich z. B. meinen Coding-Agent bitten möchte, ein bestimmtes Ticket zu implementieren. Das funktionierte in der Kombination mit Claude Code tadellos.

‍

Es gibt eine große Anzahl von bereits implementierten Open Source MCP-Servern

‍

Wer allerdings KI dazu nutzen möchte, aus Meeting-Protokollen automatisch Aufgabenpakete in OpenProject zu erzeugen, braucht einen MCP-Server, der auch Schreiboperationen unterstützt. Eine kurze Google-Suche ergibt schnell viele brauchbare Optionen. Grundsätzlich gibt es zwei unterschiedliche Arten wie Clients mit MCP-Servern kommunizieren können:

‍

• Standard-Input/-Output(stdio): In diesem Fall startet der Client den MCP-Server selbst lokal und kommuniziert direkt über die Befehlszeile mit ihm.
• Netzwerk-Server/HTTP: In diesem Fall wird der MCP-Server remote im Netzwerk zur Verfügung gestellt und die Clients kommunizieren via HTTP mit ihm.

‍

Der Weg über Standard-Input/Output hat den Vorteil, dass der MCP-Server mit dem personalisierten API-Token der:des jeweiligen Nutzer:in läuft, d. h. der MCP-Server hat genau dieselben Privilegien wie die:der jeweilige Nutzer:in und kann auch nur das tun, was der:dem jeweiligen Nutzer:in erlaubt ist. Der Nachteil ist allerdings, dass alle eine eigene Instanz des MCP-Servers installieren müssen. Das kann in Einzelfällen ein Problem sein.

‍

Genau deshalb möchte ich ihnen den Open-Source MCP-Server tmskln/spring-openproject-mcp-server empfehlen. Dieser reicht den API-Token der:des jeweiligen Nutzer:in an die OpenProject-API weiter, so dass auch hier gewährleistet ist, dass die Nutzung innerhalb der Nutzer-Privilegien gewahrt bleibt. Gleichzeitig braucht man nur eine zentrale Instanz des MCP-Servers für alle. Für die konkrete Nutzung von OpenProject mit einem lokalen KI-Modell in LM-Studio verweise ich auf den Artikel meines Kollegen Nicolas Inden. Das kann man 1:1 auf die Nutzung mit OpenProject übertragen.

‍

Weitere nützliche Features von OpenProject

‍

Wiki und Dokumente

‍

OpenProject bringt ein eigenes Wiki mit. Confluence ersetzt es nicht, denn jedes Wiki gehört zu einem konkreten Projekt. Es eignet sich daher vor allem fürprojektspezifische Dokumentation. Etwas verwirrend ist, dass OpenProject zusätzlich ein Dokumenten-Modul anbietet. Dort lassen sich verschiedene Dokumenttypen anlegen, etwa Proposal, Idea, Specification oder Documentation.

‍

Ich würde das Wiki nutzen

‍

• wenn mehrere Personen gemeinsam Inhalte erarbeiten,
• wenn die Dokumentation hierarchisch aufgebaut ist,
• wenn Seiten sich gegenseitig verlinken,
• wenn Sie Texte lieber in Markdown schreiben

‍

Jeder Wiki-Beitrag wird intern als Markdown gespeichert. Sie können jederzeit zwischen Markdown und WYSIWYG-Ansicht wechseln. Das Wiki basiert auf CKEditor 5, das Dokumenten-Modul auf BlockNote. Deshalb fehlt im Dokumenten-Modul derzeit ein Markdown-Modus.

‍

Ist ein Dokument fertig, lässt es sich grundsätzlich in das Dokumenten-Modul überführen. Einen eleganten Weg bietet OpenProject dafür jedoch nicht. Sie können einen Wiki-Beitrag als PDF exportieren und als Anhang importieren oder den Inhalt per Copy-and-paste übernehmen.

‍

Seit OpenProject 17.0 unterstützen Dokumente die Echtzeit-Kollaboration. Diese Funktion hätte ich eher im Wiki erwartet. Der Grund dafür ist wahrscheinlich, dass die technische Basis des Dokumenten-Moduls das ermöglicht. Auf konzeptioneller Ebene führt es aus meiner Sicht aber zu Verwirrung. Möglicherweise deutet sie darauf hin, dass OpenProject das Dokumenten-Modul langfristig als Nachfolger des Wikis positionieren möchte. Das ist allerdings Spekulation. Sie erklärt für mich jedoch, warum sich Wiki und Dokumenten-Modul derzeit nur schwer klar voneinander abgrenzen lassen.

‍

Meetings organisieren

‍

Das Meeting-Modul eignet sich besonders, wenn Sie Besprechungen eng mit Arbeitspaketen verknüpfen möchten. Eine Agenda können Sie aus Arbeitspaketen oder aus separaten Agenda-Punkten zusammenstellen.

‍

Nutzen Sie Arbeitspakete als Agenda, erfassen Sie die Ergebnisse direkt dort und verfolgen anschließend den Fortschritt. Arbeiten Sie mit Agenda-Punkten, speichern Sie die Notizen im jeweiligen Punkt. Diese Informationen lassen sich später jedoch nur schwer wiederfinden, da Sie dafür das Meeting erneut öffnen müssen.

‍

Praktischer ist es, aus einem Agenda-Punkt direkt ein neues Arbeitspaket zu erstellen oder ein bestehendes zu aktualisieren. Hilfreich ist auch die Einladungsfunktion. Über das Meeting-Modul können Sie Einladungen direkt an alle Teilnehmer:innen versenden. Das spart einige manuelle Arbeitsschritte.

‍

Integration mit GitLab und GitHub

‍

OpenProject kann Aktivitäten aus GitLab oder GitHub im Aktivitäten-Tab des zugehörigen Arbeitspakets anzeigen. Ich habe die Funktion nur mit GitLab getestet. Dort arbeitete sie zuverlässig.

‍

Integration mit Nextcloud

‍

OpenProject lässt sich eng mit Nextcloud verzahnen. Ich habe die Integration zwar nicht selbst getestet, sie ist jedoch hier auf der OpenProject-Website gut dokumentiert. Die Integration funktioniert in beide Richtungen. Sie können Arbeitspakete mit Dateien in Nextcloud verknüpfen und sich in Nextcloud eine Übersicht Ihrer Arbeitspakete anzeigen lassen.

‍

Arbeitspakete per E-Mail anlegen

‍

Arbeitspakete lassen sich auch per E-Mail erstellen. Darüber hinaus können Sie auf Benachrichtigungen zu Arbeitspaketen antworten. OpenProject übernimmt Ihre Antwort automatisch als Kommentar in das betreffende Arbeitspaket. Das erleichtert die Kommunikation erheblich.

‍

Jira-Migrator

‍

Das OpenProject-Team bietet ein eigenes Tool für die Migration bestehender Projekte zu OpenProject an: den Jira-Migrator. Ich hatte keine Gelegenheit, das Tool zu testen. Eine ausführliche Beschreibung seiner Features finden Sie hier.

‍

‍

Anhang

‍

Zu Beginn meiner Suche nach datensouveränen Jira-Alternativen habe ich mir durch Internetrecherche und die Befragung meines favorisierten KI-Modells einen Überblick darüber verschafft, welche Open-Source-Alternativen zu Jira es gibt. Auf die Kandidaten, die ich mir zunächst angeschaut und dann ausgeschlossen habe, möchte ich hier zunächst kurz eingehen.

‍

Gitlab: Da wir bereits eine interne GitLab-Instanz haben und GitLab generell auch die Möglichkeit bietet, Tickets zu verwalten, habe ich mir zunächst angeschaut, inwieweit GitLab meine oben genannten Kriterien erfüllt. Dabei bin ich darauf gestoßen, dass Epics ein Premium-Feature von GitLab sind, d. h. man braucht dafür eine Premium-Lizenz, die im Moment 29 Dollar pro Person und Monat kostet. Das war im Vergleich zu Lizenzen anderer Anbieter zu hoch, so dass GitLab dadurch aus meiner Liste möglicher Kandidaten herausgefallen ist.

‍

Taiga: Taiga ist ein Open-Source-Projekt, das sich auf Projektmanagement für agile Projekte fokussiert. Mich hat das Look & Feel allerdings nicht angesprochen, so dass ich es nicht weiter untersucht habe. Mich hat sehr irritiert, dass ich User Stories auf dem Board nicht verschieben konnte. Das lag daran, dass man die User Stories im Scrum-Board selbst nicht verschieben kann. Sie bleiben in der linken Spalte stehen. Man muss Subtasks zu den Stories anlegen. Diese kann man dann verschieben. Wenn man ein Open-Source-Tool für ein kleines Projekt sucht, dann ist Taiga aber sicherlich ein Kandidat, den man sich genauer anschauen kann. Man kann es lizenzkostenfrei auf eigener Hardware betreiben. Es gibt aber auch eine Cloud-Option, die man bezahlen muss. Taiga geht aber grundsätzlicher von einer flachen Projekthierarchie aus, so dass es auch bei diesem Aspekt von meinem eingangs spezifizierten Anforderungsprofil abweicht.

‍

Plane: Plane ist ebenfalls ein Open-Source-Produkt, das selbst gehostet werden kann. Es gibt aber auch Cloud-Optionen. Plane hat mich sehr angesprochen, weil ich die UX der Anwendung als angenehm empfunden habe. Alles wirkt klar, aufgeräumt und übersichtlich. Ich konnte mich sehr schnell zurückfinden. Wenn ich ein Projektmanagement-Tool für ein agiles Projekt suche, das ich selbst hosten kann, wäre Plane mein Favorit. Als Jira-Alternative habe ich es nicht in Betracht gezogen,
weil für mich Plane noch ein recht junges Projekt ist. Plane gibt es erst seit 3 Jahren, OpenProject gibt es seit 2012. Obwohl Plane auch Projekthierarchien unterstützt, erschien mir OpenProject als das reifere Produkt, das mehr Investitionssicherheit bietet. Aber Plane ist sicherlich auch einen zweiten Blick wert, wenn einem OpenProject nicht zusagt.

‍

‍