Pläne

Ein Plan ist eine geordnete Menge von Aufgaben, die in Phasen gruppiert werden. Sie genehmigen ihn, bevor Code geschrieben wird.

Verwenden 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.

1. Die Planung beginnt. Sobald die Anfrage die Qualifizierung erfolgreich durchläuft, untersucht der Architekt den Codebestand und entwirft Phasen sowie Aufgaben. Die Planung startet automatisch – es sei denn, die Anfrage enthält Anhänge oder nutzt den SDLC-Workflow; dann beginnt sie beim Erstellen des Plans oder nach Abschluss der Vorbereitung.
2. Sie prüfen den Entwurf. Dies ist der kostengünstigste Interventionspunkt im gesamten System.
3. Genehmigen, überarbeiten oder zurücksetzen. Bei Genehmigung wird der Plan zur Ausführung freigegeben; bei Überarbeitung wird er mit Ihren Rückmeldungen zurückgesendet; das Zurücksetzen startet die Planung erneut.
4. 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 erst später starten.

Überarbeiten statt zurücksetzen#

Wenn ein Plan fast richtig 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 den 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 Inhalt eines abgelehnten Plans geht nicht verloren; er dient als Grundlage 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 alle 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 Migration auf einen zweiten Service.

Abgeschlossene Pläne können archiviert werden, um die Übersicht über aktive Pläne aufrechtzuerhalten.

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-Branchzusammengeführt; dieser Branch wird als einzelner Pull Request gegen Ihren Basisbranch freigegeben, sobald die Arbeit die Qualifikation erfüllt.

So prüfen Sie das fertige Feature auf einmal – mit dem gesamten Umfang der Änderungen sichtbar – anstatt halbfertige Phasen einzeln zu genehmigen.

Pläne über Projekte hinweg sind die Ausnahme: Eine Aufgabe, die zu einem anderen Projekt als der Lane gehört, wird separat freigegeben – somit entsteht pro Repository ein pull request. Ein pull request kann zwei Repositories nicht umfassen.

Wenn sich der Basisbranch ändert#

Ein Plan kann mehrere Stunden laufen, während Ihr Team derweil weiterhin in den Basisbranch committet. Der Plan wurde gegen den Basisbranch erstellt, getestet und überprüft – genau wie er zum Zeitpunkt des Starts war. Wenn sein pull request fertig ist, entspricht der Branch möglicherweise nicht mehr dem Zielbranch für die Zusammenführung.

Sobald ein Plan gestartet wird, speichert Coroid den letzten Commit des Basisbranches als Basislinie. Bevor der pull request des Plans zusammengeführt werden kann, prüft Coroid den Basisbranch erneut. Jede Änderung am Dateiinhalt zählt, auch bei Dateien, die der Plan nie berührt hat. Ein neues Authentifizierungsverfahren oder eine Sicherheitsregel kann korrekten Code ungültig machen, ohne einen Merge-Konflikt zu verursachen – daher wartet Coroid nicht darauf.

Falls sich der Basisbranch geändert hat, Genehmigen & zusammenführen bleibt deaktiviert, und die Überprüfung der Hochstufung listet die neuen Commits sowie die davon betroffenen Dateien auf. Sie entscheiden, was geschieht:

• Neuen Hauptbranch akzeptieren (benannt nach Ihrem Basisbranch) – die Änderungen wirken sich nicht auf diese Arbeit aus. Coroid protokolliert, wer welchen Commit akzeptiert hat und warum; dieser Commit wird zur neuen Basislinie. Falls sich der Branch während Ihrer Prüfung erneut ändert, lehnt Coroid die Akzeptanz ab und zeigt Ihnen zuerst die neueren Commits an. Nichts wird ohne Vorlage akzeptiert.
• Zusammenführen und erneut überprüfen – Coroid führt den Basisbranch in den Lane-Branch ein und löst eventuelle Konflikte. Anschließend durchläuft der Lane erneut die Phasen Entwicklung, QA und Review, wobei er auf die Akzeptanzkriterien des Plans sowie die neuen Commits geprüft wird. Die Genehmigung bleibt bis zum Abschluss zurückgehalten. Erst danach wird der neue Commit zur Basislinie. Falls das Zusammenführen oder die erneute Überprüfung fehlschlägt, liegt die Entscheidung wieder bei Ihnen.

Standardmäßig wird der Plan pausiert. Ein Projekt kann stattdessen „Zusammenführen und erneut überprüfen“ wählen, sodass Coroid ohne Ihr Zutun startet; siehe Repository- und Branch-Einstellungen. Die erneute Überprüfung verbraucht Agenten-Stunden.

Ein Plan, der von vorne neu gestartet wird, legt eine neue Basis fest und läuft anschließend gegen den jeweiligen Basis-Branch. Die Belege des früheren Versuchs bleiben zwar im Verlauf erhalten, wirken sich aber nicht auf den neuen Versuch aus.

Erzwungenes Zusammenführen überspringt ebenfalls diese Prüfung und protokolliert den angegebenen Grund dafür. Siehe Zusammenführen.

Phasen und Parallelität#

Phasen definieren die Reihenfolge, nicht die gleichzeitige Ausführung. Innerhalb einer Phase können Aufgaben parallel laufen, sofern Kapazitäten vorhanden sind; die nächste Phase wartet 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?#

Im Formular „Neue Aufgaben“ wählen Sie Plan oder Aufgabe unter Erstellen als, oder lassen Sie es auf Automatisch stehen und überlassen Sie die Entscheidung der Qualifizierung. Arbeiten, die sich über mehrere Projekte erstrecken, werden immer als Plan angelegt. Falls Sie eine Variante wählen und die Qualifizierung die andere empfiehlt, sehen Sie diese Empfehlung vor der Erstellung.

Der Maßstab ist die Überprüfbarkeit: Ein pull request, den ein Kollege in einem Rutsch lesen kann, ist eine Aufgabe; alles, was mehrere geordnete Änderungen erfordert, ist ein Plan.

Bei wirklich umfangreicher Arbeit ist die Fehlentscheidung, eine Aufgabe zu wählen, riskanter – die Aufgabe könnte mitten im Prozess an ihre Grenzen stoßen und den Lauf verschwenden. Die Wahl eines Plans kostet lediglich einen überflüssigen Freigabeschritt.

Auslieferungs-Schranken#

Ein Plan kann eine Auslieferungs-Sperre enthalten, die festlegt, welche Bedingungen vor dem Weiterkommen der Ausgabe erfüllt sein müssen. Siehe Qualitäts-Sperren.

Verwandte Themen#

• Aufgaben, Pläne, Sprints und Lanes
• Sprints
• Spezifikationen
• Provenienz