← Ultimi articoli
💻 computer science

The 2nd Workshop on Agile Practice & Research: A Summary and Call For Research

Questo articolo riassume il 2° Workshop su Pratica e Ricerca Agile tenutosi presso XP 2026, che ha affrontato le persistenti lacune tra la ricerca accademica e la pratica industriale proponendo quattro proposte strategiche e tre specifici inviti alla ricerca per favorire una collaborazione più solida ed efficace.

Autori originali: Karen Eilers, Michael Neumann, Eva-Maria Schön, Mali Senapathi, Maria Rauschenberger, Tiago Silva da Silva

Pubblicato 2026-05-22
📖 5 min di lettura🧠 Approfondimento

Autori originali: Karen Eilers, Michael Neumann, Eva-Maria Schön, Mali Senapathi, Maria Rauschenberger, Tiago Silva da Silva

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina una città frenetica dove due gruppi di persone cercano di costruire lo stesso grattacielo, ma parlano lingue diverse e vivono in fusi orari differenti.

  • Gruppo A (I Ricercatori) sono come architetti che lavorano in una biblioteca silenziosa e climatizzata. Passano anni a disegnare progetti perfetti, studiando la fisica dei materiali e scrivendo manuali densi su come gli edifici dovrebbero essere costruiti.
  • Gruppo B (I Pratici) sono le squadre di costruzione sul cantiere fangoso e caotico. Devono affrontare la pioggia, i cambiamenti meteorologici, nuovi strumenti che arrivano ogni settimana e capi che vogliono l'edificio finito ieri.

Per oltre vent'anni, questi due gruppi hanno cercato di lavorare insieme allo sviluppo software "Agile" (un modo di costruire software che è flessibile e veloce). Ma, come spiega questo documento, continuano a non incontrarsi. I progetti degli architetti spesso sembrano troppo teorici per la squadra, e i problemi quotidiani della squadra cambiano troppo velocemente perché gli architetti possano scriverne in tempo.

Per risolvere questo problema, gli autori hanno organizzato un incontro speciale (un workshop) a San Paolo, in Brasile, riunendo 20 di questi architetti e costruttori per capire cosa non funziona e come risolverlo.

Le Tre Grandi Lacune

Il documento identifica tre principali "abisso" tra la biblioteca e il cantiere:

  1. La Lacuna Teorica (Manca il "Perché"):
    La squadra di costruzione spesso guarda i progetti degli architetti e dice: "Questo sembra ottimo in teoria, ma funziona davvero quando il vento ulula?". Il documento afferma che gran parte della ricerca è solo una raccolta di storie su ciò che è accaduto in un progetto specifico, senza una solida teoria di fondo che spieghi perché ha funzionato o se funzionerebbe altrove. È come avere una ricetta che dice "aggiungi sale" ma non spiega la chimica del perché il sale rende il cibo più buono.

  2. La Lacuna Temporale (Il "Quando" è sbagliato):
    Il cantiere cambia incredibilmente velocemente. Nuovi strumenti (come l'Intelligenza Artificiale) e nuovi modi di lavorare (come i team remoti) appaiono dall'oggi al domani. La biblioteca, invece, si muove lentamente. Quando un architetto finisce uno studio di 3 anni su uno strumento specifico, la squadra di costruzione è già passata alla prossima grande novità. La ricerca è spesso un anno o due indietro rispetto alla realtà del cantiere.

  3. La Lacuna di Trasferimento (Il "Come" è confuso):
    Anche quando gli architetti hanno un'ottima idea, la scrivono in una lingua comprensibile solo ad altri architetti (un pesante gergo accademico). La squadra di costruzione non riesce a leggerla, non ha tempo per decodificarla o non sa come trasformare l'idea astratta in un'azione concreta di martello e chiodo. La conoscenza c'è, ma è bloccata dietro una porta che la squadra non può aprire.

La Soluzione del Workshop: Una Riunione di Squadra

Per colmare queste lacune, i partecipanti al workshop si sono divisi in piccoli gruppi per fare brainstorming. Non si sono limitati a lamentarsi; hanno cercato le cause profonde e soluzioni immediate.

Dalla loro riunione, sono emerse Quattro Grandi Idee (Proposizioni) per far lavorare meglio i due gruppi insieme:

  1. Parla da Essere Umano: I ricercatori devono imparare a parlare come persone, non solo come professori. Dovrebbero scrivere blog, realizzare video e parlare ai raduni del settore, non solo su riviste accademiche. Devono tradurre i loro "progetti" in istruzioni che la squadra possa effettivamente utilizzare.
  2. Cavalca l'Onda: I ricercatori devono prestare attenzione a ciò che la squadra di costruzione si preoccupa ora. Invece di studiare ciò che era interessante cinque anni fa, dovrebbero concentrarsi sui problemi attuali come "come guadagniamo con questo?" o "come gestiamo questo nuovo strumento di IA?".
  3. Ricompensa il Lavoro di Squadra: Attualmente, non c'è molta ricompensa per un ricercatore nel frequentare una squadra di costruzione, o per un membro della squadra nel parlare con un ricercatore. Il documento suggerisce che dobbiamo creare migliori "incentivi" (come avanzamenti di carriera o riconoscimenti) affinché entrambe le parti voglia collaborare.
  4. Impara Facendo: Il documento suggerisce che i ricercatori dovrebbero utilizzare metodi "educativi" (come l'apprendimento basato su progetti) nella loro stessa ricerca. Proprio come gli studenti imparano meglio costruendo cose, i ricercatori dovrebbero strutturare i loro studi in modo più pratico e iterativo, invece di limitarsi a osservare da lontano.

L'Appello all'Azione: Tre Regole per il Futuro

Infine, gli autori lanciano un "Appello alla Ricerca", che è essenzialmente un insieme di regole che vogliono che i futuri ricercatori seguano per assicurarsi che il loro lavoro sia effettivamente utile:

  1. Sii Aperto (La Regola della "Casa di Vetro"): I ricercatori devono essere trasparenti. Dovrebbero condividere i loro dati grezzi, le loro note e il loro codice apertamente (Scienza Aperta). In questo modo, chiunque può verificare il loro lavoro, ripetere i loro esperimenti e costruire sui loro risultati. È come lasciare i progetti del cantiere su un tavolo pubblico affinché tutti possano vedere come è stato costruito l'edificio.
  2. Punta alla Qualità dello Standard Oro: Non limitarti a indovinare. La ricerca deve essere costruita su una solida base teorica e progettata con estremo rigore. Non dovrebbe essere solo una storia del tipo "l'abbiamo provato e sembrava ok"; deve essere uno studio scientificamente valido che può essere dimostrato funzionare di nuovo e di nuovo.
  3. Spiega il Valore: Ogni articolo di ricerca deve rispondere chiaramente alla domanda: "E allora?". Deve dichiarare esplicitamente come i risultati aiutano il mondo reale. Il documento fornisce esempi di "artefatti" (strumenti o framework) che i ricercatori possono creare. Alcuni si basano su risultati (come un nuovo modo di organizzare un team), e altri si basano su metodi (come una piattaforma che aiuta i team a raccogliere dati mentre lavorano). Entrambi devono mostrare chiaramente il loro valore alle persone che effettivamente svolgono il lavoro.

In sintesi: Il documento sostiene che affinché lo sviluppo software Agile continui a migliorare, i "pensatori" e i "fattori" devono smettere di parlarsi addosso. Devono parlare la stessa lingua, lavorare sulla stessa linea temporale e condividere i loro strumenti apertamente in modo che tutti possano costruire software migliore insieme.

Sommerso dagli articoli nel tuo campo?

Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.

Prova Digest →