Start et nyt produkt i Taiga

Forbered ét klart resultat

Scenariet bruger en fiktiv tjeneste til udstyrsbestillinger. En leder registrerer en medarbejders ønske om udstyr og beslutningen. Selvbetjening for medarbejdere er en senere udvidelse. Brug syntetiske poster under læring. Scenariet giver ikke tilladelse til rigtige personaledata.

Bekræft før oprettelsen, at organisationen og den relevante fælles kontekst er sat op. Identificér den person, der ejer tjenestens resultat, og det team, der ejer driftsmiljøet.

Skriv en indledende afgrænsning: Første version registrerer anmodninger og beslutninger. Den bestiller ikke udstyr, godkender ikke automatisk udgifter og ændrer ikke lønoplysninger.

Vælg produktets udgangspunkt

Vælg Start from scratch for denne nye tjeneste. Brug Import codebase, når et eksisterende repository skal definere udgangspunktet. Import vælges ved produktoprettelse, så vælg bevidst.

Oprettelsen spørger også, om Taiga skriver Infrastructure code og CI/CD pipelines. Det er særskilte ansvarsområder. Hvis platformteamet allerede leverer en del, skal den pågældende generering slås fra, og den nuværende arbejdsgang beskrives.

For eksempel: »Vores platform udruller reviewede containerimages gennem den eksisterende repositorypipeline. Brug dens workloadidentitet og miljøkonfiguration.« Bekræft beskrivelsens rigtighed, før I baserer jer på den.

Tilføj kontekst før samtalen

Discovery starter med Context. Tilføj relevant produktreferencemateriale og stående instruktioner før samtalen. Placér regler, der deles af flere produkter, på organisations- eller fabriksniveau.

For udstyrstjenesten er nyttig kontekst medarbejdernes identitetsmetode, godkendte datatjenester og reglen for lederadgang. Angiv uafklarede spørgsmål tydeligt. Opfind ikke en opbevaringsperiode for at udfylde en formular.

Beskriv derefter tjenesten i samtalen. Forklar brugere, ønsket resultat, begrænsninger og det, der ligger uden for omfanget. Specifikationen gemmes som kladde under arbejdet.

Gennemgå og publicér hensigten

Læs specifikationen for antagelser, der ville ændre implementeringen. Kontrollér i scenariet, om en leder kan se alle medarbejderes anmodninger eller kun sit teams. Forskellen påvirker tilladelser, datastrømme og tests.

Publicér specifikationen, når indholdet egner sig til efterfølgende arbejde. Kladdeændringer erstatter ikke den publicerede version, før du publicerer igen. Fortsæt gennem de påkrævede dokumenter, og gennemgå deres antagelser. Discovery-lektionen forklarer afhængigheder og forældede dokumenter.

Afslut Discovery, når alle otte påkrævede dokumenter er publiceret, og planlæg initiativerne. Den genererede rækkefølge er et forslag, du kan undersøge og ændre.

Forbind det faktiske leverancemål

Forbind repositoryet før detaljeret planlægning af initiativer. Definér samtidig de tilsigtede miljøer, selv om et miljø ikke kræves for at starte planlægning.

En miljøbeskrivelse giver ikke cloudadgang. Din pipeline udfører udrulningen. Kontrollér repositorybranch, identitet, infrastrukturejerskab og nødvendige opsætningsopgaver med det ansvarlige team.

Scenariets nyttige resultat er et defineret produkt og arbejde, der kan gennemgås og er forankret i det faktiske leverancemiljø. Øv beslutningsforløbet i simuleringen af Taigas arbejdsgang.