Gantt-Diagramm für die Softwareentwicklung

Ein Gantt gehört in die Software, auf die richtige Flughöhe

Der Einwand ist vertraut. Stell einem Scrum-Team ein Gantt-Diagramm hin, und jemand nennt es Wasserfall im Anzug. In einem Punkt haben sie recht, im Rest liegen sie daneben. Sie haben recht, dass das Einplanen einzelner Storys auf einem Gantt ein Fehler ist, denn diese Storys ändern sich täglich und das Diagramm wäre bis zum Mittag veraltet. Sie liegen falsch, wenn sie meinen, ein Gantt-Diagramm habe in der Software überhaupt keinen Platz.

Der Kniff ist die Flughöhe. Ein Backlog arbeitet auf Story-Ebene, wo die Arbeit klein ist, ständig umsortiert wird und vom Fluss statt von Terminen gesteuert wird. Ein Gantt arbeitet eine Ebene darüber, auf Release-Ebene, wo du dich auf ein Startdatum festlegst, mehrere Teams koordinierst und Stakeholdern Rede und Antwort stehst, die kein Jira lesen. Halte das Gantt auf dieser Höhe, und die Spannung zwischen ihm und Agilität verschwindet schlicht. Lass es auf die Story-Ebene sinken, und du hast dir jede Beschwerde verdient, die das Team dir entgegenwirft.

Die fünf Phasen eines Softwareplans

Die meiste Feature-Arbeit durchläuft fünf wiederkehrende Phasen, und ein Gantt ist dafür gebaut, genau diese Art von Abfolge zu zeigen. Die Discovery klärt das Problem und den Umfang. Das Design legt die Oberfläche, das Datenmodell und den API-Vertrag fest. Der Bau ist der Großteil der Entwicklung. Der Test deckt Integration, QA und Härtung ab. Der Release deckt Deployment, Migration und die Inbetriebnahme selbst ab. Jede Phase stützt sich auf die vorherige, und genau diese Beziehung macht ein Balkendiagramm sichtbar.

Phasen sind keine Sprints. Eine einzelne Phase wie der Bau kann sich über drei oder vier Sprints erstrecken, während die Discovery in einen einzigen passen mag. Das ist in Ordnung. Das Gantt hält einen Balken je Phase, nicht einen je Sprint und schon gar nicht einen je Ticket. Diese grobe Sicht ist es, die einer Leitung erlaubt, einen Blick auf das Diagramm zu werfen und in einer Sekunde zu sehen, ob das Team noch im Bau steckt oder schon für den Release härtet. Das Backlog kann dir diese Gestalt nie geben, weil es Termine bewusst verbirgt.

Wo ein Gantt ein Backlog schlägt

Ein Backlog ist eine flache, nach Priorität sortierte Liste. Es ist hervorragend darin, die nächsten Arbeitstage zu ordnen, und blind für drei Dinge, von denen ein Release abhängt. Erstens die Release-Sicht. Ein Stakeholder, der fragt, wann der Checkout ausgeliefert wird, will ein Bild der gesamten Spanne von der Discovery bis zum Start, kein Durchscrollen von 200 Tickets. Ein Gantt liefert ihm dieses Bild in einem einzigen Rahmen.

Zweitens die Fristen. Eine Vertragsklausel, eine Konferenzdemo oder ein Compliance-Termin ist ein fester Punkt in der Zeit. Ein Backlog kennt kein Kalenderdatum, also kann es dir nicht sagen, ob der zugesagte Termin noch realistisch ist. Ein Gantt verankert diese Termine als Meilensteine und zeigt den Puffer davor, oder dessen Fehlen. Drittens die Abhängigkeiten. Wenn ein Team ein anderes ausbremst, taucht diese Beziehung auf keinem der beiden Boards auf, und doch ist sie der mit Abstand häufigste Grund, warum Softwaretermine rutschen. Ein Gantt ist das einzige Artefakt, das sie offensichtlich macht.

Wo ein Backlog ein Gantt schlägt

Ehrlichkeit geht in beide Richtungen, und es gibt echte Arbeit, die ein Gantt nie anrühren sollte. Das hektische Tagesgeschäft gehört auf ein Board. Welches Ticket als Nächstes gezogen wird, was heute Morgen blockiert ist, wie viele Punkte im Sprint noch offen sind, wer den instabilen Test übernimmt, der gerade fehlgeschlagen ist: nichts davon gehört auf ein Gantt, und es dorthin zu zwingen ist, wie sich Gantt-Diagramme in der Entwicklung ihren schlechten Ruf verdienen.

Board-Arbeit ändert sich von Stunde zu Stunde. Schätzungen verschieben sich, Storys spalten sich, Bugs drängeln sich vor, und nach jedem Standup werden die Prioritäten neu gemischt. Ein so oft neu gezeichnetes Gantt ist schlimmer als nutzlos, denn es wirkt maßgeblich, während es falsch ist. Das Board ist dafür gebaut, diese Schwankung aufzufangen. Es behandelt Veränderung als normalen Fluss statt als Abweichung von einem Plan. Lass also das laute, schnelllebige Detail auf dem Board und lass es brodeln. Das Gantt interessiert sich nur für das Ergebnis, das jeder Sprint hervorbringt, nicht für den Weg Minute um Minute, den das Team dorthin genommen hat.

Gantt und Backlog, nebeneinander

Die beiden Werkzeuge überschneiden sich kaum, und genau deshalb betreibst du beide. Reihe die Fragen auf, die jedes beantwortet, und die Arbeitsteilung wird offensichtlich.

Beachte, wie wenig die Spalten teilen. Du wählst nicht das eine Werkzeug statt des anderen. Du deckst zwei verschiedene Fragenmengen mit zwei verschiedenen Instrumenten ab.

Teamübergreifende Abhängigkeiten sind der eigentliche Grund

Wenn sich ein Software-Gantt an einer einzigen Sache seinen Platz verdient, dann an teamübergreifenden Abhängigkeiten. Softwarearbeit steckt voller Übergaben, die kein einzelnes Board zeigen kann. Die API muss einen Endpoint bereitstellen, bevor die Oberfläche ihn aufrufen kann. Die Infrastruktur muss den Cluster bereitstellen, bevor überhaupt jemand darauf deployen kann. Das Datenteam muss die Migration ausliefern, bevor das Feature das neue Schema liest. Jede davon ist eine Ende-Anfang-Abhängigkeit, die eine Teamgrenze überschreitet, und jede ist auf den Boards der beteiligten Teams unsichtbar.

Auf einem Gantt sind diese Übergaben einzelne Pfeile, und sie verändern, wie du den Release steuerst. Sobald du siehst, dass der Oberflächen-Balken nicht starten kann, bevor der API-Balken fertig ist, weißt du, welche Arbeit zu schützen ist und welche nachgeben darf. Du hörst auf, das Rutschen jedes Teams als gleich dringend zu behandeln, und beginnst, die konkreten Übergaben zu verteidigen, die den Termin tatsächlich bestimmen. Das ist eine Entscheidung, die ein Backlog nie fundieren kann, denn das Backlog weiß nicht, dass das andere Team existiert.

Durchgerechnetes Beispiel: ein Checkout-Feature in zehn Wochen

Ein Team verpflichtet sich, einen Self-Service-Checkout in zehn Wochen auszuliefern. Discovery und Design laufen zuerst, dann bauen drei Teams parallel, dann läuft alles in Test und Release zusammen. Das Board führt die Tickets. Das Gantt führt den Release. So bilden sich die Phasen und Verantwortlichen auf die Zeitachse ab.

Die Kette, die deinen Termin festlegt

Im obigen Beispiel ist die Abfolge Design zu Zahlungs-API zu Checkout-Oberfläche zu Test zu Release die längste Kette abhängiger Arbeit. Die Infrastruktur läuft parallel und wird früh fertig, hat also Spielraum. Diese längste Kette ist dein kritischer Pfad, und sie ist das Einzige, was den Starttermin wirklich festlegt. Die Plattformarbeit könnte um ein paar Tage rutschen, und der Release ginge trotzdem raus. Die Zahlungs-API kann das nicht.

Hier zahlt sich ein Gantt in einem Entwicklungsbetrieb aus. Ein Velocity-Diagramm sagt dir, wie schnell ein Team vorankommt. Es kann dir nicht sagen, welcher von drei parallelen Arbeitssträngen den ganzen Release in Geiselhaft hält. Der kritische Pfad kann das, und er lässt dich Aufmerksamkeit dorthin lenken, wo ein Rutsch dich wirklich den Termin kostet, statt die Sorge gleichmäßig über jedes Team zu verteilen. Schätze die Balken auf dieser Kette mit echtem historischem Durchsatz, nicht mit Optimismus, und lies unseren Leitfaden zum Schätzen von Dauern, bevor du dich auf einen Termin festlegst, den ein Kunde zu hören bekommt.

Das Release-Gantt mit der Sprint-Ausführung verbinden

Das tragfähige Muster ist einfach. Das Gantt besitzt den Release. Die Sprints besitzen das Detail. Du zeichnest das Gantt auf der Ebene von Phasen und Epics und lässt dann jedes Team seine eigenen Storys auf dem Board planen, genau wie heute. An der Sprint-Zeremonie ändert sich nichts. Was sich ändert, ist, dass du bei jedem Sprint-Review den passenden Phasenbalken aktualisierst: fertig, gerutscht oder geschrumpft?

Plane die nahen Phasen im Detail, weil du sie verstehst, und halte die fernen Phasen als grobe Blöcke, weil du sie ehrlich gesagt noch nicht verstehst. Verfeinere jeden Block, sobald er sich dem aktuellen Sprint nähert. Dieser Rolling-Wave-Ansatz hält das Gantt wahrhaftig, ohne vorzutäuschen, dass du in Woche 2 die Woche 10 kennst. Das Gantt ist kein zweiter Ort, um Aufgaben zu verwalten. Es ist eine Linse, die ein Quartal an Sprint-Ergebnissen in eine einzige Antwort zum Starttermin verwandelt. Das Board beantwortet, was als Nächstes zu bauen ist. Das Gantt beantwortet, ob die Summe all dieses Bauens pünktlich ankommt.

Den Plan Schritt für Schritt bauen

Du brauchst weder ein schwergewichtiges Werkzeug noch ein Projektzertifikat, um eines zu bauen. Du brauchst die Phasen, die bereits zugesagten Termine und eine Stunde mit den Teamleitungen. Hier ist die Abfolge.

1. Liste die Phasen und großen Epics dieses Release auf, nicht die Storys. Ziele auf sechs bis zwölf Balken.
2. Markiere zuerst die festen Termine: die Inbetriebnahme, jede Demo und jede Compliance- oder Vertragsfrist. Zeichne diese als Meilenstein-Rauten, die sich nicht bewegen.
3. Dimensioniere jede Phase anhand deines echten Durchsatzes und platziere sie dann auf der Zeitachse.
4. Zeichne die Abhängigkeiten zwischen den Phasen, besonders jede Übergabe, die ein Team überschreitet. Das ist der wertvollste Schritt.
5. Finde die längste Kette abhängiger Phasen. Das ist der kritische Pfad, den du verteidigst.
6. Betraue eine einzige Person damit, das Diagramm bei jedem Sprint-Review zu aktualisieren, und sonst nirgends.

Öffne einen leeren Plan im Gantt-Editor, füge eine Zeile je Phase hinzu, verknüpfe die Abhängigkeiten, und du hast in unter einer Stunde eine Release-Sicht. Lass das Ticket-Detail auf dem Board, wo es hingehört.

Halte es grob, sonst verrottet es

Der mit Abstand häufigste Grund, warum ein Gantt in einem Softwareteam scheitert, ist das Gewicht. Jemand baut ein wunderschönes Diagramm mit einem Balken je Ticket, es ist binnen eines Sprints veraltet, und das Team folgert, dass Gantt-Diagramme nicht funktionieren. Das Diagramm ist nicht gescheitert. Die Granularität schon. Ein Release-Gantt sollte klein genug sein, dass eine Person es im Sprint-Review in zehn Minuten aktualisiert, indem sie ein paar Balken zieht und einen Termin verschiebt.

Ein Gantt-Diagramm, das einmal gebaut und nie angerührt wird, ist kein Plan, es ist ein Wunsch. Aktualisiere es oder lösche es, aber lass es nie auf einem geteilten Laufwerk verrotten und vorgeben, die Wahrheit zu sein.

Wann du das Gantt ganz weglässt

Nicht jedes Softwarevorhaben braucht ein Gantt, und eines dort hinzuzufügen, wo es nichts einbringt, ist reiner Ballast. Wenn deine Arbeit ein stetiger Fluss kleiner, unabhängiger Elemente ohne externe Frist und ohne teamübergreifende Übergaben ist, reicht ein Board völlig. Ein Wartungstrupp, eine Support-Warteschlange oder ein einzelnes Team, das mehrmals am Tag in Produktion ausliefert, gewinnt wenig durch eine Release-Ebene, weil es keinen Release zu gestalten gibt.

Greif zu einem Gantt, wenn drei Signale zusammen auftreten: ein fester externer Termin, den du zugesagt hast, mehr als ein Team, dessen Arbeit von einem anderen abhängt, und ein Stakeholder, der die gesamte Spanne in einer Sicht braucht. Sind alle drei vorhanden, lässt das Backlog echte Fragen offen und das Gantt beantwortet sie sauber. Ist keines vorhanden, lass es mit gutem Gewissen weg. Und wenn du eines willst, musst du auch nicht dafür bezahlen, denn unsere Übersicht der besten kostenlosen Gantt-Diagramm-Software behandelt Werkzeuge, die genau das leisten.

Häufige Fragen

Passend dazu

• Aufgabenabhängigkeiten erklärt
• Die Methode des kritischen Pfads erklärt
• Meilensteine und Aufgaben
• Zurück zu den Ratgebern

Dieser Artikel ist auch auf Englisch verfügbar.