Start een nieuw product in Taiga

Bereid één duidelijk resultaat voor

Dit scenario gebruikt een fictieve service voor materiaalaanvragen. Een manager registreert de materiaalaanvraag van een medewerker en de beslissing. Zelfbediening voor medewerkers is een latere uitbreiding. Gebruik synthetische records tijdens het leren. Het scenario geeft geen toestemming voor echte personeelsgegevens.

Bevestig vóór het aanmaken van het product dat de organisatie en relevante gedeelde context zijn ingericht. Benoem de persoon die verantwoordelijk is voor het serviceresultaat en het team dat de beheeromgeving beheert.

Beschrijf een eerste afbakening: de eerste versie registreert aanvragen en beslissingen. Ze bestelt geen materiaal, keurt uitgaven niet automatisch goed en wijzigt geen salarisadministratie.

Kies hoe het product begint

Kies Start from scratch voor deze nieuwe service. Gebruik Import codebase wanneer een bestaande repository het vertrekpunt moet bepalen. Importeren is een keuze bij het aanmaken van het product, dus maak die bewust.

Bij het aanmaken wordt ook gevraagd of Taiga Infrastructure code en CI/CD pipelines schrijft. Dit zijn afzonderlijke verantwoordelijkheden. Als uw platformteam al een deel verzorgt, schakel die generatieoptie uit en beschrijf hoe het werk nu gebeurt.

Bijvoorbeeld: ‘Ons platform deployt gereviewde containerimages via de bestaande repositorypipeline. Gebruik de workloadidentiteit en omgevingsconfiguratie daarvan.’ Bevestig dat deze beschrijving klopt voordat u erop vertrouwt.

Plaats context vóór het gesprek

Discovery begint met Context. Voeg vóór het gesprek relevant productreferentiemateriaal en vaste instructies toe. Plaats regels die meerdere producten delen op organisatie- of factoryniveau.

Voor de materiaalservice omvat bruikbare context de identiteitsmethode voor medewerkers, goedgekeurde gegevensdiensten en de regel voor managerstoegang. Benoem onbeantwoorde vragen expliciet. Verzin geen bewaartermijn om een formulier te vullen.

Beschrijf daarna de service in het gesprek. Leg gebruikers, gewenst resultaat, beperkingen en uitgesloten scope uit. De specificatie wordt tijdens het werken als concept opgeslagen.

Review en publiceer de intentie

Lees de specificatie op aannames die de implementatie zouden veranderen. Controleer in dit scenario of een manager alle medewerkersaanvragen kan zien of alleen die van het eigen team. Dat verschil beïnvloedt rechten, gegevensstromen en tests.

Publiceer de specificatie wanneer de inhoud geschikt is voor vervolgwerk. Conceptwijzigingen vervangen de gepubliceerde versie pas wanneer u opnieuw publiceert. Doorloop de vereiste documenten en review hun aannames. De Discovery-les legt afhankelijkheden en verouderde documenten uit.

Rond Discovery af nadat alle acht vereiste documenten zijn gepubliceerd en plan de initiatieven. De gegenereerde volgorde is een voorstel dat u kunt bekijken en aanpassen.

Verbind het werkelijke leveringsdoel

Koppel de repository vóór gedetailleerde initiatiefplanning. Definieer tegelijkertijd de beoogde omgevingen, ook al is een omgeving niet vereist om met plannen te beginnen.

Een omgevingsbeschrijving verleent geen cloudtoegang. Uw pipeline voert deployment uit. Controleer de repositorybranch, identiteit, infrastructuurverantwoordelijkheid en vereiste inrichtingstaken met het verantwoordelijke team.

Het bruikbare resultaat van dit scenario is een gedefinieerd product en reviewbaar werk op basis van de echte leveringsomgeving. Oefen de beslisvolgorde in de Taiga-workflowsimulatie.