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

1. Problématique

Dans le développement logiciel Agile, la planification de sprint repose souvent sur l'estimation de l'effort nécessaire pour accomplir des tâches, mesurée en points de story (Story Points - SP). La méthode standard, le Planning Poker, est un processus manuel, collaboratif et itératif qui présente plusieurs limites :

• Consommation de temps : Estimer chaque tâche prend entre 5 et 10 minutes, ce qui peut rendre la planification de grands projets (ex: noyau Linux) extrêmement longue.
• Biais humains : Les estimations peuvent être influencées par des personnalités dominantes, l'optimisme excessif des développeurs seniors ou d'autres biais cognitifs, conduisant à des dépassements de coûts ou à une mauvaise allocation des ressources.
• Besoin d'automatisation : Bien que des approches d'apprentissage automatique (ML) aient été proposées, elles souffrent souvent d'un manque d'interprétabilité ou d'une dépendance excessive aux vocabulaires spécifiques aux projets.

L'objectif de cette étude est d'évaluer si l'utilisation d'une architecture RAG (Retrieval-Augmented Generation) peut automatiser l'estimation des points de story avec une précision comparable ou supérieure aux méthodes existantes, tout en offrant une transparence accrue en s'appuyant sur des exemples historiques concrets.

2. Méthodologie

L'étude propose un cadre RAG composé de deux modules principaux : un Récupérateur (Retriever) et un Générateur.

A. Données

• Source : Utilisation du jeu de données de Tawosi et al., contenant 31 960 tâches issues de 26 projets open-source (23 projets retenus après filtrage).
• Prétraitement : Filtrage strict selon les recommandations de Porru et al. :
  • Exclusion des tâches dont les points de story ou les descriptions ont été modifiés après attribution.
  • Inclusion uniquement des tâches résolues ("addressed").
  • Suppression des points de story ne suivant pas la série de Fibonacci (0, 1, 2, 3, 5, 8, etc.).
• Séparation : Les données sont divisées chronologiquement (80 % pour l'entraînement, 20 % pour le test) pour simuler un scénario réel où seuls les historiques passés sont disponibles.

B. Architecture RAG

1. Module de Récupération (Retriever) :

   • Pour une nouvelle tâche, le système génère des embeddings vectoriels à partir du titre et de la description.
   • Modèles d'embedding testés : Deux modèles sont comparés :
     • bge-large-en-v1.5 (BAAI).
     • all-mpnet-base-v2 (Sentence-Transformers / SBERT).
   • Recherche de similarité : Utilisation de la similarité cosinus pour récupérer les top_k tâches les plus similaires dans le jeu de données d'entraînement. Les valeurs de top_k testées sont 2, 3 et 4.

2. Module de Génération (Generator) :

   • Modèle : Llama-3.2-3B-Instruct, choisi pour son équilibre entre performance et efficacité computationnelle.
   • Prompt Engineering : Le modèle reçoit les tâches récupérées (contexte) ainsi que la nouvelle tâche. Un prompt système et utilisateur stricts instruisent le modèle à :
     • Analyser la complexité relative par rapport aux exemples.
     • Produire une estimation numérique stricte basée sur la série de Fibonacci.
     • Éviter les textes superflus.
   • Paramètres de génération : Différentes températures (0, 0.1, 0.2, 0.3) sont testées pour évaluer l'impact de la déterminisme sur la précision.

C. Évaluation

• Métriques : Erreur Absolue Moyenne (MAE) et Erreur Absolue Médiane (MdAE).
• Comparaison : Les résultats sont comparés à quatre méthodes de base (baselines) :
  • TF-IDF (Machine Learning classique).
  • Deep-SE (Deep Learning avec LSTM/RHWN).
  • LHC-SE et LHCtc-SE (Méthodes basées sur le clustering et la modélisation de sujets).
• Tests Statistiques : Utilisation du test de rang signé de Wilcoxon (apparié) et du test de Kruskal-Wallis pour vérifier la significativité des différences.

3. Contributions Clés

• Première application du RAG : C'est la première étude à explorer spécifiquement l'utilisation du RAG pour l'estimation des points de story, en combinant récupération de contexte sémantique et génération par LLM.
• Interprétabilité : Contrairement aux modèles "boîte noire", l'approche RAG fournit aux développeurs les tâches historiques spécifiques utilisées pour l'estimation, mimant le processus de discussion du Planning Poker.
• Analyse systématique des paramètres : Étude détaillée de l'impact de la taille du projet, du choix du modèle d'embedding et des hyperparamètres de récupération (top_k, temperature).

4. Résultats Principaux

Les résultats sont présentés à travers quatre questions de recherche (RQ) :

• RQ1 (Paramètres de récupération) : Les paramètres optimaux (top_k et temperature) varient selon la taille du projet et le modèle d'embedding. Par exemple, les grands projets bénéficient souvent d'un top_k plus élevé (4) et d'une température plus faible (0) avec BAAI, tandis que les petits projets peuvent nécessiter des configurations différentes. Cependant, aucune configuration unique n'est universellement optimale.
• RQ2 (Impact de la taille du projet) : L'analyse par Kruskal-Wallis montre aucune différence statistiquement significative dans la performance (MAE) entre les petits, moyens et grands projets. Bien que les petits projets présentent une variance plus élevée, la taille du projet n'influence pas significativement la précision globale du modèle RAG.
• RQ3 (Choix du modèle d'embedding) : Le test de Wilcoxon indique aucune différence significative entre les performances des modèles BAAI et SBERT. Le choix du modèle d'embedding n'affecte pas de manière critique la précision de l'estimation dans ce cadre.
• RQ4 (Comparaison avec les baselines) :
  • Le modèle RAG obtient des résultats compétitifs et dépasse certaines baselines sur des projets individuels (notamment sur des projets de petite taille).
  • Cependant, les tests statistiques (Wilcoxon) révèlent que les améliorations ne sont pas statistiquement significatives par rapport aux méthodes de base (Deep-SE, TF-IDF, etc.) sur l'ensemble des projets.
  • Le modèle RAG ne parvient pas à rejeter l'hypothèse nulle selon laquelle il surpasse significativement les méthodes existantes.

5. Signification et Conclusion

Constat principal : Bien que l'approche RAG soit prometteuse en termes de concept (interprétabilité, utilisation de contextes réels), elle ne surpasse pas statistiquement les méthodes d'estimation traditionnelles ou d'apprentissage automatique existantes en termes de précision numérique (MAE) sur les jeux de données publics actuels.

Implications :

• L'automatisation complète de l'estimation des points de story en éliminant totalement le jugement humain semble difficile à réaliser avec une précision supérieure aux méthodes actuelles.
• La valeur principale du RAG réside potentiellement dans son rôle d'outil d'aide à la décision (Decision Support Tool). En présentant aux développeurs des tâches similaires et leurs estimations passées, le système peut faciliter la discussion et le consensus lors des réunions de Planning Poker, plutôt que de remplacer l'humain.

Travaux futurs :
Les auteurs suggèrent d'améliorer le nettoyage des données (réduction du bruit), de construire des ensembles de données industriels contrôlés (moins biaisés), d'explorer d'autres modèles d'embedding, et d'envisager un fine-tuning du générateur sur des données spécifiques à un projet avant l'application du RAG.

En résumé, le RAG est une approche viable et interprétable pour l'estimation des efforts, mais son adoption en tant que substitut direct aux méthodes humaines nécessite encore des raffinements pour atteindre une supériorité statistique significative.