Starta en ny produkt i Taiga

Förbered ett tydligt utfall

Scenariot använder en fiktiv tjänst för utrustningsförfrågningar. En chef registrerar en anställds förfrågan om utrustning och beslutet. Självservice för anställda är en senare utökning. Använd syntetiska poster under lärandet. Scenariot ger inte tillstånd att använda verkliga personaldata.

Bekräfta att organisationen och relevant gemensam kontext är konfigurerade innan produkten skapas. Identifiera personen som ansvarar för tjänstens utfall och teamet som ansvarar för driftmiljön.

Skriv en första avgränsning: den första versionen registrerar förfrågningar och beslut. Den beställer inte utrustning, godkänner inte utgifter automatiskt och ändrar inte löneposter.

Välj hur produkten börjar

Välj Start from scratch för den nya tjänsten. Använd Import codebase när ett befintligt repository ska definiera startpunkten. Import är ett val vid produktskapandet, så gör det medvetet.

När produkten skapas frågas också om Taiga ska skriva Infrastructure code och CI/CD pipelines. Det är separata ansvar. Stäng av motsvarande genereringsval och beskriv dagens arbetssätt om plattformsteamet redan tillhandahåller en del.

Till exempel: ”Vår plattform driftsätter granskade containeravbildningar genom repositoryts befintliga pipeline. Använd dess arbetslastidentitet och miljökonfiguration.” Bekräfta att beskrivningen stämmer innan du förlitar dig på den.

Lägg in kontext före samtalet

Discovery börjar med Context. Lägg till relevant referensmaterial om produkten och stående instruktioner före samtalet. Placera regler som flera produkter delar på organisations- eller fabriksnivå.

Användbar kontext för utrustningstjänsten omfattar metoden för anställdas identitet, godkända datatjänster och regeln för chefers åtkomst. Ange olösta frågor uttryckligt. Hitta inte på en lagringstid för att fylla i ett formulär.

Beskriv sedan tjänsten i samtalet. Förklara användare, önskat resultat, begränsningar och vad som ligger utanför omfånget. Specifikationen sparas som utkast medan du arbetar.

Granska och publicera avsikten

Läs specifikationen och leta efter antaganden som skulle ändra implementationen. Kontrollera i scenariot om en chef kan se alla anställdas förfrågningar eller bara förfrågningar i det egna teamet. Skillnaden påverkar behörigheter, dataflöde och tester.

Publicera specifikationen när innehållet är lämpligt för efterföljande arbete. Utkaständringar ersätter inte den publicerade versionen förrän du publicerar igen. Fortsätt genom de obligatoriska dokumenten och granska deras antaganden. Lektionen om Discovery förklarar beroenden och inaktuella dokument.

Avsluta Discovery och planera initiativen när alla åtta obligatoriska dokument är publicerade. Den genererade ordningen är ett förslag som du kan granska och ändra.

Koppla den verkliga leveransmiljön

Anslut repositoryt före detaljerad planering av initiativ. Definiera de avsedda miljöerna samtidigt, även om en miljö inte krävs för att börja planera.

En miljöbeskrivning ger inte molnåtkomst. Din pipeline utför driftsättningen. Kontrollera repositorybranch, identitet, infrastrukturansvar och nödvändiga konfigurationsuppgifter med ansvarigt team.

Det användbara utfallet av scenariot är en definierad produkt och granskningsbart arbete förankrat i den verkliga leveransmiljön. Öva beslutsföljden i simuleringen av Taigas arbetsflöde.