TOTVS Transmite

Páginas filhas
  • Processo de Atendimento e Desenvolvimento TOTVS Transmite x SPED TSS (DoR)

Versões comparadas

Versão antiga 113

changes.mady.by.user Usuário desconhecido (paulo.leopoldo)

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Usuário desconhecido (paulo.leopoldo)

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Expandir
title

...

1. Definition of

...

Ready - DoR

Processo de Atendimento e Desenvolvimento TOTVS Transmite x SPED TSS (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!

  1. Os itens marcados com * são obrigatórios constar na Issue.
  2. 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.

...

Expandir

...

title2. Conceito
Expandir
title2.1 DoR - Definition of Ready

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. 

...

Expandir
title2.2 DoD - Definition of Done

...

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).

...

Expandir
title3. Processos

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


Âncora
ErroProblema
ErroProblema

Aviso
title1. Apresentação do problema

Descrever aqui o erro ou problema que esta sendo apresentado ao usuário.


Âncora
PassoPasso
PassoPasso

Informações
title2. Simulação (Passo a passo)

Informar aqui o que deve ser feito para simular o erro ou problema.


Âncora

...

ObservacaoAnalise

...

3. Evidências e Análises

ObservacaoAnalise

Nota
title
Observações da análise

Caso houver alguma análise prévia ou qualquer outra informação que possa ajudar no entendimento, deve ser informado aqui!


Âncora
CriterioAceite
CriterioAceite

Dica
title4. Critérios de Aceite

Checklist com todas as etapas de requisitos do DoR preenchidos com clareza e corretamente. 

...

Expandir
title4. Modelos
Expandir
title4.1 ISSUE TYPE: APOIO

Image Modified ISSUE TYPE: APOIO

draw.io Diagram
bordertrue
diagramNameFluxo para abertura de issue tipo Apoio
simpleViewerfalse
width600
linksauto
tbstyletop
lboxtrue
diagramWidth1081
revision

...

32

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.

...

Evidências e Análises

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 de APOIO.

Aviso
title1. Apresentação do Problema

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:

  • Dado
  • E
  • Quando
  • Entã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:

  •  Verificar
o
  • validade do Certificado digital;
  •  Verificar se a sincronização automática esta habilitada;
  •  Verificar o Feedback e o IsLock = T;
  •  Verificar o horário da próxima sincronização;
  •  Verificar a tabela historicosincnfe.

Possíveis situações de analise relacionadas a tabela nfseparametros:

  •  Verificar
o
  • 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 o horário da próxima sincronização;
  •  Verificar a tabela historicosincnfse.

Possíveis situações de analise relacionadas a tabela sincronizacaocte:

  •  Verificar
o
  • 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
?Foi solicitado todos os anexos necessários para avaliação da situação
  • ?
  • 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.

  •  Crítica
  •  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. 
Informações
title2. Simulação (Passo a passo)

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

GIF contendo cenário apresentado no ambiente do cliente e/ou ambiente de teste (

staging

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;
Nota
title3.
Observações da análise

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?

Sim - Descrever a saída

Não

XML

É um paliativo, para que o cliente tenha uma opção funcional, enquanto a issue é avaliada. (Uso exclusivo do Dev team)

XML:Anexar um xml de exemplo para auxiliar o Dev team durante análise.
Expandir
title4.2 ISSUE TYPE: MANUTENÇÃO

Image ModifiedISSUE TYPE: MANUTENÇÃO

draw.io Diagram
bordertrue
diagramNameFluxo de abertura de issue do tipo Manutenção
simpleViewerfalse
width600
linksauto
tbstyletop
lboxtrue
diagramWidth1001
revision

...

3. Evidências e Análises

12

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 de MANUTENÇÃO.

Aviso
title1. Apresentação do Problema

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:

  • Dado
  • E
  • Quando
  • Então
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
o
  • 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
?Foi solicitado todos os anexos necessários para avaliação da situação
  • ?
  • 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.

  •  Crítica
  •  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.
  •  Sim 
  •  Não
  • Informar se cliente usa TSS Cloud e qual URL
:
  • .
Informações
title2. Simulação (Passo a passo)

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;
Nota
title
Observações da análise

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.
Dica
title4. Critérios de Aceite

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
Expandir
title4.3 ISSUE TYPE: APOIO CLIENTE

Image Modified 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.

...

Expandir
title5. Diagrama do fluxo completo

Diagrama do fluxo completo:

draw.io Diagram
bordertrue
diagramNameDiagrama do fluxo de atendimento completo
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth1811
revision

...

17


...