O índice Adadot caiu: quais pedidos de integração rever na retrospectiva?

O sprint começa bem, mas perto do fim há um conjunto de alterações de código à espera de revisão. O responsável pelo desenvolvimento precisa de perceber como o trabalho ficou bloqueado, e não apenas observar uma queda na «velocidade» da equipa. O Adadot analisa em conjunto dados da atividade de desenvolvimento e da colaboração, podendo fornecer pistas para essa retrospectiva. A decisão sobre o que mudar continua, porém, a exigir o regresso às tarefas concretas e à discussão com a equipa.

Este artigo analisa o cenário com base nas descrições oficiais do produto e em casos históricos publicados pelo fornecedor. Não foi ligada qualquer conta de equipa nem verificada a capacidade preditiva do modelo.

O site do Adadot apresenta como utilizações do produto a relação entre o tempo de espera das revisões e o número de comentários, bem como análises de cenários «What if». Isto pode ajudar o responsável a formular perguntas mais concretas: se os pedidos de integração tivessem sido revistos mais cedo, seria possível aliviar o bloqueio atual? Trata-se de uma hipótese a verificar, não de uma causa que o modelo já tenha provado pela equipa.

A próxima retrospectiva pode ser organizada como uma pequena experiência. Comece por manter a mesma equipa, projetos do mesmo tipo e períodos de observação com a mesma duração. Registe o que mudou e escolha os pedidos de integração que, nesse período, se arrastaram até ao fim do sprint. Na ferramenta de desenvolvimento original, consulte os momentos de submissão e revisão, o âmbito das alterações, os registos das discussões e eventuais mudanças de última hora nos requisitos associados. As perguntas frequentes do Adadot também o apresentam como uma camada de análise sobre as ferramentas do dia a dia e indicam que as informações ao nível das tarefas devem continuar a ser consultadas no Jira ou no Gitlab.

Assim, é possível distinguir várias formas de agir: se o âmbito dos requisitos muda repetidamente, apressar as revisões não resolve o problema; se as alterações são demasiado grandes para serem compreendidas rapidamente, pode discutir-se como dividi-las; se os revisores só entram no processo no final, é necessário preparar a colaboração mais cedo. Esta classificação é um método de retrospectiva, não uma afirmação de que o Adadot atribui automaticamente estas etiquetas a cada pedido.

Num caso sobre a sua própria equipa, publicado em agosto de 2022, o Adadot descreve como dividiu o trabalho em partes menores de acordo com a dimensão das alterações em cada pedido de integração. Ao discutir a lentidão das integrações na segunda metade do sprint, a equipa também percebeu que começava pelas tarefas fáceis e deixava para depois os problemas difíceis, mais sujeitos a bloqueios. Passou então a tratar o trabalho difícil mais cedo.

Este material é uma retrospectiva do fornecedor sobre a sua própria equipa. Não permite prometer que outra equipa conseguirá o mesmo aumento de trabalho processado. Ainda assim, oferece um ponto de partida útil: os gráficos revelam mudanças, a equipa explica o contexto e, por fim, altera-se a divisão das tarefas ou a ordem de execução. Não se deve saltar a discussão intermédia e transformar uma oscilação pontual da pontuação numa conclusão sobre o desempenho de um colaborador.

Escolha inicialmente apenas um ajuste, como discutir mais cedo as tarefas com dependências externas. No próximo período comparável, observe não só se a espera diminui, mas também se aumenta o trabalho que precisa de ser refeito ou se as tarefas difíceis foram simplesmente empurradas para fora do período observado. Se o número de tarefas concluídas aumentar sem que os problemas de entrega diminuam, ainda não se pode declarar a melhoria bem-sucedida.

As perguntas frequentes explicam que o índice normaliza os dados para uma escala de 1–10 e aplica ponderações. Por isso, serve para indicar onde olhar, mas não equivale diretamente a horas de trabalho, valor para o negócio ou contribuição individual. Tarefas com contextos diferentes também não devem ser ordenadas apenas com base numa pontuação.

A página do produto afirma que as métricas individuais são agregadas e anonimizadas ao nível da equipa e que as métricas de equipa exigem pelo menos 3 membros. Declara ainda que não processa nem guarda código. Antes de estabelecer a ligação para uso regular, o responsável deve, mesmo assim, confirmar com a equipa os campos visíveis na conta real, as fontes dos dados, as permissões de acesso e o âmbito de utilização autorizado pela organização. As declarações do produto não substituem esta verificação nem significam que os registos individuais em bruto possam ser mostrados livremente numa retrospectiva.

Se a questão for apenas quem assume hoje um determinado pedido, é mais adequado coordenar diretamente na ferramenta de tarefas já utilizada. A camada de análise do Adadot merece mais ser experimentada quando os bloqueios se repetem, atravessam várias tarefas e a equipa quer usar os dados para ajustar o processo em conjunto. O resultado da experiência deve ser uma mudança de processo que possa ser explicada claramente e verificada depois, não uma classificação individual mais elaborada.