Histórico da Página

Foram definidos como padrão os Critérios Se definieron como estándar los Criterios de DoR e y 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 issuesSoporte y Desarrollo para el RRHH Protheus, con la finalidad de estandarizar las entregas de Soporte para el Desarrollo (creación de las issue) y del Desarrollo para el Soporte (resolución, dudas o rechazo de las issue).

1.

Soporte >

Desarrollo -

Apertura 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 Al crear una nueva issue, el equipo de soporte debe seguir los Criterios de DoR y DoD - Soporte y Desarrollo definidos y utilizar el Checklist Modelo de generación de Issue para desarrollo (ejemplo de cumplimentación en 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 completándolo con todas las informaciones que fueron necesarias y adjuntándolo al ticket y la issue, para que o Desenvolvimento possa realizar a análise e atuar na sua resoluçãoel desarrollo pueda realizar el análisis y actuar en su resolución.

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) Las evidencias se deben hacer por medio de Prints de pantallas y no por videos. (En caso de excepciones, donde solamente se puede evidenciar el error por video, se alineará con los P.O. Y Proxys la apertura por video)

Para las issue de Documentación, seguir el Para as issues de Documentação, seguir o modelo indicado> Modelo de Issue de Documentação

documentación

En cualquier pantalla del Protheus se pueden pulsar las teclas SHIFT + F6

del teclado,

simultáneamente, para

mostrar informaciones de la rutina indicando que usted está en el sistema, informaciones del entorno y herramientas útiles.

Si existe alguna situación, en que no se puede reproducir en entorno local, el Maestro y/o Líder del soporte deben ponerse de acuerdo con el Product Owner, y este puede aceptar o no la apertura de la issue, frente a las evidencias.

Image Added Plazo estándar para respuesta del soporte al desarrollo:

Image AddedEn la situación en que el Desarrollo, después de analizar la issue verifique que se debe rechazar la issue y realizar el acuerdo con el analista de atención y el Maestro y/o Líder de Atención. Queda establecido el plazo de 2 días hábiles para la respuesta del Soporte, si no hubiera respuesta, el desarrollo hará el rechazo.

2. Desarrollo > Soporte - Rechazo y apoyo

El equipo de Desarrollo, al iniciar el análisis de una nueva issue, debe verificar si los Criterios de DoR y DoD - Soporte y Desarrollo definidos, fueron seguidos por el soporte para crear la issue y debe seguir también los Criterios de DoR y DoD definidos en la actuación de la resolución de las demandas. El proceso de priorización debe estar alineado con el Product Owner de la Squad.

Verificar los procedimientos para los casos donde sea necesaria la Devolución / Rechazo de la issue, en: Image AddedInstrucción de Trabajo - Procedimiento antes de rechazar o no rechazar una Issue

3. Procesos para Issues sin posicionamiento

Se definieron procesos de formalización de plazos y planificación de issues a través de los campos "PRIORIZADO" en el ticket en el Zendesk y "FECHA DE ACUERDO" en la issue en el JIRA. Los flujos que se definieron y deben ser seguidos por elSoporte y Desarrollo (Product Owners) son:

Image AddedPosicionamento del plazo para el cliente.

Image AddedRechazo del plazo por el cliente.

Image AddedFecha Acuerdo entrega vencida.

Los detalles de cada uno de estos procesos están documentados en la space de la Guild Protheus en: Image AddedDesarrollo Protheus - Issues sin posicionamiento

4. Proceso de estandarización para subir fuentes

4.1. Documento con el paso a paso de todas las características necesarias para crear la base congelada, de acuerdo con el siguiente ejemplo

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.

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

Image RemovedNa 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: Image RemovedInstruçã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:

Image RemovedPosicionamento do prazo para o Cliente;

Image RemovedRejeição do prazo pelo Cliente;

Image RemovedData Acordo Entrega vencida.

Os detalhes de cada um desses processos estão documentados na space da Guild Protheus em: Image RemovedDesenvolvimento 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 Si el programa esteja está 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.evidencie la ejecución de todos los casos de pruebas en el AdvPR y/o TIR, mostrando que a pesar de la modificación propuesta, ningún caso de prueba antiguo volvió a fallar.

Image AddedLa evidencia de ejecución local o Smart Test son válidas para este procesoImage RemovedA evidência de execução local ou Smart Test são válidas para este processo.

4.3. Fonte alterado com versão e Fuente modificado con versión y changeset utilizado como base (enviar o fonte compatibilizado com a última alteração na data do envioenvíe el fuente compatibilizado con la última modificación en la fecha del envío).

4.4. Texto com descritivo do Texto con descriptivo del ajuste para Check In.

4.5. Sub Sub-task de Codificação da codificación de la issue (Squad que solicita a alteração) onde vai ser realizado o la modificación) donde se realizará el check-in.

4.6. No En el caso de criação de crear la CH, tabelastablas, índices, campos, gatilhosdisparadores, consultas padrões, e parâmetros enviar também no documento TODOS OS DETALHES referentes para a criação/alteração dos mesmos.estándar y parámetros, envíe también en este documento TODOS LOS DETALLES que se refieren a la creación/modificación de los mismos.

Image AddedTambién es válido el informe del paquete de la base de datos ATUSX con las informaciones de los Image RemovedTambém é válido o relatório do Pacote do ATUSX com as informações dos ajustes realizados.

4.7. Importante: A criação La creación de funções funciones 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.no son los "dueños" de los fuentes, se debe realizar en fuentes propios. Es decir, en el fuente (motivo de apoyo de subir) solamente debe constar las protecciones del módulo/existencia de la nueva función, y el ticket de esta nueva función.

Image AddedEsta observación también tiene validez cuando la situación es específica para una localización, como por ejemplo, Localización Brasil o Localización Image RemovedEsta 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 Si aparecen fallas futuras en los Script de pruebas creados por los equipos solicitantes, el equipo "Dueño del programa" evaluará y tratándose de un problema del equipo solicitante, se pedirá su corrección.

5. Processos específicos para Central Colaborativa  Procesos específicos para central colaborativa 

5.1. Ponto Punto de Entradaentrada: 

Ponto de Entrada não será considerada como melhoria na Central Colaborativa e deverá seguir o processo abaixoPunto de entrada no se considerará como mejora en la central colaborativa y debe seguir el siguiente proceso:

5.1.1.Solicitação do Cliente Solicitud del cliente: 

Fazer alinhamento com os Hacer la alineación con los P.O. s antes da aberturade la apertura.

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

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

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

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

evalúa si el punto de entrada hace sentido y si se debe realizar

Image AddedEl Product Owner realiza el presupuesto en horas de desarrollo para los puntos de entrada aprobados

Image AddedEl Product Owner devuelve la respuesta al suporte con el presupuesto en horas, macro objetivo y objetivo detallado para el desarrollo

Image AddedDespués de responder al P.O. el soporte abre la issue de punto de entrada al productoImage Added

Image AddedEl Product Owner prioriza la creación del punto de entrada y lo devuelve al clienteImage RemovedProduct Owner prioriza a criação do Ponto de Entrada e retorna para o Cliente.

5.1.2. Solicitação do time de Serviços Solicitud del equipo de servicios:

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

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

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

al Produt Owner y realiza la apertura del ticket con la solicitud del presupuesto

Image AddedPEl Product Owner evalúa si el punto de entrada hace sentido y si se debe realizar

Image AddedPrEl Product Owner realiza el presupuesto en horas de desarrollo para los puntos de entrada aprobados

Image AddedPElProduct Owner estable el precio del costo de desarrollo según la regla de determinación de precio de la Tribe involucrada y envía el presupuesto al área de servicios por e-mail, solicitando la respuesta con la aceptación del presupuesto y el suministro de los datos financieros (Centro de costo / Ítem y clase contable) para cobrar el costo mediante el workflow de Transferencia de Gestión en el Fluig, y pone en copia en el e-mail al PMO de Ingeniería Protheus Image RemovedProduct 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]);

El Product Owner cria uma abre una issue para a realização do Ponto de Entrada;crear el punto de entrada

El Product Owner prioriza a criação do Ponto de Entrada e retorna para o Consultorla creación del punto de entrada y lo devuelve al consultor.

Importante: Caso o Si el Product Owner não veja sentido na criação do Ponto de Entrada, o próprio Product Owner deve responder para o Consultor no ve sentido en crear el punto de entrada, el mismo Product Owner debe responder al consultor.

5.2. Definição Definición de Melhoria mejora / Erro Error de Concepçãoconcepción

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

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

Si la funcionalidad puesta a disposición con la documentación está realizando el resultado documentado, el entendimiento es de mejora.

Image AddedSi la funcionalidad no está haciendo lo que está documentado, entonces es Error (sea en la documentación o en el producto).

Image AddedSi el entendimiento final no es error de concepción o mejora, se debe alinear con el P.O. y si es necesario documente el concepto de la funcionalidadImage RemovedSe 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 Definición del límite para la primera interacción en la Central Colaborativa

90 dias.

5.4. Definição Definición de quem podequien puede/deve realizar a interação na debe realizar la interacción en la Central Colaborativa

Product Owner, Proxy PO e Substitutos na ausência do y sustitutos en la ausencia del Product Owner.

5.5. Uso de funções padrões disponíveis para customizações / Documentação da Função Uso de funciones estándares disponibles para personalizaciones / Documentación de la función

Image AddedNo debe Image RemovedNão deverá entrar como Central Colaborativa;

Deve ser realizado o alinhamento com o Se debe realizar la alineación con el P.O. e após isso a abertura de issue do tipo Documentaçãoy después de esto la apertura de la issue del tipo Documentación.

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 Funciones que no están a disposición ni documentadas en el TDN, no se deben utilizar para personalizaciones, porque en cualquier momento puede sufrir cambios y el equipo no se responsabilizará por posibles reflejos. Si el Product Owner define que la función no se puede utilizar para personalización, el mismo Product Owner debe responder al soporte, que oficializará para el cliente.

6.

Soporte >

Desarrollo -

Procedimiento para Issues de

apoyo

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

7. Soporte > Desarrollo - Procedimiento para Issues de documentación

7.1. Notas sobre Issues de

documentación

• Questões Cuestiones técnicas, como as las 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

• a continuación, se atenderán puntualmente como apoyo:
  
  • Utilización de tablas
  • Utilización de campos
  • Detalles de funcionamiento de rutinas 

• Execauto y punto de entrada.

Si no existe, vamos a crear el enlace y colocar los ejemplos más utilizados 

8. Soporte > Desarrollo - Procedimiento para repase de funcionalidades