Pular para conteúdo

Política de Definição de Pronto e Feito

Esta política relaciona os critérios mínimos para definição de Pronto e Feito que devem ser adotados pelos times. Novos critérios podem ser adicionados, e itens indicados como "opcional" podem ser removidos conforme necessário.

Definição de Pronto (Definition of Ready - DOR)

Acordos do Time de Desenvolvimento para garantir que os itens do backlog do produto estejam aderentes e com detalhamento suficiente para desenvolvimento.

  • Histórias de Usuário precisam de alinhamento e priorização junto ao cliente;
  • Histórias de Usuário devem ser escritas no padrão definido no PPA;
  • Histórias de Usuário devem ser refinadas junto com ao time de desenvolvimento;
  • Histórias de Usuário devem ter pelo menos um critério de aceite;
  • Histórias de Usuário devem ter pontuação definida;
  • Histórias de Usuário devem ter Protótipo (Wireframe básico) quando for de Front-End (opcional);
  • Histórias de Usuário devem ter tabelas de dados quando houver campos/formulários que necessitam carregar dados de um banco Relacional ou Não Relacional (opcional);
  • Bugs, Erro ou Defeito precisam conter detalhamento suficiente para sua adequada correção. Poderá possuir todas as informações que constam em uma História de Usuário. O Analista de negócio / requisito pode decidir ou não realizar esse detalhamento.
  • Serão inseridas Labels de Melhorias quando for uma evolução de um Épico, Feature ou História de Usuário já entregue anteriormente. Isso é apenas para poder separar evolução do produto de inovação (opcional);
  • Deve se puxar para a Sprint atual apenas itens que estão da coluna PRONTO PARA DESENVOLVER.

Definição de Feito (Definition of Done - DOD)

Acordo com todos os membros do Time de Desenvolvimento. Deve ser genérico e aplicável a todos os itens do backlog do produto. Visa facilitar e deixar transparente o entendimento do que é considerado "Done" após o final de um ciclo de desenvolvimento (Incremento do produto).

  • O código deve ter sido revisado pelo Arquiteto, Líder Técnico ou outro Desenvolvedor;
  • O código deve rodar em uma esteira DevOps;
  • Devem ter sido executados testes unitários quando for back-end. Para front-end é opcional;
  • Devem ser entregues cenários de testes manuais;
  • Todos os testes devem ser realizados no navegador definido pelo cliente;
  • Devem ser entregues as evidências dos testes executados manualmente;
  • O Analista de negócio / requisito deve validar todos os critérios de Aceite dos itens do Ciclo (Revisão) e informar o resultado no respectivo milestone;