Sviluppare software non basta: un progetto deve essere pianificato, verificato, finanziato, documentato e mantenuto. Nel mio intervento alla DevConf 2026 parto da questa distinzione per spiegare il project management e presentare gli strumenti che sto costruendo per organizzare il lavoro.

L’idea nasce dalla mia esperienza nello sviluppo e nel collaudo del software. Mi interessa soprattutto una domanda: una persona o un piccolo gruppo possono trasformare un’intuizione in un prodotto sostenibile senza perdere il controllo di attività, dati e decisioni?

Il project management parte da un problema da risolvere

Nel linguaggio quotidiano, gestire un progetto significa decidere che cosa realizzare, con quali risorse e in quanto tempo. Scrivere il codice è una delle attività necessarie, ma non risponde da solo a queste domande.

Nel talk richiamo tre vincoli: tempo, costo e ambito. L’ambito comprende ciò che il progetto deve consegnare e i suoi confini; costi e risorse riguardano denaro, persone e disponibilità effettiva; il tempo comprende scadenze e passaggi intermedi.

Sono elementi collegati. Una richiesta aggiuntiva può modificare il lavoro necessario, una dipendenza può rallentare una consegna e una stima iniziale può rivelarsi troppo ottimista.

La percentuale di progetti in ritardo o fuori budget citata nel parlato non è accompagnata da una fonte identificabile. Il ragionamento non ha bisogno di trasformarla in una statistica universale: anche un solo progetto concreto mostra quanto contino requisiti, priorità e comunicazione.

Il ciclo di vita del software

Presento sei attività fondamentali: analisi, progettazione, sviluppo, test, rilascio e manutenzione. L’analisi chiarisce il bisogno; la progettazione definisce una soluzione; lo sviluppo la implementa; i test cercano riscontri sulla qualità; il rilascio la rende disponibile; la manutenzione affronta difetti, cambiamenti e nuove esigenze.

Queste attività non devono necessariamente svolgersi una sola volta in sequenza. Possono essere ripetute e intrecciate, a seconda del processo adottato.

Insisto sul collaudo perché un prodotto destinato ad altre persone va verificato prima di essere presentato come pronto. Superare i test, però, non significa dimostrare che ogni difetto possibile sia stato eliminato. Occorre definire quali verifiche sono state eseguite e quale uso si vuole sostenere.

Anche la documentazione appartiene al lavoro. In un progetto aperto permette agli altri di capire come utilizzare, modificare e mantenere ciò che viene pubblicato.

Waterfall e Agile: scegliere in base all’incertezza

Nel modello a cascata descrivo una pianificazione che procede per fasi, con requisiti e documentazione definiti in anticipo. Può essere utile quando il contesto è sufficientemente stabile e le condizioni di consegna sono chiare.

Il limite emerge quando cambiano le esigenze: correggere decisioni prese molto tempo prima può comportare lavoro aggiuntivo. Non significa che ogni modifica richieda letteralmente di ricominciare tutto, ma che il suo costo va considerato.

L’approccio Agile valorizza invece il confronto frequente e l’adattamento. Nel Manifesto per lo sviluppo Agile la collaborazione e la risposta al cambiamento hanno un ruolo centrale; questo non elimina il valore di piani, strumenti e documentazione.

Non considero i due approcci identità a cui appartenere. La domanda utile è quanto sappiamo già del problema e quanto abbiamo bisogno di imparare attraverso l’uso del prodotto.

Scrum non è un altro nome per qualsiasi lavoro Agile

Nel talk uso Scrum per rendere concreto il lavoro a cicli: priorità, pianificazione, sviluppo, verifica del risultato e miglioramento del metodo.

È utile mantenere i termini precisi. Scrum è uno specifico quadro di lavoro; gli Sprint hanno durata fissa di un mese o meno. La Review riguarda il risultato e il confronto con gli interlocutori, mentre la Retrospective serve a migliorare efficacia e qualità del modo di lavorare. Il riferimento è la Scrum Guide.

Una serie di piccole consegne rigide, senza apprendimento e adattamento, non diventa automaticamente Agile. Questa distinzione risponde anche alla domanda del pubblico sui “tanti piccoli waterfall”. Le esperienze aziendali possono produrre compromessi, ma è importante capire che cosa si sta realmente praticando.

Ruoli e responsabilità: non sono soltanto titoli

Descrivo il project manager attraverso il coordinamento di obiettivi, tempi, costi e rischi. Presento poi Product Owner, Scrum Master e persone che costruiscono il prodotto.

Nel quadro Scrum, queste responsabilità non coincidono con una gerarchia in cui il project manager comanda tutti gli altri: la guida distingue Product Owner, Scrum Master e Developers. Questi ultimi non si limitano a digitare codice, ma concorrono a realizzare un risultato utilizzabile e alla sua qualità.

Per un progetto personale può accadere che una sola persona affronti molte di queste attività. Questo non equivale ad avere automaticamente implementato Scrum da soli: serve soprattutto a rendersi conto del lavoro che rimane, anche quando non esistono reparti separati.

Nel video accenno alla possibilità di usare agenti di intelligenza artificiale per programmare. Possono assistere alcune attività, ma il loro impiego non dimostra che sia possibile sostituire senza conseguenze un intero gruppo di sviluppo. Scelte, revisione, sicurezza e responsabilità del rilascio rimangono da gestire.

LibrePM: organizzare il progetto oltre l’editor di codice

Un IDE aiuta a sviluppare. Non tiene necessariamente insieme tutte le esigenze di pianificazione, finanziamento e documentazione. Da questo bisogno presento LibrePM.

Nel talk mostro il progetto come strumento per pianificare, monitorare risorse, organizzare scadenze e conservare documenti decisionali. Cito viste Kanban e Gantt, traguardi intermedi, registri dei rischi e riferimenti rispetto ai quali confrontare l’avanzamento.

La direzione progettuale è mantenere i dati sotto il controllo di chi lavora, con un uso locale. Il repository di LibrePM è il riferimento per descrizione, codice e stato delle versioni; non va confuso con un test indipendente delle funzioni annunciate nella conferenza.

Devo precisare due espressioni molto nette del parlato. “Locale” non significa invulnerabile: accessi al computer, copie dei dati e configurazione continuano a contare. E “zero dipendenze” non è una descrizione letterale sostenibile di un’applicazione costruita con framework, librerie e componenti di esecuzione. Semplificare l’installazione per l’utente è diverso dall’eliminare ogni dipendenza tecnica.

AssociaGo: il progetto vive anche dentro un’organizzazione

Il secondo strumento è AssociaGo, pensato per le esigenze delle associazioni e degli enti del Terzo settore. Nel video ne descrivo attività relative a persone, volontari, contabilità, assemblee, verbali, eventi ed esportazione dei documenti.

L’idea è collegare il lavoro organizzativo al progetto che si vuole realizzare. Un gruppo non deve soltanto decidere che cosa sviluppare: deve anche gestire chi partecipa, le risorse disponibili e le attività comuni.

La presentazione non equivale a una certificazione che il software soddisfi ogni obbligo contabile, amministrativo o normativo di qualsiasi ente. Funzioni e adeguatezza vanno verificate rispetto al contesto; un attestato di partecipazione generato in PDF, per esempio, non acquisisce automaticamente valore di qualifica riconosciuta.

Il repository di AssociaGo permette di seguire il progetto e consultare le informazioni tecniche aggiornate.

Pecie: scrittura, fonti e storia del documento

Il terzo progetto è Pecie, uno studio editoriale per testi lunghi e documentazione. Lo presento attraverso esigenze che conosco bene: organizzare capitoli, allegare materiali, mantenere una scaletta e scrivere senza perdere continuamente il contesto.

Markdown costituisce una parte dell’ambiente di scrittura; capitoli, modalità concentrazione e materiali di ricerca completano il progetto. Le citazioni bibliografiche richiedono le funzioni e gli strumenti previsti dal programma: non appartengono automaticamente a ogni possibile implementazione del Markdown di base.

Nel talk descrivo anche il tracciamento dei contributi e la storia delle modifiche, richiamando Git. L’esempio è lo scambio di un progetto tra me e un’altra persona, in modo da conservare informazioni su chi ha modificato il testo.

La quantità di testo prodotta può essere un dato utile, ma non determina da sola il valore intellettuale del contributo o i diritti d’autore. Idee, ricerca, revisione e responsabilità possono pesare molto anche senza aggiungere il maggior numero di pagine. Un nome impostato in un profilo, inoltre, non è una verifica legale dell’identità.

Recupero delle versioni ed esportazione

Pecie mira a rendere più semplice il ritorno a una versione precedente e a riunire ciò che serve per lavorare sul documento. Il recupero dipende comunque dalla presenza della versione salvata: nessun sistema può ripristinare un contenuto mai registrato.

Per l’esportazione cito Pandoc e formati come DOCX, ODT, EPUB, PDF e LaTeX. Convertire non significa mantenere perfettamente ogni caratteristica in qualsiasi destinazione; va controllato il documento prodotto e, per alcune uscite, la disponibilità dei componenti necessari.

Durante la conferenza dichiaro esplicitamente che Pecie è ancora in pre-rilascio, con un problema da risolvere. Mantengo questa informazione: il repository del progetto può evolvere, ma un aggiornamento successivo non rende retroattivamente definitiva la versione descritta nel talk.

Glaia e il limite delle promesse sulla privacy

Come aggiunta alla presentazione cito Glaia, il mio ambiente per accedere a più servizi di intelligenza artificiale. Ne apprezzo l’organizzazione delle sessioni, ma occorre evitare un equivoco: un sito aperto in un browser non può, per questo solo fatto, leggere liberamente tutti i dati degli altri siti.

Allo stesso tempo, separare una sessione non impedisce al servizio remoto di ricevere i messaggi inviati, le informazioni dell’account e i dati necessari alla connessione. L’applicazione non rende automaticamente locale l’elaborazione del modello e non certifica la conformità al GDPR di ogni utilizzo.

Queste distinzioni rendono più concreto l’obiettivo della privacy: capire quali dati rimangono nel dispositivo e quali vengono trasmessi, invece di affidarsi a una promessa assoluta.

Software libero, distribuzione e sostenibilità

Collego i progetti alla categoria Enterprise di Ufficio Zero Ayah, la distribuzione ammiraglia del progetto. L’integrazione facilita la scoperta degli strumenti, ma disponibilità e versione del singolo pacchetto vanno controllate: in particolare non cambia lo stato di pre-rilascio dichiarato per Pecie.

Nel parlato il nome della licenza viene abbreviato. Per i progetti bisogna leggere il relativo file LICENSE; nei repository consultati compare AGPL-3.0. La licenza Affero GPL versione 3 non vieta usi commerciali, compensi o finanziamenti e prevede condizioni specifiche anche per versioni modificate utilizzate tramite rete.

Alla domanda sui finanziamenti rispondo che non avevo ricevuto quelli descritti dal pubblico per realizzare i progetti presentati. È il racconto della mia situazione nel momento dell’intervento, non una conseguenza necessaria della licenza libera.

Le domande del pubblico riportano agli utenti reali

Nel finale emergono possibili usi nelle scuole, nella pubblica amministrazione e nella gestione di attività formative. Li considero scenari da approfondire, non adozioni già avvenute o garanzie di idoneità per ogni struttura.

Racconto anche una richiesta ricevuta per Glaia e trasformata in una funzione. È il collegamento più diretto con il tema iniziale: ascoltare, valutare una necessità, intervenire e rendere disponibile un miglioramento.

Un’idea acquista forza quando diventa comprensibile alle persone che dovrebbero usarla. Per questo il project management, nella mia prospettiva, serve anche a rendere più umano il lavoro tecnico: chiarire il problema, scegliere un risultato verificabile e costruire le condizioni per mantenerlo nel tempo.