Comece um novo produto na Taiga

Prepare um resultado claro

Este cenário usa um serviço fictício de pedidos de equipamento. Um gestor regista o pedido de equipamento de um trabalhador e a decisão. O autosserviço para os trabalhadores é uma extensão posterior. Use registos sintéticos durante a aprendizagem. O cenário não autoriza a utilização de dados reais de pessoal.

Antes de criar o produto, confirme que a organização e o contexto partilhado relevante estão configurados. Identifique a pessoa responsável pelo resultado do serviço e a equipa responsável pelo ambiente de operação.

Escreva um limite inicial: a primeira versão regista pedidos e decisões. Não encomenda equipamento, não aprova despesas automaticamente nem altera registos de processamento salarial.

Escolha como o produto começa

Escolha Start from scratch para este novo serviço. Use Import codebase quando um repositório existente deva definir o ponto de partida. A importação é uma escolha feita na criação do produto. Tome-a de forma deliberada.

A criação pergunta também se a Taiga escreve Infrastructure code e CI/CD pipelines. São responsabilidades separadas. Se a equipa de plataforma já fornece uma parte, desative essa opção de geração e descreva como o trabalho é feito atualmente.

Por exemplo: «A nossa plataforma faz o deployment de imagens de contentor revistas através da pipeline existente no repositório. Use a respetiva identidade de workload e configuração de ambiente.» Confirme que esta descrição é exata antes de contar com ela.

Coloque o contexto antes da conversa

O Discovery começa com Context. Acrescente material de referência relevante para o produto e instruções permanentes antes da conversa. Coloque as regras partilhadas por vários produtos ao nível da organização ou da factory.

Para o serviço de equipamento, o contexto útil inclui o método de identidade dos trabalhadores, os serviços de dados aprovados e a regra de acesso dos gestores. Indique explicitamente as perguntas por resolver. Não invente um prazo de conservação para preencher um formulário.

Descreva depois o serviço na conversa. Explique os utilizadores, o resultado pretendido, as restrições e o que fica fora do âmbito. A especificação é guardada como rascunho durante o trabalho.

Reveja e publique a intenção

Leia a especificação à procura de pressupostos que alterem a implementação. Neste cenário, verifique se um gestor pode ver os pedidos de todos os trabalhadores ou apenas os da sua equipa. A diferença afeta as permissões, o fluxo de dados e os testes.

Publique a especificação quando o conteúdo for adequado para o trabalho seguinte. As alterações ao rascunho não substituem a versão publicada até voltar a publicar. Prossiga pelos documentos obrigatórios e reveja os seus pressupostos. A lição sobre Discovery explica as dependências e os documentos desatualizados.

Depois de publicar os oito documentos obrigatórios, conclua o Discovery e planeie as iniciativas. A sequência gerada é uma proposta que pode examinar e alterar.

Ligue o destino real da entrega

Ligue o repositório antes do planeamento detalhado das iniciativas. Defina os ambientes previstos na mesma altura, embora não seja necessário ter um ambiente para começar a planear.

A descrição de um ambiente não concede acesso cloud. É a sua pipeline que executa o deployment. Verifique com a equipa responsável a branch do repositório, a identidade, a responsabilidade pela infraestrutura e as tarefas de configuração necessárias.

O resultado útil deste cenário é um produto definido e trabalho que pode ser revisto, assente no ambiente real de entrega. Pratique a sequência de decisões na simulação do fluxo da Taiga.