Definition of Ready - DoR
O Solicitante ao criar uma Issue do tipo Apoio deverá seguir os Critérios de DoR estabelecidos, preenchendo os respectivos campos dos critérios no campo de Descrição da Issue com as informações necessárias. Após passar pela Análise do PO, o mesmo irá direcionar ao time de Desenvolvimento para a sua resolução.
Atenção!
- Os itens marcados com * são obrigatórios constar na Issue.
- Copie a Tabela com os critérios para o campo Descrição da Issue e preencha os dados necessários na coluna Informações. A tabela para cópia está destacada com cabeçalho Preto.
Conceito:
DoR - Definition of Ready
- Conceito de Preparado (Definition of Ready - DoR) é a condição geral estabelecida para que os requisitos de produtos estejam especificados o suficiente e sejam elegíveis para iniciar o desenvolvimento.
- O DoR viabiliza que apenas o escopo seja desenvolvido.
DoD - Definition of Done
- O Conceito de Pronto (Definition of Done - DoD) é a condição geral de entrega estabelecida para os requisitos de produto gerados durante o Plano de Entregas/Release.
- A Definition of Done (DoD) é um conjunto de “combinados” entre o Time (PO + Devs + SM) que indica que cada item produzido na sprint/ciclo deve atender, para ser considerado pronto (concluído).
Processos:
- Ao abrir uma issue para o time de desenvolvimento TOTVS Transmite, por gentileza utilizar o modelo padrão para cada situação, conforme modelos abaixo.
- A descrição da issue deve seguir uma sequencia lógica para facilitar o entendimento e organização das informações.
Obs: Muitas vezes, o cenário está claro para o time de suporte, devido aos alinhamentos internos através de reuniões, refinamentos e afins. Para que possamos estar na mesma página de entendimento é de suma importância que essas informações sejam compartilhadas através do preenchimento correto do DoR
Descrever aqui o erro ou problema que esta sendo apresentado ao usuário. |
Informar aqui o que deve ser feito para simular o erro ou problema. |
Caso houver alguma análise prévia ou qualquer outra informação que possa ajudar no entendimento, deve ser informado aqui! |
Checklist com todas as etapas de requisitos do DoR preenchidos com clareza e corretamente. |
Modelos:
ISSUE TYPE: MANUTENÇÃO
Issue Type utilizada para problemas identificados no produto padrão após liberação ao mercado. Podem ser identificados externa ou internamente.
Descrever aqui o erro ou problema que esta sendo apresentado ao usuário. *Histórico do atendimento: | Informar quais análises e tratativas foram feitas e discutidas antes da Issue ser aberta. (informar issue pai, caso houver). | *Título da Issue: | Estar de acordo com o problema informado. Problemas relacionado a documentos inserir a esquerda o tipo de documento (Ex: NFe, NFSe, CTe). Caso seja problema de importação ou exportação inserir "IMPORT/EXPORT" após o informar o tipo de documento. | | *Cenário apresentado: | Informar a situação / cenário identificado no ticket e alinhado com o cliente
Importante: Colocar todos os anexos na análise interna da solicitação. | | *Resultado esperado: | Em linhas gerais quanto a negócio, informar como deveria ser o processo | | *Requisitos Iniciais: | Informações essenciais para o entendimento do problema/dúvida. Sincronismo Possíveis situações de analise relacionadas a tabela mdeparametros: Possíveis situações de analise relacionadas a tabela nfseparametros: - Verificar o Certificado digital;
- Verificar se a sincronização automática esta habilitada;
- Verificar o Feedback e o IsLock = T;
- Verificar se o Web Service da prefeitura em questão esta disponível;
- Verificar pelo Código do município (Serviços de recebimento Nota Fiscal de Serviços (NFSe));
- Verificar o horário da próxima sincronização;
- Verificar a tabela historicosincnfse.
Possíveis situações de analise relacionadas a tabela sincronizacaocte: - Verificar o Certificado digital;
- Verificar se a sincronização automática esta habilitada;
- Verificar o Feedback e o IsLock = T;
- Verificar o Status se esta com o valor 2:
- 0 - Aguardando primeira sincronização
- 1 - Nenhum documento localizado
- 2 - Sucesso na sincronização
- 3 - Rejeição ou Falha
- Verificar o horário da próxima sincronização;
- Verificar o campo "Apenas Tomador";
- Verificar a tabela historicosinccte.
Importação Manual Possíveis situações de analise relacionadas a documentos Federais (NFE/CTE/CTEOS). - Realizar a validação da estrutura do XML.
- Verificar se a Filial correspondente ao XML esta cadastrada.
Possíveis situações de analise relacionadas a documentos Municipais (NFSE).
Exportação Individual: - Realizar a validação da estrutura do XML.
- Verificar se o path da nota fiscal está na base de dados do documento em questão.
Exportação em lote: - Verificar a data do filtro selecionada, não pode ser superior a 31 dias.
- Realizar a validação da estrutura do XML.
| | *TenantID: | Informar o código Tenant do cliente disponível na tabela "customers" no mongodb. | | Motivo da criticidade: | Justificar a criticidade do Ticket, nos casos em que for classificada como prioridade Crítica ou Alta. | | Mais informações: | Informar se cliente usa ambiente cloud tenantizado, on-premise. | | Integrações: | Exemplos:- Cliente possui integração com o módulo COMPRAS no Protheus.
|
|
Informar aqui o que deve ser feito para simular o erro ou problema. | *Simulação: | - Enviar evidências de simulação do problema:
Exemplo: Se for um cenário de sincronismo, evidenciar o passo a passo realizado para chegar até o comportamento apresentado, a consulta realizada no banco de dados e um gif contendo cenário apresentado no ambiente do cliente e/ou ambiente de teste (staging). - Informar TenantID, CodigoFilial (Caso haja mais de uma filial, informar quais)
- Gerar um vídeo ou um GIF com a situação relatada.
- Informar o motivo caso não se aplique a simulação;
- Informar qual foi a última vez que o sistema se comportou como esperado.
|
|
Havendo análise prévia ou qualquer outra informação que possa ajudar no entendimento, deve ser informado aqui! Possui saída de contorno? É um paliativo, para que o cliente tenha uma opção funcional, enquanto a issue é avaliada. | Sim - Descrever a saída Não | | Análise: | Enviar o entendimento da situação: detalhar as abordagens utilizadas para resolver a situação e se possível, gerar uma saída de contorno para o cliente. | | *XML | Anexar um xml de exemplo para que o time de desenvolvimento possa se basear durante análise. |
|
Checklist com todas as etapas de requisitos do DoR e DoD preenchidos com clareza e corretamente. *DoR | - A história está clara e compreendida pelo time todo
- Possível desenvolver a história com os dados fornecidos no DoR
- A história possui critérios de aceite claros
- Mapear requisitos técnicos
- História aprovada pelo PO
| *DoD | - Ter 100% dos testes executados e aprovados:
- Codificação com evidência;
- Teste Unitário com evidência;
- Teste Integrado com evidência;
- Documentação com evidência;
- Critérios de aceite atendidos
- Entrega aceita pelo PO
|
|
ISSUE TYPE: APOIO
Issue Type utilizada quando é necessário apoio de alguma outra equipe para solução de algum item. Exemplos de situações em que a issue type é utilizada: Área de Atendimento solicita apoio da equipe de desenvolvimento na solução de algum atendimento a cliente; Uma Squad solicita apoio para realizar um desenvolvimento, um entendimento, ou solicitação de automação para outro time.
Um apoio pode se classificar entre possível problema, configuração, orientação a processos e dúvidas.
Descrever aqui o erro ou problema que esta sendo apresentado ao usuário. | *Título da Issue: | Estar de acordo com o problema informado. Estar de acordo com o problema informado. Problemas relacionado a documentos inserir a esquerda o tipo de documento (Ex: NFe, NFSe, CTe). Caso seja problema de importação ou exportação inserir "IMPORT/EXPORT" após o informar o tipo de documento. | *Cenário apresentado: | Informar a situação / cenário identificado no ticket e alinhado com o cliente
Importante: Colocar todos os anexos na análise interna da solicitação. | *Resultado esperado: | Informar qual o objetivo do apoio (o que é esperado como atuação do time de desenvolvimento, com o apoio) | *Requisitos Gerais: | Informações essenciais para o entendimento do problema/dúvida. Sincronismo Possíveis situações de analise relacionadas a tabela mdeparametros: Possíveis situações de analise relacionadas a tabela nfseparametros: - Verificar o Certificado digital;
- Verificar se a sincronização automática esta habilitada;
- Verificar o Feedback e o IsLock = T;
- Verificar se o Web Service da prefeitura em questão esta disponível;
- Verificar pelo Código do município (Serviços de recebimento Nota Fiscal de Serviços (NFSe));
- Verificar o horário da próxima sincronização;
- Verificar a tabela historicosincnfse.
Possíveis situações de analise relacionadas a tabela sincronizacaocte: - Verificar o Certificado digital;
- Verificar se a sincronização automática esta habilitada;
- Verificar o Feedback e o IsLock = T;
- Verificar o Status se esta com o valor 2:
- 0 - Aguardando primeira sincronização
- 1 - Nenhum documento localizado
- 2 - Sucesso na sincronização
- 3 - Rejeição ou Falha
- Verificar o horário da próxima sincronização;
- Verificar o campo "Apenas Tomador";
- Verificar a tabela historicosinccte.
Importação Manual Possíveis situações de analise relacionadas a documentos Federais (NFE/CTE/CTEOS). - Realizar a validação da estrutura do XML.
- Verificar se a Filial correspondente ao XML esta cadastrada.
Possíveis situações de analise relacionadas a documentos Municipais (NFSE). Exportação Individual: - Realizar a validação da estrutura do XML.
- Verificar se o path da nota fiscal está na base de dados do documento em questão.
Exportação em lote: - Verificar a data do filtro selecionada, não pode ser superior a 31 dias.
- Realizar a validação da estrutura do XML.
| Requisitos Adicionais:
(quando houver ticket) | - Enviar registros de apoios anteriores referentes ao assunto, caso houver.
- Foi solicitado todos os anexos necessários para avaliação da situação?
- Foi feito acesso remoto no ambiente do cliente?
- Error Log (Caso houver)
| | *TenantID: | Informar o código Tenant do cliente disponível na tabela "customers" no mongodb. | | Motivo da criticidade: | Justificar a criticidade do Ticket, nos casos em que for classificada como prioridade Crítica ou Alta. | | Mais informações: | Informar se cliente usa ambiente cloud tenantizado, on-premise. | | Integrações: | Exemplos:- Cliente possui integração com o módulo COMPRAS no Protheus.
|
|
Informar aqui o que deve ser feito para simular o erro ou problema. | *Simulação: | - Enviar evidências de simulação do problema:
Exemplo: Se for um cenário de sincronismo, evidenciar o passo a passo realizado para chegar até o comportamento apresentado, a consulta realizada no banco de dados e um gif contendo cenário apresentado no ambiente do cliente e/ou ambiente de teste (staging). - Informar TenantID, CodigoFilial (Caso haja mais de uma filial, informar quais)
- Gerar um vídeo ou um GIF com a situação relatada.
- Informar o motivo caso não se aplique a simulação;
- Informar qual foi a última vez que o sistema se comportou como esperado.
|
|
Caso houver alguma análise prévia ou qualquer outra informação que possa ajudar no entendimento, deve ser informado aqui! *Histórico do Atendimento: | Informar tudo que foi analisado e discutido em relação à situação reportada previamente à abertura, inclusive o nome do analista do desenvolvimento caso tenha ocorrido um contato. | Possui saída de contorno? É um paliativo, para que o cliente tenha uma opção funcional, enquanto a issue é avaliada.
| Sim - Descrever a saída Não
| | *XML | Anexar um xml de exemplo para que o time de desenvolvimento possa se basear durante análise. |
|
ISSUE TYPE: APOIO CLIENTE
O time de desenvolvimento não faz atendimento a clientes. Dessa forma, não é possível abrir a issue do tipo “Apoio cliente”. A issue aberta ao time de desenvolvimento deve ser APOIO, que será dado ao suporte/produto.
Atenção: a issue do tipo Apoio cliente será utilizada internamente pelo time, em situações pontuais ou exceções a serem tratadas junto ao PO e SM do time.