GitHub: Neue angehende Features fürs Projektmanagement unter der Lupe

Inhalt

Neue Möglichkeiten für Projektmanagement in GitHub

In den letzten Jahren hat sich GitHub über seine Funktion als reines Repository sowie als Plattform für Actions und Pipelines weit hinaus entwickelt – hin zu einer ganzheitlichen ALM-Lösung (Application Lifecycle Management), die mit etablierten Projektmanagement-Tools wie Jira, Azure DevOps oder GitLab durchaus im Funktionsumfang konkurriert werden kann. Dieser Wandel überrascht kaum, wenn die stetig wachsende Nutzerzahl der GitHub-Plattform betrachtet wird, wie die folgende Grafik (Quelle Statista) veranschaulicht wird.

Die drei zuletzt genannten Plattformen bieten weit mehr als nur das klassische Git-Repository und Standard-Pipelines. Der Aufbau agiler Prozesse wird ebenfalls ermöglicht und komplexe Projektmanagement-Methoden werden unterstützt – von hierarchischen Backlogs bis hin zu ausgefeilten Work-Item-Automatisierungen. Hier wird GitHub mit GitHub Actions und den neuen Funktionen nun auch ein großer Leistungsumfang geboten. Auch wenn GitHub vor allem für leichtgewichtige, kleinere Teams geeignet ist, wird intensiv daran gearbeitet, diese Grenzen zu erweitern, und es wurden hierzu bereits einige Neuerungen eingeführt, die den Funktionsumfang zukünftig weiter ausbauen sollen.

Welche neuen Funktionen gibt es?

Bisher wurde die Möglichkeit geboten, Projekte zu erstellen, die direkt mit einem Repository verknüpft sind – in denen sogenannten Issues, die mit User Stories im agilen Ansatz vergleichbar sind, Aufgaben zugewiesen werden konnten. Diese Issues waren bis dato der einzige Work-Item-Type in GitHub. Im Januar 2025 wurden nun zahlreiche Verbesserungen für GitHub Issues eingeführt.

Zu den bedeutendsten Neuerungen zählen Sub-Issues, anpassbare Issue-Typen sowie eine erweiterte Suche – zuvor ausschließlich als Opt-In-Vorschau verfügbar, ist sie jetzt aber allen Nutzern als Public Preview zugänglich. Zudem erhielt die Benutzeroberfläche von Issues ein umfassendes Redesign. Da diese Neuerungen von GitHub sauber dokumentiert und zusammengefasst wurden, möchte hier nicht erneut ins Detail gegangen werden, sondern im Folgenden soll ein kurzer Vergleich der neuen Funktionen mit den Angeboten von Azure DevOps und Jira gezogen werden.

Eine neue Möglichkeit zur Kategorisierung mit Issue-Types

Mit Sub-Issues wird von GitHub eine hierarchische Struktur in Issues eingebracht, sodass große Aufgaben in kleinere Einheiten unterteilt werden können. Jedes Issue kann als übergeordnetes Element fungieren und bis zu 100 untergeordnete Sub-Issues enthalten, die ihrerseits ebenfalls eigene Sub-Issues haben können. Dadurch lassen sich komplexe Projekte in bis zu acht Ebenen tiefen Baumstrukturen organisieren. Die Verbindung zwischen einem Haupt-Issue und seinen Sub-Issues wird direkt im Issue dargestellt und kann auch in GitHub Projects ausgewertet werden. So zeigt das übergeordnete Issue eine Liste seiner Sub-Issues inklusive Fortschrittsanzeige an. Anstatt feste Hierarchie-Bezeichnungen wie „Epic“, „Story“ oder „Subtask“ vorzugeben, basiert die Organisation allein auf der Parent-Child-Beziehung. So kann jedes Issue weitere Unterpunkte enthalten, ohne dass dafür unterschiedliche Issue-Typen erforderlich sind.

Ebenfalls stehen nun verschiedene, anpassbare und erweiterbare Issue Types (standardmäßig Bug, Task und Feature) zur Verfügung, wie im unteren Bild dargestellt. Es können bis zu 25 eigene Typen hinzugefügt werden. Diese Typen sorgen für ein einheitliches Vokabular innerhalb einer Organisation und erleichtern die Übersicht über laufende Arbeiten. Bisher war es erforderlich, diese Aufteilung über Labels oder eigene „custom fields“ nachzubauen. Im Gegensatz zu Labels sind Issue Types ein eigenes Attribut und beeinflussen nicht das Layout oder die Felder eines Issues – sie dienen rein der Klassifizierung. In der folgenden Abbildung werden die verschiedenen verfügbaren Issue Types dargestellt – das Beispiel zeigt dabei auch bereits benutzerdefinierte Typen.

Kombiniert mit Sub-Issues wird von GitHub erstmals eine strukturierte Planung ermöglicht, die der Verwendung von Epics und Stories in klassischen Tools wie Jira und Azure DevOps vergleichbar ist. So beinhaltet das Standardtemplate in Azure DevOps bereits die Typen Epic, Feature, User Story, Task und Bug. Testpläne, die in Azure DevOps ebenfalls verfügbar sind, können vorerst außer Acht gelassen werden, da sie lediglich einen weiteren Typ darstellen, der über eine separate Lizenzierung genutzt wird. Darüber hinaus besteht allgemein die Möglichkeit, wie in der offiziellen Dokumentation beschrieben, eigene Typen zu definieren. Es sei angemerkt, dass ein Issue in Azure DevOps eher als ein Impediment zu verstehen ist – wohingegen ein GitHub Issue eher mit einer User Story verglichen wird. Eine Übersicht über verschiedene Work Item Types in Azure DevOps findet sich in der folgenden Abbildung.

Wenn ein Blick auf Jira geworfen wird, zeigt sich ebenfalls, dass es ähnliche Work Item Types gibt. Als Standard stehen hier Issue, Sub-Issue und Sub-Task zur Verfügung. Es ist jedoch auch möglich, weitere neue Typen zu definieren, wie in der folgenden Abbildung dargestellt.

Hierarchien und Abbildung im Backlog ermöglichen eine neue Strukturierung

Wie bereits erwähnt, wird von allen Plattformen die Möglichkeit geboten, eigene Issue-Kategorien zu definieren. Interessant ist dabei vor allem, wie die Hierarchien dargestellt werden und wo sich die Ansätze unterscheiden. Während grundsätzlich alle Systeme auf einer Parent-Child-Beziehung basieren, gibt es bei der visuellen Darstellung deutliche Unterschiede. So bieten Jira und Azure DevOps dedizierte Backlogs und Sprint-Tools mit Drag-&-Drop-Priorisierung, Velocity-Tracking und umfassenden Berichten. Im Gegensatz dazu setzt GitHub auf einen flexibleren – wenn auch etwas aufwändigeren – Ansatz: Statt eines festen Backlog-Moduls wird hier mit GitHub Projects gearbeitet, um eigene Backlogs, Boards und Roadmaps zu erstellen.

In GitHub ist die Darstellung eines Work Items äußerst übersichtlich und schön schlank gestaltet. Ein einzelnes Issue bietet die Möglichkeit, direkt Sub-Issues zu erstellen und diese unkompliziert in den Arbeitsprozess zu integrieren. Wie im Folgenden gezeigt wird, sind Sub-Issues direkt in das Issue integriert.

In GitHub kann jedes Work Item flexibel genutzt werden – ein Unterschied zu Plattformen wie Azure DevOps oder Jira, bei denen Work Items zwar miteinander verknüpft werden können, deren Beziehung aber in der Regel fest vorgegeben ist (zum Beispiel Epic → Feature → User Story). Bei diesen Plattformen erfolgt die Typisierung über ein separates Feld „Type“, mit dem ein Work Item einer bestimmten Kategorie, etwa „Feature“, zugeordnet wird. Hierbei ist zu betonen, dass es sich dabei um eine reine Kategorisierung handelt. In Azure DevOps und Jira gibt es hingegen spezifische Work Item Types, bei denen sich Aufbau und Standardkonfiguration – etwa zwischen einem Epic und einer Story – erheblich unterscheiden. In GitHub bleibt der Grundaufbau eines Issues hingegen zunächst stets identisch. Folgend sind Beispiele einer User Story und eines Epic in Azure DevOps zu sehen.

GitHub bietet hier einen ansprechenden, leichtgewichtigen Lösungsansatz, der hervorragend zu seiner Ausrichtung passt. Mithilfe von Templates lassen sich individuelle Inhalte für Work Items festlegen, die bei der Erstellung ausgewählt werden können. Dabei ist es zwar erforderlich, den passenden Issue Type zu definieren, jedoch bleibt die Konfiguration insgesamt sehr flexibel. Azure DevOps und Jira bieten ebenfalls die Möglichkeit, Work Item Templates zu erstellen und anzupassen – allerdings erweist sich deren Ansatz oft als schwergewichtiger, mit zahlreichen Optionen, die auch komplexer zu handhaben sind. Im Gegensatz dazu wird bei GitHub lediglich ein Markdown-Template sowie etwas Konfiguration im Repository benötigt, um den gewünschten Effekt zu erzielen. Solche Templates könnten beispielsweise die folgenden Issues definieren:

Automatisierungsmöglichkeiten in GitHub

GitHub Projects bietet nun eingebaute Automatisierungen für einfache Workflows. So kann der Status eines Issues automatisch auf „Done“ gesetzt werden, wenn es geschlossen wird. Ebenso lassen sich Items, die bestimmte Kriterien erfüllen, direkt ins Projekt aufnehmen oder erledigte Items automatisch archivieren. Diese Regeln sind in der Projektkonfiguration verfügbar und können pro Projekt aktiviert oder deaktiviert werden.

Für komplexere Automatisierungen setzt GitHub auf GitHub Actions und Webhooks. Damit lassen sich individuelle Workflows erstellen, etwa das automatische Zuweisen von Labels oder das Anlegen von Folge-Issues beim Merge eines Pull Requests. Anders als Jira bietet GitHub jedoch keinen grafischen Regel-Editor, sodass Anpassungen Programmieraufwand erfordern. Jira nutzt hier die Automation Engine, die in Jira Cloud integriert ist, um komplexere Automatismen abzubilden. Azure DevOps bot lange Zeit keine einfache No-Code-Automatisierung, da Regeln meist nur über Prozessanpassungen oder APIs umgesetzt werden konnten. Mit den Ende 2023 eingeführten Team Automation Rules hat Microsoft jedoch eine neue Möglichkeit geschaffen, grundlegende Workflows zu automatisieren. So kann etwa ein Parent-Work-Item automatisch auf „Active“ gesetzt werden, sobald ein Child aktiv ist, oder geschlossen werden, wenn alle untergeordneten Items erledigt sind.

Wie sieht es mit der „User Experience“ aus?

GitHub Issues bleibt minimalistisch und entwicklerfreundlich, da die neuen Features sich nahtlos einfügen, ohne die gewohnte Nutzung zu verändern. Es gibt keine separaten Masken für Epics oder Stories – alles bleibt ein Issue, was die Handhabung vereinfacht. Allerdings ist die Oberfläche stark auf technische Nutzer ausgerichtet, was für Nicht-Entwickler eine Hürde darstellen kann. Geführte Workflows oder intuitive Strukturen für cross-funktionale Teams fehlen, wodurch GitHub eher für Entwicklerteams als für klassisches Projektmanagement geeignet ist.

Jira hingegen ist mächtig, aber komplex. Die Vielzahl an Funktionen und Anpassungsmöglichkeiten macht es für Administratoren flexibel, für Endanwender jedoch oft schwerfällig. Entwickler empfinden Jira häufig als überladen und langsam, während Business-User mit der anpassbaren Oberfläche besser zurechtkommen. Die Lernkurve ist steil, doch für Teams mit unterschiedlichen Rollen bietet Jira die größte Vielseitigkeit. Dennoch führt der hohe Konfigurationsaufwand oft zu unnötigem Micro-Management, wodurch Jira für viele Entwickler eher eine Notwendigkeit als eine bevorzugte Lösung ist.

Azure DevOps ist stark auf .NET- und Windows-Entwicklung ausgerichtet und integriert sich gut in Microsofts Entwicklungsumgebung. Es bietet eine funktionale, jedoch weniger moderne Benutzeroberfläche als Jira oder GitHub. Während es von manchen als übersichtlicher empfunden wird, erschweren die vielen separaten Hubs wie Repos, Pipelines und Boards die Navigation. Nicht-technische Nutzer haben ähnliche Herausforderungen wie bei GitHub, da das Tool stark entwicklerzentriert ist. Insgesamt ist Azure DevOps primär für Softwareprojekte gedacht und bewegt sich in Sachen Benutzerfreundlichkeit zwischen Jira, das zwar umfangreich, aber kompliziert ist, und GitHub, das schlank, aber sehr technisch bleibt.

Ein weiteres Feature: Advanced Search

Die erweiterte Suche für Issues wurde ebenfalls eingeführt. Dabei können Filter nun mithilfe logischer Operatoren verknüpft werden – konkret werden AND, OR und Klammern zur Gruppierung unterstützt. Bisher waren in der Suche lediglich implizite UND-Verknüpfungen möglich, was bedeutete, dass mehrere label:-Filter erzwingen, dass alle angegebenen Bedingungen erfüllt sein müssen. Mit der neuen Syntax lassen sich deutlich komplexere Abfragen erstellen, wie zum Beispiel: „Zeige alle offenen Issues, die entweder vom Typ Bug oder Task sind und dem Benutzer X zugewiesen wurden.“ Diese Kombinationen und Verschachtelungen entsprechen in etwa den Möglichkeiten, die Jira mit JQL oder Azure Boards mit ihren Abfrage-Editoren bieten.

Entwickler erhalten so ein mächtiges Werkzeug ins GitHub-Ökosystem, um große Mengen an Issues gezielt zu durchsuchen. Die erweiterte Suche kann sowohl über das neue Filterfeld in der Web-UI genutzt werden – inklusive Autocomplete-Unterstützung für Operatoren – als auch über URL-Queries. So listet beispielsweise der Query-String is:issue AND state:open AND (type:Bug OR type:Task) exakt die offenen Issues vom Typ Bug oder Task auf. Diese Abfragen können selbstverständlich auch in Projekten verwendet werden, um Ansichten oder Tabellen individuell zu filtern.

Zusammenfassende Worte

Zusammengefasst hat GitHub in puncto Work Item Management stark aufgeholt: Issue Types und Sub-Issues liefern nun Konzepte, die zuvor nur über Umwege (Labels/Links) machbar waren. Teams, die GitHub bereits als Entwicklungsplattform nutzen, können jetzt auch komplexere Projektplanungen darin abbilden. GitHub hat mit Issue Types eine Lücke geschlossen, die in Jira und Azure DevOps schon lange Standard ist.

Während Jira und Azure DevOps verschiedene Work Item-Typen mit individuellen Feldern und Workflows bieten, bleibt GitHubs Ansatz bewusst einfach: Ein Issue bleibt ein Issue, unabhängig vom Typ – der Typ dient nur zur Kategorisierung. Der Vorteil dabei ist, dass keine komplizierten Konfigurationen erforderlich sind. Der Nachteil ist jedoch, dass keine spezialisierten Felder wie Story Points oder Prioritäten direkt im Issue zur Verfügung stehen (diese sind nur über Custom Fields in Projects verfügbar).