 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. A equipe de Suporte ao criar uma nova issue, deverá seguir os Critérios de DoR - Suporte Transmite definidos e utilizar o Checklist Modelo de Geração de Issue para Desenvolvimento Descrever aqui o erro ou problema que esta sendo apresentado ao usuário. | *Título da Issue: | Estar de acordo com o problema informado. Inserir como padrão (Tipo doc completo (Rotina) - Problema). - Ex: NFSe Recebida (Sincronização Automática) - Sincronismo travado
| | *Tenant ID: | Informar o código Tenant do cliente disponível na tabela "customers" no mongodb. | | *Código Filial: | Informar o código da filial, Caso haja mais de uma filial, informar quais (Consultar na tabela "companys" no mongodb.) | *Cenário apresentado: | Informar a situação / cenário identificado no ticket e alinhado com o cliente
Utilizar o conceito BDD se possível: | 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 validade do 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 validade do 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:
| - Enviar registros de apoios anteriores referentes ao assunto, caso houver.
- Foi feito acesso remoto no ambiente do cliente?
- Error Log (Caso houver) e/ou erro no console do navegador.
| | Motivo da criticidade: | Justificar a criticidade do Ticket, nos casos em que for classificada como prioridade Crítica ou Alta. Porque? (Ex: Cliente em processo de churn.) | | Mais informações: | Mais informações:- Campo para inserir qualquer informação que entende-se como relevante para análise.
- Se for um caso que se trate de documentos informar, Numero, Chave e CNPJ.
- Informar quando foi última vez que a rotina/sistema funcionou.
| | Integrações: | Exemplos:- Cliente possui integração com o módulo COMPRAS no Protheus.
- Informar se cliente usa TSS Cloud e qual URL.
|
|
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). - Print de tela inteira, contendo data e hora do ocorrido;
- Gerar um vídeo ou um GIF com a situação relatada.
- Informar o motivo caso não se aplique a simulação;
|
|
Caso houver alguma 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. (Uso exclusivo do Dev team) | Sim - Descrever a saída Não
| | XML: | Anexar um xml de exemplo para auxiliar o Dev team durante análise. |
|
|
 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. A equipe de Suporte ao criar uma nova issue, deverá seguir os Critérios de DoR - Suporte Transmite definidos e utilizar o Checklist Modelo de Geração de Issue para Desenvolvimento 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 de apoio, caso houver). | *Título da Issue: | Estar de acordo com o problema informado. Inserir como padrão (Tipo doc completo (Rotina) - Problema. - Ex: NFSe Recebida (Sincronização Automática) - Sincronismo travado
| *Tenant ID: | Informar o código Tenant do cliente disponível na tabela "customers" no mongodb. | *Código Filial: | Informar o código da filial, Caso haja mais de uma filial, informar quais (Consultar na tabela "companys" no mongodb.) | | *Cenário apresentado: | Informar a situação / cenário identificado no ticket e alinhado com o cliente
Utilizar conceito BDD se possível: | | Resultado esperado: | Em linhas gerais quanto a negócio, informar como deveria ser o processo | | *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 validade do 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 validade do 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:
| - Enviar registros de apoios anteriores referentes ao assunto, caso houver.
- Foi feito acesso remoto no ambiente do cliente?
- Error Log (Caso houver) e/ou erro no console do navegador.
| | Motivo da criticidade: | Justificar a criticidade do Ticket, nos casos em que for classificada como prioridade Crítica ou Alta. Porque? (Ex: Cliente em processo de churn.) | | Mais informações: | - Campo para inserir qualquer informação que entende-se como relevante para análise.
- Se for um caso que se trate de documentos informar, Numero, Chave e CNPJ.
- Informar quando foi última vez que a rotina ou o sistema funcionou.
| | Integrações: | Exemplos:- Cliente possui integração com o módulo COMPRAS no Protheus.
- Informar se cliente usa TSS Cloud e qual URL.
|
|
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). - Print de tela inteira, contendo data e hora do ocorrido;
- Gerar um vídeo ou um GIF com a situação relatada.
- Informar o motivo caso não se aplique a simulação;
|
|
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. (Para issues abertas direto, sem precisar de apoio) | Sim - Descrever a saída Não | | XML: | Anexar um xml de exemplo para auxiliar o Dev team durante análise. |
|
Checklist com todas as etapas de requisitos do DoR e DoD preenchidos com clareza e corretamente. DoR: | - A issue está clara e compreendida pelo time todo
- Possível desenvolver a issue com os dados fornecidos no DoR
- A issue possui critérios de aceite claros
- 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 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. |
|