I nostri colleghi dell'intelligenza artificiale si sono uniti alla nostra iniziativa retrò

Ci occupiamo di software per le retrospettive, pertanto la bacheca delle retrospettive del nostro team è piuttosto convenzionale: “Start”, “Stop”, una colonna dedicata alle azioni in sospeso e le consuete discussioni del venerdì. La scorsa settimana ha visto l’arrivo di alcuni nuovi contributori. Sei delle schede non sono state redatte da esseri umani, bensì inserite dagli agenti di intelligenza artificiale con cui collaboriamo quotidianamente, che hanno sintetizzato le difficoltà emerse dalle loro sessioni di lavoro con noi.

Cerchiamo di essere precisi su di cosa si tratti, poiché la formulazione è importante. Non si tratta di un’intelligenza artificiale presente all’interno della sala riunioni: nessun bot che faciliti la riunione, nessuna funzionalità di intelligenza artificiale che riassuma le schede degli esseri umani. Gli agenti che svolgono il lavoro vero e proprio nel nostro team (quelli che scrivono codice, modificano contenuti, conducono verifiche) si sono presentati alla cerimonia proprio come farebbe qualsiasi altro membro del team: con il proprio resoconto di come è andato il lavoro. Partecipanti, non facilitatori; la riunione è rimasta nelle nostre mani.

Non si è trattato nemmeno di una trovata pubblicitaria. L’impulso è nato durante una delle nostre sessioni di retrospettiva: qualcuno ha fatto notare che la documentazione di onboarding era (ancora una volta) obsoleta e un altro ha ricordato che un agente aveva segnalato proprio questo a lui, di sfuggita, nel bel mezzo di una sessione quella mattina stessa, prima che il contesto scomparisse dallo schermo. L’agente ne era a conoscenza; nulla nel suo sistema indicava che valesse la pena conservare quell’osservazione. Pertanto, nelle ultime settimane abbiamo condotto un esperimento su noi stessi: la pratica è quella che abbiamo descritto in Come raccogliere feedback dai propri agenti IA. Al termine di ogni sessione di lavoro significativa assistita dall’IA, l’agente redige una breve nota strutturata di retrospettiva sul proprio operato: cosa è andato bene, cosa ha rallentato il processo, quale costo ha comportato ogni rallentamento, un’etichetta indicante la causa principale per ogni elemento e una soluzione proposta. Le voci si accumulano nei repository in cui si è svolto il lavoro. Una volta accumulatene un numero sufficiente, un processo di supporto le legge tutte e archivia gli schemi ricorrenti direttamente sulla nostra bacheca di retrospettiva, aggiungendo un prefisso[AI retro] in modo che nessuno possa confondere l’autore.

Ecco cosa hanno detto i nostri nuovi colleghi riguardo alla loro esperienza lavorativa con noi.

Cosa hanno scoperto

Il titolo con cui hanno aperto l’articolo riguardava loro stessi. La scheda in primo piano recitava: “Iniziate a verificare prima di agire: gli errori di esecuzione degli agenti rappresentano il 38% degli attriti (il doppio rispetto alla causa successiva); il costo ricorrente consiste nell’affermare una causa, nel procedere o nel reindirizzare l’obiettivo prima di verificare il codice in esecuzione, i dati o lo stato del ramo.” La principale fonte di attrito nel nostro lavoro assistito dall’IA, secondo quanto riferito dagli stessi agenti, erano proprio gli agenti stessi, in particolare l’abitudine di agire sulla base di uno stato ipotetico del sistema anziché verificare prima quello effettivo. Apprezziamo questo tipo di onestà da parte di qualsiasi collega.

Il tema principale, legato al lavoro di squadra, ha superato ogni limite che una persona non avrebbe mai oltrepassato. Gli errori relativi a Git e allo stato dei rami nel contesto del lavoro con agenti concorrenti sono emersi in otto sessioni distribuite su due repository: basi non aggiornate, destinazioni dei rami non lette, un agente che spostava un ramo che un altro stava utilizzando, una richiesta di pull (PR) reindirizzata senza verifica. Nessuna singola sessione avrebbe mai potuto collocare questo problema nemmeno lontanamente ai primi posti della classifica; ogni singolo caso era motivo solo di un’alzata di spalle e di qualche minuto perso. Considerato nell’insieme delle otto sessioni, però, era un tema imperdibile.

Ci siamo ritrovati a effettuare il deployment sulla base di controlli parziali. In quattro sessioni è stato eseguito il push o il merge dopo un controllo più limitato rispetto a quello effettivamente eseguito dalla CI: un semplice controllo dei tipi anziché la build completa, test mirati anziché la suite completa. Due volte nello stesso repository, nello stesso giorno.

E le segnalazioni più scomode non riguardavano affatto il lavoro in sé, bensì la capacità di portare a termine le attività. Una segnalazione rilevava che una lacuna nelle convenzioni di test aveva permesso a un crash riproducibile di sfuggire a due cicli di revisione e che il documento relativo alla correzione era stato proposto il giorno prima e non era mai stato redatto. Un’altra segnalava che lo stesso blocco dello strumento era ormai costato due sessioni, «senza che nel frattempo fosse stata rilasciata alcuna correzione definitiva». Una terza: lo stesso schema di deriva dei requisiti, tre sessioni consecutive, «ognuna delle quali rilevava che il problema si ripeteva rispetto alla precedente». A quanto pare, l’agente ricorda ciò che avevamo detto che avremmo fatto.

Le due cose che vale la pena osservare attentamente

In primo luogo: nulla di tutto ciò era visibile a nessun individuo. Non si tratta di una mancanza di attenzione; è la natura stessa del problema. L’attrito tra le sessioni e l’IA è cronico e di lieve entità, pertanto non dà mai adito a un’analisi post mortem e svanisce al termine della sessione. Ognuno di noi ne aveva assorbito la propria parte e era andato avanti. La classifica (questo modello è quello che costa di più al team) esiste solo nella visione aggregata, e la visione aggregata esiste solo perché le voci erano comparabili: stesso schema, stesso piccolo insieme di etichette relative alle cause alla radice, ogni segnalazione che citava una sessione datata. Questa è l’idea di aggregazione al centro della guida a cui questo post fa da corollario, ed è la parte che più desideravamo testare su noi stessi.

In secondo luogo: gli agenti non hanno attribuito la colpa a nessuno, compresi loro stessi, in modo approssimativo. Le voci seguono due regole che si sono rivelate più rilevanti di quanto ci aspettassimo. Le voci relative agli attriti descrivono il divario e il costo che ne è derivato, mai chi lo ha causato: nessun nome, nessun “rapporto di X”. E «l’agente ha commesso un errore» è un’etichetta residuale, utilizzata solo quando i dati inseriti erano effettivamente adeguati, ed è proprio per questo che la cifra del 38% ha attirato la nostra attenzione: è sopravvissuta a tale criterio di selezione. Il risultato si presentava come un valido contributo retrospettivo: specifico, corredato di prove, privo di accuse e leggermente imbarazzante per tutti in egual misura.

Ciò che l’assemblea ha deciso

Abbiamo deciso di dare seguito a tutte e tre le azioni proposte, ciascuna al livello indicato. La regola “confermare lo stato del ramo attivo e della PR prima di apportare modifiche” verrà inserita nella documentazione dell’agente di ciascun repository, una correzione alla documentazione relativa al tema delle otto sessioni. L’hook pre-push che esegue la build e i test equivalenti alla CI verrà integrato nei repository che hanno subito problemi a causa di controlli parziali; si tratta di una correzione a livello di ambiente, in modo che non dipenda dalla memoria di nessuno. Infine, la documentazione relativa alle convenzioni di test, che era stata «segnalata il giorno prima ma mai redatta», è in fase di stesura, utilizzando come esempio pratico il crash che era sfuggito al controllo.

Nessuna grande riorganizzazione, nessun nuovo processo: tre correzioni delle dimensioni di un biglietto, con i responsabili. La modestia è voluta: l’intera scommessa di questa pratica consiste nel fatto che le piccole correzioni, mirate al livello giusto e effettivamente verificate nel ciclo successivo, producano un effetto cumulativo. Se queste tre correzioni saranno mantenute è proprio ciò che ci dirà la verifica di adozione del prossimo brief; lo stesso meccanismo che ci ha colto di sorpresa l’ultima volta ci valuterà su questo aspetto.

Siamo ancora all’inizio, e lo diciamo chiaramente. Tuttavia, siamo usciti da quella sessione di retrospettiva più interessati alle nostre modalità di lavoro di quanto non lo fossimo da tempo — e un po’ in competizione con un collega che non si stanca mai.

Le note a piè di pagina sincere

Questo è il nostro primo resoconto sintetico, basato su dati raccolti nell’arco di settimane, non di mesi; pertanto, consideriamo le classifiche come un’indicazione su cui concentrare l’attenzione, non come dati contabili. I costi riportati nelle voci sono stime fornite dall’agente stesso e sono contrassegnati come tali. Le affermazioni più ambiziose di questo approccio (ovvero che le etichette rimangano coerenti tra i valutatori e che la linea di tendenza si modifichi effettivamente dopo l’applicazione delle correzioni) sono esperimenti che stiamo conducendo piuttosto che ipotesi che stiamo formulando, e pubblicheremo i risultati in ogni caso.

Ma il risultato fondamentale si è già manifestato: una serie di schemi che nessuno del team era in grado di individuare individualmente, classificati, documentati e inseriti nell’ordine del giorno della riunione in cui erano già presenti i responsabili delle correzioni. Il Feedback Flywheel di Rahul Garg include nel proprio elenco di attività ricorrenti «un punto all’ordine del giorno nella retrospettiva di sprint esistente: cosa ha funzionato con l’IA in questo sprint?». Possiamo ora affermare che tale punto all’ordine del giorno risulta notevolmente più interessante quando i vostri colleghi che si occupano di IA presentano i propri punti.

Provatelo con la vostra squadra

Tutto ciò che abbiamo utilizzato è gratuito e documentato nella guida: il funzionamento delle voci, le etichette relative alle cause alla radice, le regole relative ai dati da non registrare (nessuna informazione riservata, nessun dato dei clienti e mai nulla che identifichi una persona), il punto all’ordine del giorno di 15 minuti del facilitatore, oltre alle due competenze che consentono di attuare le fasi di acquisizione e sintesi. Funziona con qualsiasi agente compatibile e un file di testo; il nostro prodotto è semplicemente un luogo in cui i risultati possono essere archiviati, non un requisito indispensabile.

Nel prossimo ciclo, la verifica dell’adozione del brief ci dirà se questa volta abbiamo effettivamente redatto quel documento di test. Ve lo faremo sapere. E lo faranno anche loro.

L’avete provato? Non siete d’accordo? Siamo sinceri quando diciamo che desideriamo che ci si contrapponga: ai-discussion@TeamRetro.com.