Prontidão (DoR/DoD)

DoR — Definition of Ready: o que precisa estar pronto para o trabalho começar. Existe para acabar com a demanda que entra em execução e volta em dois dias porque faltava o acesso, o dado ou a decisão.
DoD — Definition of Done: o que precisa estar feito para o trabalho ser considerado terminado. Existe para acabar com o "terminei" que ainda não foi testado, documentado nem comunicado.

Os dois são a mesma ideia aplicada nas duas pontas: escrever o combinado antes, para não discutir depois. E os dois são por ETAPA do quadro — cada coluna pode ter o seu.

Duas listas que o time combina uma vez e usa sempre: o que precisa estar pronto para uma demanda PODER começar (Definition of Ready) e o que precisa estar pronto para ela ser considerada TERMINADA (Definition of Done). É o que evita a demanda que entra na sprint sem escopo e a que "está pronta" mas ninguém testou.

Aqui você cadastra um item do combinado de prontidão do time (DoR/DoD): em qual etapa ele vale, se é condição para ENTRAR ou para SAIR dela, se vale só para um tipo de demanda, o texto do combinado, se bloqueia a saída da etapa, a ordem de exibição e se está ativo. É o checklist de qualidade do fluxo, item a item.

O campo "Entrar ou sair" define de que lado da etapa o combinado mora. Item de ENTRADA é Definition of Ready: o que precisa estar pronto ANTES de a demanda entrar naquela etapa ("critérios de aceite escritos", por exemplo, antes de entrar em execução). Item de SAÍDA é Definition of Done: o que precisa estar feito para a demanda SAIR da etapa ("code review aprovado"). O campo "Só para o tipo" restringe o item a um tipo de demanda — um combinado de bug não precisa valer para melhoria.

Você escreve o item aqui uma vez; ele é copiado para o checklist da própria demanda quando ela entra na etapa, com o rótulo entre colchetes (por exemplo [DoD Em execução] testes automatizados verdes).

Repare que não existe uma segunda lista para marcar: quem trabalha marca no mesmo lugar de sempre, dentro da demanda, e a conferência lê dali. Uma segunda lista significaria, na prática, uma lista abandonada.

É a parte mais contraintuitiva. Ao arrastar um card de uma coluna para outra, o sistema confere o DoD da coluna de onde ele está saindo — porque a pergunta é "isto pode ser dado por encerrado aqui?".

O DoR nunca bloqueia. Ele entra como conferência de entrada, aparece no checklist e serve de lembrete. Se você marcar o bloqueio num item de DoR, o sistema desliga e avisa.

Três desfechos possíveis ao mover: nada pendente, e o card passa; pendência sem bloqueio, e o card passa com aviso listando o que ficou; pendência com bloqueio, e o card volta ao lugar. Basta um item bloqueante em aberto para barrar.

Gate imposto antes do acordo produz desvio, não qualidade: o time aprende a burlar o quadro. Escreva os itens, deixe o time conviver com eles algumas semanas e ligue o bloqueio só naquilo que virou hábito e ainda assim escapa.

Dois limites honestos do gate, para você não confiar demais nele: ele só age no arrastar do quadro — mudar o status pelo formulário da demanda, em lote, ou por "finalizar" não passa por aqui. E, se a conferência falhar por erro técnico, o movimento passa. Um gate que trava a operação por falha de infraestrutura é pior do que o problema que ele evita.

O item e a marcação se reconhecem pelo texto do rótulo. Ao editar a descrição de um combinado (ou renomear a etapa, que entra no rótulo), o sistema deixa de reconhecer o que já estava marcado: a marcação antiga continua visível no histórico da demanda e o item novo entra pendente.

É o comportamento correto — mudou a regra, a conferência é refeita —, mas planeje a mudança: fazer isso no meio da sprint devolve pendência para o quadro inteiro.

Ao salvar uma visão pelo botão Visões, ela guarda quatro coisas: o texto da busca, os filtros aplicados, quais colunas aparecem (e em que ordem) e por qual coluna a lista está ordenada. Aplicar a visão restaura tudo de uma vez — inclusive zerando a ordenação e a página em que você estava, para o resultado ser exatamente o que a visão descreve. Visões salvas antes desta versão continuam válidas: o que elas não guardaram simplesmente não muda ao aplicar.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

A chave "Bloqueia a saída" separa o combinado orientativo do combinado com dente: item bloqueante segura a demanda na etapa enquanto não for cumprido; item não bloqueante aparece como lembrete do acordo do time, mas não impede o avanço. Use a trava com parcimônia — bloquear tudo transforma o fluxo em burocracia e convida o time a marcar itens sem olhar; o bloqueio vale para o que realmente não pode passar sem conferência, como "testes executados" antes de concluir.

No painel de atividade do registro, cada anotação tem "Virar demanda". O clique cria um ticket com o texto da anotação, quem a escreveu e o link deste registro — nada é redigitado. Use quando a anotação é um pedido de ação ("alguém precisa revisar isto"); a anotação continua onde estava. O botão só aparece com o registro já salvo; sessão somente-leitura (demonstração) não cria.

Só se você deixar o tipo em branco — aí ele é uma regra geral. Preenchendo o tipo, o item passa a valer apenas para aquele tipo de demanda (bug, melhoria, suporte...).

Cuidado com uma sutileza: demanda sem tipo definido recebe apenas as regras gerais. Se o seu DoD importante está preso a um tipo, a demanda sem tipo escapa dele.

Abra o registro e olhe a Linha do tempo, à direita: ela mostra cada alteração como "de um valor para outro", com a pessoa e a data. Quando há muita alteração, use os dois filtros no topo da linha do tempo — um por campo, outro por pessoa. A procura é feita no banco, então alteração antiga aparece do mesmo jeito. Você também pode perguntar ao Tenkai: "quem mudou o contrato 482?".