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

Titolo

Stima dei Punti Storia in Agile: È il RAG un Percorso Migliore?

1. Il Problema

Nello sviluppo software Agile, la pianificazione degli sprint è un processo critico in cui il team stima lo sforzo necessario per completare le attività (User Stories) utilizzando i Punti Storia (Story Points - SP). La tecnica standard è il Planning Poker, un metodo basato sul consenso che coinvolge sviluppatori, tester e manager.
Sebbene efficace, il Planning Poker presenta due svantaggi principali:

1. Consumo di tempo: Richiede dai 5 ai 10 minuti per ogni attività; per progetti grandi (es. Kernel Linux), una sessione di pianificazione potrebbe richiedere mesi.
2. Bias umani: Le stime possono essere influenzate da dinamiche di gruppo, personalità dominanti o eccessivo ottimismo, portando a sovrastime o sottostime che causano sforamenti di budget o tempi morti.

Esistono approcci automatizzati basati su Machine Learning (ML), ma spesso mancano di interpretabilità o si basano su feature limitate. Questo studio indaga se l'approccio RAG (Retrieval-Augmented Generation) possa automatizzare la stima dei punti storia fornendo contesti storici rilevanti, mimando il processo umano di confronto con task simili, ma in modo scalabile e oggettivo.

2. Metodologia

Gli autori hanno proposto un sistema RAG composto da due moduli principali: un Retriever e un Generator.

• Dataset: È stato utilizzato il dataset di Tawosi et al., contenente 31.960 task da 23 progetti open-source di diverse dimensioni (piccoli, medi, grandi). I dati sono stati filtrati per rimuovere task incompleti, punti storia modificati successivamente o non appartenenti alla serie di Fibonacci (0, 1, 2, 3, 5, 8...).
• Modulo Retriever:
  • Per ogni nuovo task, il sistema genera embedding vettoriali del titolo e della descrizione.
  • Sono stati testati due modelli di embedding: BAAI (bge-large-en-v1.5) e SBERT (all-mpnet-base-v2).
  • Vengono recuperati i top_k task più simili dal dataset di addestramento basandosi sulla similarità del coseno. I valori di k testati sono stati 2, 3 e 4.
• Modulo Generator:
  • Utilizza il modello LLM Llama-3.2-3B-Instruct.
  • Riceve in input il task da stimare e i top_k task simili recuperati (con i loro titoli, descrizioni e punti storia reali).
  • Attraverso prompt engineering specifico, il modello è istruito a fornire una stima numerica basata sulla serie di Fibonacci, imitando il ragionamento umano.
  • È stato testato un parametro di temperature (0, 0.1, 0.2, 0.3) per bilanciare determinismo e creatività.
• Valutazione:
  • Metriche principali: MAE (Mean Absolute Error) e MdAE (Median Absolute Error).
  • Confronto con quattro baseline esistenti: TF-IDF, Deep-SE, LHC-SE e LHCtc-SE.
  • Test statistici: Test di Wilcoxon signed-rank (per confronti a coppie) e Test di Kruskal-Wallis (per confronti tra gruppi di dimensioni dei progetti).

3. Contributi Chiave

1. Prima applicazione del RAG alla stima dei Punti Storia: Questo studio è il primo a esplorare l'uso di Retrieval-Augmented Generation per questo specifico compito, superando i limiti dei modelli puramente generativi o di classificazione tradizionali.
2. Interpretabilità: A differenza delle "scatole nere" del Deep Learning, il sistema RAG mostra esplicitamente quali task storici sono stati utilizzati per generare la stima, aumentando la trasparenza e la fiducia degli sviluppatori.
3. Analisi sistematica dei parametri: Lo studio analizza come parametri di recupero (top_k) e generazione (temperature) interagiscano con la dimensione del progetto e la scelta del modello di embedding.

4. Risultati Sperimentali

Lo studio ha risposto a quattro domande di ricerca (RQ):

• RQ1 (Parametri di Recupero): I parametri ottimali variano in base alla dimensione del progetto e al modello di embedding. Ad esempio, per progetti grandi con BAAI, top_k=4 e temperature=0 sono ottimali, mentre per progetti piccoli con SBERT, top_k=4 e temperature=0.1 funzionano meglio. Non esiste una configurazione universale.
• RQ2 (Dimensione del Progetto): Non è stata trovata alcuna differenza statisticamente significativa nelle prestazioni (MAE) tra progetti piccoli, medi e grandi (p > 0.05 nel test di Kruskal-Wallis). Sebbene i progetti medi abbiano mostrato la media MAE più bassa, la varianza non è stata statisticamente significativa.
• RQ3 (Scelta del Modello di Embedding): Non c'è stata alcuna differenza statisticamente significativa tra l'uso di BAAI e SBERT (p = 0.16). Entrambi i modelli forniscono qualità di recupero comparabile per questo compito.
• RQ4 (Confronto con le Baseline): Sebbene il modello RAG abbia superato le baseline in alcuni progetti specifici (es. 7 volte contro LHC-SE su progetti piccoli), non ha mostrato una superiorità statisticamente significativa complessiva rispetto alle baseline (TF-IDF, Deep-SE, ecc.) quando testato con il test di Wilcoxon (p > 0.05 in tutte le categorie).

5. Significato e Conclusioni

• Risultato Principale: L'approccio RAG, sebbene competitivo e capace di fornire stime ragionevoli, non supera in modo statisticamente significativo i metodi di Machine Learning tradizionali già esistenti per la stima dei punti storia.
• Implicazioni:
  • L'automazione completa della stima, rimuovendo il giudizio umano, potrebbe non essere sufficiente per ottenere una precisione superiore, poiché la stima degli SP dipende fortemente dal contesto e dall'esperienza del team che i modelli attuali faticano a catturare pienamente.
  • Il vero valore del RAG risiede nel suo ruolo di strumento di supporto alle decisioni. Invece di sostituire il Planning Poker, il sistema può fornire ai team una lista di task storici simili e le relative stime, facilitando il dibattito e il raggiungimento del consenso durante la riunione di pianificazione.
• Lavori Futuri: Gli autori suggeriscono di migliorare la pulizia dei dati (rimozione di rumore), utilizzare dataset industriali controllati per ridurre i bias umani nelle etichette, e sperimentare il fine-tuning del generatore su dati specifici del progetto prima dell'applicazione RAG.

In sintesi, il paper conclude che il RAG è un approccio promettente per l'interpretabilità e l'efficienza, ma non rappresenta ancora una soluzione "migliore" in termini di pura accuratezza numerica rispetto agli stati dell'arte esistenti, richiedendo ulteriori ricerche per ottimizzarne l'efficacia.