Como categorizar o esforço das issues nos ajudou no onboarding de desenvolvedores(as)
A integração, ou onboarding, de novos colaboradores é um assunto que está em alta nos últimos anos e sabemos que nem sempre é uma tarefa fácil. Aqui na Resultados Digitais, temos um processo de onboarding estruturado há alguns anos, onde novos integrantes de todas as áreas participam de uma imersão de duas semanas sobre a cultura e estrutura da empresa e aprendem na teoria e na prática sobre marketing digital. Chamamos esse processo de Get Ready e há mais detalhes neste post no blog da Resultados Digitais.
Mas não para por aí. Após o Get Ready da empresa, temos um Get Ready para novos integrantes do time de Produto e Engenharia, onde eles conhecem nosso fluxo de desenvolvimento, estrutura dos times e processos. Também são incentivados a fazer uma primeira entrega, e é nesse ponto que categorizar o esforço das issues tem ajudado no onboarding de novos RDoers.
Neste post, vou contar como priorizamos o esforço das issues aqui no time do RD Station CRM e como isso ajudou nossa nova integrante a resolver quatro delas na sua primeira semana de trabalho. Ficou curioso(a)? Segue comigo.
Como categorizamos o esforço das issues
Nosso cenário
Antes de explicar a dinâmica que utilizamos para categorizar o esforço das issues do time, vou passar um contexto breve de como organizamos nosso backlog.
Aqui na RD, cadastramos nossas issues no próprio projeto no Github, utilizamos a metodologia GUT para categorizar as suas criticidades e dividimos elas em categorias: Bug, Débito Técnico e Débito de UX. Para saber mais detalhes de como priorizamos as issues, temos um post no Ship it! explicando mais sobre isto.
Porque estimar esforço?
O principal objetivo da categorização do esforço é auxiliar a priorização de issues. Quando issues são categorizadas por criticidade, é comum que as com maior GUT sejam priorizadas e, com o passar do tempo, nos deparamos com o backlog cheio de issues que são simples de se resolver e que estão ali envelhecendo por não serem algo tão crítico no sistema, como por exemplo um botão desalinhado ou uma validação de campo que não é feita corretamente. Por este motivo, é interessante que, além da criticidade, também seja categorizado o esforço de cada issue, para sermos mais assertivos no momento da priorização.
Dinâmica PMG
Há várias formas de se categorizar o esforço de atividades, como Planning Poker, Estimativa por Analogia, Pontos por Caso de Uso, etc. Porém, pela praticidade, optamos pela dinâmica PMG para estimar o esforço das nossas issues.
A dinâmica PMG consiste em dividir nossas issues em esforço Pequeno, Médio e Grande de acordo com uma estimativa baseada no conhecimento das features do sistema pelos desenvolvedores com maior senioridade do time. O que vale destacar é que a dinâmica PMG consiste em estimativas superficiais e baseadas em issues semelhantes e não se aprofunda muito a detalhes técnicos. Abaixo vou explicar como fizemos:
Participantes: Condutor da dinâmica (no nosso caso o QA do time) e um ou dois desenvolvedores(as) que conhecem bem o produto.
Agrupar issues por tipo: A dinâmica flui mais rápido quando analisamos todas as issues de um determinado tipo (bug, débito técnico ou débito de UX). No nosso caso, começamos a estimar as issues pelos bugs.
Utilizar Post-its ou um Board Virtual: Para facilitar a dinâmica é interessante utilizar post-its em um quadro ou um board virtual para mover cada bug para sua respectiva coluna de esforço Pequeno/Médio/Grande. Em ambos os casos é interessante um preenchimento prévio de cada post-it para otimizar o tempo da dinâmica.
Passo a passo da dinâmica:
Primeira etapa:
- Pegar um bug da lista e explicá-lo aos participantes;
- Discutir com os participantes qual seria o esforço aplicado para resolver este bug. Nesta etapa pode haver alguma discussão ou impasse, mas um consenso se fará necessário.
- Mover o post-it do bug ou card para a respectiva coluna de esforço Pequeno/Médio/Grande em que as pessoas entraram em consenso.
- Pegar o próximo bug e repetir os passos anteriores até passar por toda a lista dos bugs.
Após finalizar a lista, teremos alguns bugs categorizados como esforço pequeno, médio e grande e, agora, esta divisão servirá de agrupamento para a próxima etapa da dinâmica.
Segunda etapa:
Primeiramente, devemos pegar todos os bugs que foram categorizados como esforço pequeno e reaplicar a dinâmica PMG. Fizemos nossa dinâmica com post-its, por isso aproveitamos para escrever ao lado de cada post-it o seu respectivo esforço dessa segunda etapa. Como output, os bugs que antes eram categorizados como P, agora estarão categorizados como PP, PM e PG. Em seguida repetir o procedimento para os médios e grandes. Ao final deste processo os bugs estarão categorizados em PP, PM, PG, MP, MM, MG, GP, GM ou GG.
Em seguida, repetimos o processo com os débitos técnicos e débitos de UX e por fim, colocamos a informação do esforço em cada uma das issues no nosso Github através de uma tag que nos auxiliará no momento de buscar as issues com esforço pequeno no futuro.
Onboarding de uma nova desenvolvedora
No mês de Agosto, a Camila Belo iniciou sua jornada como desenvolvedora front-end aqui no time do RD Station CRM. Após duas semanas no Get Ready da empresa, ela começou o Get Ready de Produto e Engenharia e, como citado no início deste post, ela teria o desafio de entregar uma tarefa até o final daquela terceira semana.
Foi aí que as issues com esforço categorizado entraram no desafio. Por ser desenvolvedora front-end, priorizamos débitos de UX que tínhamos categorizados como PP e passamos não apenas um, mas logo três para ela resolver.
Para contar como foi o processo, nada melhor do que um depoimento dela para explicar como foi essa primeira semana junto com o time:
“Esperava receber uma única issue que levasse a semana toda para ser resolvida, mas recebi três. Me disseram que estaria tudo bem se não desse para resolver todas, mas que tinham selecionado issues de esforço PP para serem resolvidas sobrando tempo para eu conciliar com as outras atividades do Get Ready de Produto. De fato a estimativa foi super assertiva, pois no segundo dia do Get Ready eu já tinha corrigido duas das três issues.
Vale muito contar que a revisão das minhas soluções foram rápidas, teve colaboração de todos e fazer o deploy foi tão simples que com uma única explicação aprendi a fazer! Deu tempo de resolver a terceira issue, e mais duas outras novas que recebi do Giacomini. Até o final da semana pude trabalhar e fechar cinco issues! Quatro para o Get Ready de produto e uma antes de ir embora pra casa na sexta-feira.
Resolver essas issues me fez navegar pelo sistema e ganhar familiaridade com ele, pois no Get Ready da RD não aprendemos sobre o CRM e após o Get Ready de Produto eu já me senti produtiva e engajada com o time a ponto de eu mesma abrir uma issue e conseguir trabalhar nela de maneira autônoma.”
— Camila Belo.
Como citado anteriormente, o principal objetivo da categorização do esforço é auxiliar a priorização de issues, porém, também percebemos o quanto esse trabalho está ajudando no onboarding de novos integrantes do time, permitindo uma rápida integração e passagem por todo fluxo de trabalho.
E aí, você também categoriza o esforço das issues do seu time? Se sim, compartilhe conosco de que forma você categoriza e ajude a comunidade compartilhando pouco mais sobre o assunto. :)
