Meu RH

Atalhos

Árvore de páginas

  • Criado por Usuário desconhecido (kaio.alves), última alteração por Usuário desconhecido (jose.silveira) em 22 dez, 2021

Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 13 Próxima »



Data Hora Linha Evento

03/11

 14:00 RM Kaizen
03/11 15:30 RM Replenishment
03/11 16:00 Protheus Retro
03/11 17:00 Protheus Planning
03/11 11:00 Datasul Momento solução
04/11 16:00 Todas Qualidade Meu RH
05/11 10:00 Todas AMPOPLAC
05/11 16:00 Datasul Refinamento negócio
08/11 08:30 Datasul Refinamento técnico
08/11 09:00 RM Refinamento negócio
08/11 10:00 RM Refinamento técnico
08/11 11:00 Datasul Alinhamentos com liderança do atendimento
08/11 15:00 Datasul Replenishment
08/11 16:00 Todas Qualidade Meu RH
10/11 11:00 Datasul Momento solução
11/11 9:00 Protheus Refinamento negócio
11/11 10:30 Protheus Refinamento técnico
12/11 10:00 Todas AMPOPLAC
12/11 16:00 Datasul Refinamento negócio
16/11 08:30 Datasul Refinamento técnico
16/11 09:00 RM Refinamento negócio
16/11 10:00 RM Refinamento técnico
16/11 15:00 Datasul Replenishment
16/11 16:00 Protheus Planning
17/11 11:00 Datasul  Momento solução
17/11 16:00 Todas Qualidade Meu RH
17/11 15:30 RM Replenishment
19/11 10:00 Todas AMPOPLAC
19/11 16:00 Datasul Refinamento negócio
22/11 08:30 Datasul Refinamento técnico
22/11 09:00 RM Refinamento negócio
22/11 10:00 RM Refinamento técnico
22/11 15:00 Datasul Replenishment
22/11 16:00 Todas Qualidade Meu RH
24/11 11:00 Datasul Momento Solução
25/11 9:00 Protheus Refinamento negócio
25/11 10:30 Protheus Refinamento técnico
26/11 10:00 Todas AMPOPLAC
26/11 16:00 Datasul Refinamento negócio
29/11 08:30 Datasul Refinamento técnico
29/11 09:00 RM Refinamento negócio
29/11 10:00 RM Refinamento técnico
29/11 14:00 Datasul Kaizen
29/11 15:00 Datasul Replenishment
29/11 16:00 Todas Qualidade Meu RH
30/11 14:00 Protheus Retro
30/11 15:00 Protheus Planning
30/11 16:00 Todas Review

DoR - Definition of Ready - Definição de Pronto

  • Detalhamento do fluxo e necessidade do usuário (issuetype Story), esperada pelo PO e time de UX
  • Critérios de aceite devidamente descritos e apresentados
  • Especificar em quais linhas de produto deve ser feito desenvolvimento e teste
  • Descrever quando novo menu deve aparecer na parte de Mais Acessados
  • Adicionar o Link Issues quando uma issue for dependente de outra
  • Ter documentação de UX
  • O time deve entender se as tarefas para entregar a Story estão claras
  • Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH


DoD - Definition of Done - Definição de Feito

  • Definição de contrato sempre que houver atuação de front-end, sempre fazendo checkin com as atualizações
  • Code review antes de iniciar o teste integrado
  • Teste unitário automatizado nos projetos do angular e ionic
  • Documentação (documento técnico e documentação de referência)
  • Comentário ou evidência do que foi corrigido de forma detalhada dentro da issue
  • Subir commit ou pull request em PT, EN, ES 
  • Cumprir critérios de aceite
  • Considerar Permissionamento e fieldProperties
  • Quando houver alteração de layout deve haver validação de UX/UI (com tarefa de Design)
  • Tarefas que envolvem front-end devem ser testadas em todas as linhas (criar tarefa de TI para cada linha) - conversar com todas as squads


Última revisão em  

DoR - Definition of Ready - Definição de Pronto

  • Detalhamento da jornada do usuário, esperada pelo PO e time de UX
  • Critérios de aceite devidamente descritos e apresentados, e que não apresentem riscos
  • Story com 8 pontos ou menos
  • Quebras de Story com a relação mencionada (ou seja, as relações de dependência)
  • O time deve entender se as tarefas para entregar o requisito estão claros
  • Especificar em quais linhas de produto deve ser feito desenvolvimento e teste (no refinamento técnico deixar descrito para apoiar PO)
  • Quando for nova funcionalidade especificar em qual Versão/Release ela será disponibilizada
  • Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH
  • Na planning levar em consideração as observações levantadas no refinamento técnico e passar o que for necessário para os critérios de aceite
  • Descrever como devem ser os Permissionamentos e se deve considerar no Mais acessados
  • (validar processo de UX sobre ter prototipo do sistema real e do sistema 'futuro')


DoD - Definition of Done - Definição de Feito

  • Definição de contrato sempre que houver atuação de front-end, sempre fazendo checkin com as atualizações
  • Code review
  • Teste unitário automatizado nos projetos do angular e ionic
  • Teste automatizado unitário e/ou de API (desde de que seja possível automatizar)
  • Documentação (evidência de teste de desenvolvimento, documento técnico e documentação de referência)
  • Tradução feita pelo dev (no projeto angular e ionic)
  • Cumprir critérios de aceite
  • Quando houver alteração de layout deve haver validação de UX/UI (com subtarefa de Design)
  • Quando criar novos cenários automatizados de backend, atualizar o kanoah e o mapa mental


Última revisão em  

DoR - Definition of Ready - Definição de Pronto

  • Detalhamento da jornada do usuário, esperada pelo PO e time de UX
  • Critérios de aceite devidamente descritos e apresentados, e que não apresentem riscos
  • Story com 13 pontos ou menos
  • Quebras de Story com a relação mencionada (ou seja, as relações de dependência)
  • Ícones, imagens, protótipo de tela, enfim, toda UX/UI pronta
  • O time deve entender se as tarefas para entregar a Story estão claras
  • Especificar em quais linhas devem executar
  • Preservar funcionalidades existentes nos portais legados de acordo com cada story


DoD - Definition of Done - Definição de Feito

  • Definição de contrato
  • Code review
  • Teste unitário automatizado nos projetos do angular e ionic
  • Teste automatizado unitário e/ou de API
  • Atualizar documentação de referência
  • Comentário do que foi corrigido
  • Tradução feita pelo dev
  • Cumprir critérios de aceite
  • Considerar Permissionamento/Mais acessados


Última revisão em 04/08/21

Acordos:

  • Apresentar somente as issues fechadas (exceto quando o PO solicite que apresente tarefas incompletas)
  • Mostrar a issue no jira e explicar o contexto e a regra do negócio (rapidamente)
  • Foco na demonstração do produto que foi entregue
  • Todas tarefas devem ser apresentadas no mobile
  • Todas as sugestões de melhorias e comentários podem ser ditas para que o PO anote
  • Automações de front e back
  • Mostrar documentações
  • Apresentar números no final


Última revisão em 05/03/21

Refinamento negócio:
Datasul: semanal, sexta-feira, 16:00 - 17:00
Protheus: quinzenal, quarta-feira, 14:00 - 15:30
RM: semanal, sexta-feira, 15:00 - 16:00

Refinamento técnico:
Datasul: semanal, segunda-feira, 08:30 - 12:00
Protheus: quinzenal, quarta-feira, 14:00 - 15:30
RM: semanal, segunda-feira, 08:00 - 15:00

Acordos:

  • O refinamento de negócio é apresentado pelo PO, com foco no entendimento da demanda e explicação do valor
  • No refinamento técnico participa todo o junto em conjunto
  • Toda discussão deve ser registrada na issue
  • O teste integrado, casos de uso e automação devem ser considerados
  • Após refinado o status da issue deve ser "Grooming concluído"

Última revisão em 02/11/21

Acordos:

  • Na discussão ter uma pessoa de cada linha e um especialista de front end
  • Alterar versão sempre que tiver modificação (versão 1.3.2 | 1-> alterações de API incompatíveis | 3-> adiciona funcionalidade de maneira compatível com versões anteriores | 2-> correções de bugs compatíveis com versões anteriores)
  • Deixar APIs preparadas para paginação (page, pageSize)
  • Permissions para determinar quais menus/botões de função que serão exibidos
  • fieldProperties para determinar quais campos serão exibidos para cada linha
  • Formato de data: String as Date-Time
  • Utilizar padrão lowerCamelCase
  • Após atualizar APICurio subir o PR para o DocsMeuRH


Última revisão em 05/03/21

Acordos:

  • Reunião com o time sempre que desenhar uma nova tela para analisar ícones, componentes, menus, etc;
  • XD como repositório para buscar todos artefatos do Meu RH;
  • Nos protótipos se basear nos componentes do PO-UI, caso o PO-UI não tenha o componente necessário para a tela, conversar com algum dev para pensar no componente a ser desenvolvido;
  • Fazer validações em todas stories de front-end, apontando e controlando a sub-tarefa de Validação UI/UX;
  • Quando houver mudanças nas telas atualizar os protótipos.
  • URLs para buscar protótipos do Meu RH


Última revisão em 05/03/21



  • Sem rótulos