5 errori comuni nella pianificazione dello sviluppo software

È difficile prevedere il futuro, anche se esistono metodi specifici per farlo. La realtà è che anche la pianificazione di un progetto semplice nello sviluppo software rappresenta una sfida. Ci sono molte cose da considerare e altrettante che possono andare storte. È dimostrato che spesso le cose non funzionano quando il software viene consegnato basandosi solo su previsioni. Purtroppo, questa rimane ancora un'abitudine consolidata.

Gli errori più comuni nella pianificazione dello sviluppo software:

1. La complessità dello sviluppo software viene spesso sottovalutata

Lo sviluppo software viene spesso paragonato alla costruzione di una casa. Sembra un buon paragone, perché a prima vista gli sviluppatori software "costruiscono" qualcosa. Purtroppo, lo sviluppo software è fondamentalmente diverso dalla costruzione tradizionale di una casa. Quando si applicano questi metodi di pianificazione, possono sorgere problemi.

Nassim Nicholas Taleb descrive nel suo libro "The Black Swan" due mondi diversi: "Mediocristan" ed "Extremistan". Entrambi i mondi rappresentano due tipi diversi di incertezza.

Per dimostrare questa differenza, Taleb propone il seguente esperimento:
Si scelgono 1.000 persone diverse dalla popolazione. Queste persone si sdraiano una dietro l'altra, testa a piedi, formando una lunga fila.

Supponiamo che l'altezza media di una persona sia 1,68 m. La fila sarebbe quindi lunga circa 1.680 metri. Una fila lunga il doppio (3.360 m) dovrebbe essere composta da circa 2.000 persone (anch'esse con un'altezza media di 1,68 m).

Cosa succederebbe se altre 1.000 persone si aggiungessero alla fila esistente? Questa volta però si includerebbe l'uomo più alto del mondo (Sultan Kösen, 2,51 m). In questo caso servirebbero solo 1.999 persone. Anche dopo aver incluso uno scenario del caso peggiore nella pianificazione, non c'è quindi una grande differenza rispetto al nostro calcolo iniziale.

Ora proviamo lo stesso esperimento, ma con un calcolo diverso:

Questa volta vengono selezionate 1.000 persone diverse dalla popolazione e si registra il patrimonio delle rispettive famiglie. Il patrimonio medio di una famiglia negli USA è ad esempio di 110.000 dollari. Per questo gruppo la somma totale sarebbe di 110.000.000 di dollari. Successivamente si stima la dimensione necessaria di un caveau per contenere il patrimonio totale di 2.000 persone. Si può calcolare la dimensione in modo relativamente semplice, trovando la dimensione necessaria per il patrimonio di 1.000 persone e poi raddoppiandola.

Ora prendiamo di nuovo 1.000 persone, ma includiamo Bill Gates. Cosa potrebbe succedere? La stima originale era per un caveau in grado di contenere 220.000.000 di dollari. Ora però ne serve uno per 77.500.000.000 di dollari. Che differenza fa qui uno scenario del caso peggiore?

Cosa hanno a che fare questi esperimenti con lo sviluppo software?
Se hai già esperienza con lo sviluppo software, sicuramente ti sei imbattuto in qualche problema che non riuscivi a risolvere. Forse è un bug molto difficile da correggere. Oppure è un problema tecnico che non riesci a risolvere con gli strumenti disponibili. La stima originale non era solo leggermente imprecisa, ma presenta una deviazione del 10%, 20% o 500%. Questo è il mondo dello sviluppo software. Questo è "Extremistan" (secondo esperimento), dove un singolo evento o elemento può avere un grande impatto sul risultato.

La maggior parte dei progetti edilizi appartiene al mondo di "Mediocristan" (il primo esperimento), dove le deviazioni vengono compensate nel complesso. Ripetiamo l'esperimento con grattacieli scelti casualmente e mettiamoli uno accanto all'altro come tessere del domino. Ora entra in gioco l'edificio più alto del mondo, il Burj Khalifa. Il risultato finale è lo stesso dell'esempio con l'altezza delle persone o dell'esempio con il patrimonio?

Come si può evitare di confondere "Extremistan" con "Mediocristan"? È importante comprendere nei minimi dettagli il tipo di attività che si sta pianificando. Se il carico di lavoro di un singolo elemento può potenzialmente deviare in modo significativo da quello di altri elementi, è consigliabile utilizzare metodi di pianificazione adeguati. Per questo i metodi di pianificazione empirici utilizzati in Scrum sono più adatti per i progetti di "Extremistan".

2. Non pianifichiamo l'imprevedibile

I compiti complessi richiedono un tipo diverso di gestione del rischio. Nella pianificazione tradizionale dei progetti, vengono utilizzati buffer per gli imprevisti. Spesso si crede che l'imprevedibile venga compensato recuperando il tempo perso con il tempo guadagnato. Purtroppo, nel caso di lavoro complesso, questo non funziona.

In questo progetto siamo fiduciosi di poter consegnare entro la data prevista. Ma supponiamo che i fatti di fondo fossero i seguenti:

• Sei un tacchino
• Il progresso che viene monitorato è il tuo peso
• Nessuno ti ha parlato del Giorno del Ringraziamento. Cosa succede ai tacchini il Giorno del Ringraziamento?
  Come ti senti adesso?

Nassim Nicholas Taleb utilizza questa metafora nel suo libro "The Black Swan" per illustrare l'impatto degli eventi imprevedibili. Il tacchino non ha mai sentito parlare del Giorno del Ringraziamento e non è stato calcolato alcun buffer. Gli eventi imprevedibili non sono previsti nella pianificazione tradizionale. Ma nello sviluppo software si verificano frequentemente.

Come si può evitare questo errore? Il framework Scrum prevede che singole parti di software vengano consegnate a intervalli regolari. Il rischio viene ridotto consegnando presto e spesso, non attraverso buffer pianificati. Quando si verificano eventi imprevedibili, c'è la possibilità di fare affidamento su ciò che è stato costruito finora.

3. Spesso facciamo promesse agli stakeholder che non possiamo mantenere

Se sappiamo che lo sviluppo software è complesso e rischioso, perché non possiamo semplicemente comunicarlo agli stakeholder? Perché facciamo promesse che non possiamo mantenere? La risposta è che i dirigenti hanno bisogno di certezze. Stabiliscono il budget, devono essere sicuri che tutte le attività siano pianificate, vogliono una scadenza e naturalmente vogliono tutte le funzionalità desiderate.

Ma sono davvero necessari impegni scolpiti nella pietra?
La maggior parte dei professionisti del settore comprende il rischio. Capiscono anche che spesso devono assumersi dei rischi per ottenere rendimenti e profitti. Molto spesso l'entità del rischio è direttamente correlata al rendimento potenziale. La maggior parte delle aziende preferirebbe un rendimento garantito. Ma sanno che il guadagno da tali investimenti è così basso che spesso non vale affatto la pena investire. Se tutti lo sanno, perché non lo fanno tutti?

Se gli stakeholder comprendono il rapporto rischio-rendimento, perché nello sviluppo software non si segue lo stesso principio? Con ogni nuova release c'è un elemento di ricompensa. In ogni buon progetto c'è un calcolo del ritorno sull'investimento (ROI). Se in un progetto si prevede un rendimento significativo, allora gli stakeholder devono aspettarsi un certo rischio. Parla quindi con i tuoi stakeholder. Rendili consapevoli che forse non otterranno tutto ciò che era previsto al momento della pianificazione. Questo è il rischio nello sviluppo software. Non significa che il rischio non possa essere limitato. Ma una discussione onesta dovrebbe assolutamente essere condotta.

Se gli stakeholder vogliono impegni vincolanti da te, allora dovresti prendere solo quelli che puoi effettivamente mantenere. Impegnati nella collaborazione. Impegnati a rispettare il processo concordato. Impegnati a lavorare orientato alla qualità. Impegnati nel miglioramento continuo e nell'adattamento. Impegnati a garantire la trasparenza.

Parla con gli stakeholder del rapporto rischio-rendimento e spiega loro che la creazione di un nuovo software segue lo stesso principio. Discuti quali misure di mitigazione del rischio possono essere applicate. E impegnati solo per ciò che puoi realmente realizzare.

4. Spesso diamo agli stakeholder l'impressione che alcuni lavori siano gratuiti

Quando promettiamo ai nostri stakeholder determinate funzionalità entro una certa data e per un determinato budget, pensano di aver pagato e acquistato quelle funzionalità. Come sviluppatore ti sei impegnato a consegnare le funzionalità. Il rischio ora è che gli stakeholder pensino che non ci saranno costi aggiuntivi. Dopotutto hanno già pagato e credono che tutte le funzionalità aggiuntive siano incluse nel prezzo. L'unica cosa di cui si preoccupano sono i costi per eventuali modifiche. Nel suo libro "Predictably Irrational", Dan Ariely descrive il cambiamento del comportamento umano quando qualcosa è gratuito:

"Ovunque ci sono vantaggi e svantaggi, ma quando qualcosa è gratuito, ci si dimentica degli svantaggi."
Quando i tuoi stakeholder capiscono che nessuna funzionalità è garantita fino a quando non è completata, parteciperanno più spesso, prenderanno decisioni e faranno compromessi. Insisteranno affinché prima vengano completate le funzionalità importanti e poi quelle meno importanti. Saranno meno disposti a investire molto sforzo per funzionalità poco importanti.

Quindi dovresti ricordare regolarmente ai tuoi stakeholder che non c'è garanzia che una funzionalità venga consegnata come previsto, fino a quando non è stata effettivamente rilasciata.

Per la definizione delle priorità, si dovrebbe collaborare costantemente con gli stakeholder durante il progetto. Le Sprint Review di Scrum danno regolarmente agli stakeholder l'opportunità di verificare l'avanzamento del processo, discutere i lavori in sospeso e stabilire le priorità.

5. Non agiamo in modo professionale

Immagina di dover subire un'operazione agli occhi. L'oculista sa che questa operazione comporta un rischio del 10% di complicazioni e che invece di un miglioramento potrebbe causare la cecità. Il medico decide di non comunicarti questa informazione. Crede che altrimenti potrebbe perdere il tuo incarico. Ora immagina di sottoporti all'operazione e di perdere la vista. Poi scopri che l'oculista conosceva questo rischio ma non te ne aveva informato. Dovrebbe affrontare serie conseguenze. Questo sicuramente non è il comportamento che ci si aspetterebbe da un professionista.

Sarebbe meglio se l'oculista avvertisse del rischio ma poi dicesse: "Non ti preoccupare, sono un oculista molto bravo e ti garantisco che non succederà nulla." Sarebbe più professionale?

Questo scenario si ripete costantemente nei progetti di sviluppo software. Mentiamo ai nostri stakeholder. Il motivo per cui mentiamo può essere negativo (convincere gli stakeholder a firmare il contratto) o positivo (togliere la paura agli stakeholder) oppure semplicemente mentiamo a noi stessi. Il risultato rimane lo stesso: è estremamente poco professionale!

Per evitare questo errore, bisogna essere onesti, anche quando è difficile. In questo modo si dà agli stakeholder la possibilità di riconoscere i rischi e pianificare di conseguenza. Un professionista utilizza e promuove le basi empiriche di Scrum e aiuta così gli stakeholder a gestire meglio i rischi.

Riepilogo: errori di pianificazione nello sviluppo software

È difficile prevedere il futuro. Quando pianifichiamo sviluppo software complesso, commettiamo molti errori che spesso portano a un basso tasso di successo. Utilizzando Scrum, questi errori vengono evitati.

Questo testo proviene dal blog di Steve Porter ed è stato tradotto.

Cosa fa un Product Owner?

=> Scopri di più sui compiti e le responsabilità dei Product Owner.

Lo Sprint Planning Meeting

=> Svolgimento e consigli importanti per Product Owner sullo Sprint Planning