Transforme um resultado numa iniciativa

Descreva o resultado antes dos passos

O serviço fictício de equipamento precisa de autosserviço para os trabalhadores. Um pedido útil indica o resultado: «Um trabalhador autenticado pode criar um pedido e ver apenas os seus próprios pedidos.»

Explique a importância: atualmente, os gestores introduzem os pedidos pelos trabalhadores. Defina o âmbito: criação de pedidos, apresentação do estado, verificações de acesso e evidências desses comportamentos. Exclua compras automáticas e alterações à regra de aprovação pelos gestores.

Não prescreva edições de ficheiros antes de examinar o repositório. A iniciativa regista a intenção. O planeamento detalhado transforma essa intenção em passos de implementação.

Reveja 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. O trabalho novo chega a Backlog. Um pedido maior pode exigir várias alterações que possam ser revistas de forma independente.

Leia o estado final gerado, Why e Scope. Verifique que o comportamento necessário foi preservado e que as exclusões foram respeitadas. Se uma iniciativa existente já abranger o pedido, a Taiga pode identificá-la em vez de criar um duplicado.

Um pedido bloqueado por uma política publicada precisa do percurso de decisão definido nessa política. Leia a explicação e resolva o conflito por esse percurso. 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 numa iniciativa de cada vez por produto, incluindo o planeamento. Inicia a iniciativa seguinte na fila depois de o pull request atual ser integrado por merge. Não move automaticamente elementos de Backlog ou Todo para Queue.

A colocação em Queue é relevante. Sobrepõe-se à espera por dependências inacabadas. Antes de colocar o autosserviço para os trabalhadores na fila, confirme que a base de identidade existe ou que o âmbito escolhido a estabelece corretamente.

Examine o plano detalhado

O planeador lê o repositório, os documentos do produto, as políticas, as instruções e o contexto de deployment. Verifique o plano face ao resultado real para o utilizador e ao ambiente.

No serviço de equipamento, verifique três casos de acesso. Um trabalhador vê o seu pedido. Outro trabalhador não o consegue ver. Um gestor mantém o acesso de revisão pretendido. Inclua a migração de dados e os efeitos operacionais se a implementação os alterar.

Se Build on its own by default estiver desativado, o plano concluído fica à espera da sua decisão. Approve inicia a implementação em nome da pessoa que aprova, sujeita às permissões dessa pessoa. Reject usa os seus comentários para planear novamente. Uma iniciativa pode ter a sua própria definição.

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

Os planos têm versões. Uma execução regista o plano que executou. Se a abordagem pretendida mudar, reveja a iniciativa e a ação de replaneamento adequada. Use a execução para examinar a tentativa anterior.

Uma implementação, um pull request integrado por merge e um lançamento em produção são estados diferentes. Mantenha visíveis as evidências de aceitação e a responsabilidade pelo deployment à medida que o trabalho avança. Prossiga para as definições de autonomia.