Processos Meu RH

Novembro de 2021

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

Dezembro de 2021

Datasul
Fluxo inteiro: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7621
Upstream: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7056
Downstream: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7058
Board do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63019
Board kaizen: https://slice.wbrain.me/#/board/yFpJECboWweDlG91Lo

Protheus
https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=1462
Pontuação: https://docs.google.com/spreadsheets/d/1dGu7vTsiMlPqpzenbX3F_BDy11Mbd3RR6JsfLkMT4hI/
Board do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63020
Board retro: https://slice.wbrain.me/#/list/axSPfnqABzKEq3Uitz

RM
Fluxo inteiro: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7703
Board do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=62912
Board retro: https://slice.wbrain.me/#/list/dpobba5mvdoChRmrMj

Todas
OKR: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63702
Ações de melhoria: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=5213
Board do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63020

Datasul

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 14/12/2021

Protheus

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 22/12/2021

RM

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:

Cada analista só pode ter um PR em aberto
Grupo de tester como required em todos os PRs, ou seja, os PRs só irão pra dev/master quando o tester aprovar
Será feito merge da dev pra master toda sexta-feira, em sistema de rodízio por squad
- 07/01: Datasul
- 14/01: Protheus
- 21/01: RM
- 28/01: Datasul
No canal #pull-requests sempre será enviado quando um novo PR for aberto

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

Acordo entre Atendimento, Consultoria e Desenvolvimento RH RM para abertura de tarefas no Jira

Padrão de abertura de issues para Meu RH RM

Padrão de abertura de issues para Meu RH Datasul

Como apontar horas no Jira

Qual é a quantidade diária esperada de horas apontadas por dev?

Apontar no Jira conforme o espelho do ponto, distribuindo os apontamentos nas atividades que realizou ao longo do dia.

As ausências de férias, compensações e afastamentos precisam ser apontadas?

Não.

Qual tipo de apontamento para o totver que preparou e ministrou repasse/treinamento?

Deve ser gerada uma tarefa de Lição Aprendida para cada treinamento onde todos irão apontar e depois fecha-la.

É preciso apontar as dailies e os eventos ágeis?

Sim,
A daily apontar na DRHMEURH-568 - Obtendo detalhes do item... STATUS ou na própria tarefa que está atuando no momento.

Os refinamentos na DRHMEURH-594 - Obtendo detalhes do item... STATUS

A review na DRHMEURH-592 - Obtendo detalhes do item... STATUS

A Planning/Replenishment na DRHMEURH-591 - Obtendo detalhes do item... STATUS

A Retrospective/Kaizen na DRHMEURH-593 - Obtendo detalhes do item... STATUS

Todas são subtarefas da DRHMEURH-590 - Obtendo detalhes do item... STATUS .

Como apontar os apoios?

Para o PO quando for refinamento de algum item apontar na DRHMEURH-594 - Obtendo detalhes do item... STATUS ou se for outro assunto e ultrapassar 30min gerar uma issue de apoio e apontar nela.

Para o atendimento quando ultrapassar 30min gerar uma issue de apoio e apontar nela.

Para o time, apontar na issue que está apoiando.

Onde apontar o tempo com configuração e atualização de ambiente?

Onde apontar as reuniãos de feedback, OKR, alinhamentos?

Na tarefa DRHMEURH-567 - Obtendo detalhes do item... STATUS . Quando houver uma reunião sobre um tema especifico deve ser criada uma nova subtarefa e todos do time apontam nela e depois fecha-la.

Onde apontar problemas na VPN, ferramentas da totvs indisponíveis, café, falha do Noteboo ou qualquer indisponibilidade ou ociosidade gerados por parte da TOTVS?

Esse é um exemplo de apontamento na issue de contigência DRHMEURH-3395 - Obtendo detalhes do item... STATUS .