Transforme um resultado em uma iniciativa

Descreva o resultado antes das etapas

O serviço fictício de equipamentos precisa de autosserviço de funcionários. Um pedido útil informa o resultado: “Um funcionário autenticado pode criar uma solicitação e ver apenas as próprias solicitações.”

Explique por que isso importa: hoje, os gerentes registram solicitações para os funcionários. Defina o escopo: criação de solicitações, exibição de status, verificações de acesso e evidências desses comportamentos. Exclua compras automáticas e mudanças na regra de aprovação dos gerentes.

Não prescreva edições de arquivos antes de inspecionar o repositório. A iniciativa registra a intenção; o planejamento detalhado transforma essa intenção em etapas de implementação.

Revise o que o pedido produziu

A Taiga usa o pedido e o contexto do produto para criar uma iniciativa ou um conjunto ordenado de iniciativas. Novos trabalhos chegam a Backlog. Um pedido maior pode precisar de várias alterações que possam ser revisadas separadamente.

Leia o estado final gerado, Why e Scope. Verifique se o comportamento exigido foi mantido e as exclusões foram respeitadas. Se uma iniciativa existente já cobrir o pedido, a Taiga pode indicá-la em vez de criar uma duplicata.

Um pedido bloqueado por uma política publicada precisa do caminho de decisão definido por essa política. Leia a explicação e resolva o conflito por esse caminho. Não reescreva o pedido apenas para esconder a ação proibida.

Trate o quadro como uma sequência de execução

A Taiga trabalha em uma iniciativa por vez por produto, incluindo o planejamento. Inicia a próxima iniciativa na fila depois do merge do pull request atual. Não move automaticamente itens de Backlog ou Todo para Queue.

Colocar uma iniciativa em Queue importa. Isso dispensa a espera por dependências ainda não concluídas. Antes de colocar o autosserviço de funcionários na fila, confirme que a base de identidade existe ou que o escopo escolhido a estabelece corretamente.

Inspecione o plano detalhado

O planejador lê o repositório, os documentos do produto, as políticas, as instruções e o contexto de deployment. Confira o plano diante do resultado real para o usuário e do ambiente.

Para o serviço de equipamentos, verifique três casos de acesso. Um funcionário vê sua solicitação. Outro funcionário não consegue vê-la. Um gerente mantém o acesso pretendido de revisão. Inclua migração de dados e efeitos operacionais se a implementação os alterar.

Se Build on its own by default estiver desativado, o plano concluído espera sua decisão. Approve inicia o build em nome da pessoa que aprova, sujeito às permissões dela. Reject usa seu feedback para planejar novamente. Uma iniciativa pode ter sua própria configuração.

Use o registro certo para a próxima decisão

Os planos são versionados. Uma execução registra qual plano executou. Se a abordagem pretendida mudar, revise a iniciativa e a ação adequada de replanejamento. Use a execução para inspecionar a tentativa anterior.

Um build, um pull request com merge concluído e um release em produção são estados diferentes. Mantenha visíveis as evidências de aceitação e a responsabilidade pelo deployment conforme o trabalho avançar. Continue com configurações de autonomia.