Avvia un nuovo prodotto in Taiga

Prepara un risultato chiaro

Questo scenario usa un servizio fittizio di richieste di attrezzature. Un manager registra la richiesta di un dipendente e la decisione. Il self-service per i dipendenti è un’estensione successiva. Usa record sintetici durante l’apprendimento. Lo scenario non autorizza dati reali del personale.

Prima di creare il prodotto, conferma che organizzazione e contesto condiviso pertinente siano configurati. Individua la persona responsabile del risultato del servizio e il team responsabile dell’ambiente operativo.

Scrivi un confine iniziale: la prima versione registra richieste e decisioni. Non ordina attrezzature, non approva spese automaticamente e non modifica record delle paghe.

Scegli come avviare il prodotto

Scegli Start from scratch per questo nuovo servizio. Usa Import codebase quando un repository esistente deve definire il punto di partenza. L’importazione si sceglie alla creazione del prodotto: decidi consapevolmente.

La creazione chiede anche se Taiga scrive Infrastructure code e CI/CD pipelines. Sono responsabilità separate. Se il team di piattaforma fornisce già una parte, disattiva quella opzione di generazione e descrivi come viene svolto oggi il lavoro.

Per esempio: «La nostra piattaforma distribuisce immagini container revisionate tramite la pipeline esistente del repository. Usa la sua identità del carico di lavoro e la configurazione degli ambienti». Conferma che la descrizione sia accurata prima di farci affidamento.

Inserisci il contesto prima della conversazione

Discovery inizia con Context. Aggiungi materiale di riferimento pertinente al prodotto e istruzioni permanenti prima della conversazione. Colloca le regole condivise tra più prodotti a livello di organizzazione o factory.

Per il servizio di attrezzature, il contesto utile include metodo di identità dei dipendenti, servizi dati approvati e regola di accesso dei manager. Indica esplicitamente le domande irrisolte. Non inventare un periodo di conservazione per completare un modulo.

Descrivi poi il servizio nella conversazione. Spiega utenti, risultato desiderato, restrizioni e ciò che è fuori ambito. La specifica viene salvata come bozza durante il lavoro.

Revisiona e pubblica l’intento

Leggi la specifica cercando ipotesi che cambierebbero l’implementazione. In questo scenario, verifica se un manager possa vedere tutte le richieste dei dipendenti o solo quelle del proprio team. La differenza influisce su permessi, flussi di dati e test.

Pubblica la specifica quando il contenuto è adatto al lavoro successivo. Le modifiche in bozza non sostituiscono la versione pubblicata finché non pubblichi di nuovo. Prosegui con i documenti richiesti e revisionane le ipotesi. La lezione su Discovery spiega dipendenze e documenti non aggiornati.

Dopo aver pubblicato tutti gli otto documenti richiesti, completa Discovery e pianifica le iniziative. La sequenza generata è una proposta che puoi esaminare e modificare.

Collega la destinazione reale della consegna

Collega il repository prima della pianificazione dettagliata delle iniziative. Definisci contemporaneamente gli ambienti previsti, anche se un ambiente non è necessario per iniziare la pianificazione.

La descrizione dell’ambiente non concede accesso cloud. La pipeline esegue il deployment. Verifica con il team responsabile branch del repository, identità, responsabilità infrastrutturali e attività di configurazione richieste.

Il risultato utile dello scenario è un prodotto definito e lavoro revisionabile basato sull’ambiente reale di consegna. Esercitati nella sequenza decisionale con la simulazione del flusso Taiga.