TOTVS Transmite

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

Versões comparadas

Versão antiga 102

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.

...

Informar o código Tenant do cliente disponível na tabela "customers" no mongodb

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.

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

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

Importante: Colocar todos os anexos na análise interna da solicitação.

Utilizar o conceito BDD se possível:

  • Dado
  • E
  • Quando
  • Então

Resultado esperado:

Informar qual o objetivo do

apoio 

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:

(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) e/ou erro no console do navegador
.		*TenantID:
  • .
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:
Informar se cliente usa ambiente cloud tenantizado, on-premise
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;
  • 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.
    • Nota
    title3.
    Evidências e Análises

    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
    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!

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

    XML:Anexar um xml de exemplo para
    que o time de desenvolvimento possa se basear
    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
    diagramWidth

    ...

    1001
    revision

    ...

    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
    pai
    de apoio, 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.*

    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

    Importante: Colocar todos os anexos na análise interna da solicitação.

    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
    Iniciais
    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.
    		*TenantID:
    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
    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.

    •  Crítica
    •  Alta

    Porque? (Ex: Cliente em processo de churn.)

    Mais informações:
    Informar se cliente usa ambiente cloud tenantizado, on-premise
    • 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.
    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;
  • Error Log (Caso houver) e/ou erro no console do navegador.
  • 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.
    Nota
    title
    3. Evidências e Análises
    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

    Análise
    XML:
     *XML
    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.
    Anexar um xml de exemplo para
    que o time de desenvolvimento possa se basear
    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
    história
    • issue está clara e compreendida pelo time todo
    •  Possível desenvolver a
    história
    • issue com os dados fornecidos no DoR
    •  A
    história
    • issue 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
    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


    ...