Foram definidos como padrão os Critérios de DoR e DoD - Suporte e Desenvolvimento para o RH Protheus, afim de padronizar as entregas do Suporte para o Desenvolvimento (criação das issues) e do Desenvolvimento para o Suporte (resolução, dúvidas ou rejeição das issues).

1. Suporte > Desenvolvimento - Abertura de Issue

A equipe de Suporte ao criar uma nova issue, deverá seguir os Critérios de DoR e DoD - Suporte e Desenvolvimento definidos e utilizar o Checklist Modelo de Geração de Issue para Desenvolvimento (exemplo de preenchimento em http://tdn.totvs.com/x/h25YGw), preenchendo-o com todas as informações que se fizerem necessárias e anexando-o ao ticket e a issue, para que o Desenvolvimento possa realizar a análise e atuar na sua resolução.

NOTA: As evidências devem ser feitas através de prints de telas e não por vídeos. (Em caso de exceções onde apenas por vídeo é possível evidenciar o erro, será alinhado com os P.Os e Proxys a abertura por vídeo)

Para as issues de Documentação, seguir o modelo indicado> Modelo de Issue de Documentação

Em qualquer tela do Protheus podem ser pressionadas as teclas SHIFT + F6 do teclado, simultaneamente, para que seja exibida informações da rotina que você está no sistema, informações do ambiente e ferramentas úteis.

Se existir alguma situação, no qual, não seja possível a reprodução em ambiente local, o Maestro e/ou Líder do Suporte deverá alinhar com o Product Owner, podendo este aceitar ou não a abertura da issue, diante das evidências.

 Prazo padrão para retorno do Suporte para o Desenvolvimento:

Na situação em que o Desenvolvimento, após a análise da issue verificar que a issue deve ser rejeitada e realizado o alinhamento com o Analista de Atendimento e o Maestro e/ou Líder de Atendimento. Fica estabelecido o prazo de 2 dias úteis para o retorno do Suporte, não havendo o retorno, o Desenvolvimento irá realizar a rejeição.

2. Desenvolvimento > Suporte - Rejeição e Apoio

A equipe de Desenvolvimento ao iniciar a análise de uma nova issue, deverá verificar se os Critérios de DoR e DoD - Suporte e Desenvolvimento definidos foram seguidos pelo Suporte para criação da issue e deverá seguir também os Critérios de DoR e DoD definidos na atuação de resolução das demandas. O processo de priorização deve ser alinhado com o Product Owner da Squad.

Verificar os procedimentos para os casos onde seja necessária a Devolução / Rejeição da issue, em: Instrução de Trabalho - Procedimento Antes de Rejeitar ou Não Rejeitar uma Issue

3. Processos para Issues sem Posicionamento

Foram definidos processos de formalização de prazos e planejamento de issues através dos campos "PRIORIZADO" no ticket no Zendesk e "DATA DE ACORDO" na issue no JIRA. Os fluxos que foram definidos e devem ser seguidos pelo Suporte e Desenvolvimento (Product Owners) são:

Posicionamento do prazo para o Cliente;

Rejeição do prazo pelo Cliente;

Data Acordo Entrega vencida.

Os detalhes de cada um desses processos estão documentados na space da Guild Protheus em: Desenvolvimento Protheus - Issues sem Posicionamento

4. Processo de Padronização para Subida de Fontes

4.1. Documento com o passo a passo de todas as características necessárias para criação da base congelada, conforme o exemplo a seguir:

4.2. Caso o programa esteja automatizado, evidenciar a execução de todos os Casos de Testes no AdvPR e/ou TIR, demonstrando que mesmo após a alteração proposta, nenhum caso de teste antigo passou a quebrar.

A evidência de execução local ou Smart Test são válidas para este processo.

4.3. Fonte alterado com versão e changeset utilizado como base (enviar o fonte compatibilizado com a última alteração na data do envio).

4.4. Texto com descritivo do ajuste para Check In.

4.5. Sub-task de Codificação da issue (Squad que solicita a alteração) onde vai ser realizado o check-in.

4.6. No caso de criação de CH, tabelas, índices, campos, gatilhos, consultas padrões, e parâmetros enviar também no documento TODOS OS DETALHES referentes para a criação/alteração dos mesmos.

Também é válido o relatório do Pacote do ATUSX com as informações dos ajustes realizados.

4.7. Importante: A criação de funções específicas para módulos que não são os "donos" dos fontes, deve ser realizada em fontes próprios. Ou seja, no fonte (motivo de apoio da subida) somente deverá constar as proteções do módulo/existência da nova função, e a chamada dessa nova função.

Esta observação também é válida quando a situação é específica para uma localização, como por exemplo, Localização Brasil ou Localização Argentina.

4.8. Caso apareçam quebras futuras nos Scripts de Testes criados pelos times Solicitante, o time "Dono do Programa" irá avaliar e se tratando de um problema do time Solicitante, será solicitado a sua correção.

5. Processos específicos para Central Colaborativa 

5.1. Ponto de Entrada: 

Ponto de Entrada não será considerada como melhoria na Central Colaborativa e deverá seguir o processo abaixo:

5.1.1. Solicitação do Cliente: 

Fazer alinhamento com os P.O.s antes da abertura.

Product Owner avalia se o Ponto de Entrada faz sentido e se deve ser realizado;

Product Owner realiza o orçamento em horas de desenvolvimento para os Pontos de Entrada aprovados;

Product Owner retorna para o Suporte com o orçamento em horas, macro escopo e escopo detalhado para o desenvolvimento;

Após retorno ao P.O. suporte abre a issue de Ponto de Entrada ao Produto;

Product Owner prioriza a criação do Ponto de Entrada e retorna para o Cliente.

5.1.2. Solicitação do time de Serviços:

Consultor encaminha e-mail para o Produto Owner e realiza a abertura de ticket com a solicitação de orçamento;

Product Owner avalia se o Ponto de Entrada faz sentido e se deve ser realizado;

Product Owner realiza o orçamento em horas de desenvolvimento para os Pontos de Entrada aprovados;

Product Owner precifica o custo de desenvolvimento conforme regra de precificação da Tribe envolvida e encaminha o orçamento para a área de Serviços por e-mail, solicitando o retorno com o aceite do orçamento e o fornecimento dos dados financeiros (Centro de Custo / Item e Classe Contábil) para a cobrança do custo via workflow de Transferência Gerencial no Fluig, copiando no e-mail o PMO da Engenharia Protheus ([email protected]);

Product Owner cria uma issue para a realização do Ponto de Entrada;

Product Owner prioriza a criação do Ponto de Entrada e retorna para o Consultor.

Importante: Caso o Product Owner não veja sentido na criação do Ponto de Entrada, o próprio Product Owner deve responder para o Consultor.

5.2. Definição de Melhoria / Erro de Concepção

Se a funcionalidade disponibilizada com a documentação está realizando o resultado documentado, o entendimento é Melhoria.

Se a funcionalidade não está fazendo o que está documentado, então é Erro (seja na documentação ou no produto).

Se o entendimento final não for Erro de Concepção ou Melhoria, deve ser alinhado com o P.O. e se necessário documentado o conceito da funcionalidade.

5.3. Definição do limite para a primeira interação na Central Colaborativa

90 dias.

5.4. Definição de quem pode/deve realizar a interação na Central Colaborativa

Product Owner, Proxy PO e Substitutos na ausência do Product Owner.

5.5. Uso de funções padrões disponíveis para customizações / Documentação da Função

Não deverá entrar como Central Colaborativa;

Deve ser realizado o alinhamento com o P.O. e após isso a abertura de issue do tipo Documentação.

Importante: Funções não disponibilizadas e documentadas no TDN, não devem ser utilizadas para customizações, pois a qualquer momento pode sofrer mudanças e o time não poderá ser responsabilizado por possíveis reflexos. Caso o Product Owner definir que a função não pode ser utilizada para customização, o próprio Product Owner deve responder para o suporte, que oficializará para o cliente.

6. Suporte > Desenvolvimento - Procedimento para Issues de Apoio

7. Suporte > Desenvolvimento - Procedimento para Issues de Documentação

7.1. Notas sobre Issues de Documentação

• Questões técnicas, como as citadas abaixo, serão atendidas pontualmente como apoio:
  
  • Utilização de tabelas
  • Utilização de Campos
  • Detalhes de funcionamento de rotinas 

• Execauto e ponto de entrada.

Caso não exista vamos criar o link e colocar exemplos mais usados 

8. Suporte > Desenvolvimento - Procedimento para Repasse de Funcionalidades