Il backlog non ti salverà
Quando partecipo alla pianificazione di un progetto software, osservo subito quali attività ricevono una stima riconoscibile e quali entrano nel piano come conseguenze implicite. Lo sviluppo ha un impegno espresso in ore o punti. Il test compare accanto a una scadenza. La correzione di un difetto possiede una priorità che può spostare altre attività. La documentazione, invece, compare spesso alla fine, quando il resto del lavoro è già stato distribuito.
In quel momento la sua collocazione sembra un dettaglio organizzativo. Non lo è. Se una guida tecnica, una procedura di esercizio o una decisione architetturale rimangono fuori dal calcolo iniziale, il gruppo riceve un messaggio preciso: quel lavoro serve, però vale meno. Quando lo sprint si accorcia o arriva un’urgenza, la documentazione può essere rinviata senza dichiarare apertamente quale costo si sta trasferendo al futuro.
Ho visto accadere la stessa cosa con i test e con la manutenzione. La nuova funzione produce un risultato che si può mostrare. Una verifica completa, una spiegazione leggibile o una configurazione ripulita producono invece condizioni che permettono al risultato di durare. Il sistema di pianificazione registra più facilmente ciò che ha un inizio e una fine visibili. Il lavoro che protegge il risultato rimane esposto alla prima riduzione di capacità.
La stima decide che cosa conta
Una stima non predice il futuro con precisione matematica. Esprime una valutazione condivisa sull’impegno necessario per ottenere un risultato entro determinate condizioni. Quando assegno tempo a un’attività, riconosco che quella attività richiede attenzione, competenze, coordinamento e verifiche. Quando la lascio fuori, tratto il suo costo come se potesse essere assorbito senza conseguenze.
La distinzione è importante perché il lavoro tecnico e organizzativo contiene molte operazioni che un elenco superficiale non mostra. Per scrivere una guida occorre comprendere chi la userà, ricostruire il comportamento del sistema, verificare i passaggi, scegliere gli esempi, consultare gli esperti, revisionare il testo e conservare la versione corretta. Il tempo dipende dalla qualità delle informazioni già disponibili e dalla stabilità dell’oggetto descritto.
Una funzione che cambia ogni due giorni produce una guida diversa da quella richiesta da una funzione già verificata. Se il piano considera soltanto la scrittura materiale, la stima non è prudente: ha semplicemente lasciato fuori il lavoro necessario per capire che cosa si deve scrivere.
Lo stesso criterio vale per un test. Un test significativo richiede dati, ambiente, condizioni di esecuzione, interpretazione dei risultati e gestione degli esiti inattesi. Una correzione può richiedere codice, verifica, aggiornamento della configurazione, comunicazione e controllo dopo il rilascio. La voce «correggere il difetto» può indicare un’operazione breve oppure un percorso che coinvolge più persone e più sistemi.
Quando il piano registra soltanto l’azione più visibile, il gruppo impara a proteggere ciò che viene contato. Chiude un’attività, rimanda la verifica, lascia in sospeso la spiegazione e accumula un problema che apparirà più avanti sotto forma di rilavorazione, attesa o dipendenza da una persona precisa.
L’equivoco della documentazione Agile
Il Manifesto Agile assegna maggiore valore al software funzionante rispetto alla documentazione completa. Questa frase ha avuto una funzione correttiva: ha reagito a documenti prodotti in anticipo, lontani dall’uso reale e trattati come prove di avanzamento. Il testo non autorizza però a considerare inutile ogni documentazione. I principi del Manifesto insistono sulla consegna frequente, sulla qualità tecnica, sulla riflessione del gruppo e sulla capacità di adattarsi.
La documentazione serve quando rende possibile una decisione, un uso, una verifica o una manutenzione. Una pagina che descrive ogni dettaglio senza aiutare nessuno diventa peso. Una procedura che permette di ripristinare un servizio, formare una persona o verificare una scelta conserva invece una parte del valore prodotto dal lavoro.
Il problema nasce quando l’opposizione fra software e documentazione diventa una scorciatoia per evitare di decidere quale documentazione serva. A quel punto il gruppo non riduce il lavoro inutile: rinvia il lavoro necessario e lo riconsegna a chi arriverà dopo, spesso con informazioni più povere e meno tempo disponibile.
Anche la gestione della conoscenza deve quindi entrare nel flusso del lavoro. La pagina tecnica va collegata alla funzione, al ticket, alla versione e alla responsabilità di revisione. Una decisione architetturale deve indicare quale problema risolve, quali alternative sono state scartate e in quali condizioni deve essere riesaminata. Questi legami aiutano chi arriva dopo a comprendere il percorso senza interrogare ogni persona coinvolta nell’origine del progetto.
Che cosa significa davvero «finito»
Nei gruppi che usano Scrum, la Definition of Done descrive lo stato che un incremento deve raggiungere per soddisfare i requisiti di qualità del prodotto. La regola ha una conseguenza pratica: un’attività non è conclusa soltanto perché il codice è stato scritto o perché il ticket ha cambiato colonna.
La Definition of Done spiegata da Scrum.org collega il completamento a una comprensione condivisa del lavoro svolto e degli standard rispettati. La sua utilità dipende dalla concretezza dei criteri. Se la definizione include test completati, revisione del codice, aggiornamento della documentazione necessaria e condizioni di rilascio, il gruppo riconosce questi passaggi come parte del risultato. Se si limita a formule generiche sulla qualità, lascia alle persone il compito di interpretarla ogni volta.
La Definition of Done non risolve da sola il problema. Un gruppo può includere la documentazione nella checklist e continuare a considerarla un’attività residuale. Il criterio diventa efficace quando influenza la capacità dello sprint, le priorità e il momento nel quale il gruppo dichiara concluso l’incremento. Il lavoro non entra davvero nella definizione del risultato finché non entra anche nella decisione sulle risorse.
Questa considerazione vale oltre Scrum. Ogni metodo che prevede una conclusione deve chiarire che cosa viene consegnato, quale verifica ha ricevuto e quale conoscenza rimane disponibile. Un prodotto che funziona soltanto nella memoria di chi lo ha costruito è un risultato fragile, anche quando il registro delle attività mostra una lunga serie di chiusure.
Il debito di conoscenza
Quando un gruppo rinvia più volte la spiegazione di una scelta, non accumula soltanto pagine mancanti. Accumula un debito di conoscenza. Questo debito comprende decisioni prive di motivazione, configurazioni che nessuno sa più spiegare, procedure valide soltanto nella memoria di una persona e termini usati con significati diversi.
Il costo emerge quando un collega cambia ruolo, quando il servizio deve essere ripristinato o quando un nuovo progetto riutilizza una soluzione precedente senza conoscerne i limiti. La squadra può continuare a lavorare finché la persona che possiede il contesto rimane disponibile. Quando quella persona manca, una parte del lavoro ricomincia da capo.
Nel lavoro professionale riconosco il debito di conoscenza da alcuni segnali. Le persone chiedono più volte la stessa spiegazione. Un documento possiede molte versioni senza indicare quale sia valida. Una configurazione funziona, però nessuno sa dire quale problema risolva. Il ticket è chiuso, ma la decisione che lo ha prodotto non è consultabile. Il rapporto fra un requisito e la modifica realizzata si ricostruisce attraverso messaggi personali.
Questi segnali non dimostrano da soli che il processo sia sbagliato. Indicano però che il gruppo sta pagando un costo per il lavoro lasciato fuori dalla pianificazione. Il costo può comparire come attesa, rilavorazione, dipendenza, errore o formazione ripetuta. La forma cambia; l’origine spesso rimane la stessa.
Il National Institute of Standards and Technology richiama, nella propria riflessione sulla gestione della conoscenza, ruoli chiari, processi sistematici di condivisione, individuazione degli asset conoscitivi e strumenti adeguati all’organizzazione. Il punto che considero più utile riguarda il passaggio: la conoscenza deve sostenere il lavoro delle persone e rimanere disponibile durante le transizioni. Non serve soltanto quando tutto procede secondo programma. Serve soprattutto quando una persona cambia incarico, un sistema viene sostituito o una decisione deve essere riesaminata.
La qualità produce lavoro invisibile
La qualità non coincide con l’assenza di difetti riscontrati. Comprende la possibilità di capire che cosa è stato fatto, in quali condizioni, con quali limiti e attraverso quali verifiche. Per questo una parte importante della qualità rimane invisibile quando la si osserva soltanto attraverso il numero di attività concluse.
Le pratiche di consegna continua insistono sul feedback rapido, sulla possibilità di verificare la qualità del sistema e sulla riduzione del rischio del rilascio. La guida DORA alla continuous delivery collega il feedback sulla qualità e sulla possibilità di rilascio alla capacità del gruppo di lavorare con maggiore affidabilità. La documentazione dei test, dei requisiti e delle decisioni rende quel feedback interpretabile: senza contesto, un esito dice che qualcosa è accaduto; con il contesto, aiuta a capire che cosa fare dopo.
Anche l’automazione può aumentare o ridurre il debito. Una regola che esegue una classificazione chiara riduce un’attività ripetitiva. Una regola costruita sopra categorie ambigue propaga rapidamente un errore. Il problema non dipende dall’automazione in astratto. Dipende dalla qualità della decisione che il sistema rende eseguibile e dalla possibilità di capire quando quella decisione non vale più.
Il rischio opposto: documentare per dimostrare di avere documentato
Difendere la documentazione non significa trasformare ogni attività in un obbligo documentale. Moduli, approvazioni e controlli possono produrre pagine che nessuno consulta. Un archivio può diventare più voluminoso e meno utile. La misura deve dipendere dall’uso previsto.
Una procedura operativa deve permettere di agire. Una decisione deve permettere di ricostruire un ragionamento. Una guida introduttiva deve ridurre il tempo necessario per iniziare. Una nota tecnica può conservare un’ipotesi che non ha ancora raggiunto lo stato di regola. Confondere questi oggetti produce documenti formalmente ordinati e praticamente ambigui.
La domanda utile non è «abbiamo documentato?». È «che cosa dovrà capire un’altra persona per usare, verificare, modificare o ripristinare questo lavoro?». La risposta stabilisce il livello di dettaglio, il luogo nel quale conservare il contenuto, la relazione con gli altri oggetti e la responsabilità di revisione.
Proteggere la capacità di lavorare domani
Un’organizzazione Agile non diventa più rapida soltanto perché cambia spesso priorità. Se ogni urgenza può interrompere il lavoro in corso, il gruppo perde la capacità di completare attività che richiedono concentrazione. La riunione può chiamare tutto questo flessibilità. Dopo qualche mese il sistema lo riconosce come dipendenza da poche persone, errori ripetuti e tempo speso a cercare quanto avrebbe dovuto essere già disponibile.
La velocità apparente si ottiene spesso sottraendo tempo al lavoro che conserva il risultato. Si consegna la funzione, si rinvia il test approfondito, si lascia la procedura in sospeso e si registra l’attività come quasi conclusa. Nel momento della consegna il piano appare più leggero. Il progetto successivo riceve però un oggetto che richiede spiegazioni, correzioni e nuove verifiche.
Secondo me il punto decisivo è questo: l’Agile deve proteggere la possibilità di lavorare domani. La protezione non nasce da una formula, da una cerimonia o da una voce aggiunta al backlog. Nasce da una decisione esplicita sul risultato, da una stima che comprenda il lavoro necessario e da una definizione di qualità che il gruppo possa verificare.
Quando un’organizzazione impara a stimare documentazione, test, manutenzione e revisione delle decisioni, smette di scegliere fra consegna immediata e qualità futura. Comincia a governare il costo reale delle proprie priorità. La conoscenza diventa parte del prodotto del lavoro, non un residuo affidato alla memoria di chi era presente.
Riferimenti
- Principi del Manifesto Agile.
- Scrum.org, What is a Definition of Done?
- National Institute of Standards and Technology, Baldrige Criteria Commentary.
- DORA, Continuous delivery.