Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

1) Estou com o banco maior que 30h, como devo combinar as compensações?

Alinhar com o time e o PO para avaliar as demandas e datas acordadas. Sempre adicionando na planilha.

2) Tendo um banco de horas inferior a 25h posso fazer até 2h pra entregar alguma demanda crítica ou pra não perder o foco?

Sim, só atentar para não aumentar o banco de horas.

3) Qual máximo de horas extras diárias?

2 horas.

4) Estou com mais de 30h de banco de horas, posso fazer hora extra?

Nesse cenário deve ser alinhado previamente com PL.

5) Quando parar de trabalhar mais tarde tem problema com adicional noturno?

Deve-se cuidar para não gerar interjornada, descanso de 11h entre a saída no dia e entrada no outro dia.

6) Preciso fazer mais de 2 hora extra no dia para entregar uma demanda urgente, como fazer?

Conversar com o PL, pois é necessário aprovação do Tribe Leader.

Última revisão em  

Image Removed

Board com detalhes

Última revisão em  

Image Removed

Link do Miro

Última revisão em  

Image Removed

Link do Miro

Última revisão em  

Painel
JIRA
Deck of Cards
historyfalse
iddeck principal
Card
labelBoards

Datasul
Board: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=76219517
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63019
Board kaizen:  https://slice.wbrain.me/#/boardlist/yFpJECboWweDlG91Lon3bKQCbnjXF6UAYwkV

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

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

Todas
OKR: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=69615
Ações de melhoria: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=5213
Dashboard do analista: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=63020
Alguns números de entrega: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa?selectPageId=64500
Dashboard Meu RH: https://jiraproducao.totvs.com.br/secure/Dashboard.jspa
Daily Geral: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=10885

Card
labelDoR
Card
labelDoR e DoD
Expandir
titleDatasul

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 (documentação);
  • Critérios de aceite devidamente descritos e apresentados;
  • Quando a entrega for fatiada deixar somente os critérios de aceite que devem ser entregues naquela issue;
  • 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;
  • Preservar funcionalidades existentes nos portais legados de acordo com cada story, que fazem sentido pro Meu RH;
  • Definição de contrato sempre que houver atuação de front-end, fazendo checkin com as atualizações.;


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

  • Code review antes de iniciar o teste integrado;
  • Teste unitário automatizado nos projetos do angular e ionic;
  • Documentação feita na etapa de codificação (documento técnico e documentação de referência);
  • Comentário ou evidência do que foi corrigido de forma detalhada dentro da subtarefa de codificação;
  • Subir commit ou pull request com arquivos de tradução (PT, EN, ES) do 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);



Última revisão em  

Expandir
titleProtheus

Protheus

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

  • 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).
  • Nos refinamentos incluir os fontes que serão alterados nos comentários.



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 e Components), sendo os components (Front, Back e UX);
  • 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;
  • Considerar Permissionamento e fieldProperties de acordo com a necessidade de cada linha.

*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 0706 

Expandir
titleRM

RM

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 mínima 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);
  • No gromming, as tarefas que envolvem front-end, devem ser avaliadas para verificar a necessidade de serem 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 acordo com a necessidade de cada linha.
  • Check-in no back-end deve ser realizado sempre na versão atual e após os testes integrados realizar o merge para as versões de mercado.

Última revisão em  

Card
labelReview

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 e preferencialmente no mobile;
  • Todas as sugestões de melhorias e comentários podem ser ditas para que o PO anote;
  • Apresentação é mensal dividida em 3 agendas seguidas;
  • O tempo da apresentação médio é de 20min, quando for variar é necessário ajustar o invite;
  • Para facilitar a organização é gerado um TDN de cada Review DRHMEURH.


Última revisão em  

Card
labelDaily

Acordos:

  • Compartilhar o board;
  • Foco no que falta para entregar as tarefas;
  • Os impedimentos e necessidades de ajuda já saem mapeados com responsável por resolver/ajudar;
  • Não é status report (muito menos pro AM);
  • Revisão da estratégia de entrega.


Última revisão em  

Card
labelRetro/Kaizen

Boards:
Datasul: https://slice.wbrain.me/#/board/yFpJECboWweDlG91Lo

Protheus: https://slice.wbrain.me/#/list/axSPfnqABzKEq3Uitz

RM: https://slice.wbrain.me/#/list/dpobba5mvdoChRmrMj


Todos os materiais utilizados estão no drive: RH ->Novo RH -> Meu RH

AM sempre faz o registro em uma subtarefa da DRHMEURH-1967AM transcreve as ações de melhoria para o Jira e transcreve as ações de melhoria para o Jira e adiciona no board dos times.

Board só de ações de melhoria: https://jiraproducao.totvs.com.br/secure/RapidBoard.jspa?rapidView=5213

Card
labelUpstream

DoR - Definição de Pronto do Refinamento de negócio/funcional

  • Quando tiver legado fazer a leitura e análise das documentações do produto para escrever as stories
  • Analisar os parâmetros/parametrizador relacionado a funcionalidade e especificar o que deve ser levado em consideração (quando houver necessidade abrir spike para o time apoiar)
  • 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 (separar os epic por linha de produto)
  • 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
  • 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
  • (Responsabilidade UX) ter prototipado pensando em como funciona nas 3 linhas (tamanho e tipo do campo)
  • (Responsabilidade UX) 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:  

Card
labelPR

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
Card
labelContratos

Acordos para definição de contrato:

  • Seguir o padrão de API da TOTVS https://api.totvs.com.br/guia
  • A primeira linha que pegar a tarefa fica encarregada de fazer o Modelo rascunho de contrato (não esquecer de duplicar o doc e não editar o original);
  • 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 o Apicurio subir o PR para o DocsMeuRH


Acordos para desenvolvimento de API:

  • Sempre devolver todos os campos do contrato (quando a linha não utilizar devolver como null)
  • Atentar aos fieldProperties que precisem ser enviados
  • Só liberar a funcionalidade no permissions quando estiver concluída


Falta definir:

  •  Padrão para contratos
  •  Padão de nomenclaturas de rotas
  •  Documentação de fieldProperties


Última revisão em  

Card
labelAutomações

Apresentação de qualidade


Board Automação

Planilha e2e

Planilha contrato

Planilha Geral

Card
labelExpedição

Expedição

Card
labelUX

Acordos:

  • Deve ser criada e atribuida atribuída 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 protótipos 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, Raniel
    • Datasul: Eslin, Marcia
  • Usar link do fluxo completo ao invés do link da tela (porque estes mudam a cada versão);
  • Sempre que tiver um link de protótipo verificar se está no versionamento mais atual;
  • Ajustes de protótipo devem ser solicitados antes do comprometimento com a issue, assim teremos tempo hábil para o UX alterar posteriormente (esse é o processo padrão, devemos abusar do design critique pra antecipar esses erros);
  • Quando esses ajustes aparecem no decorrer da execução da tarefa o UX dará um entendimento e rascunho de como deve ser feito para o time não ficar parado e o UX faz o mapeamento para voltar com essas alterações no momento em que for planejado;
  • O time de dev fica sabendo das alterações atraves através do canal #UX ;
  • Combinamos de sempre usar os componentes do PO-UI e quando houver exceções e precisar criar componentes que não estão no PO-UI, o ideal é criar um novo componente, não ficar sobrescrevendo os componentes do PO-UI, porque quando o time do PO-UI ajusta o componente gera a possibilidade de quebrar;
  • Convencionar o uso de ícones do https://po-ui.io/guides/icons;
  • Quando houver necessidade de um diferente alinhar com o time de dev no discord, design critique ou notion e deixar salvo em SVG;

Pendentes:

  • Repasse para o time sobre a perceção percepçã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.


Guia de Padronização conforme pauta do dia   com a Helen.Almeida


Última revisão em  

Card
labelAcordos com atendimento

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)

JIRA
Card
labelApontamento de horas

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 2024, para 2025 utilizar planilha de ausências .2025


  • 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?
  • ou participou/assistiu um treinamento?

Para quem preparou e ministrou apontar na

Sim,
A daily apontar na 
Jira
serverJIRA
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-568
 ou na própria tarefa que está atuando no momento.
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
Os refinamentos na 
Jira
serverJIRA
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-594
A review na 
8550

Para quem assistiu/participou de um treinamento ou capacitação, apontar na

Jira
showSummaryfalse
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverIdserverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-5928549


  • É preciso apontar as dailies e os eventos ágeis?

Sim,
A daily apontar na A Planning/Replenishment na 

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-8547
 ou na própria tarefa que está atuando no momento.

Os refinamentos na 591A Retrospective/Kaizen na 

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-
593

  • Como apontar os apoios?

8546

A review na 

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
Jira
serverJIRA
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-3643

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

columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
Na issue 
Jira
server
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-
3429

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

8544

Na tarefa Planning/Replenishment na 

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-
567. 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?

8543

A Retrospective/Kaizen na Esse é um exemplo de apontamento na issue de contigência 

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-3395
.

  • 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?

8545

Os OKRs e seus acompanhamentos na

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
Esse é um exemplo de apontamento na issue de contigência 
Jira
server
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-
3395. Deve criar uma issue para cada analista e todos os repasses feito com ele apontados nessa issue.

  • Sou novo na equipe, devo apontar?

Sim, com exceção da semana dos treinamentos iniciais, todas as atividades que a pessoa estiver atuando, devem ser apontadas. 

Card
labelHoras extras
Expandir
titleRM
Card
labelDelegation Board
Expandir
titleRM
Card
labelFluxo Desenvolvimento
Expandir
titleManutenção
Expandir
titleInovação
Card
labelEscopo de atuação

O objetivo da atuação do Meu RH é Atuação na camada rest, front-end e app, mas em um período houve uma estratégia que o Meu RH assumiu as todas as partes das entregas para acelerar o crescimento do produto.
O cenário de Protheus é que muitas regras estão dentro dos fontes do Meu RH, inclusive com várias duplicidades. 
No RM, a divisão é bem clara porque o portal antigo e o Meu RH utilizam os mesmos dataservers, onde o dataserver é de responsabilidade de produto.
No Datasul é mais complexo porque misturou regras nos fontes do Meu RH e API.

Para Datasul existe o seguinte acordo:

  • A partir de 01/05/22 novas demandas de API (regra de negócio) serão tratadas pelos times de Datasul:
    • DRHJORNDTS - Jornadas
    • DRHROTDTS - Rotinas
    • DRHCALCDTS - Cálculos
    • DRHHCM - Capital humano
  • Após a transferência, caso falte alguma evidência ou simulação deverão ser solicitadas diretamente ao atendimento ou rejeitadas;
  • Quando houver a necessidade de atuação do Meu RH em algum teste ou apoio, deve ser gerada uma issue do tipo Apoio e solicitada prioridade ao PO para incluir no planejamento;
  • As issues continuaram sendo abertas para o Meu RH (DRHMEURH):
    • Quando se tratar de problemas nas APIs serão transferidas para o projeto correspondente;
    • É importante ter o comentário da análise feita pelo Meu RH explicando porque foi transferida;
    • Feito estudo na DRHMEURH-4951 (documento) para listar quais regras estão dentro dos fontes do Meu RH, será feito um planejamento para manter as regras somente nas APIs, após isso será necessário um novo alinhamento para as aberturas serem direcionadas para cada projeto pelo atendimento.

Material utilizado no acordo

Última revisão em  

Card
labelLinks úteis

Arquitetura Mobile

Expedição

https://tdn.totvs.com/display/public/NPR/

http://tfs2015.totvs.com.br:8080/tfs/_home

https://dev.azure.com/totvstfs/AppMeuRH/_git/Portais

https://po-ui.io/

https://studio.apicur.io/dashboard

Espelho de tela mobile x windows scrcpy: https://drive.google.com/file/d/1on2oAvudNFLIw3MvL3vDgba88H1qxETb

App para conectar VPN no celular: https://play.google.com/store/apps/details?id=com.f5.edge.client_ics&hl=pt-br

Apontamento no TOTVS 12: https://docs.google.com/document/d/1gBtvg0ZA-XPiteqkTlZbKsxezrlR28jc/

11520


  • 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

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-8552

Quando for um apoio pontual: lançar na issue

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-8551


  • Onde apontar as reuniões de feedback, OKR, alinhamentos?

Na tarefa 

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-8554


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

Esse é um exemplo de apontamento na issue de contingência

Jira
serverJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution,customfield_20500
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution,Resolution
serverId0c783de1-186e-383b-975c-a1acd7d76cb5
keyDRHMEURH-8555
.


  • 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.


  • Sou novo na equipe, devo apontar?

Sim, com exceção da semana dos treinamentos iniciais, todas as atividades que a pessoa estiver atuando, devem ser apontadas. 


draw.io Diagram
bordertrue
diagramNameApontamentos
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth2234
revision9

Card
labelHoras extras
Expandir
titleRM

1) Estou com o banco maior que 30h, como devo combinar as compensações?

Alinhar com o time e o PO para avaliar as demandas e datas acordadas. Sempre adicionando na planilha.


2) Tendo um banco de horas inferior a 25h posso fazer até 2h pra entregar alguma demanda crítica ou pra não perder o foco?

Sim, só atentar para não aumentar o banco de horas.


3) Qual máximo de horas extras diárias?

2 horas.


4) Estou com mais de 30h de banco de horas, posso fazer hora extra?

Nesse cenário deve ser alinhado previamente com PL.


5) Quando parar de trabalhar mais tarde tem problema com adicional noturno?

Deve-se cuidar para não gerar interjornada, descanso de 11h entre a saída no dia e entrada no outro dia.


6) Preciso fazer mais de 2 hora extra no dia para entregar uma demanda urgente, como fazer?

Conversar com o PL, pois é necessário aprovação do Tribe Leader.


Última revisão em  

Card
labelDelegation Board
Expandir
titleRM

Image Added

Board com detalhes


Última revisão em  

Card
labelFluxo Desenvolvimento
Expandir
titleManutenção

Image Added

Link do Miro


Última revisão em  

Expandir
titleInovação

Image Added

Link do Miro


Última revisão em  

Card
labelEscopo de atuação

O objetivo da atuação do Meu RH é Atuação na camada rest, front-end e app, mas em um período houve uma estratégia que o Meu RH assumiu as todas as partes das entregas para acelerar o crescimento do produto.
O cenário de Protheus é que muitas regras estão dentro dos fontes do Meu RH, inclusive com várias duplicidades. 
No RM, a divisão é bem clara porque o portal antigo e o Meu RH utilizam os mesmos dataservers, onde o dataserver é de responsabilidade de produto.
No Datasul é mais complexo porque misturou regras nos fontes do Meu RH e API.

Para Datasul existe o seguinte acordo:

  • A partir de 01/05/22 novas demandas de API (regra de negócio) serão tratadas pelos times de Datasul:
    • DRHJORNDTS - Jornadas
    • DRHROTDTS - Rotinas
    • DRHCALCDTS - Cálculos
    • DRHHCM - Capital humano
  • Após a transferência, caso falte alguma evidência ou simulação deverão ser solicitadas diretamente ao atendimento ou rejeitadas;
  • Quando houver a necessidade de atuação do Meu RH em algum teste ou apoio, deve ser gerada uma issue do tipo Apoio e solicitada prioridade ao PO para incluir no planejamento;
  • As issues continuaram sendo abertas para o Meu RH (DRHMEURH):
    • Quando se tratar de problemas nas APIs serão transferidas para o projeto correspondente;
    • É importante ter o comentário da análise feita pelo Meu RH explicando porque foi transferida;
    • Feito estudo na DRHMEURH-4951 (documento) para listar quais regras estão dentro dos fontes do Meu RH, será feito um planejamento para manter as regras somente nas APIs, após isso será necessário um novo alinhamento para as aberturas serem direcionadas para cada projeto pelo atendimento.

Material utilizado no acordo

Última revisão em  

Card
labelLinks úteis

Arquitetura Mobile

Expedição

https://tdn.totvs.com/display/public/NPR/

http://tfs2015.totvs.com.br:8080/tfs/_home

https://dev.azure.com/totvstfs/AppMeuRH/_git/Portais

https://po-ui.io/

https://studio.apicur.io/dashboard

Espelho de tela mobile x windows scrcpy: https://drive.google.com/file/d/1on2oAvudNFLIw3MvL3vDgba88H1qxETb

App para conectar VPN no celular: https://play.google.com/store/apps/details?id=com.f5.edge.client_ics&hl=pt-br

Apontamento no TOTVS 12: https://docs.google.com/document/d/1gBtvg0ZA-XPiteqkTlZbKsxezrlR28jc/

Card
labelInformações úteis (Linha RM)

Clique Aqui

Card
labelTeste Sistêmico

Datasul

Protheus

RM

Card
labelInformações úteis

Code Review: Quando o analista finaliza a codificação de uma tarefa deve ser realizado o code review, que se trata de uma análise do código por outro membro da equipe, caso haja alguma melhoria ou correção a ser efetuada no código deve ser efetuado antes de avançar a tarefa para a etapa de teste. Ao se realizar o code review de uma tarefa é importante seguir o CheckList do link abaixo: