Gantt-Diagramm für Softwareentwicklung: Release von Discovery bis Review planen
Planen Sie ein Softwareprojekt als Gantt-Diagramm: Discovery, Design, Entwicklung, QA, Deployment, Release und Review mit parallelen Strängen und Entscheidungspunkten, und wie es zu Agile-Sprints passt.
Ein Gantt-Diagramm für ein Softwareprojekt zeigt, wie Arbeitsstränge voneinander abhängen und wann ein Release landen kann. Es beantwortet, was ein Sprint-Board nicht beantwortet: Was ist bei diesen Abhängigkeiten der früheste Termin für das Release?
Kurz gesagt
- Planen Sie auf Release-Ebene: Stränge, Entscheidungspunkte und Abhängigkeiten, nicht einzelne Tickets.
- Parallele Stränge entstehen durch Aufgaben, die auf denselben Vorgänger warten; der längere bestimmt den Termin.
- Entscheidungspunkte wie Umfang abgestimmt und Go-/No-go gehören als Meilensteine ins Diagramm.
- Ein Entwicklungsstrang lässt sich in Sprints bemessen, umgerechnet in Arbeitstage.
- Kapazität und Aufwand werden nicht modelliert; nutzen Sie dafür Ihren Tracker.
Wo ein Gantt-Diagramm einem Softwareteam hilft und wo nicht
Die meisten Softwareteams arbeiten in Sprints, und ein Sprint-Board ist der richtige Ort, die Arbeit darin zu steuern. Ein Gantt-Diagramm steht darüber. Es deckt das ganze Release ab: was fertig sein muss, bevor das Design beginnt, welche Stränge parallel laufen können, wo das Testen auf die Integration warten muss und welche Entscheidungen das Deployment freigeben. Es zeigt die Gestalt des Projekts, ersetzt aber nicht das Backlog.
Was ein Gantt-Diagramm zeigt und ein Board nicht, ist Zeit und Abhängigkeit zusammen. Ein Board sagt, was in Arbeit ist. Ein Gantt-Diagramm sagt, dass Frontend und Backend beide fertig sein müssen, bevor integriert wird, dass das Testen erst danach beginnen kann und dass der längere von zwei parallelen Strängen den Termin bestimmt. Das hilft bei der Release-Planung, im Gespräch mit Menschen außerhalb des Teams und beim Aufspüren des einen Strangs, der alles aufhält.
Halten Sie die Aufgaben grob. Planen Sie auf der Ebene von Discovery, Design, Entwicklungssträngen, Integration, Test, Release und Review, in Arbeitstagen, und überlassen Sie Stories und Tickets Ihrem Tracker. Arbeiten Sie in Sprints, kann ein Entwicklungsstrang einfach eine Aufgabe sein, deren Dauer eine Anzahl Sprints in Arbeitstagen ist. Bilden Sie nicht den Umfang jedes Sprints hier ab; das Diagramm ist veraltet, sobald sich das Backlog bewegt.
Ergänzen Sie die Entscheidungspunkte als Meilensteine der Dauer 0: Umfang abgestimmt, Design-Review, Go oder No-go. Dort wird ein Terminplan wirklich entschieden, und im Diagramm lässt sich die Frage, wer wann entscheidet, kaum überspringen. QueryChart erfasst weder Aufwand noch Kapazität; die Teamgröße wird nicht modelliert. Das Beispiel unten ist ein vollständiger Release-Plan, Phase für Phase.
Ein Software-Release von den Interviews bis zum Review nach dem Release
Siebzehn Aufgaben. Öffnen Sie das Tabellenfenster, um die Abhängigkeiten hinter jeder Phase zu sehen.
Discovery endet in einer Umfangsentscheidung
„Stakeholder-Interviews“ (4 Arbeitstage) führen zu „Anforderungen schreiben“ (5). „Umfang abgestimmt“ ist ein Meilenstein der Dauer 0, und beide Design-Stränge warten darauf.
Zwei Design-Stränge, ein Review
„Technische Architektur“ (4 Arbeitstage) und „UX-Design und Prototyp“ (8) beginnen beide nach „Umfang abgestimmt“. „Design-Review“ wartet auf beide; die UX-Arbeit als der längere Strang bestimmt also, wann es stattfindet.
Entwicklungsstränge und Testvorbereitung
„Backend-Entwicklung“ (20 Arbeitstage) und „Frontend-Entwicklung“ (18) beginnen nach „Design-Review“ und treffen sich bei „Integration“ (5). „Testplan und Testdaten“ (4) beginnt ebenfalls nach dem Review und ist daher lange vor dem Testen bereit.
Testen, entscheiden, ausliefern, auswerten
„Systemtest“ wartet auf „Integration“ und die Testvorbereitung. „Go-/No-go-Entscheidung“ ist ein Meilenstein vor „Deployment in Produktion“ (2 Arbeitstage), danach folgen „Release“, „Hypercare-Support“ (10) und „Review nach dem Release“ (2).
So funktioniert es
Den Detailgrad festlegen
Planen Sie auf Release-Ebene. Jede Aufgabe sollte ein Strang oder eine Phase sein, die Tage oder Wochen dauert, kein Ticket. Ist eine Aufgabe kürzer als ein paar Tage, fassen Sie sie in ihre übergeordnete Aufgabe.
Discovery und Design mit den Entscheidungs-Meilensteinen eintragen
Tragen Sie Discovery- und Design-Aufgaben mit Dauern in Arbeitstagen ein und ergänzen Sie Meilensteine der Dauer 0 für Umfang abgestimmt und Design-Review. Lassen Sie die nächste Phase vom Meilenstein abhängen, nicht von der letzten Aufgabe.
Parallele Stränge an denselben Vorgänger hängen
Backend, Frontend und Testvorbereitung sollten alle vom Design-Review abhängen. Reihen Sie sie nicht hintereinander; der Sinn des Diagramms ist zu zeigen, was sich überlappen kann.
Sprints in Arbeitstage umrechnen
Dauert ein Strang vier Zwei-Wochen-Sprints, tragen Sie 40 Arbeitstage ein. Ergänzen Sie einen Versatz nur bei einer echten Wartezeit, etwa einem Release-Freeze.
Die Release-Schranken ergänzen
Setzen Sie Go/No-go als Meilenstein vor das Deployment und geben Sie Hypercare und dem Review nach dem Release eigene Aufgaben, damit der Plan auch die Wochen nach dem Start abdeckt.
Kritischen Pfad einschalten und teilen
Schalten Sie über Ansicht, Kritischer Pfad die Kette ein, die den Release-Termin bestimmt, und teilen Sie das Diagramm dann als Link oder exportieren Sie ein PDF für Stakeholder.
Häufige Fehler
Auf Ticket-Ebene planen
Ein Gantt-Diagramm mit Hunderten kleiner Aufgaben ist nach einem Sprint überholt. Bleiben Sie auf Strang-Ebene und überlassen Sie das Detail dem Tracker.
Parallele Stränge verketten
Das Frontend hinter das Backend zu setzen, weil dieselbe Person beides macht, verbirgt die wahre Abhängigkeitsstruktur. Verknüpfen Sie nach dem, was Aufgaben wirklich brauchen, und vermerken Sie gemeinsame Personen im Feld „Personen“.
Vergessen, dass Kapazität nicht modelliert wird
Zwei Aufgaben derselben Person können sich ohne Warnung überlappen. QueryChart erfasst Verantwortliche, prüft aber keine Auslastung.
Die Wochen nach dem Release auslassen
Hypercare und ein Review sind echte Arbeit. Lassen Sie sie weg, endet der Plan am Release-Tag, an dem das Team selten frei ist.
Die Software-Projekt-Vorlage öffnen
Öffnen Sie den Software-Projektplan als eigenes Diagramm, ersetzen Sie die Stränge durch Ihre und teilen Sie die Release-Zeitplanung.
Verwandte Anleitungen
Häufig gestellte Fragen
Passt ein Gantt-Diagramm zu einem agilen Team?
Ja, auf Release-Ebene. Nutzen Sie es für die Gestalt des Projekts, seine Abhängigkeiten und Schranken und halten Sie den Sprint-Umfang in Ihrem Backlog-Werkzeug. Beide beantworten unterschiedliche Fragen.
Was zeigt ein Gantt-Diagramm, was ein Board nicht zeigt?
Zeit und Abhängigkeit zusammen: welche Stränge parallel laufen, welche enden müssen, bevor der nächste beginnt, und welche Kette den Release-Termin bestimmt.
Wie plane ich einen Sprint im Diagramm?
In der Regel gar nicht. Bilden Sie einen Entwicklungsstrang als Aufgabe ab, deren Dauer seine Sprintzahl in Arbeitstagen ist, und überlassen Sie den Sprint-Umfang dem Board.
Kann ich es mit meinem Issue-Tracker verbinden?
Nein. QueryChart hat keine Integrationen mit Issue-Trackern. Sie können Zeilen aus einem Tabellenexport in die Tabelle einfügen.
Kann ich zeigen, wer woran arbeitet?
Ja, jede Aufgabe hat ein Feld „Personen“. Eine Prüfung auf Auslastung oder Überlastung gibt es nicht.
