Start et nytt produkt i Taiga

Forbered ett tydelig resultat

Dette scenarioet bruker en fiktiv tjeneste for utstyrsforespørsler. En leder registrerer en ansatts forespørsel om utstyr og beslutningen. Selvbetjening for ansatte er en senere utvidelse. Bruk syntetiske opplysninger under læringen. Scenarioet gir ikke tillatelse til å bruke reelle personaldata.

Før produktet opprettes, bekrefter du at organisasjonen og relevant felles kontekst er satt opp. Identifiser personen som eier tjenestens resultat, og teamet som eier driftsmiljøet.

Skriv en første avgrensning: Den første versjonen registrerer forespørsler og beslutninger. Den bestiller ikke utstyr, godkjenner ikke utgifter automatisk og endrer ikke lønnsopplysninger.

Velg hvordan produktet starter

Velg Start from scratch for denne nye tjenesten. Bruk Import codebase når et eksisterende repository skal definere utgangspunktet. Import er et valg ved produktopprettelse, så ta det bevisst.

Ved opprettelse blir du også spurt om Taiga skriver Infrastructure code og CI/CD pipelines. Dette er separate ansvarsområder. Hvis plattformteamet allerede leverer en del, slår du av den genereringsmuligheten og beskriver hvordan arbeidet gjøres i dag.

For eksempel: «Plattformen vår ruller ut gjennomgåtte containerimager gjennom den eksisterende repository-pipelinen. Bruk arbeidslastidentiteten og miljøkonfigurasjonen derfra.» Bekreft at beskrivelsen er riktig før dere baserer dere på den.

Legg inn kontekst før samtalen

Discovery starter med Context. Legg til relevant referansemateriale for produktet og stående instruksjoner før samtalen. Legg regler som deles av flere produkter, på organisasjons- eller fabrikknivå.

For utstyrstjenesten omfatter nyttig kontekst identitetsmetoden for ansatte, godkjente datatjenester og regelen for ledertilgang. Oppgi uavklarte spørsmål tydelig. Ikke finn på en oppbevaringsperiode for å fylle ut et skjema.

Beskriv deretter tjenesten i samtalen. Forklar brukerne, ønsket resultat, begrensningene og hva som ligger utenfor omfanget. Spesifikasjonen lagres som utkast mens du arbeider.

Gjennomgå og publiser hensikten

Les spesifikasjonen for antakelser som ville endret implementasjonen. I dette scenarioet kontrollerer du om en leder kan se alle ansattes forespørsler eller bare forespørsler i eget team. Forskjellen påvirker tillatelser, dataflyt og tester.

Publiser spesifikasjonen når innholdet egner seg som grunnlag for videre arbeid. Endringer i utkast erstatter ikke den publiserte versjonen før du publiserer igjen. Fortsett gjennom de nødvendige dokumentene, og gjennomgå antakelsene deres. Discovery-leksjonen forklarer avhengigheter og utdaterte dokumenter.

Når alle åtte påkrevde dokumenter er publisert, fullfører du Discovery og planlegger initiativene. Den genererte rekkefølgen er et forslag du kan undersøke og endre.

Koble til det faktiske leveransemålet

Koble til repositoryet før detaljert initiativplanlegging. Definer de tiltenkte miljøene samtidig, selv om et miljø ikke er påkrevd for å starte planlegging.

En miljøbeskrivelse gir ikke skytilgang. Pipelinen utfører utrullingen. Kontroller repository-branchen, identiteten, infrastruktureierskapet og nødvendige oppsettsoppgaver med det ansvarlige teamet.

Det nyttige resultatet av scenarioet er et definert produkt og arbeid som kan gjennomgås, forankret i det faktiske leveransemiljøet. Øv på beslutningsrekkefølgen i simuleringen av Taiga-arbeidsflyten.