Ein Ergebnis in eine Initiative überführen

Beschreiben Sie das Ergebnis vor den Schritten

Der fiktive Ausstattungsdienst braucht Selbstbedienung durch Mitarbeiter. Eine nützliche Anfrage nennt das Ergebnis: „Ein authentifizierter Mitarbeiter kann eine Anfrage erstellen und ausschließlich seine eigenen Anfragen sehen.“

Erklären Sie den Nutzen: Führungskräfte erfassen derzeit Anfragen für Mitarbeiter. Definieren Sie den Umfang: Anfrageerstellung, Statusanzeige, Zugriffsprüfungen und Nachweise für dieses Verhalten. Schließen Sie automatische Beschaffung und Änderungen an der Freigaberegel für Führungskräfte aus.

Schreiben Sie keine Dateiänderungen vor, bevor das Repository geprüft wurde. Die Initiative erfasst das Ziel; die detaillierte Planung macht daraus Umsetzungsschritte.

Prüfen Sie, was die Anfrage erzeugt hat

Taiga nutzt Anfrage und Produktkontext, um eine Initiative oder eine geordnete Folge von Initiatives zu erstellen. Neue Arbeit erscheint in Backlog. Eine größere Anfrage kann mehrere unabhängig prüfbare Änderungen benötigen.

Lesen Sie den erzeugten Endzustand sowie Why und Scope. Prüfen Sie, ob erforderliches Verhalten erhalten blieb und Ausschlüsse eingehalten wurden. Wenn eine bestehende Initiative die Anfrage bereits abdeckt, kann Taiga diese benennen, statt ein Duplikat anzulegen.

Eine Anfrage, die durch eine veröffentlichte Richtlinie blockiert wird, braucht den dort definierten Entscheidungsweg. Lesen Sie die Erklärung und lösen Sie den Konflikt über diesen Weg. Schreiben Sie die Anfrage nicht nur um, um die verbotene Handlung zu verbergen.

Behandeln Sie das Board als Ausführungsreihenfolge

Taiga bearbeitet pro Produkt jeweils eine Initiative, einschließlich der Planung. Die nächste Initiative aus Queue startet, nachdem der aktuelle Pull Request gemergt wurde. Taiga verschiebt Einträge nicht automatisch aus Backlog oder Todo nach Queue.

Die Platzierung in Queue ist wichtig. Sie setzt das Warten auf noch nicht abgeschlossene Abhängigkeiten außer Kraft. Bestätigen Sie vor der Einreihung der Mitarbeiterselbstbedienung, dass die Identitätsgrundlage besteht oder der gewählte Umfang sie korrekt schafft.

Prüfen Sie den detaillierten Plan

Die Planung liest Repository, Produktdokumente, Richtlinien, Anweisungen und Deployment-Kontext. Prüfen Sie den Plan anhand des tatsächlichen Nutzerergebnisses und der Umgebung.

Prüfen Sie beim Ausstattungsdienst drei Zugriffsfälle. Ein Mitarbeiter sieht seine Anfrage. Ein anderer Mitarbeiter kann sie nicht sehen. Eine Führungskraft behält den vorgesehenen Prüfzugriff. Berücksichtigen Sie Datenmigration und betriebliche Auswirkungen, wenn die Implementierung sie verändert.

Ist Build on its own by default ausgeschaltet, wartet der fertige Plan auf Ihre Entscheidung. Approve startet den Build als genehmigende Person und im Rahmen ihrer Berechtigungen. Reject nutzt Ihr Feedback für eine neue Planung. Eine Initiative kann eine eigene Einstellung haben.

Nutzen Sie die richtige Aufzeichnung für die nächste Entscheidung

Pläne sind versioniert. Ein Lauf hält fest, welchen Plan er ausgeführt hat. Ändert sich der gewünschte Ansatz, prüfen Sie die Initiative und die passende Aktion zur Neuplanung. Nutzen Sie den Lauf, um den vorherigen Versuch zu untersuchen.

Ein Build, ein gemergter Pull Request und ein Produktionsrelease sind unterschiedliche Zustände. Halten Sie Abnahmenachweise und Deployment-Verantwortung während der Arbeit sichtbar. Fahren Sie mit den Autonomy-Einstellungen fort.