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 26 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:

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

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

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


    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.


    Última revisão em  

    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

    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.


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

    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  

    Board com detalhes


    Última revisão em  



    • Sem rótulos