Coroid modelliert einen vollständigen Software-Lebenszyklus – nicht nur den Build-Schritt. Der Großteil davon läuft automatisch; ein Teil ist eine optionale Prüfstufe, die Sie aktivieren, wenn die Arbeit wichtig genug ist, um diese zu rechtfertigen.
Der optionale SDLC-Workflow
Im Neue Aufgaben Formular unter erweiterten Einstellungen befindet sich ein Kontrollkästchen:
SDLC-Workflow nutzen (optional) – eine Absicht und Spezifikation vor der Planung überprüfen. Deaktivieren Sie diese Option, um direkt mit der Planung auf Basis Ihrer Vorgabe zu beginnen.
Er ist standardmäßig deaktiviert. Wenn er deaktiviert ist, gelangt Ihre Vorgabe direkt in die Planung. Ist er aktiviert, werden zuerst zwei Artefakte erstellt und freigegeben:
- Absicht – der eigentliche Zweck der Arbeit, wobei die dahinterstehenden Entscheidungen und Annahmen festgehalten werden.
- Spezifikation – Umfang, Ausnahmen und Akzeptanzkriterien.
Erst nach deren Freigabe beginnt die Planung.
Wann sollten Sie ihn aktivieren?
Aktivieren Sie ihn, wenn die Kosten für das Erstellen des falschen Produkts hoch sind, wenn die Anfrage von jemandem stammt, der den Plan selbst nicht überprüfen wird, oder wenn die Vorgabe eine Annahme enthält, die Sie lieber schriftlich festgehalten und abgestimmt sehen würden.
Deaktivieren Sie ihn, wenn die Vorgabe bereits eindeutig ist. Eine zusätzliche Freigabestufe bei Routineaufgaben bedeutet unnötigen Aufwand ohne Nutzen – und die Planfreigabe gilt in jedem Fall weiterhin.
Die fünf Stationen
Der vollständige Lebenszyklus besteht aus fünf Phasen, wobei jede Phase Nachweise liefert, die die nächste Phase nutzt.
| Station | Was passiert? | Status |
|---|---|---|
| Definieren | Eine mehrdeutige Anfrage wird zu einer freigegebenen Absicht, Entscheidungen, Annahmen und Erfolgsmaßstäben. | Beta |
| Visualisieren | Optionale UI-Konzepte, die als Designrichtlinien ausgearbeitet und freigegeben werden. | Beta |
| Ausliefern | Der Plan wird aufgeschlüsselt und von Agenten ausgeführt. | Verfügbar |
| Nachweisen | Anforderungen werden in Aufgaben, Prüfschritte, Überprüfungsergebnisse und Pull-Request-Änderungen umgewandelt. | Verfügbar |
| Verbessern | Überwachungen, Korrekturmaßnahmen und Bewertungen wandeln Regressionsfehler in die Arbeit des nächsten Zyklus um. | Verfügbar |
Definieren und Visualisieren befinden sich in der aktiven Entwicklung. Ausliefern, Nachweisen und Verbessern laufen bereits heute bei jeder Aufgabe – unabhängig davon, ob Sie die Prüfstufe aktiviert haben oder nicht.
Warum die Artefakte versioniert werden
Freigaben beziehen sich auf eine exakte Version eines Artefakts. Wird ein freigegebenes Artefakt bearbeitet, entsteht ein neuer Entwurf – anstatt das bereits Vereinbarte stillschweigend zu ändern.
Das ist es, was eine Freigabe bedeutsam macht. Eine Freigabe, die nicht an eine spezifische Version des Artefakts gebunden ist – sondern an „die Spezifikation“ –, genehmigt später alles, was in dem Dokument steht; das ist keine echte Freigabe.
Freigabepapiere
Produkt-, Design-, technische, Sicherheits- und Release-Verantwortlichkeiten können unabhängig voneinander zugewiesen werden, sodass die Person, die die Sicherheitsauswirkungen freigibt, nicht zwangsläufig die Person ist, die den Umfang freigibt.
Nachweis-Kette
Der Zweck der Erstellung von Nachweisen in jeder Station besteht darin, dass ein fertiges pull request rückverfolgt werden kann: Diese Änderung implementiert diese Aufgabe, die wiederum aus dieser Anforderung resultiert, die ihrerseits aus dieser freigegebenen Absicht stammt.
Diese Kette macht die autonome Auslieferung nachvollziehbar. Ohne sie haben Sie funktionierenden Code – aber keine Erklärung dafür, warum dies der von Ihnen gewünschte Code ist.
Wie hängt das mit Plänen zusammen?
Der SDLC-Workflow und Pläne sind unterschiedliche Prüfstufen:
- Der SDLC-Workflow genehmigt was gebaut werden soll, noch bevor ein Ansatz existiert.
- Der Plan genehmigt wie es gebaut werden soll, noch bevor Code existiert.
Sie können eine der Optionen nutzen, beide oder keine davon. Beide Varianten sind kostengünstiger als die Überprüfung einer fertigen pull request, mit der Sie nicht einverstanden sind.