Ein neues Produkt in Taiga starten

Bereiten Sie ein klares Ergebnis vor

Dieses Szenario nutzt einen fiktiven Dienst für Ausstattungsanfragen. Eine Führungskraft erfasst den Ausstattungswunsch eines Mitarbeiters und die Entscheidung dazu. Selbstbedienung durch Mitarbeiter ist eine spätere Erweiterung. Nutzen Sie beim Lernen synthetische Datensätze. Das Szenario autorisiert keine echten Personaldaten.

Bestätigen Sie vor dem Anlegen des Produkts, dass die Organisation und der relevante gemeinsame Kontext eingerichtet sind. Benennen Sie die Person, die das Dienstergebnis verantwortet, und das Team, das die Betriebsumgebung verantwortet.

Formulieren Sie eine erste Grenze: Die erste Version erfasst Anfragen und Entscheidungen. Sie bestellt keine Ausstattung, genehmigt keine Ausgaben automatisch und verändert keine Gehaltsdaten.

Wählen Sie den Startweg des Produkts

Wählen Sie Start from scratch für diesen neuen Dienst. Nutzen Sie Import codebase, wenn ein bestehendes Repository den Ausgangspunkt bestimmen soll. Der Import wird beim Anlegen des Produkts gewählt. Treffen Sie diese Wahl bewusst.

Beim Anlegen wird auch gefragt, ob Taiga Infrastructure code und CI/CD pipelines schreibt. Das sind getrennte Verantwortlichkeiten. Wenn Ihr Plattformteam einen Teil bereits bereitstellt, deaktivieren Sie diese Generierungsoption und beschreiben Sie das bisherige Verfahren.

Zum Beispiel: „Unsere Plattform stellt geprüfte Container-Images über die bestehende Repository-Pipeline bereit. Nutzen Sie deren Workload-Identität und Umgebungskonfiguration.“ Bestätigen Sie die Richtigkeit dieser Beschreibung, bevor Sie sich darauf verlassen.

Stellen Sie den Kontext vor das Gespräch

Discovery beginnt mit Context. Ergänzen Sie relevante Produktreferenzen und dauerhafte Anweisungen vor dem Gespräch. Hinterlegen Sie Regeln für mehrere Produkte auf Organisations- oder Factory-Ebene.

Für den Ausstattungsdienst gehören dazu die Methode zur Mitarbeiteridentifikation, freigegebene Datendienste und die Regel für den Zugriff von Führungskräften. Benennen Sie offene Fragen ausdrücklich. Erfinden Sie keine Aufbewahrungsfrist, um ein Formular zu vervollständigen.

Beschreiben Sie anschließend den Dienst im Gespräch. Erklären Sie Nutzer, gewünschtes Ergebnis, Einschränkungen und ausgeschlossene Funktionen. Während der Arbeit wird die Spezifikation als Entwurf gespeichert.

Prüfen und veröffentlichen Sie die Zielbeschreibung

Lesen Sie die Spezifikation auf Annahmen, die die Implementierung verändern würden. Prüfen Sie hier, ob eine Führungskraft alle Mitarbeiteranfragen oder nur die ihres Teams sehen darf. Dieser Unterschied beeinflusst Berechtigungen, Datenfluss und Tests.

Veröffentlichen Sie die Spezifikation, wenn ihr Inhalt für nachgelagerte Arbeit geeignet ist. Entwurfsänderungen ersetzen die veröffentlichte Version erst nach einer erneuten Veröffentlichung. Bearbeiten Sie die erforderlichen Dokumente weiter und prüfen Sie deren Annahmen. Die Discovery-Lektion erklärt Abhängigkeiten und veraltete Dokumente.

Wenn alle acht erforderlichen Dokumente veröffentlicht sind, schließen Sie Discovery ab und planen Sie die Initiatives. Die erzeugte Reihenfolge ist ein Vorschlag, den Sie prüfen und ändern können.

Verbinden Sie das tatsächliche Lieferziel

Verbinden Sie das Repository vor der detaillierten Initiative-Planung. Definieren Sie gleichzeitig die vorgesehenen Umgebungen, auch wenn keine Umgebung nötig ist, um die Planung zu starten.

Eine Umgebungsbeschreibung gewährt keinen Cloud-Zugriff. Ihre Pipeline führt das Deployment aus. Prüfen Sie Repository-Branch, Identität, Infrastrukturverantwortung und erforderliche Einrichtungsaufgaben mit dem zuständigen Team.

Das nützliche Ergebnis dieses Szenarios ist ein definiertes Produkt mit prüfbarer Arbeit, die auf seiner tatsächlichen Lieferumgebung beruht. Üben Sie die Entscheidungsfolge in der Taiga-Workflow-Simulation.