Software-Release im Gantt-Diagramm planen: vom Freeze zur Produktion
Die Strecke von Feature Complete bis Produktion planen: Code-Freeze als Meilenstein, Teststränge parallel, Zusammenführung vor der Freigabe und der kritische Pfad als Hinweis darauf, was den Release-Termin bestimmt.
Release-Termine werden meist genannt, bevor es einen Testplan gibt. Der Leitfaden zeigt, wie Sie die Strecke vom Freeze bis zur Produktion in einen Zeitplan verwandeln, den Sie gegen den vorgegebenen Termin prüfen können.
Kurz gesagt
- Machen Sie den Code-Freeze zu einem Meilenstein der Länge null, den alle Entwicklungsaufgaben erreichen müssen.
- Starten Sie Teststränge, Release Notes und Runbook vom Freeze aus, damit sie nebeneinander laufen.
- Führen Sie alle Stränge vor der Freigabe in einer Aufgabe zusammen und binden Sie das Deployment an Freigabe und Dokumente.
- Planen Sie die Tage nach dem Deployment als Aufgaben: Smoke-Test, Ankündigung und ein Monitoring-Fenster.
- Schalten Sie den kritischen Pfad ein, um zu sehen, welcher Strang den Termin bestimmt, und vergleichen Sie das Ende mit dem Datum, das Sie brauchen.
Die Strecke nach dem letzten Feature planen
Ein Release-Plan ist kurz, aber dicht. Siebzehn Aufgaben passen in etwa einen Monat, und die meisten hängen von zwei oder drei anderen ab. Deshalb scheitert hier eine flache Checkliste: Sie sagt, was geschehen muss, aber nicht, dass der Abnahmetest zwei Tage nach dem Freeze starten kann, während die Regressionstests nicht davor enden können, oder dass das Runbook an dem Tag bereit sein muss, an dem das Deployment beginnt, nicht an dem Tag, an dem die Tests enden.
Die Methode besteht aus vier Schritten. Erstens: Machen Sie den Freeze zum Meilenstein, den alles davor erreichen muss. Zweitens: Starten Sie die Teststränge vom Freeze aus und lassen Sie auch die Dokumentation dort beginnen. Drittens: Führen Sie die Stränge vor der Freigabe in einer Aufgabe zusammen, damit die Freigabe nicht zu früh erscheint. Viertens: Geben Sie dem Deployment seine Gates und planen Sie die Tage danach als echte Aufgaben. Die Termine werden aus Längen und Verknüpfungen berechnet, und Sie vergleichen das Ende mit dem Datum, das Sie brauchen, statt das Datum zuerst einzutragen.
Ein Zeitplan macht ein Release nicht sicher. Er zeigt, wann die Arbeit fertig sein sollte, wenn jede Schätzung hält, und er findet weder einen fehlenden Test noch einen ungetesteten Rollback. Halten Sie Testergebnisse, Freigaben und Fehlerliste in den Systemen, die sie führen. Das Diagramm plant Reihenfolge und Zeit; es ist nicht mit einem Repository, einem Ticketsystem oder einem Deployment-Werkzeug verbunden.
Das Beispiel ist die Vorlage [Gantt-Diagramm Software-Release](/de/templates/software-release-gantt-diagramm). Brauchen Sie den Prozess und seine Entscheidungen statt des Zeitplans, siehe die Flussdiagramme zum [Software-Release-Prozess](/de/templates/software-release-prozess) und zum [Software-Deployment-Prozess](/de/templates/software-deployment-prozess). Für ein gesamtes Vorhaben von den Anforderungen bis zum Launch nutzen Sie die [Vorlage für Softwareprojekte](/de/templates/software-projekt-gantt-diagramm).
Ein Release-Zeitplan, in Stufen aufgebaut
Siebzehn Aufgaben in vier Gruppen. Die Dauern sind beispielhafte Arbeitstage; setzen Sie eigene ein. Öffnen Sie das Tabellenfenster, um die Zeilen hinter jeder Stufe zu sehen.
Die Entwicklung endet mit einem Meilenstein
„Restliche Features fertigstellen“ dauert 10 Arbeitstage. „Bekannte Fehler beheben“ (6 Tage) beginnt 5 Arbeitstage nach dessen Start, eine Verknüpfung von Start zu Start mit Versatz, sodass die Fehlerbehebung das Ende der Entwicklung überlappt. „Feature Complete“ ist ein Meilenstein der Länge 0.
Der Freeze und drei Teststränge
„Code-Freeze“ ist ein Meilenstein. „Regressionstests“ (5 Tage), „Performance- und Sicherheitsprüfung“ (4) und „Abnahmetest durch Anwender“ (6) folgen ihm alle, und der Abnahmetest beginnt 2 Arbeitstage nach dem Freeze. „Release-Blocker beheben“ (3 Tage) wartet auf alle drei.
Vorbereitung und Deployment-Gates
„Release Notes schreiben“ und „Runbook und Rollback-Plan aktualisieren“ (je 3 Tage) beginnen beim Freeze, nicht nach den Tests. „In Produktion ausrollen“ (1 Tag) wartet auf „Release-Freigabe“, die Notes und das Runbook. „Smoke-Test in Produktion“ folgt darauf.
Die Tage nach dem Deployment
„Release ankündigen“ (1 Tag) und „Überwachen, frühe Probleme beheben“ (5 Tage) warten beide auf den Smoke-Test und laufen daher nebeneinander. „Release-Retrospektive“ ist die letzte Aufgabe, ein Tag dafür, was der nächste Plan ändern sollte.
So funktioniert es
Die Aufgaben zwischen letztem Feature und erstem Nutzer auflisten
Schreiben Sie jede Aufgabe auf, die vor und nach der Produktion fertig sein muss, einschließlich Dokumenten und Rollback-Plan. Geben Sie jeder eine Länge in Arbeitstagen. Nur ganze Tage: Runden Sie eine halbtägige Aufgabe auf.
Den Freeze als Meilenstein setzen
Legen Sie eine Aufgabe der Länge 0 für den Freeze an. Lassen Sie sie von den Entwicklungsaufgaben abhängen und die Teststränge, die Release Notes und das Runbook von ihr.
Überlappen, was sich überlappen lässt
Nutzen Sie eine Verknüpfung von Start zu Start mit Versatz, wo Arbeit mitten in einer anderen Aufgabe beginnt, zum Beispiel 4SS+2 in der Spalte „Abhängig von“ (Depends on). Nutzen Sie sie für die Fehlerbehebung während der Entwicklung und für den Abnahmetest, der einige Tage nach dem Freeze startet.
Die Stränge vor der Freigabe zusammenführen
Geben Sie der Aufgabe nach den Tests eine Abhängigkeit von jedem Strang, geschrieben als kommagetrennte Liste. Die Freigabe kann dann nicht früher liegen als der langsamste Strang.
Das Deployment mit Gates versehen und die Tage danach planen
Lassen Sie das Deployment von der Freigabe und von den Dokumenten abhängen. Ergänzen Sie Smoke-Test, Ankündigung und ein Monitoring-Fenster als Aufgaben, damit Supportzeit Teil des Plans ist.
Den kritischen Pfad gegen Ihr Datum prüfen
Öffnen Sie das Menü „Ansicht“ und schalten Sie den kritischen Pfad ein. Vergleichen Sie das Enddatum mit dem Datum, das Sie brauchen. Steht das Datum fest, ändern Sie die Kette, die es bestimmt, denn das Kürzen anderer Aufgaben verschiebt es nicht.
Häufige Fehler
Dokumente erst nach den Tests schreiben
Release Notes und ein Rollback-Plan, die nach den Tests entstehen, hängen ihre Länge an das Planende. Starten Sie sie beim Freeze und lassen Sie das Deployment darauf warten, damit sie unter Zeitdruck nicht übersprungen werden.
Freigabe ohne Zusammenführung
Hängt die Freigabe nur von einem Teststrang ab, zeigt das Diagramm ein Datum, das die anderen Stränge vielleicht nicht halten. Verknüpfen Sie sie, direkt oder über eine Fehlerbehebungsaufgabe, mit jedem Strang.
Die Tage nach dem Deployment vergessen
Ein Plan, der beim Deployment endet, verbirgt das Monitoring und die Korrekturen danach. Behalten Sie ein Monitoring-Fenster im Diagramm, auch wenn seine Länge geschätzt ist.
Das Release-Datum als Start festsetzen
Ein fester Start der Deployment-Aufgabe sorgt nicht dafür, dass die frühere Arbeit hineinpasst. Liegt das berechnete Datum später als das festgesetzte, markiert das Diagramm den Konflikt. Lesen Sie die Markierung als Hinweis, dass sich der Termin mit diesen Schätzungen nicht halten lässt.
Gantt-Diagramm Software-Release öffnen
Öffnen Sie die Release-Vorlage, ändern Sie die Dauern auf Ihre und sehen Sie, welcher Teststrang den Termin bestimmt.
Verwandte Anleitungen
Häufig gestellte Fragen
Wie lang sollte ein Release-Zeitplan sein?
So lang, wie die Arbeit zwischen Freeze und Produktion in Ihrem Team dauert. Die Längen der Vorlage sind Beispiele. Ersetzen Sie sie durch die Werte Ihrer letzten Releases und beziehen Sie die Tage nach dem Deployment ein.
Sollte der Freeze eine Aufgabe oder ein Meilenstein sein?
Ein Meilenstein, also eine Aufgabe der Länge 0, gezeichnet als Raute. Er markiert den Punkt, den alles davor erreichen muss, und die Teststränge sind mit ihm verknüpft.
Kann ich sehen, welcher Teststrang den Release-Termin bestimmt?
Ja. Schalten Sie den kritischen Pfad im Menü „Ansicht“ ein. Er hebt die Kette von Aufgaben hervor, die das Ende bestimmt, und die Auswahl einer Aufgabe hebt hervor, wovon sie abhängt und was von ihr abhängt.
Funktioniert das auch für Hotfixes?
Ein Hotfix ist ein kurzes Diagramm: beheben, testen, freigeben, ausrollen, Smoke-Test. Duplizieren Sie ein Release-Diagramm, entfernen Sie, was Sie nicht brauchen, und behalten Sie die Gates.
Wo finde ich den Release-Prozess selbst?
In den Flussdiagramm-Vorlagen, die Entscheidungen und Freigaben zeichnen: [Software-Release-Prozess](/de/templates/software-release-prozess) und [Software-Deployment-Prozess](/de/templates/software-deployment-prozess). Nutzen Sie das Gantt-Diagramm für die Dauer und das Flussdiagramm dafür, wer was entscheidet.
