Agile Story-Point Estimation: Is RAG a Better Way to Go?

Título: Estimativa de Pontos de História Ágil: O RAG é um Caminho Melhor?

Autores: Lamyea Maha, Tajmilur Rahman e Chanchal Roy.
Conferência: ICPC '26 (34ª Conferência Internacional IEEE/ACM sobre Compreensão de Programas).

---

1. Problema e Motivação

No desenvolvimento de software ágil, o Planejamento de Sprint é uma etapa crítica onde a equipe estima o esforço necessário para concluir tarefas do backlog do produto. A técnica mais comum é o Planning Poker, que utiliza Pontos de História (Story Points - SP) como unidade de medida para complexidade e esforço.

Apesar de seus benefícios (como feedback contínuo e adaptação), o Planning Poker apresenta desafios significativos:

• Consumo de Tempo: Estimar manualmente cada tarefa pode ser extremamente demorado (ex: estimar o kernel do Linux levaria meses).
• Vieses Humanos: A presença de membros dominantes ou a influência de desenvolvedores seniores pode enviesar as estimativas dos juniores, levando a subestimações, atrasos e falhas de projeto.
• Inconsistência: Diferentes equipes podem atribuir valores diferentes para a mesma tarefa.

O objetivo deste estudo é investigar se a Geração Aumentada por Recuperação (RAG - Retrieval-Augmented Generation) pode automatizar essa estimativa, oferecendo uma alternativa mais rápida, consistente e interpretável, baseada em dados históricos de projetos similares.

---

2. Metodologia

Os autores propuseram um framework de RAG composto por dois módulos principais: um Recuperador (Retriever) e um Gerador (Generator).

2.1. Dados

• Fonte: Utilizaram o conjunto de dados de Tawosi et al., que contém 31.960 tarefas de 23 projetos de código aberto (após filtragem).
• Pré-processamento:
  • Remoção de tarefas sem descrição ou sem SP atribuído.
  • Exclusão de tarefas com SP alterados após a atribuição inicial (para evitar ruído).
  • Filtragem de tarefas com status não resolvidos.
  • Validação de que os SPs seguem a série de Fibonacci (0, 1, 2, 3, 5, 8, etc.).
• Divisão: Os dados foram divididos em 80% para treino e 20% para teste, mantendo a ordem temporal (apenas dados históricos disponíveis para o treino).

2.2. Módulo Recuperador (Retriever)

• Função: Identificar tarefas históricas semanticamente similares à nova tarefa a ser estimada.
• Modelos de Embedding: Foram testados dois modelos para gerar vetores de texto (título + descrição):
  1. BAAI: bge-large-en-v1.5.
  2. SBERT: all-mpnet-base-v2.
• Mecanismo: Utiliza similaridade de cosseno para recuperar os top_k (k=2, 3, 4) tarefas mais similares do conjunto de treino.

2.3. Módulo Gerador (Generator)

• Modelo: Llama-3.2-3B-Instruct.
• Função: Receber a nova tarefa e o contexto das tarefas recuperadas para gerar uma estimativa numérica.
• Prompt Engineering: Foi desenvolvido um prompt estruturado que instrui o modelo a agir como um especialista ágil, analisar a complexidade relativa das tarefas de referência e retornar apenas um número da série de Fibonacci, evitando textos longos ou desvios.
• Hiperparâmetros: Foram testadas diferentes temperaturas (0, 0.1, 0.2, 0.3) para controlar a aleatoriedade da geração.

2.4. Avaliação e Comparação

• Métricas: Erro Absoluto Médio (MAE) e Erro Absoluto Mediano (MdAE).
• Baselines (Métodos de Comparação):
  1. TF-IDF: Aprendizado de máquina clássico.
  2. Deep-SE: Rede neural profunda (LSTM + RHWN).
  3. LHC-SE e LHCtc-SE: Métodos baseados em clusterização e modelagem de tópicos (LDA).
• Testes Estatísticos:
  • Kruskal-Wallis: Para verificar diferenças entre tamanhos de projetos.
  • Wilcoxon Signed-Rank Test: Para comparações pareadas entre modelos e baselines.

---

3. Contribuições Principais

1. Primeira Investigação de RAG para SP: Este é o primeiro estudo a explorar a aplicação de RAG especificamente para a estimativa de Pontos de História, preenchendo uma lacuna na literatura que focava principalmente em modelos de aprendizado de máquina tradicionais ou LLMs sem recuperação contextual explícita.
2. Abordagem Interpretável: Diferente de "caixas pretas", o sistema RAG mostra ao desenvolvedor quais tarefas históricas foram usadas para a estimativa, mimetizando o processo humano de comparar com o passado durante o Planning Poker.
3. Análise de Hiperparâmetros e Escala: Investigação sistemática de como o tamanho do projeto (pequeno, médio, grande) e a escolha do modelo de embedding afetam a precisão.

---

4. Resultados e Discussão

Os resultados foram analisados através de quatro Perguntas de Pesquisa (RQs):

• RQ1 (Parâmetros de Recuperação):

  • Os parâmetros ideais (top_k e temperatura) variam dependendo do tamanho do projeto e do modelo de embedding.
  • Projetos grandes tendem a se beneficiar de mais contexto (top_k=4) e menor aleatoriedade (temp=0), enquanto projetos menores podem precisar de menos contexto ou maior flexibilidade.
  • Conclusão: Não há uma configuração universalmente ótima; a sintonização deve considerar o tamanho do repositório.

• RQ2 (Impacto do Tamanho do Projeto):

  • Projetos de tamanho médio apresentaram os menores erros médios (MAE), seguidos por grandes e pequenos.
  • Teste Estatístico: O teste de Kruskal-Wallis mostrou nenhuma diferença estatisticamente significativa no desempenho entre os grupos de tamanho de projeto (p > 0.05).
  • Conclusão: O tamanho do projeto não afeta significativamente a precisão do RAG neste contexto.

• RQ3 (Escolha do Modelo de Embedding):

  • Comparação entre BAAI e SBERT.
  • Teste Estatístico: O teste de Wilcoxon não encontrou diferenças significativas entre os dois modelos de embedding (p > 0.05).
  • Conclusão: A escolha entre BAAI e SBERT não impactou significativamente a precisão final.

• RQ4 (Comparação com Baselines):

  • O modelo RAG superou as baselines (Deep-SE, TF-IDF, LHC-SE, LHCtc-SE) em vários projetos individuais (ex: venceu 7 vezes o LHC-SE em projetos pequenos com SBERT).
  • Teste Estatístico: No entanto, ao analisar a significância estatística global, não houve diferença significativa entre o RAG e as baselines (todos os p > 0.05).
  • Conclusão: O RAG é competitivo e comparável aos melhores métodos existentes, mas não demonstrou superioridade estatística consistente.

---

5. Significância e Conclusão

O estudo conclui que, embora a abordagem baseada em RAG seja competitiva e ofereça uma alternativa automatizada viável para a estimativa de esforço, ela não superou estatisticamente os métodos de estado da arte existentes (como Deep-SE ou métodos baseados em clusterização) em termos de precisão numérica pura.

Pontos Chave para o Futuro:

• Limitação Atual: A remoção completa do julgamento humano (substituindo o Planning Poker) pode limitar a performance, pois a estimativa de SP depende fortemente de contexto e negociação que modelos puramente baseados em dados históricos podem não capturar totalmente.
• Recomendações:
  • O RAG deve ser visto como uma ferramenta de suporte à decisão (exibindo tarefas similares para ajudar a equipe a debater) em vez de um substituto total do processo humano.
  • Futuras pesquisas devem focar na limpeza de dados (redução de ruído nas descrições), uso de dados industriais controlados e ajuste fino (fine-tuning) do modelo gerador específico para o projeto.

Em suma, o RAG é uma "boa direção" para a interpretabilidade e eficiência, mas ainda precisa de refinamento para superar a precisão dos métodos estabelecidos em cenários de estimativa puramente numérica.