In questa guida ti parlerò di Project Management e di come puoi riuscire a centrare le scadenze senza sfondare il budget che ti è stato messo a disposizione.

Ti rivelerò le migliori strategie per diventare un esperto di sviluppo software e di come entrare a far parte di quel 30% di persone che concludono con successo progetti IT.

Le informazioni che troverai all’interno di questo articolo valgono migliaia di euro. E’ quanto ho speso di tasca mia per seguire corsi, partecipare a conferenze ma soprattutto ho applicato provando sulla mia pelle quali strategie funzionano e quali no.

Gli ingredienti del successo sono responsabilità ed automazione.
Ma come ottenerle?

Mettiti comodo e prenditi il tempo necessario a leggere questa guida con calma ed attenzione.

Sei pronto?

Partiamo!

---

La regola più importante per gestire progetti software da centinaia di migliaia di euro. La mia storia.

Prima di passare ai tecnicismi facciamo un tuffo nel passato.

Primavera 2005, Torino.

Mi ero appena laureato: ero diventato un ingegnere informatico.

“Dopo tutti questi anni a studiare gli insegnamenti dei professori più brillanti d’Italia e d’Europa, conosco tutto ciò che mi serve per lavorare“, mi dicevo.

(si ero molto ingenuo, ma lo avrei capito a mie spese solo anni più tardi).

Ti dico la verità.

Ho fatto meno fatica a laurearmi, rispetto a diplomarmi alle superiori.

Sai perché?

Alle superiori ti impongono un piano giornaliero di studi, all’università ti comunicano una data dell’esame e sta a te organizzarti per arrivare preparato a quel giorno.

La mia strategia per superare gli esami era questa: raccoglievo tutti gli esercizi scritti degli esami passati e li svolgevo fino allo sfinimento.

Se l’esame era orale seguivo tutte le interrogazione segnandomi le domande e le risposte corrette.

Studiavo lo stretto necessario. Tutto ciò che non rientrava in uno scritto o orale passato, semplicemente lo ignoravo.

Ero preparato alla perfezione?

No (ma non mi interessava).

Mi sono laureato in 5 anni?

Si, e durante gli studi ho potuto anche coltivare i miei interessi.

"done is better than perfect" insegna Benjamin Franklin.

Ma la lezione più importante che ho imparato non è stata questa.

Per raggiungere un obiettivo devi analizzare il contesto e adattarti.
Questo è stato il metodo vincente nel mio percorso di studi.

Sai qual è la cosa strana? Nello sviluppo software invece facciamo l’esatto contrario.

Troppo spesso siamo convinti di avere la ricetta magica: abbiamo sempre usato quel linguaggio di programmazione, quella libreria o quella metodologia, perché cambiare?

Pensaci

Siamo biologicamente costruiti per opporci al cambiamento.

Ogni stimolo esterno viene analizzato per primo dalla parte del cervello chiamato rettiliano il cui compito è rispondere alla domanda: è pericoloso?

E’ l’istinto di sopravvivenza.

Per l’uomo delle caverne sottovalutare il rischio poteva significare essere sbranato da bestie feroci.

Non un bel finale, vero?

Oggi il massimo del pericolo è mancare la consegna di una milestone. (noi siamo decisamente più fortunati!)

Meglio un male già noto ad un bene non sperimentato raccontava un detto popolare nel Gattopardo di Giuseppe Tomasi.

Come accade nello sviluppo software.

Facciamo un tuffo nel futuro.

Era Marzo 2018 quando squilla il telefono.

“Ciao Gianluca, sono Samuel“.
“Ciao Samuel dimmi.”

Era parecchio che non sentivo Samuel. Sette anni prima lo avevo convinto a trasferirsi da Udine a Milano e fare uno stage nella mia azienda, stage divenuta poi assunzione.

Al tempo mi aveva colpito la sua parlantina, la curiosità e la capacità di parlare di argomenti di sviluppo software su cui non aveva esperienza diretta.

Samuel era appena entrato come sviluppatore nella sede italiana di una multinazionale nel campo del lavoro interinale.

Questa, come tantissime multinazionali era ancora strutturata come i reparti IT nati negli anni novanta/duemila: tecnologie legacy a volte neanche supportate dai propri vendor.

“Gianluca, abbiamo bisogno di un architetto software per definire le linee guida per sviluppare le nuove applicazioni dei prossimi 10 anni, sei interessato?“.

Non ero molto convito, ma visto che Samuel era è un amico decisi di andare a capirne di più con il loro responsabile IT.

La sede era in centro Milano, in una zona in cui ho abitato per due anni.

Quanti ricordi!

Il mio cocktail bar preferito (non solo il mio visto che è stato inserito tra i migliori 100 al mondo), la pasticceria dove facevo colazione ogni mattina e il cinema dove andavo tutti i weekend.

E’ una delle poche zone di Milano che ancora oggi puoi vivere come quarant’anni fa.

Il responsabile IT mi raccontò della sua idea: partire con un progetto pilota per testare la nuova architettura e le nuove tecnologie. Buon piano, se non fosse che nel dipartimento non esisteva un team e neanche un processo formalizzato.

La divisione IT era formata da un insieme di sviluppatori, ognuno concentrato solo delle proprie applicazioni senza sapere nulla del lavoro degli altri.

E’ un pattern ricorrente nelle organizzazioni IT delle grandi aziende: io lo chiamo modello “one man show”.

Ricapitolando:

• nuovo progetto da integrare in una struttura legacy
• sviluppatori “one man show” fortemente ancorati a vecchie tecnologie e oberati dal supporto giornaliero
• 4 mesi per rilasciare la prima release del software
• requisiti funzionali incompleti

Gli uomini delle caverne avrebbero preferito continuare a confrontarsi con le bestie feroci piuttosto che affrontare una sfida simile!

ALT!

Non vi serve un architetto software.

Il vostro (grosso) problema è un altro.

Gli dissi.

Samuel e il responsabile IT rimasero scioccati.

Non potevano credere alla frase che avevo appena pronunciato.

Si, avevo detto loro che non sapevano cosa stavano facendo. (Non proprio la migliore mossa quando discuti un lavoro)

In pratica, mi ero licenziato prima ancora di iniziare.

Gli dissi che stavano rischiando grosso.

Cosa succede se a ridosso di una scadenza il vostro ‘one man show’ dedicato a quel progetto si ammala?

Cosa fate se vi accorgete di non essere in grado di rispettare una scadenza?

Puoi immaginare la risposta.

CAZZO!

Non avevano la padronanza del loro processo di sviluppo!

E’ come costruire un aeroporto senza una torre di controllo.

Rimodernare la tecnologia sarebbe stato uno sforzo inutile se avessero continuato ad affidare il successo dei progetti a singoli sviluppatori.

Per farla breve avevano bisogno di un processo di project management strutturato.

Aspetta!

Tutti parlano di project management, ma cosa è realmente? Non preoccuparti, tra poco saprai tutto.

Gli suggerii di riorganizzare il processo di sviluppo e solo dopo di preoccuparsi della parte tecnologica.

Ripetiamolo!

Per raggiungere un obiettivo devi analizzare la situazione e adattarti.

Riuscii a convincerli e mi ascoltarono.
Almeno in parte.

Si resero conto del rischio che stavano correndo ma erano altrettanto fermi nella necessità di riprogettare subito anche l’architettura tecnologica.

Mia madre mi diceva sempre: non fare mai due cose alla volta, le farai male entrambe.

Forse era l’unico consiglio di mia mamma che ho sempre seguito!

Gli raccontai quanto sarebbe stato complicato modificare le abitudini di un team di sviluppatori fortificate in dieci anni.

Se allo stesso tempo gli avessimo chiesto di abituarsi a nuove tecnologie e nuovi pattern di sviluppo avrebbero sicuramente reagito con molta resistenza.

Samuel ed il responsabile IT erano d’accordo con me del rischio che avrebbero corso, ma la decisione di rimodernare la tecnologia “proveniva dall’alto” e non poteva essere messa in discussione.

Quando "dall'alto" prendono decisioni tecniche non è mai un buon segno.

Ero davanti ad un problema non da poco.

Quale?

Semplice: un cliente voleva intraprendere una strada secondo me troppo rischiosa.

Certo, era una bella opportunità ed una sfida affascinante, ma il rischio valeva la pena?

Il rischio nel Project Management. Come prendere le decisioni giuste.

Gianluca, sei fuori di testa?

Un cliente ti ha appena dato carta bianca per scegliere l’architettura e la metodologia che preferisci e ti tiri indietro? Non senti l’adrenalina salire in circolo?

Sono fatto così.

Se sono ragionevolmente sicuro di andare incontro ad un treno in corsa, mi sposto.

Gianluca, mi hai detto poco fa che senza rischio non c’è cambiamento????

Vero bisogna rischiare, non essere incoscienti.

A volte il rischio è la strada per il successo, altre volte è quella verso il baratro.

La differenza è tutta dietro una attenta valutazione.

Lascia che ti spieghi.

L’85% delle persone che investono in borsa perde il proprio denaro.

Non perdono perché rischiano, perdono perché non sanno rischiare.

La stragrande maggioranza delle persone esegue operazioni a mercato spinta dall’emotività.

“Questa è la volta buona, me lo sento”.

Se ragioni così ragiona quello che senti è il suono della sconfitta.

Pensaci.

Il 15% che guadagno in borsa non ha la sfera di cristallo, sta rischiando esattamente come il restante 85%.

La differenza è che quel 15% sa cosa sta facendo, ha preso una decisione dopo una accurata valutazione senza essere influenzato dalla parte emotiva.

Ma allora, come si valuta il rischio?

Quando ti trovi a valutare il rischio prova a seguire questi sei punti:

• Fai trascorrere (almeno) qualche ora prima di fare la tua valutazione. Il tempo aiuta ad attenuare il fattore emotivo.
• Raccogli più dati possibili che possano supportare la tua valutazione
• Se non hai dati fai una lista dei pro e dei contro (è banale ma sempre utile)
• Chiediti. Posso semplificare qualcosa abbassando il rischio?
• Se andasse male, quali sarebbero le conseguenze?
• Se andasse male, come dovrò reagire?

L’ultimo punto è il più importante.
E’ la tua exit strategy.

Ricordati.

Cadrai sempre in piedi, se hai una buona exit strategy che compenserà (almeno parzialmente) il tuo rischio.

La prima regola di un buon investitore è: rischia solo il capitale che, se perdessi, non modificherebbe il tuo tenore di vita.

Noi non siamo trader (almeno in questo contesto) ma proviamo ad declinare la stessa regola nel nostro contesto.

La prima regola di un manager IT è non mettere a rischio l'operatività dell'azienda.

Prendi il caso della multinazionale: cambiare tutto insieme avrebbe messo a rischio i processi aziendali così come hanno funzionato (nel bene e nel male) fino a quel giorno.

Sai cosa ho fatto?

Niente.

Ho semplicemente salutato Samuel, il responsabile IT ed ho trascorso il resto della giornata distraendomi e facendo altro.

Ho preso tempo, così da non prendere decisioni d’impulso.

La mattina dopo andai in un bosco vicino casa a fare le mie riflessioni (il verde e l’aria buona mi aiutano a riflettere meglio).

La valutazione fu semplice. La mia esperienza mi confermava la prima sensazione: il rischio è troppo alto.

In caso di fallimento (molto probabile) si sarebbe spaccato il team attuale e avremmo causato ritardi a cascata nella manutenzione del software legacy.

Non una gran prospettiva.

Ho rifiutato la proposta?

No.

Provo sempre a fornire almeno una alternativa al mio cliente.

Cercai quindi di ragionare su scenari differenti che prevedessero sia una riorganizzazione del processo che la modernizzazione della tecnologia, così come mi è stato chiesto.

Il mio pensiero era uno solo: come abbassare il rischio?

Creare un nuovo team per un progetto in poco tempo. Si, ma come?

Avevo una certezza.

Il team esistente doveva rimanere concentrato sull’operatività giornaliera. Nessuna nuova tecnologia, nessun nuovo processo.

Almeno all’inizio.

Per il nuovo progetto avremmo dovuto costruire un nuovo team che fosse basato su una governance diversa e padroneggiasse tecnologie più moderne.

La nostra idea era di sfruttare il progetto pilota per creare un caso vincente e, una volta consolidata la nuova organizzazione, estenderla anche al team interno.

Risultato raggiunto. Avevamo preservato l’operatività.

Peccato che per farlo, abbiato aggiunto un fattore di rischio sul progetto pilota: la costruzione di un team nuovo.

Da zero o quasi.

E se non fosse realmente un rischio?

E se il team fosse invece un’opportunità?

Lascia che ti spieghi.

Dovevamo introdurre un nuovo modo di lavoro e nuove tecnologie.

Ma nuove per chi?

Erano nuove per l’azienda, certo non per il team che avremmo costruito. Sarebbe bastato applicare metodologie e tecnologie consolidate nel mondo dello sviluppo software, adattandole al contesto.

Senza inventarci nulla.

In questo modo avremmo avuto il vantaggio di costruire rapidamente un team rivolgendoci al mercato ed abbassando il rischio.

Accadde proprio questo.

Inserimmo nel team due persone di un partner con cui avevo lavorato con successo su svariati progetti in passato e di cui io mi fidavo ciecamente.

Lavorare con persone che condividono il tuo stesso mindset e utilizzano tecnologie mainstream, ti permette di partire molto più rapidamente.

Il resto del team sarebbe stato composto da Samuel, un altro sviluppatore dell’azienda che avrebbe lavorato da una sede remota nel sud Italia ed un Project Manager interno che si sarebbe occupato delle priorità.

Avevamo pensato anche al dopo.

A fine progetto Samuel avrebbe avuto gli strumenti per gestire la riorganizzazione del team interno secondo l’esperienza accumulata nel corso del progetto pilota.

BINGO!

Avevamo trovato il modo di sperimentare un nuovo approccio per l’azienda mantenendo un livello di rischio sostenibile.

Il cliente fu entusiasta della proposta.

Avevo la loro fiducia.

DOVEVAMO SOLO INIZIARE.

Ci serviva mettere in campo un processo di Project Management efficace nel minor tempo possibile.

Ma che diavolo è il Project Management?

E’ l’organizzazione delle risorse, delle metodologie e delle tecniche atte a pianificare e monitorare le azioni necessarie a raggiungere un obiettivo strategico nei vincoli di tempo e costi definiti.

“Gianluca, non si capisce un cazzo”

Facciamo un passo alla volta.

Settimana scorsa ero in riunione con un cliente. Dovevano concludere gli sviluppi della prima release di un prodotto entro un mese e mezzo.
Speriamo di farcela, fu la frase conclusiva dell’incontro.

Non ho mai visto nessun obiettivo raggiunto affidandosi alla speranza. Non basta nello sviluppo software, nella scienza e neanche nello sport. La speranza non serve neppure quando giochi a carte con gli amici.

La speranza non è una strategia.

Allora cosa serve?

Il nostro obiettivo è portare a termine con successo un progetto software (dovrà diventare la tua ossessione!)

Per riuscirci devi essere in grado di rispondere ad alcune domande.

FERMATI!

Dobbiamo trovare un accordo. (si hai capito bene, un accordo!)

Dimmi, quali sono per te i parametri che decretano il successo o l’insuccesso di un progetto software?

Pensaci bene.

La risposta a questa domanda deve essere la stella polare che dovrà guidare tutte le tue decisioni nel corso di un progetto.

Perchè i progetti software falliscono?

Sappi che il 60% dei progetti software nell’IT falliscono. (fonte IBM)

Falliscono perché non rispettano le scadenze, richiedono un extra budget oppure non raggiungono una qualità adeguata.

Addirittura il 20% dei progetti sono abbandonati prima di andare in produzione.

Una strage.

• scadenza
• budget
• qualità

Sono questi i parametri di valutazione di un progetto.

Sembrano ovvi, ma non lo sono. O meglio se lo fossero le percentuali di successo sarebbe molto più alte, non credi?

Riflettiamo su ognuno di questi punti insieme.

Partiamo dalle scadenze.

Troviamo sempre delle scuse per giustificare i ritardi.

I ritardi non sono ammissibili.

Mi spiego meglio.

Ogni software nasce con uno scopo ed in base alla data che hai accordato con il tuo committente molto probabilmente sono state programmate azioni come:

• bloccare giornate degli utenti per fare dei test
• organizzare programmi di traning per imparare il prodotto
• avviare campagne di marketing
• pianificare delle entrate economiche grazie al nostro software

Il reparto IT è un ingranaggio nell’organizzazione di una azienda, spesso è il primo anello della catena: se falliamo noi fallirà tutto il processo a valle.

In pratica, un nostro ritardo farà accumulare una montagna di costi (o mancati guadagni) che qualcuno dovrà sobbarcarsi a causa nostra.

Te lo spiego con un esempio.

Immagina di essere tornato a scuola durante un compito in classe. (_ho i brividi come te al solo ricordo di quel moment_o).

Stai svolgendo il tuo compito (magari anche bene!) quando suona la campanella e il professore ti dice di consegnare ma tu non hai concluso.

Pensa a come l’avrebbe presa il professore se gli avessi risposto:

“Mi scusi professore non ho finito, ma non si preoccupi il compito sta venendo una bomba e glielo consegnerò domani“.

Stai sentendo nella tua testa le urla del professore, vero?

Nello sviluppo software è lo stesso: devi consegnare, fine. Non ci sono scuse.

Gianluca ma esistono gli imprevisti, come li gestisco per rispettare le scadenze?

Ci arriviamo dopo non preoccuparti.

Prima parliamo di qualità.

ATTENZIONE!

Non sto parlando di qualità del codice.

E’ il momento di svelarti un segreto, preparati.

Sicuro di essere pronto?

Non frega niente a nessuno che il tuo codice sia di alta qualità.

Aggiungo. Ed è giusto così.

So che è difficile da digerire per chi fa il nostro mestiere.

Io stesso amo scrivere codice e sono fissato con tutte le tecniche per produrre software robusto e mantenibile.

Il software nasce con uno scopo: deve risolvere un problema ad un costo più basso rispetto a risolvere lo stesso problema in modo differente. (ovviamente il costo va considerato in tutto il suo ciclo di vita: sviluppo, manutenzione e utilizzo).

Mi stai dicendo che devo fregarmene di investire nella qualità del codice?

No! Ti sto dicendo un’altra cosa.

Scrivere dell'ottimo codice deve essere un mezzo non il fine.

Prima impareremo a convivere con questa realtà, prima faremo del bene al nostro cliente. (e di riflesso anche a noi)

Proseguiamo.

Ti stai chiedendo cosa si intende per qualità di un progetto, giusto?

Ti faccio un esempio.
Quante volte capita di fare l’analisi con un cliente, sviluppare il software, consegnarlo e sentirsi dire: ma io mi aspettavo qualcosa di diverso!

La qualità è esattamente questo.

Significa azzerare il divario tra ciò che ha in testa il cliente e ciò che fa il software.

Non serve scrivere un software robusto, scalabile, senza bug, con una grafica accattivante se questo risolve un problema diverso rispetto al desiderio del cliente.

Non preoccuparti, scoprirai in questo articolo come risolvere questo divario.

Siamo arrivati all’ultimo parametro di valutazione di un progetto: il budget.

Rispettare il budget è importante per il nostro cliente.

Bravo Gianluca, dimmi un’altra banalità!

Odio essere banale. La banalità fa sprecare tempo eso bene quanto sia prezioso il tuo (e il mio) tempo.

Però hai ragione, è banale. Ciò che non è banale il motivo per cui è importante rispettare il budget.

So cosa stai pensando.

E’ importante perché il cliente vuole risparmiare.

Sbagliato!

Rispettare il budget non significa sviluppare un progetto con poche risorse, o peggio ancora con risorse non sufficienti.

Una volta stabilito un congruo budget (non ho detto basso, ho detto congruo!) l’azienda può pianificare il costo ipotizzato nei propri flussi economici ed organizzandosi di conseguenza.

Ricordi quando ti parlavo di rischio?

Sapere che chi sviluppa il prodotto rispetterà i costi, permette all’azienda di valutare in modo attendibile i rischi dell’investimento che sta sostenendo.

Fantastico!

Siamo allineati su come valutare il successo di un progetto.

Siamo pronti a fare un passo in avanti.

Il checkup del Project Management.

Torniamo alle domande necessarie per portare (con successo) a termine un progetto.

• Quando sarà disponibile la funzionalità A?
• Quanto costerà la funzionalità A?
• Quanto è costata la funzionalità A?
• Che vantaggio darebbe al business avere disponibile la funzionalità A rispetto alla funzionalità B?
• Quante funzionalità riusciamo a rilasciare costantemente in un periodo di tempo?
• Se potessimo investire 100 (persone, infrastruttura, training o servizi), come dovremmo spenderlo per massimizzare il ritorno?
• Se dovessimo abbassare i costi di 100, cosa dovremmo tagliare per minimizzare l’impatto?

Il cliente (chi paga) e il team (chi lavora) devono fare scelte cruciali durante tutta la vita di un progetto.
Più e più volte.

Il Project Management è lo strumento in grado di rispondere in modo oggettivo alle domande necessarie a condurre le scelte strategiche di un progetto.

In modo oggettivo e suffragato dai dati, non da sensazioni.

Ma come? (si, come?)

Seguimi.

Hai bisogno di metriche.

La buona notizia è che non ne servono tante, la cattiva è che servono quelle giuste.

Se torturi i dati abbastanza, alla fine confesseranno ciò che vuoi.

Darrell Huff

Ricordati però che i dati sono costosi da raccogliere (e mantenere): più ne acquisisci maggiore sarà lo sforzo richiesto a te e al team per pulirli, analizzarli e mantenerli.

Accumulare dati che poi lasci a far muffa è come riempire una stanza di libri che sai non leggerai mai: inutile.

Senza le giuste competenze e i giusti strumenti è impossibile portare a termine progetti in tempo budget e qualità.

E’ come una meravigliosa auto senza freno, acceleratore e sterzo: incontrollabile.

Aspetta però.

Ogni progetto ha bisogno di un processo di Project Management costruito ad hoc. Non esiste la ricetta perfetta ma va affinata giorno per giorno in base ai dati che raccoglierai ed analizzerai con il tuo team.

Per questo è fondamentale dotarti dei tool giusti.

Puoi usare Jiira, Trello, Excel, Azure DevOps, GitHub, una lavagna in ufficio.

Usa quello che vuoi. L’importante è che il tool (o i tool) scelto ti permetta di rispondere alle domande importanti.

Io nella maggior parte dei casi utilizzo Azure DevOps (ex Team Foundation Server) perché:

• E’ una soluzione all-in-one. Azure DevOps mette a disposizione degli strumenti per gestire l’intero processo: raccolta dei requisiti, gestione delle release e milestone, sviluppo, time tracking, continuous integration, deploy, testing, gestione dei bug.
• Supporta diversi template di progetto. Puoi creare dei progetti con il modello che si adatta meglio alle tue esigenze tra Basic, Agile, Scrum o CMMI.
• Gestisce lo stato dei backlog. Azure DevOps permette di tracciare le nuove richieste, quelle aperte, chiuse e in lavorazione; di quest’ultime permette di tracciare il tempo rimanente (fondamentale come vedremo tra poco).
• Si basa su git. Puoi creare un numero illimitato di repository privati.
• Supporta test automatici e manuali. Traccia i risultati dei test automatici e offre strumenti per gestire i piani di test manuali ed integrarli nel processo di QA (Quality Assurance).
• Ha una suite di collaborazione per sviluppatori. Azure DevOps mette a disposizione un sistema molto semplice per gestire discussioni e Code Review del team all’interno delle Pull Request.
• Compatibile con Excel. Puoi gestire le richieste con Excel (comodo per il Project Manager) oppure con altri client come Office, la web app o Visual Studio (Code) (comodo per lo sviluppatore).
• E’ versatile. Ogni utente può configurarsi report e grafici personalizzati e pianificare il lavoro tramite dashboard, lavagne Kanban o backlog.
• Integra una pipeline di Continuous Integration e Delivery. Offre una semplice interfaccia per creare pipeline di build in qualsiasi linguaggio (Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android e iOS) ed automatizzare i rilasci su qualsiasi piattaforma come Docker, Kubernetes, servizi Azure, AWS, GCP o on premise.
• Mette a disposizione del team un artifact repository. Puoi pubblicare e distribuire pacchetti Maven, npm, NuGet e Python accessibili solo al tuo team.
• Storia dei backlog. Puoi collegare ai backlog tutte le attività del team: codice, commit sul repository, code review, test, rilasci e bug. Da ogni attività puoi risalire alla richiesta originale ed analizzarne la storia.
• Azure DevOps espone API e Webhook. Puoi estendere ed integrare tutti i dati e i processi di Azure DevOps con le tue applicazioni e processi.
• Estensioni Azure DevOps. Il marketplace per le estensioni puoi collegare applicazioni e servizi che già utilizza la tua organizzazione come Slack, Teams, Email, Jiira, Office, Trello, Zendesk, Zapier.
• E’ self hosted. Non sei costretto ad installare e mantenere nessun server (ma esiste anche una versione on premise).

Insomma, tutto quello che può servirti è disponibile ed inoltre è gratis fino a 5 utenti.

Non hai più scuse: crea il progetto e partiamo!

Si, ma da dove partiamo?

Setup del modello organizzativo

Torniamo alla multinazionale.

Il nuovo modello organizzativo doveva essere costruito secondo alcuni principi necessari a superare i problemi presenti fino a quel momento:

• scalabilità del team. Mai più one man show, dovevamo distribuire il rischio su tutto il team ed essere in grado di inserire velocemente nuove figure nel team in caso di necessità.
• abbracciare il cambiamento. Il business della multinazionale è soggetto a normativa molto stringente che cambia frequentemente. E’ necessario riuscire ad adeguarsi rapidamente alle nuove leggi.
• pianificazione attendibile. Dobbiamo mettere in grado l’azienda di organizzare i propri processi tenendo conto del software che sarà prodotto.
• anticipare il ROI. Su cosa dobbiamo concentrarci come team di sviluppo per portare più valore possibile e il prima possibile all’azienda?

Adattamento, obiettivi chiari, velocità e frequenza di rilasci.

Sembrano proprio alcuni dei principi del manifesto Agile.

Se non conosci i principi Agili ti consiglio di leggere il manifesto: ti capiterà spesso di trovarti in contesti in qui potrebbero esserti molto utili.

ATTENTO PERO’!

Non sto dicendo che i processi Agili sono il miglior modello organizzativo possibile (ti assicuro che nella mia carriera ho coscientemente gestito processi con modelli Waterfall, e non cambierei quella scelta).

Devi sempre considerare cosa vuoi ottenere e scegliere la metodologia che più ti avvicina agli obiettivi che ti sei prefissato.

Non è finita qui.

Una volta scelta la metodologia non prenderla come dogma ma adattala al tuo team e al tuo contesto.

• obiettivi
• Analisi
• Scelta
• Adattamento

Sono questi gli step da seguire che ti porteranno alla definizione del miglior modello organizzativo per il tuo team.

Ora posso riprenderti a parlare del progetto con la multinazionale.

Per fartela breve abbiamo scelto un processo iterativo e incrementale basato su sprint di 2 settimane.

Gianluca, che roba è uno sprint?

Lo sprint è un ciclo di lavoro a durata breve e costante (non più grande di un mese, generalmente 2 settimane) finalizzata ad incrementare il prodotto del maggior valore (di business) possibile (ROI, Return Of Investment**).**

Lo sprint inizia con un meeting chiamato sprint planning in cui sono decise tutte e sole le attività in ordine di priorità, che saranno lavorate nello sprint.

Lo sprint si conclude con una nuova versione del software pronta per essere rilasciata in produzione.

Fine dello spiegone.

Concentriamoci su quattro parole chiave:

• costante. Scegliere un periodo di tempo fisso permette di costruire metriche confrontabili tra sprint (la più famosa è la velocity, indicatore che esprime l’ammontare di lavoro completato).
• breve. Un periodo di tempo breve permette di fissare obiettivi tangibili che tengono motivato e produttivo il team. (non preoccuparti, su questo aspetto ci torneremo tra poco).
• priorità. Quali attività pianificare nello sprint e in che ordine è il passo più critico. La scelta deve avvenire rispondendo ad una sola domanda: quale set di funzionalità, se completate durante lo sprint, offrirebbe il maggior valore possibile al business?
• completato. Se una funzionalità non può essere messa in produzione non è completata: non basta che sia stata sviluppata ma deve superare i test di qualità e conformità. E’ un aspetto tanto semplice quanto potente perché porta il team a pensare in termini di valore e non di quantità.

Probabilmente ti sto raccontando qualcosa che ti suona familiare.
Si chiama Scrum ed è un modello di Project Management basato sui principi agili.
Se vuoi saperne di più ho scritto una guida su SCRUM.

Sembra facile, no?

Scegliere il modello di sviluppo è la parte più semplice, ma non ti basterà per portare al successo un progetto software.

Lascia che ti spieghi.

Il modello di sviluppo è “solo” uno strumento, una serie di regole; è si, un ecosistema che serve a supportare un cambiamento ma è qualcosa di fermo, inerte, “senza vita”.

Non puoi pensare che da solo possa risolvere tutti i tuoi problemi, sarebbe un errore grossolano.

E’ come iscriversi alla migliore università al mondo senza frequentarla.

Se non hai chiaro l’obiettivo che vuoi raggiungere, trovarti all’interno del miglior contesto possibile non potrà aiutarti.

Nel caso della multinazionale bisognava cambiare il mindset del team. (è un problema che ho dovuto affrontare spesso in molte altre aziende)

Serviva fare uno switch nella mente delle persone.

Seguimi.

E’ un punto cruciale.

Qual è la nostra responsabilità all’interno del progetto?

Un Project Manager ti risponderebbe rispettare le scadenze, uno sviluppatore scrivere codice che funziona, un tester verificare la release…

Sono tutte responsabilità corrette ma rimangono confinate all’aspetto tecnico delle varie figure coinvolte nel progetto.

Il problema è che ogni momento della nostra giornata lavorativa siamo presi dai tecnicismi, li seguiamo a volte impuntandoci su di essi e dimenticandoci qual è il vero obiettivo che ci siamo fissati con il team.

E’ come navigare in barca senza mappa e sperare che le correnti ci portino alla meta.

Lo ripeto.

Le skill tecniche devono essere un mezzo, non il fine.

Ogni persona del team, in ogni momento del proprio lavoro, deve prendere le proprie decisioni (anche le più tecniche) perseguendo l’obiettivo di business del progetto.

In una parola: responsabilità.

Serve che ognuno di noi sia responsabilizzato nel convogliare i propri sforzi verso il massimo miglioramento possibile del prodotto che stiamo costruendo.

Sempre.

In ogni piccola azione che svolgiamo nella giornata.

Siamo d’accordo sul principio?

Bene.

Ma come facciamo a non farlo rimanere solo tale? Quali azioni dobbiamo eseguire per concretizzare questo principio? (si, quali azioni?)

Adesso arriva il bello.

Ti sto per raccontare la parte più importante del Project Management.

Per farlo, andiamo avanti con la costruzione del processo.

Riprendiamo dal punto in cui eravamo rimasti, un processo iterativo e incrementale basato su sprint di due settimane.

Concentriamoci su questi tre passaggi:

• come pianifichiamo gli sprint
• come tracciamo le performance
• come monitoriamo i progressi del progetto

In ognuno di questi passaggi ti racconterò quali azioni permettono di modificare il mindset del team e perché.

Sei pronto?

Come pianificare lo sprint.

La pianificazione ha lo scopo di identificare le funzionalità che miglioreranno il prodotto alla fine dello sprint.

La figura che ha la responsabilità di scegliere le funzionalità è chiamata in Scrum Product Owner.

Vuoi sapere la verità?

Non importa come la chiami, è importante ciò che fa.

Serve una persona in contatto costante con gli utenti e il cliente (stakeholder) per identificare le necessità del progetto, trasformarle in funzionalità, definirne le priorità e scegliere ciò che bisogna sviluppare nello sprint.

Ti ho parlato di Marta?

Marta è il Project Manager della multinazionale. Persona sorridente, attaccata al lavoro e molto volenterosa. Conosce perfettamente i processi della sua azienda, le persone e sa perfettamente come muoversi nella burocrazia di una multinazionale.

Marta però era frustrata perché era costretta a vivere in un ambiente in cui era difficile pianificare e controllare i progetti.

Appena le ho raccontato di come volevamo organizzare lo sviluppo del progetto pilota, è rimasta subito entusiasta: vedeva finalmente nascere una struttura organizzata con ruoli e responsabilità chiare dove poter lavorare al meglio.

Marta sarebbe stata il nostro Product Owner.

Ti ho appena detto che il Product Owner ha la responsabilità delle funzionalità del progetto. Ma Marta, dove avrebbe dovuto inserire queste funzionalità?

In una lista, anzi due.

Precisamente, una lista con tutte le funzionalità del prodotto (chiamata product backlog), ed una lista contenente tutto e solo ciò che sarebbe stato sviluppato nello sprint corrente (sprint backlog).

Come puoi facilmente intuire, le funzionalità all’interno di entrambe le liste si chiamano backlog item.

Marta sapeva che il suo compito era riempire le due liste, ciò che non aveva ancora chiaro era come farlo.

Come costruire (e mantenere) il Product Backlog perfetto.

Come suggerisce il nome, in questa lista finiscono tutti i backlog item del progetto.

Tutto ciò di cui il progetto ha bisogno dovrà entrare qui dentro, prima o poi.

Si, ho detto prima o poi.

Lascia che ti spieghi.

Durante la vita di un progetto le esigenze si modificano per due motivi principali: cambiamenti esterni o cambiamenti interni.

I primi sono avvenimenti provenienti da agenti esterni, fuori dal nostro controllo, che impattano in positivo e in negativo i presupposti del progetto. Ne sono un esempio i cambi legislativi o del mercato. Un aspetto che all’inizio del progetto poteva essere di fondamentale importanza, dopo qualche mese potrebbe non esserlo più.

I cambiamenti interni sono invece il cuore di un processo iterativo: man mano che il progetto avanza e si raggiungono degli obiettivi, si acquisiscono informazioni strategiche.

Pensa soltanto a quanti feedback puoi ricevere dagli utenti a cui metti a disposizione una nuova release ogni due settimane.

Hai intuito dove voglio arrivare?

Puoi capire come gli utilizzatori interagiscono con il sistema, quanto lo usano, quali sono le funzionalità che semplificherebbero la loro vita, quali malfunzionamenti hanno un impatto negativo e quali possono essere tralasciati temporaneamente perché stimolati poco di frequente dagli utenti.

Insomma capisci quanto queste informazioni possono esserti utili e, se sfruttate a dovere, guidarti nelle scelte strategiche per il progetto?

It is not the strongest or the most intelligent who will survive but those who can best manage change.

Charles Darwin

Torniamo al product backlog.

Te la faccio semplice.

Metti dentro a questa lista quello che vuoi, l’importante è che tu segua queste regole:

• inserisci solo bug o funzionalità utilizzando il linguaggio di business (non tecnico)
• appena inserisci un nuovo backlog item assegnali lo stato new
• quando il backlog item è pronto per essere lavorato in modo autonomo dal team, assegnali lo stato accepted
• non modificare mai un backlog item assegnato ad un componente del team
• i backlog item in status accepted devono essere atomici

Gli stati del backlog sono fondamentali, ma non abusarne in numero. Pochi, ma buoni.

Piccola nota. Gli stati che ho usato sono riferiti ad Azure DevOps, se utilizzi un altro strumento troverai facilmente i nomi corrispondenti.

Soffermiamoci sull’ultima regola, la più importante.

Con “atomici” si intende che i backlog item devono indicare un solo comportamento o una sola regola di business.

Ti avverto, all’inizio sarà abbastanza innaturale, ma non preoccuparti, una volta che ci prenderai la mano sarà naturale scrivere backlog item così.

E se ti accorgi che un backlog item non è atomico?

Semplice, lo spezzi in due.

Se può esserti d’aiuto, eccoti una metrica. Il backlog item deve essere piccolo abbastanza da non richiedere al team di sviluppo più di due giorni di lavoro (osserverai che mediamente richiederanno circa una mezza giornata).

Sai perché è così importante scrivere i backlog item in questo modo?

Pensaci.

Più i backlog item sono atomici più le stime saranno soggette ad un margine di errore più basso. Errore più basso significa più controllo e minori ritardi. (BOOM!)

Inoltre, gestendo funzionalità più piccole godrai di maggiore libertà nel definire le priorità e scegliere la migliore combinazione possibile che possa portare il più alto valore possibile al progetto.

Ho scritto un post in cui ti spiego dettagliatamente attraverso esempi come creare backlog atomici ti aiuta a limitare i ritardi.

Grazie a questo metodo, scoprirai tra poco anche come fare stime attendibili senza l’aiuto di un tecnico.

Sai una cosa?

La maggior parte dei progetti che ho visto fallire non seguivano queste regole.

Sono semplici indicazioni, ma rappresentano il frutto di anni passati ad analizzare e destrutturare ciò che funziona nei progetti di successo.

Ti accorgerai presto di come queste semplici regole miglioreranno l’attendibilità della tua pianificazione, e ti permetteranno di anticipare il ROI.

Hey, fammi guardare bene….

Sono due dei 4 principi che volevamo perseguire con il nuovo modello di sviluppo!

Mi piace, ma spezzettare i backlog item e renderli atomici è un lavoro faticoso, lo devo fare per tutti?

No!

Devi analizzare nel dettaglio solo le funzionalità a più alta priorità, ovvero quelli che presumibilmente saranno rilasciate nel prossimo o al massimo nei due sprint successivi.

Puoi usare il product backlog anche come lista delle funzionalità in bozza provenienti da te, dal team o semplicemente ipotizzate dagli stakeholder. Quando sarà il momento deciderai se rimuovere la bozza, analizzarla e magari dividerle in attività più piccole.

Come vedi il Product Backlog è uno strumento da coccolare, accudire ed affinare di continuo.

Rimane però un problema irrisolto nel Product Backlog e che rischia di far franare il progetto: la qualità.

Ricordi la definizione di qualità?

azzerare il divario tra ciò che ha in testa il cliente e ciò che fa il software.

Come ci riusciamo?

Puoi sperare di avere una botta di fortuna e capire perfettamente con uno sguardo cosa serve al tuo cliente.

Io però alla fortuna piovuta dal cielo non credo.

Piuttosto, negli anni ho imparato a credere e tanto in una disciplina: la User Experience.

Non mi voglio dilungare, ma un’azienda che vuole sviluppare applicazioni che funzionano ha bisogno di un team di User Experience.

Attenzione!

Non ho detto belle applicazioni ho detto applicazioni che funzionano.

Il primo fraintendimento quando si parla di User Experience è che sia una disciplina che cura solo gli aspetti grafici.

Io stesso ero caduto in questo pregiudizio, per poi ricredermi quando non ne ho capite le potenzialità.

Il vero valore della progettazione della User Experience è capire cosa realmente serve e farlo fruire all’utente nel modo più naturale possibile.

Ma come la User Experience può azzerare il divario tra ciò che è in testa del cliente e ciò che è prodotto dallo sviluppatore?

E’ semplicissimo. Segui questi passi:

• il team UX disegna le interazioni utente, i flussi e le interfacce grafiche
• il lavoro è sottoposto al cliente ed agli utenti
• il cliente valida i flussi
• il Product Owner inserisce la UI all’interno dei backlog item.

In questo modo il risultato atteso è chiaro e condiviso a tutti: chi progetta il software, chi lo userà, chi lo ha richiesto e chi lo svilupperà.

Posso assicurarti che in questo modo la possibilità di produrre un software diverso da ciò che si aspetta il cliente è praticamente azzerata.

Oltre a questo, la User Experience porta tantissimi altri vantaggi in un progetto e ti consiglio di approfondire l’argomento.

Se vuoi una introduzione a questa disciplina ti consiglio il libro di Donald Norman “La caffettiera del Masochista. Il design degli oggetti quotidiani” .

E’ semplice da leggere e racconta con tanti esempi come costruire prodotti centrati sull’uomo.

Fantastico! Ma se non hai un team dedicato all’interno della azienda?

Hai centrato il punto.

Questo era esattamente il problema che abbiamo avuto con il progetto pilota.

Non te lo nascondo: la User Experience è un aspetto molto delicato; lo è a tal punto da far dedicare a me e a Samuel la prima settimana del progetto alla ricerca di uno User Experience Designer.

Per fortuna Samuel trovò Filippo: mai nessuna scelta avrebbe portato più valore al progetto.

Finalmente ci siamo!

Filippo può costruire la User Experience e Marta ha il materiale per popolare il Product Backlog.

Finalmente eravamo in grado di dare al team lavoro sufficiente per partire con gli sviluppi.

Dal Product Backlog allo Sprint Backlog.

Lavorare settimana dopo settimana aggiornando il Product Backlog ha un solo fine: preparare lo sprint successivo.

Marta era molto precisa. Analizzava i risultati dello sprint precedente, sceglieva un obiettivo per quello successivo e preparava i Product Backlog item che sarebbero serviti per raggiungere quell’obiettivo.

Alla conclusione di questo lavoro, Marta si assicurava che tutti i backlog item su cui si era concentrata per lo sprint successivo, avessero due caratteristiche:

• essere in stato “accepted” (il che presupponeva anche che fossero atomici)
• fossero in cima al Product Backlog ordinato per priorità.

In questo modo sarebbe stato molto semplice preparare lo Sprint Backlog.

FERMATI!

Ma non hai mai parlato dell’obiettivo dello sprint?

E’ arrivato il momento.

Definire (e dichiarare) l’obiettivo dello sprint è, forse, l’attività più importante dello sprint stesso.

Ahimè nonostante la sua importanza, anche questa, è una attività che molto raramente vedo fare nei progetti. (e si vedono le conseguenze)

Fissare un obiettivo a breve termine è il modo migliore per responsabilizzare il team.

Inoltre, spiegare i vantaggi che porterà il raggiungimento di quell’obiettivo è il modo migliore per spingere il team a fare l’impossibile per completarlo.

Ne ho già parlato prima ma voglio ripetertelo.

Responsabilizzare il team deve essere il pensiero principe nella gestione del progetto.

Fissare un obiettivo per il progetto è il primo passo per ottenerlo.

Ma ci torniamo tra poco.

Ora concentriamoci su come organizzare lo sprint planning e partire con lo sprint.

Il primo passo è riempire lo Sprint Backlog.

Il lavoro settimanale di Marta ha portato i suoi frutti: può ordinare il Product Backlog per priorità e prendere i necessari item in stato accepted.

Si, ma cosa vuol dire “necessari”?

Un numero tale da poter raggiungere l’obiettivo dello sprint in base alla capacità del team.

Lascia che mi spieghi meglio.

Una delle metriche che dovrai calcolare nello sprint è la velocity, ovvero il numero di item che mediamente il team è capace di concludere in uno sprint.

Hai notato che ho parlato di numero di item e non di giorni uomo?

E’ una semplificazione possibile perché hai costruito i backlog item in modo atomico. Questa caratteristica ti farà “pesare” ogni item “peserà” mediamente allo stesso modo.

Sai cosa vuol dire?

Una volta che la velocity si sarà stabilizzata (ci vorranno almeno 3/4 sprint), chiunque, anche un non tecnico, potrà fare stime semplicemente contando il numero di backlog item.

UNA BOMBA!

Abilitare un non tecnico a fare stime è un vantaggio collaterale ottenuto dalla costruzione di backlog item atomici.

Non è un caso.

Uno dei pilastri di questo metodo è ciò che io chiamo “Push Project Management“: mettere in grado ogni soggetto coinvolto del progetto di ottenere tutte le informazioni sull’andamento del progetto, senza dover disturbare il team per chiedergli informazioni. (da sviluppatore, so quanto è controproducente essere disturbato mentre si scrive codice!)

Non preoccuparti, tra poco parleremo di tracciamento e ti sarà tutto più chiaro.

Ricapitoliamo.

Per riempire lo Sprint Backlog ti basta prendere dal Product Backlog un numero di item accepted pari alla velocity.

ALT!

Ma come faccio a costruire il primo Sprint Backlog senza la velocity?

Ci sono varie tecniche, il mio consiglio è di farti aiutare da un membro del team a produrre una prima stima sommaria (ti servirà al massimo mezzora).

Un altro consiglio: non ti serve inserire il numero perfetto di item nello Sprint Backlog. Sbaglia pure per eccesso, tanto “correggerai” il tiro durante lo Sprint Planning insieme al team.

Ci siamo, è arrivato il momento dello Sprint Planning.

Come svolgere lo Sprint Planning.

Non mi interessa spiegarti tutta la cerimonia, quella la puoi leggere nei libri.

Ti voglio parlare degli accorgimenti di cui tenere conto per mettere il team nelle condizioni di sviluppare in piena autonomia durante lo sprint. Se hai dubbi su qualche dettaglio organizzativo chiedi pure nei commenti.

Vogliamo un team responsabilizzato e focalizzato.

Per ottenerlo, il primo passo dello sprint planning è condividere l’obiettivo dello sprint.

Il passo successivo è spiegare al team tutti gli item dello Sprint Backlog. In questa fase aiutati con i wireframe e la UI prodotta dallo UX designer.

Prenditi tutto il tempo necessario per questa fase: è fondamentale.

Alla fine di questa sessione, il team deve essere in grado di concludere lo sprint senza la necessità di ulteriori chiarimenti dal punto di vista funzionale.

Fermati!

Non sto dicendo che il Product Owner non potrà essere disturbato durante lo sprint, sto dicendo che fissare questo traguardo aiuta a diminuire il numero delle volte in cui servirà il suo coinvolgimento.

Così facendo, ogni elemento del team acquisirà maggiore consapevolezza di ciò che sta facendo.

Marta gestiva gli Sprint Planning in video conferenza, con parte del team che era remoto.

Eravamo riusciti a trasformare un possibile difetto di comunicazione in un vantaggio.

Vuoi sapere come?

Registravamo le sessioni. In questo modo ogni componente del team poteva rivedere durante lo sprint la spiegazione dei backlog item ai quali stava lavorando.

Era talmente un vantaggio che probabilmente avremmo fatto lo Sprint Planning in video conferenza anche se fossimo stati tutti nella stessa stanza!

Alla fine della spiegazione funzionale del backlog si passa alla fase più tecnica (io la chiamo sprint injection).

In questa fase non serve la presenza del Product Owner.

L’obiettivo dello sprint injection è mettere in grado le persone di sviluppare in autonomia ogni attività presente nel backlog.

Funzionava pressapoco cosi.

Per ogni sprint backlog item:

• chiedevamo ad ogni componente del team se aveva tutte le conoscenze tecniche per sviluppare in autonomia quella attività
• eventualmente analizzavamo tutti assieme i passaggi tecnici da affrontare
• stimavamo tutti assieme il backlog item

Alla fine di questo passaggio, ogni componente del gruppo aveva tutte le informazioni funzionali e tecniche per svolgere in autonomia il lavoro delle due settimane successive.

Ho capito bene? Ogni componente del team doveva essere in grado di sviluppare tutto?

Si, o almeno questo doveva essere l’obiettivo.

Ritorniamo (come sempre) al tema della responsabilità.

Se tutti gli sviluppatori sono in grado di prendersi in carico qualsiasi attività del backlog, nessuno può più preoccuparsi solo della propria parte ma deve costantemente fare tutto il possibile per raggiungere l’obiettivo dello sprint.

Raggiungere l'obiettivo dello sprint deve diventare l'ossessione di ogni singolo componente del team.

Il focus deve passare da quello che faccio io a quello che faccio per il progetto.

Mancano le stime. Proprio loro, uno dei temi più dibattuti nel project management.

Sono un grande sostenitore delle stime.

Il motivo è semplice: se chiami un idraulico per rifare il bagno di casa tua, da cliente pretendi una stima dei costi e dei tempi.

Perché un tuo cliente non dovrebbe chiedere altrettanto?

Già questo basterebbe a sensibilizzarti riguardo la necessità della stima.

Le stime però non sono solo necessarie al tuo cliente, lo sono anche al tuo team.

Fare le stime è un momento fondamentale di analisi e comprensione di ciò che farai.

Non solo. Fare le stime ti permette in fase di retrospettiva di analizzare quali aspetti tecnologici sono stati sottovalutati dal team per migliorarli negli sprint successivi.

E’ inutile sottolinearti quanto sia fondamentale verificare le stime con atteggiamento costruttivo, invece che critico.

Il team ha completato le stime.

Bene, perché le useremo subito!

Come?

Seguimi.

Come abbiamo visto lo Sprint Backlog è riempito in modo volutamente approssimativo. E’ probabile che nello sprint, ci siano più backlog item rispetto a quelli che il team potrà completare.

Ricordi? Ora dobbiamo raffinare lo sprint backlog.

Ti servono tre cose:

• lo sprint backlog ordinato per priorità
• gli item stimati
• la capacity del team

Non ti ho mai parlato della capacity, vero?

Rimedio subito.

La capacity è la carica del team disposizione per lo sprint

E‘ espressa nella forma di un numero della stessa unità di misura della stima.

Mettiamo dei numeri e facciamo un calcolo d’esempio. Potrai adattarlo facilmente al tuo caso.

Ipotizziamo che hai scelto di calcolare la stima in ore/uomo, ovvero in quante ore un singolo sviluppatore completerà l’item.

Immagina inoltre un team composto da 3 sviluppatori full time.

Mediamente, ogni sviluppatore passa a lavoro circa 8 ore al giorno.

Escludendo meeting, pause, telefonate, cerimonie… sfrutta circa 5 ore effettive a scrivere codice (aggiusta tu il numero in base al tuo contesto).

Supponi inoltre che nel mezzo dello sprint che stai pianificando cada un giorno di festa (ad esempio il primo maggio).

Mettendo insieme tutti questi dati, calcoli la capacity così:

3 sviluppatori * (10 giorni di sprint – 1 giorno di festa) * 5 ore.

Il totale è 135 ore.

Ora hai tutto per completare il tuo backlog.

Non ti resta che prendere gli item ordinati per priorità, sommare la stima di ogni item, fino ad arrivare a saturare il valore della capacity.

Facile, vero?

Tutto ciò che rimane fuori dalla capacity non riuscirai (presumibilmente) a concluderlo entro lo sprint: elimina questi item dal backlog dello sprint.

Rimane un ultimo step.

E’ la più critica: la fase del commitment.

Il commitment è quella fase in cui Il team deve scegliere un sottoinsieme del backlog che è sicuro di portare a termine entro la fine dello sprint.

Su questa parte del backlog, il team dovrà prendere un impegno formale (commitment appunto**)**. Gli item rimanenti sono opzionali: il mancato completamento non dovrà pregiudicare l’obiettivo dello sprint.

Ma prendere un impegno con chi?

Con il tuo Product Owner prima di tutto, con stackholder, utenti e/o il team di comunicazione poi.

Insieme alla formalizzazione dell’obiettivo il commitment rappresenta lo strumento per responsabilizzare del team.

Ma come scegli gli item committed?

Costruiamolo un sottoinsieme del backlog con queste caratteristiche:

• la somma delle stime deve garantirti un margine di sicurezza. Ricordati, qualsiasi catastrofe succeda durante lo sprint, quegli item vanno completati. (io generalmente rimango sotto il 60% della capacity)
• deve raggiungere l’obiettivo dello sprint in modo consistente. Magari rinuncerai a qualche dettaglio ma lo spirito dell’obiettivo deve essere mantenuto.

E’ probabile che il tool che hai adottato ti metta a disposizione uno stato che identifica gli item committed. In questo caso usalo. (ad esempio Azure DevOps).

Ci siamo. Il team ha uno sprint backlog.

Ti rimane solo una cosa da fare: richiamare il Product Owner e presentargli il piano per la sua approvazione.

Il Product Owner dovrà verificare che lo sprint backlog sia congruente con l’obiettivo dello sprint. Se così non fosse, insieme, farete piccoli aggiustamenti per metterlo in linea.

Ti ho sottolineato quanto è strategica la responsabilità. Prima di passare oltre, ricapitoliamo quali azioni concrete devi attuare per responsabilizzare il team?

Ecco l’elenco:

• definisci un obiettivo di team
• ogni componente del team deve apprendere tutte le conoscenze funzionali e tecniche per sviluppare in autonomia i backlog item dello sprint
• il team deve fare le stime (e verificarle a fine sprint)
• il team deve avere un commitment congruo con l’obiettivo

Siamo pronti per il primo giorno dello sprint.

Da questo momento, per le successive due settimane, il team avrà un solo pensiero: rispettare gli impegni presi con il Product Owner.

Giorno dopo giorno il team si farà sempre le stesse due domande:

Quanto lavoro manca a chiudere lo sprint?

Riusciremo a raggiungere l’obiettivo?

Il tuo processo metodologico dovrà essere in grado di rispondere a queste domande.

Push Project Management

Ho una immagine fissa in testa quando parlo di questo argomento.

Devi sapere che il primo progetto a cui ho partecipato era per un grosso gruppo bancari; la sua necessità era ridisegnare un processo strategico per tutta la banca.

Il progetto era così grande e importante che la divisione IT non aveva tutte le risorse necessarie ad affrontarlo.

Chiesero così aiuto ad una società di consulenza che costruì un team di circa una quindicina di persone, tra le quali c’ero anche io.

Niente di particolare fino a qui.

L’inefficienza che ti sto per raccontare però, ti sembrerà assurda.

Il progetto era gestito da un Project Manager. Il suo lavoro principale era passare ogni giorno tra le postazioni di ogni sviluppatore analizzando lo stato di avanzamento dei task.

Tutti i giorni.

Per ogni sviluppatore.

Questa è l’immagine che non riesco a levarmi dalla testa. Per fortuna.

Si per fortuna, sai perché?

Mi ricorda sempre cosa non va fatto.

Tralasciamo il quantitativo costante di tempo speso per questa attività (circa un paio di ore al giorno).

Se fosse utile, nulla di male.

Purtroppo non è così anzi, è tempo sprecato.

Ancora peggio: è dannoso.

Lascia che ti spieghi.

Ricordo in modo nitido il mio stato d’animo quando il Project Manager passava da me.

Che palle!

Questa era sempre l’esclamazione che rimbombava nella mia testa durante quel rituale.

Nulla di personale contro il Project Manager, ma se c’è una cosa che dà fastidio ad uno sviluppatore è essere bloccato quando è concentrato a scrivere codice.

Se vuoi farti odiare da uno sviluppatore, questa è la via.

Quanto può essere accurata una attività fatta controvoglia?

E’ come chiedere ad un figlio: come è andata oggi la scuola?

Non ho mai sentito (e non ho mai dato) risposta diversa: bene.

Una risposta ad entropia zero. E’ utile solo per chiudere l’argomento e continuare a fare ciò che è stato interrotto.

Per lo sviluppatore, lo stato avanzamento lavori è di per sé una scocciatura. E’ inevitabile sia così; se poi questa attività è fatta interrompendone una per lui piacevole (scrivere codice), lo stato d’animo non può che diventare frustante.

Su un punto però non possiamo prescindere: avere il controllo è necessario.

Ma come?

Semplice: bisogna passare dalla modalità pull a quella push.

Hai presente le notifiche sul cellulare? Non chiedi al telefono se ci sono notifiche, arrivano loro.

Il Project Manager non deve chiedere le informazioni al team, deve sfruttare il proprio tempo per analizzare gli aggiornamenti che gli arrivano.

E’ quello che io amo definire Push Project Management.

Mi piace pensare che ci sia un patto silente tra Project Manager e sviluppatore.

io non ti disturbo chiedendoti lo stato di avanzamento, tu mi aggiorni puntualmente sulla situazione.

Torniamo sempre al solito punto: la responsabilità.

Capisci perché è così strategico coinvolgere lo sviluppatore negli obiettivi del progetto?

La responsabilità purtroppo non basta, serve anche una procedura chiara di gestione dei task.

Una procedura lineare e snella genera meno distrazioni per lo sviluppatore: in altre parole l’aggiornamento deve diventare una routine.

Ho parlato di routine. Non l’ho fatto a caso.

Se hai letto il libro di Charles Duhigg “The power of habit” sai bene che per formare una routine servono 3 elementi: trigger, azione, ricompensa.

In altri termini: devi creare dei segnali precisi e ricorrenti (trigger) che inducano nello sviluppatore lo stimolo per aggiornare i propri task (azione).

La conclusione dell’azione genererà la ricompensa che permetterà di rafforzare l’abitudine.

Se non hai letto questo libro fallo, cambierà radicalmente la tua produttività.

Con questa premessa, costruiamo la routine dello sviluppatore:

• ordina lo sprint backlog per priorità
• prende il primo item non assegnato e non completato
• se lo assegna
• lo lavora
• a fine giornata se l’item non è completato aggiorna il remaining work
• una volta completato l’item lo chiude

E la ricompensa dov’è?

Lo sviluppatore può vedere in tempo reale l’impatto che il proprio lavoro ha sull’obiettivo dello sprint e sul progetto.

Non sottovalutare quanto può essere gratificante avere la riprova di quanto è utile ciò che fai.

Come ti senti quando sei riuscito a montare un mobile dell’Ikea, a completare un puzzle oppure a costruire un Lego?

La sensazione è proprio questa.

E’ un noto bias cognitivo chiamato appunto effetto Ikea: possiamo “sfruttarlo” per il bene del progetto.

Ma esiste un altro vantaggio per lo sviluppatore.

Sapere di essere sul punto di raggiungere un obiettivo è una grande leva di stimolo per rimanere focalizzato; esattamente come essere in ritardo ma sapere di potercela ancora fare.

Questo è il Push Project Management.

La routine dello sviluppatore è il nostro sistema di acquisizione dati.

Grazie a questi dati siamo in grado di mettere il Project Manager – e chiunque abbia accesso al progetto – nelle condizioni di monitorare lo stato di avanzamento.

Pensaci.

Puoi conoscere in tempo reale quali attività sono state completate nello sprint, quali sono in lavorazione, quanto lavoro manca al completamento dell’obiettivo, qual è la velocity del team.

Tutto senza che il Project Manager debba disturbare gli sviluppatori e compilare pile di fogli Excel.

Abbiamo ciò che volevamo: i dati.

Sappiamo che informazioni vogliamo ottenere.

Manca solo un tassello: usarli.

E’ la parte più incredibile perché lo sforzo organizzativo fatto fino ad ora si trasformerà in una macchina perfetta.

Sei pronto?

Come tracciare le performance del team durante lo sprint.

Non te lo nascondo. Il remaining work è il dato centrale per il monitoraggio del progetto.

Lascia che ti spieghi.

Il remaining work è la valutazione del lavoro necessaria a completare un task. In altre parole è la stima del lavoro in corso.

Ogni volta che un task è lavorato, questo valore deve essere aggiornato.

Il remaining work è la bussola del nostro sprint.

Ti mostro come costruirti questa bussola.

Il primo giorno dello sprint somma i valori del remaining work di tutti gli item dello sprint backlog.

Il valore che ottieni è il totale del lavoro da completare nello sprint.

Fai un salto nel tempo fino all’ultimo giorno dello sprint: somma i remaining work riferiti a quel giorno.

Quale valore dovresti ottenere?

Se lo sprint è andato per il meglio dovresti aver completato tutto il lavoro e la somma dovrebbe essere zero.

Fin qui tutto semplice.

Ora Costruisci un grafico e metti sulle ascisse i giorni dello sprint (su due settimane dovrebbero essere 10 punti) e sulle ordinate il valore del remaining work dello sprint.

Segna sul grafico il punto corrispondente al primo giorno (la stima iniziale) e quella all’ultimo giorno (zero).

Traccia una linea tra questi due punti.

Hai ottenuto proprio lei: la bussola del tuo sprint.

Ti spiego il perché.

Immagina che alla fine di ogni giornata lavorativa, il totale del remaining work fosse pari al valore corrispondete al punto sulla retta: significa che il team sta procedendo ad un ritmo tale da completare tutto il lavoro entro la fine dello sprint.

E se il totale del remaining work supera il valore della retta?

Significa che il team è in ritardo sulla tabella di marcia.

Ovviamente, se il totale del remaining work è minore del valore del punto sulla linea, significherebbe che il team è in anticipo sui tempi dello sprint.

Segna ogni giorno sul grafico il punto corrispondente alla somma del remaining work.

SBAM!

Hai costruito uno strumento che a colpo d’occhio permette a chiunque e in qualsiasi momento di capire se si è in ritardo nello sprint.

Ciò che hai creato si chiama burndown chart, un grafico che mette in corrispondenza la linea ideale da mantenere nello sprint con il reale andamento del team.

La cosa incredibile è che puoi ottenere il burndown senza chiedere nulla agli sviluppatori e in automatico con la maggior parte dei tool di Project Management (se hai dubbi, Azure DevOps ha questa funzionalità).

Ricapitoliamo.

Quando guardi i burndown chart puoi ritrovarti in una di queste tre situazioni:

• il remain work è sopra il punto ideale: sei in ritardo
• il remain work è sotto il punto ideale: sei in anticipo
• il remain work è uguale al punto ideale: sei in linea con la pianificazione

Se ti sei perso non preoccuparti. Ho scritto un post su questo grafico che ti spiega passo passo come costruirlo.

Il burndown chart è un tool di controllo così potente che non puoi non introdurre nel tuo team.

Non solo è semplice ed efficace, ma è anche un incredibile strumento motivazionale e di responsabilizzazione.

Ti spiego il perché.

Facciamo un gioco. Immergiti nella testa dello sviluppatore la mattina, appena acceso il pc.

Prima di iniziare a scrivere codice guarda il burndown chart.

La senti la scossa? E’ la motivazione che ti guiderà per tutta la giornata.

Non ci credi? Ragiona con me.

Se il team è in ritardo farai di tutto per portare a fine giornata il remain work sotto la linea ideale, vero?

Al contrario: se fossi in piano o addirittura in anticipo sarebbe questo il momento di mollare il colpo?

Mi credi ora?

Senza il tuo contributo quel grafico non potrà mai scendere abbastanza: sai bene quanto il tuo lavoro può incidere sul team.

E’ un sottile equilibrio tra dare importanza al lavoro di ogni singolo componente del team e fare in modo che il progetto non sia legato mani e piedi ad uno sviluppatore.

Motivazione e responsabilità.

Ti ho raccontato fino allo sfinimento di questi due concetti. Nulla di nuovo a dire la verità, ne parlano tutti.

Quanti però ti propongono strumenti concreti per sostenere questi due aspetti?

Il burndown chart e l’obiettivo dello sprint sono le frecce al tuo arco per ottenere dal team motivazione e responsabilità: usale con costanza e fermezza ed otterrai risultati sorprendenti.

Abbiamo costruito un semplice strumento per monitorare lo sprint.

Portare a termine con successo lo sprint è un solo pezzo del puzzle, dobbiamo monitorare l’intero progetto. Si, ma come?

Come monitorare i progressi del progetto.

Settembre 2018.

Avevamo iniziato il progetto da un mese circa: due sprint per la precisione.

La macchina era ormai oliata.

Filippo produceva UX e UI della nuova applicazione, Marta popolava il Product Backlog e il team era concentrato sullo sprint.

OH FERMATI UN MOMENTO!

Ma come puoi affermare che la macchina era oliata? Non sarà mica una tua sensazione?

No, sono dati, dati mostrati tramite un (altro) grafico: il cumulative flow.

Questo semplicissimo grafico mostra il flusso del lavoro da quando un item è entrato nel product backlog (stato new), a quando è stato analizzato (accepted), fino a diventare un impegno del team (committed) prima ed a concludersi poi (done).

Tranquillo, non devi fare nulla, anche il cumulative flow è prodotto in automatico senza nessun intervento manuale.

Osserva bene il grafico.

Puoi notare facilmente come ogni linea che rappresenta uno stato stava crescendo in modo lineare, si dall’inizio.

E’ un aspetto molto confortante perché significava due cose: il team aveva metabolizzato molto in fretta il nuovo metodo di lavoro e produceva in modo costante (costante è sinonimo di prevedibile).

In altre parole, il meccanismo era oliato.

C’era un problema però, un problema che sarebbe stato evidente qualche settimana dopo.

Le prime settimane di progetto la mia massima preoccupazione era raccogliere un quantitativo di dati tale da rispondere ad un’unica domanda:

riusciamo a rispettare la data di rilascio della prima release dell’applicazione? (fine ottobre per la cronaca)

Serviva una stima di massima di tutte le funzionalità che dovevano far parte della prima release.

Gianluca guarda il grafico! Il lavoro da fare lo stai costruendo di settimana in settimana, come fai a fare una stima di ciò che ancora non hai analizzato?

Bisognava costruire un’altra stima, quella di progetto.

Questa stima, nonostante non potesse essere precisa e puntuale, era la traccia che ci permetteva di capire il prima possibile se avremmo potuto rilasciare il prodotto in tempo.

Ogni fine sprint avremmo poi aggiornato la nostra stima di progetto.

Le prime settimane, io e Marta le abbiamo dedicate a produrre una lista sommaria di funzionalità di alto livello necessarie a fare una stima. (spesso le avrai sentite chiamare User Story o Epic)

Finalmente avevamo i numeri: la stima diceva che per concludere il progetto sarebbero stati necessari circa 400 backlog item.

Houston abbiamo un problema!

Il cumulative flow parlava chiaro: con la velocity attuale del team per fine ottobre (data di consegna della release) saremmo riusciti a concludere solo circa la metà dei backlog item necessari.

Dovevo andare dal responsabile IT e spiegare la situazione.

Non c’era tempo da perdere.

Ti parlerò chiaro.

Non esiste nessuna metodologia, tecnica o framework che ti proteggerà dall'affrontare i problemi.

Non puoi scappare.

Ma allora a cosa serve il Project Management?

A far emergere i problemi il più presto possibile.

Infatti parliamo di gestione di progetti, non di magia nei progetti.

Nessun problema è irrisolvibile se lo conosci per tempo.

Hai presente una innocente palla di neve che scende dalla cima della montagna? Se non la fermi in tempo diventerà una valanga.

E sarà tardi.

Incontrai il responsabile, gli spiegai la situazione e gli diedi una buona notizia: abbiamo tempo per rimediare.

9 donne possono partorire un bambino in un mese?

No non è uno scherzo.

E’ una frase che dico molto spesso.

Lascia che ti spieghi.

Avevamo stimato che nel tempo a disposizione e con l’attuale team avremmo potuto concludere solo circa la metà del lavoro.

2013 Milano.

Era inverno, lo ricordo bene perché era uno di quei giorni in cui la città si blocca per la neve. Sapevi quando uscivi di casa ma non avevi idea di quando saresti riuscito a tornare.

Non il miglior clima per districarsi in una situazione complicata.

Ero esattamente nella stessa situazione in cui mi sarei ritrovato 5 anni dopo con la multinazionale: progetto che secondo le stime non saremmo riusciti a consegnare in tempo.

In quella occasione il management uscì con la sua soluzione risolutiva:

raddoppiamo il team così dimezzeremo i tempi di sviluppo

Sai, questa è la più grossa cazzata che si possa dire durante la vita di un progetto. Certo, ne ho sentite tante, ma questa di certo la batte tutte.

Ovviamente non posso spiegarlo con gli stessi toni ad un cliente, per questo motivo, in quella occasione, coniai una espressione più diplomatica.

certo, esattamente come 9 donne possono partorire un bambino in un mese

GAME, SET AND MATCH!

Semplice, efficace e capace anche di strappare una risata.

Il motivo è banale.

L'aumento delle risorse non è proporzionale all'aumento della velocity. Rispetto a 5 anni prima, questa volta però era diverso. Il responsabile IT, per mia fortuna, non uscì con la stessa frase, ma soprattutto avevamo creato dei presupposti diversi.

Con il nuovo processo di sviluppo potevamo avvicinarci a questo utopico obiettivo.

No, nessun miracolo.

Avevamo costruito le condizioni affinché si potesse fare.

Mi spiego meglio.

Ricordi i principi del nuovo modello organizzativo?

E’ importante poter scalare il team inserendo nuove risorse qualora si presenti la necessità.

Ma quali sono queste condizioni che abilitano la scalabilità?

• tempismo. Inserire le risorse ad inizio progetto richiede un tempo molto basso di allineamento tecnico delle persone
• organizzazione. Procedure chiare, definite ed automatizzate diminuiscono la complessità con l’aumento della dimensione del team
• knowledge base. Le procedure sono consultabili in autonomia dai nuovi membri del team
• tecnologie mainstream. Scegliere tecnologie diffuse sul mercato semplifica la ricerca delle risorse (sia in termini di costi che tempistiche)
• network di partner affidabili. Costruire negli anni un network di professionisti ed aziende di fiducia permette di inserire nel team figure con lo stesso mindset e modello di lavoro

Tre settimane dopo da quella riunione avevamo trovato due nuovi sviluppatori, inserirti nel team ed eravamo riusciti a cambiare la rotta del cumulative flow.

Lo ammetto, la velocità di inserimento ha stupito anche noi!

Guarda il grafico. La pendenza della linea degli item in stato done era quasi raddoppiata.

Man mano che passavano gli sprint la distanza con in nuovi item nel product backlog si assottigliava.

Avevamo trovato la rotta giusta che ci avrebbe condotto alla prima release in modo controllato.

Per concludere. Project Management, alcune considerazioni.

Potrebbe sembrarti tutto semplice.

Qualche regola qua e là e porti un progetto al successo.

Non è così.

Non te lo nascondo: è stato un progetto complicato, pieno di insidie fino all’ultimo giorno.

Nonostante le formule magiche che ti raccontano formatori o libri, la verità è una sola: il Project Management serve per metterti nelle condizioni di risolvere i problemi che inevitabilmente incontrerai.

Seguire alla lettera i manuali di Project Management, non ti porterà da nessuna parte.

Osserva, impara, adatta.

Per farlo, instaura un clima di fiducia e responsabilizzazione con il team e rendi il project management meno invasivo possibile nella vita del progetto.

Il miglior Project Management è quello che non si nota.

Questo è quello che ho cercato di raccontarti.

In modo pratico con esempi reali.

Sai qual è stata la più grande soddisfazione di questa esperienza?

No, non è stato rispettare la data di scadenza della release. Rispettare la scadenza è un dovere.

L’aspetto più gratificante è stato vedere la multinazionale continuare ad usare in autonomia il modello che abbiamo costruito insieme.

Ci ho messo settimane a scrivere questo post.

Ti ho appena regalato quindici anni di ricerca: strumenti, strategie, mindset.

E’ uscita una guida di migliaia di parole, la più lunga e completa guida che tu possa trovare sul Project Management.

Sarei contento se lasciassi un commento per raccontare le tue strategie, i tuoi spunti, le tue riflessioni o i dubbi costruttivi.

Parliamone ed arricchiamoci insieme.

E se vuoi, condividi questa guida con chi pensi possa essergli utile. Se invece vuoi contattarmi, scrivimi

Tieni botta,
Gianluca