Ein Plan ist eine geordnete Ansammlung von Aufgaben, die in Phasen gruppiert werden. Sie genehmigen ihn, bevor Code geschrieben wird.
Nutzen Sie einen Plan, wenn die Arbeit mehrere Änderungen in einer bestimmten Reihenfolge erfordert oder wenn Sie den gesamten Ansatz vor der Umsetzung überblicken möchten.
Der Lebenszyklus
Die Planung ist ein eigenständiger Schritt – keine sofortige Umwandlung.
- Die Planung beginnt. Der Architekt untersucht den Codebestand und entwirft Phasen sowie Aufgaben.
- Sie prüfen den Entwurf. Dies ist der kostengünstigste Ansatzpunkt im gesamten System.
- Genehmigen, überarbeiten oder zurücksetzen. Durch die Genehmigung wird der Plan zur Ausführung freigegeben; bei der Überarbeitung wird er mit Ihren Rückmeldungen zurückgesendet; das Zurücksetzen startet die Planung neu.
- Ausführung. Die Aufgaben werden nacheinander ausgeführt und respektieren dabei die Phasengrenzen.
Sie können Genehmigung und Ausführung in einem Schritt vornehmen oder die Genehmigung später einleiten.
Überarbeiten statt zurücksetzen
Wenn ein Plan fast korrekt ist, bewahrt die Überarbeitung das Wissen des Architekten über Ihren Codebestand und berücksichtigt Ihre Rückmeldungen. Beim Zurücksetzen geht dieses Wissen verloren und die Planung beginnt von vorn.
Setzen Sie einen Plan zurück, wenn der gesamte Ansatz fehlerhaft ist. Überarbeiten Sie ihn, wenn der Ansatz stimmt, aber die Details nicht. Die Überarbeitung ist deutlich kostengünstiger – der abgelehnte Planinhalt geht nicht verloren, sondern dient als Ausgangspunkt für den nächsten Versuch.
Steuerung eines laufenden Plans
Ein laufender Plan kann pausiert, fortgesetzt oder abgebrochen werden; Sie können den Fortschritt über die einzelnen Phasen hinweg verfolgen. Pläne lassen sich außerdem klonen – das ist die praktische Möglichkeit, eine bewährte Struktur zu wiederholen, etwa bei der Übertragung auf einen zweiten Service.
Abgeschlossene Pläne können archiviert werden, um die Übersichtlichkeit der aktiven Ansicht zu wahren.
Ein pull request, nicht einer pro Aufgabe
Die Aufgaben eines Plans öffnen jeweils keinen eigenen pull request. Sie arbeiten auf eigenen Branches und werden in einen gemeinsamen Lane-Branch; dieser Branch wird zum Abschluss als einzelner Pull Request gegen Ihren Basis-Branch hochgestuft.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘So prüfen Sie das fertige Feature auf einmal – mit allen Änderungen sichtbar – anstatt halbfertige Phasen einzeln zu genehmigen.
Pläne über Projekte hinweg bilden die Ausnahme: Eine Aufgabe aus einem anderen Projekt als der Lane wird separat hochgestuft, sodass Sie pro Repository einen pull request erhalten. Ein pull request kann zwei Repositories nicht umfassen.
Phasen und Parallelität
Phasen definieren die Reihenfolge, nicht die gleichzeitige Ausführung. Aufgaben innerhalb einer Phase können bei ausreichender Kapazität parallel laufen; die nächste Phase wartet jedoch auf die Abschluss der aktuellen.
Ein Plan mit zehn parallel ausführbaren Aufgaben und nur einem Agenten-Slot führt diese dennoch nacheinander aus. Die Struktur schafft keine zusätzliche Kapazität – siehe Kapazität und Agenten-Slots.
Plan oder Aufgabe?
Sie entscheiden durch die Auswahl von Phasenarbeitsplan oder Eine ausführbare Aufgabe im Routing-Schritt. Niemand analysiert Ihr Anliegen und entscheidet für Sie.
Der Prüfmaßstab ist die Überschaubarkeit: Ein pull request, den ein Kollege in einem Zug lesen kann, ist eine Aufgabe; alles, was mehrere geordnete Änderungen erfordert, ist ein Plan.
Bei wirklich umfangreicher Arbeit ist die Fehlentscheidung zugunsten einer Aufgabe riskanter – die Aufgabe könnte unterwegs an ihre Grenzen stoßen und die Ausführung verschwenden. Die Wahl eines Plans kostet lediglich eine überflüssige Freigabestufe.
Auslieferungs-Sperren
Ein Plan kann eine Auslieferungs-Sperre enthalten, die festlegt, welche Bedingungen vor dem Weiterleiten des Ergebnisses erfüllt sein müssen. Siehe Qualitäts-Sperren.