Processos Meu RH

Datasul
Fluxo inteiro: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=7621
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;
Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH;
Quando tiver integração ter disponibilidade de ambiente, usuário e senha que devem ser utilizados

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 de referência para inovações (quando houver issues fatiadas, será feita ao final do Epic);
Comentário ou evidência do que foi corrigido de forma detalhada dentro da issue;
Subir commit ou pull request com arquivos de tradução (PT, EN, ES) do projeto angular e ionic;
Sempre garantir cobertura ideal dos testes unitários, Branches: 74% | Functions: 85% | Lines: 88%
Cumprir critérios de aceite;
Quando houver alteração de layout deve haver validação de UX/UI (com subtarefa de Design);
Tarefas que envolvem front-end devem ser testadas em todas as linhas:
- Quando o teste for rápido (em média 1h) criar uma subtarefa de teste para cada linha;
- Quando for um teste mais extenso devem ser criadas novas issues e repassadas ao PO para priorizar.
Considerar Permissionamento e fieldProperties de com a necessidade de cada linha.

Última revisão em 06/04/2022

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;
Fatiamento de story com a relação mencionada (ou seja, as relações de dependência);
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;
UX prototipar pensando em como funciona nas 3 linhas (tamanho e tipo do campo).

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;
Tarefas que envolvem front-end devem ser testadas em todas as linhas:
- Quando o teste for rápido (em média 1h) criar uma subtarefa de teste para cada linha;
- Quando for um teste mais extenso devem ser criadas novas issues e repassadas ao PO para priorizar;
Quando desenvolver front-end adicionar fieldProperties e/ou permissions em todas novas funcionalidades.

*entender como isso funciona na estrutura do Protheus - Kaio (deve ser usado em todos os casos? tem sentido não usar BDD, tem planejamento para automatizar rodar o advpr a partir do ciclo de teste)

Última revisão em 05/04/2022

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
Tarefas que envolvem front-end devem ser testadas em todas as linhas:
- Quando o teste for rápido (em média 1h) criar uma subtarefa de teste para cada linha;
- Quando for um teste mais extenso devem ser criadas novas issues e repassadas ao PO para priorizar.
Quando desenvolver front-end adicionar fieldProperties e/ou permissions em todas novas funcionalidades.

Última revisão em 27/01/2022

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

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

Leitura de documentações do produto para escrever as stories
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, e que não apresentem riscos/dúvidas
Especificar em quais linhas de produto deve ser feito desenvolvimento e teste
Quando for nova funcionalidade especificar em qual Versão/Release ela será disponibilizada
Descrever como devem ser os Permissionamentos e se deve considerar no Mais acessados
Analisar os parâmetros/parametrizador relacionado a funcionalidade e especificar o que deve ser levado em consideração
Adicionar o Link Issues quando uma issue for dependente de outra
Quando já houver o front-end pronto, verificar como funciona na linha que desenvolveu. Descrever as diferenças para a linha que irá desenvolver em comparação com a outra linha e protótipo
Ter documentação de UX completa
UX ter prototipado pensando em como funciona nas 3 linhas (tamanho e tipo do campo)
Ao final de cada prototipo fazer a validação com as 3 linhas (uma pessoa de cada linha) - Design Critique

Refinamento negócio:
Datasul: quinzenal, normalmente, sexta-feira às 16:00, mas caso o fluxo esteja bem abastecido reagendamos
Protheus: quinzenal, quinta-feira, 09:00 - 10:00
RM: quinzenal, normalmente, segunda-feira às 09:00, mas caso o fluxo esteja bem abastecido reagendamos

Refinamento técnico:
Datasul: acontece após o refinamento de negócio
Protheus: acontece após o refinamento de negócio
RM: acontece após o refinamento de negócio

Acordos:

Cumprir o DoR
O refinamento de negócio é apresentado pelo PO, com foco no entendimento da demanda e explicação do valor
No refinamento técnico, a squad define a estratégia para cada item, quando necessário participa todo o junto
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: 31/03/2022

Acordos:

Agenda separada para revisão de PR todos os dias às 9hrs e às 14hrs onde todos os analistas devem praticar a revisão
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:

A primeira linha que pegar a tarefa fica encarregada de fazer o rascunho do contrato conforme o modelo XXXX
As outras linhas devem analisar o rascunho, fazer as anotações e comentários
Na discussão ter uma pessoa de cada linha e um especialista de front (não ter muitas pessoas pra evitar o prolongamento da agenda)
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 29/03/2022

Expedição

Acordos:

Deve ser criada e atribuida a subtarefa de Design em todas as tarefas que precisem de validação;
A etapa de validação de UX deve ser feita no status em Codificação;
O tempo média de resposta é de 1 dia, caso precise de prioridade avisar o analista de UX (AM Ronize Junkes Schmitz);
As telas de aprovações do datasul não fazem parte das revisões e prototipos do Ux, quando necessário solicitar apoio pontual;
Quando a issue for de back-end, normalmente, significa que o front-end já foi feito e validado, com isso as tarefas de back-end dispensam nova validação com protótipo;
No Design critique ter um dev de cada linha de produto:
- Protheus: Henrique, Jose Marcelo, Alberto, Fabio
- RM: Zaira, Bianca, Valdemar, Flavio, Robson
- Datasul: Eslin, Raniel, Marcia

Pendentes:

Repasse para o time sobre a perceção dos usuários após a entrega de novos requisitos;
Sistema muito diferente do protótipo;
Onboarding com conceitos de UX para novos analistas;
Analisar itens que o UX tem encontrado nas demandas para fazer análise de causa raiz;
UX possuir o tamanho e tipo dos campos em cada linha para montar o protótipo que atenda

Última revisão em 20/01/2022

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 (Atualizado)

Como apontar horas no Jira

Material de consulta

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, mas adicionar na planilha de ausências.

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

Como apontar os apoios?

DevTeam: na issue que a pessoa está atuando.
Outro DevTeam: apontar na issue do projeto da pessoa.
Atendimento: na issue do atendimento.
Cliente: na issue do cliente.
Quando não houver issue: lançar na issue D DRHMEURH-3643 - Obtendo detalhes do item... STATUS

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

Na issue DRHMEURH-3429 - Obtendo detalhes do item... STATUS

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 .

Preciso apontar as pausas/banheiro/café?

Não é necessário, entende-se que esse tempo estará agregado na issue que está atuando.

Onde apontar problemas na minha energia/internet?

Não apontar.

Onde apontar o onboarding dos novatos?

Esse é um exemplo de apontamento na issue de contigência DRHMEURH-3395 - Obtendo detalhes do item... STATUS . Deve criar uma issue para cada analista e todos os repasses feito com ele apontados nessa issue.