Gestire progetti in modo Agile

Le liste di task si perdono in infiniti scambi di e-mail. I complicati software di ticketing costringono ad un livello di gestione che può rasentare la follia. Nel tempo abbiamo imparato ad abbracciare, al loro posto, strumenti di lavoro intelligenti, fatti bene, creati con l’intento di favorire la collaborazione asincrona.

Indipendentemente dallo strumento scelto, ciò che conta veramente è creare uno spazio, virtuale o fisico, in cui sia facilmente visibile il lavoro da svolgere. In Moze utilizziamo lo strumento di project management come punto di riferimento per le attività da svolgere. Siamo attenti a dare importanza alle discussioni sul da farsi tra i membri del team. Seguiamo i principi della filosofia Agile, che valorizzano “il software funzionante più che la documentazione esaustiva”. Tuttavia, questo non significa lavorare partendo da specifiche vaghe. Ad esempio, un developer apprezza quando gli viene assegnato un task che è stato già esplorato nelle diverse casistiche e scenari possibili, si trova a suo agio nel partire da una documentazione sintetica ma completa. D’altra parte, se il compito è di natura esplorativa, è importante specificarlo chiaramente in anticipo, consentendo ai membri del team di interpretarlo in modo flessibile.

Organizza il lavoro in sprint

All’inizio della nostra attività, impostavamo il lavoro creando lunghe liste di to-do su Basecamp. Quando si affrontano progetti che durano diversi mesi, questo approccio può essere controproducente. Questo perché la proiezione del progresso è basata unicamente sulle scadenze impostate per i diversi task. Alla fine, ci si ritrova a lavorare come criceti su una ruota, sempre ad inseguire la prossima scadenza, avendo comunque di fronte un’infinita lista di cose da fare. Ci siamo passati, lo sappiamo bene.

Iniziando a lavorare in maniera Agile, abbiamo organizzato le attività interne ad ogni progetto in sprint, cioè in iterazioni di durata prestabilita, di solito di due settimane. In pratica, questo significa suddividere un progetto più ampio in sottoprogetti più piccoli. Ogni iterazione porta a una versione incrementale del prodotto su cui si sta lavorando. L’obiettivo di ogni sprint è lo sviluppo di qualcosa – una parte del prodotto – che sia completo e funzionante, almeno dal punto di vista delle funzionalità di base. Naturalmente, ci sarà sempre tempo per apportare miglioramenti o aggiungere al prodotto nuove funzionalità. Tuttavia, alla fine di ogni sprint condividiamo con il cliente una sua nuova, anche se piccola, parte funzionante.

Questo obiettivo non è sempre facile da raggiungere. Lavorando per i clienti, i primi sprint sono quelli più critici. Ad esempio, occorre spesso trascorrere l’intero primo sprint concentrati sul setup tecnico del progetto e lo sviluppo dei componenti di base dell’interfaccia utente. Nonostante questo possa dare l’impressione di una fase iniziale più lenta, in realtà consente di essere molto più rapidi nei successivi sprint di implementazione. È cruciale essere trasparenti da subito e stabilire chiaramente le aspettative, altrimenti un cliente non tecnico potrebbe preoccuparsi che il progetto sia già in ritardo sin dall’inizio.

Definisci un processo

È importante anche definire in modo chiaro il flusso di lavoro che verrà seguito durante gli sprint. Nel corso degli anni, abbiamo sviluppato un processo molto semplice che ci consente di mantenere un livello sufficiente di organizzazione. Utilizzando uno strumento di Project Management, suddividiamo le attività di un progetto in colonne. La prima colonna è il backlog, dove inseriamo tutte le attività da svolgere. Poi abbiamo una colonna dedicata alle attività che verranno affrontate nello sprint corrente. Segue una colonna per il controllo qualità (Quality Assurance), in cui un altro membro del team può supportare la revisione del lavoro di design o sviluppo. Infine, abbiamo una colonna per le attività completate durante lo sprint, che verranno presentate al cliente.

Forse è dovuto all’orizzonte temporale più breve o al fatto che le persone tendono a lavorare meglio quando le attività sono organizzate in “timebox”, ma seguendo questo approccio, abbiamo l’impressione che i progetti siano più gestibili. Poi, questo processo si integra perfettamente con i contratti agili, in cui assieme al cliente si concorda che l’unità di progresso (e di remunerazione) è il singolo sprint, insieme al valore prodotto al momento della sua conclusione.