Comece um novo produto na Taiga

Prepare um resultado claro

Este cenário usa um serviço fictício de solicitação de equipamentos. Um gerente registra a solicitação de equipamento de um funcionário e a decisão. O autosserviço de funcionários é uma extensão posterior. Use registros sintéticos durante o aprendizado. O cenário não autoriza dados reais de pessoal.

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

Escreva um limite inicial: a primeira versão registra solicitações e decisões. Não encomenda equipamentos, não aprova despesas automaticamente nem altera registros da folha de pagamento.

Escolha como o produto começa

Escolha Start from scratch para este novo serviço. Use Import codebase quando um repositório existente deve definir o ponto de partida. A importação é uma escolha feita na criação do produto; tome essa decisão de forma consciente.

A criação também pergunta se a Taiga escreve Infrastructure code e CI/CD pipelines. São responsabilidades separadas. Se a equipe de plataforma já fornece uma dessas partes, desative a geração correspondente e descreva como o trabalho é feito hoje.

Por exemplo: “Nossa plataforma implanta imagens de contêiner revisadas pelo pipeline existente do repositório. Use sua identidade de carga de trabalho e a configuração do ambiente.” Confirme a precisão dessa descrição antes de depender dela.

Coloque o contexto antes da conversa

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

Para o serviço de equipamentos, o contexto útil inclui o método de identidade dos funcionários, serviços de dados aprovados e a regra de acesso dos gerentes. Informe explicitamente as questões não resolvidas. Não invente um prazo de retenção para preencher um formulário.

Depois, descreva o serviço na conversa. Explique usuários, resultado desejado, restrições e o que fica fora do escopo. A especificação é salva como rascunho durante o trabalho.

Revise e publique a intenção

Leia a especificação procurando premissas que mudariam a implementação. Neste cenário, verifique se um gerente pode ver todas as solicitações de funcionários ou apenas as da sua equipe. Essa diferença afeta permissões, fluxo de dados e testes.

Publique a especificação quando o conteúdo estiver adequado para o trabalho posterior. Alterações em rascunho não substituem a versão publicada até uma nova publicação. Prossiga pelos documentos obrigatórios e revise suas premissas. A lição sobre Discovery explica dependências e documentos desatualizados.

Depois que os oito documentos obrigatórios estiverem publicados, conclua Discovery e planeje as iniciativas. A sequência gerada é uma proposta que você pode inspecionar e alterar.

Conecte o destino real de entrega

Conecte o repositório antes do planejamento detalhado das iniciativas. Defina os ambientes pretendidos ao mesmo tempo, embora um ambiente não seja obrigatório para começar a planejar.

Uma descrição de ambiente não concede acesso à nuvem. Seu pipeline executa o deployment. Verifique com a equipe 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 um trabalho que possa ser revisado, com base no ambiente real de entrega. Pratique a sequência de decisões na simulação de fluxo da Taiga.