Aumentare il valore nel ciclo di vita del software
Molti progetti software adottano un ciclo di vita iterativo al fine di consegnare in modo incrementale nuove funzionalità agli utenti. Una funzionalità viene quindi identificata, analizzata, progettata, pianificata, implementata, testata ed infine consegnata all’utente finale, e questo ciclo si ripete per ogni funzionalità nel corso del progetto.
Questo tipo di approccio è molto utile soprattutto quando si sviluppano applicazioni in rapida evoluzione e per le quali il time to market è fondamentale. Le iterazioni brevi aiutano a ricevere il più presto possibile feedback da parte degli utenti identificando così i punti che forniscono loro maggior valore. Usare i feedback per assegnare le priorità nelle iterazioni successive aiuta ad aumentare la soddisfazione degli utenti, oltre a ridurre gli sprechi evitando di sviluppare funzionalità che non servono o che comunque danno poco valore.
Se esistono pratiche così consolidate, perché molti team trovano difficoltà?
Un buon ciclo di vita del software dovrebbe includere alcune fasi chiave e coinvolgere tutti gli stakeholder. L’ordine di queste fasi è importante e generalmente segue il percorso dall’ideazione di una funzionalità fino all’utilizzo da parte dell’utente finale. Le iterazioni dovrebbero avvenire all’interno di ogni fase, ma anche a cavallo di fasi diverse: nel piano di progetto le fasi si possono sovrapporre, per cui potrebbe essere necessaria anche una parallelizzazione del lavoro.
Le fasi chiave sono:
ideazione ed analisi: definire una visione del valore che potrebbe apportare la funzionalità e stabilire quali sono i requisiti necessari per realizzare tale visione. Le domande da porsi sono “Cosa?” e “Perché?”
progettazione ed architettura: descrivere in dettaglio come potrebbe essere la funzionalità in termini di esperienza utente e architettura. La domanda da porsi è “Come?”
pianificazione e prioritizzazione: definire le dipendenze e ordinare il lavoro in modo da fornire più funzionalità possibili nel modo più efficace, dati tutti i vincoli. La domanda da porsi è “Quando?”
sviluppo e test: stabilite le fasi precedenti, implementare la funzionalità in modo che sia verificabile e che fornisca quanto definito dalla visione.
Chi ha partecipato ad un progetto software sa che raramente fila tutto liscio; e anche se non ci fossero intoppi, ci sono sempre punti che si possono migliorare.
La prima cosa da fare per migliorare la software delivery è analizzare il ciclo di vita del software che si sta seguendo. In che modo un’idea passa dalla testa del product owner ad essere una feature funzionante nel software di produzione? Se c’è una risposta e corrisponde alla realtà, si è già sulla buona strada. In caso contrario, o se si sta definendo per la prima volta il ciclo di vita del software, esaminare ogni passaggio aiuta ad evidenziare le aree problematiche o carenti.
Per esempio alcuni punti critici possono essere:
analisi insufficiente
pianificazione errata
prioritizzazione inefficace
scarso coinvolgimento degli stakeholder
architettura non adeguata
progettazione mediocre
Man mano che una funzionalità si muove all’interno del ciclo di vita del software, comporta costi maggiori: bisogna infatti considerare tutto il lavoro intrinseco nella progettazione e lavorazione. Questo costo è per la maggior parte stimabile, reso visibile e pianificato in anticipo tramite stime con story points o meccanismi analoghi.
Tuttavia si possono generare costi nascosti in un ciclo di vita del software non ottimale; tipicamente questi costi extra si concretizzano quando si verifica il feature thrashing cioè il rilavorare più e più volte la stessa funzionalità. Qualche piccola modifica o rilavorazione è inevitabile in ogni progetto, soprattutto in un paradigma incrementale nel quale il feedback dell’utente è parte integrante del processo, ma rilavorazioni non necessarie o eccessive sono la spia che il ciclo di vita del software non è efficace quanto dovrebbe.
Forse la funzionalità era del tutto sbagliata fin dall’inizio e qualsiasi implementazione già completata deve essere buttata via. Forse la funzionalità è complessa e non è stata sufficientemente progettata prima dell’inizio dello sviluppo, portando a bug, prestazioni scadenti o vicoli ciechi nello sviluppo. O forse la funzionalità viene modificata ad ogni iterazione perché non è ben chiaro qual è il suo valore reale e la sua priorità.
Se il feature thrashing si verifica per grandi funzionalità, può intaccare in modo considerevole il budget del progetto; avere un ciclo di vita del software ben definito e consolidato aiuta a ridurre i costi non necessari.
Quali sono le cause del feature thrashing?
insufficiente (o eccessiva) analisi, pianificazione, architettura o progettazione
Identificare e risolvere le cause è la chiave per implementare un buon ciclo di vita del software.
Dato che i costi aumentano man mano che una funzionalità si sposta nel ciclo di vita del software, dovrebbe esserci uno sforzo attivo da parte di tutti (product owner, team, stakeholder) per “spostare prima” le attività di analisi, progettazione e architettura della funzionalità: queste dovrebbero essere fatte il prima possibile nel piano complessivo del progetto, o meglio nel punto in cui sono più economiche da realizzare e dove il costo di rilavorazione è ridotto al minimo. E’ meno costoso modificare un requisito prima che venga implementato anziché dopo.
Una buona pratica è cercare di identificare in anticipo le potenziali aree critiche, ossia quelle aree complesse o controverse che richiederanno un’analisi inziale molto più dettagliata, o che potrebbero richiedere una prototipazzione prima dello sviluppo per poi selezionare la strada migliore: wireframe per la User Experience e Proof-of-Concept per la parte tecnologica.
Identificare un product owner che garantisca che le decisione prese vengano documentate e stabilire procedure per gestire eventuali modifiche assicura che le priorità siano costantemente monitorate. I costi derivanti dalle modifiche devono essere trasparenti e noti a tutte le parti, in modo da evitare brutte sorprese in futuro.
Quando si prendono decisioni sulle priorità, è necessario sempre tenere a mente il quadro generale e non esclusivamente la scadenza a breve termine. Per ogni iterazioni bisogna comunque prevedere che una parte del budget venga destinata a lavori non pianificati (per es. bug critici).
Coinvolgere tutte le parti interessate (product owner, team, stakeholder) è fondamentale per la buona riuscita del progetto; per questo è necessario garantire una comunicazione efficace per consentire la discussione di problematiche non appena vengono individuate e responsabilizzare tutti nel processo decisionale. Bisogna prevedere del tempo per sistemare i punti problematici prima che diventino ancora più critici, o perlomeno formulare una stima della loro portata e priorità rispetto ad altri problemi da affrontare.
L’orizzonte temporale è un criterio importante da tenere in considerazione per un progetto software di successo. Se il team è sovraccarico e l’unico orizzonte visibile è la fine dell’iterazione, possono sorgere dei problemi. La visione e l’ambito diventano troppo ristretti e il team può finire a girare in tondo sviluppando, modificando, riprogettando la stessa funzionalità: insomma, il peggior genere di feature thrashing.
Al contrario se l’attenzione si concentra solo sul quadro generale e l’ambito è troppo ampio, il progetto può allontanarsi dall’obiettivo di consegnare valore in modo costante e iterativo.
In questo caso può succedere o che non si definisce adeguatamente la feature prima che venga sviluppata, generando così inevitabili rilavorazioni successive, oppure al contrario si rimane paralizzati nella fase di analisi non arrivando mai all’implementazione.
I progetti software di successo sono quelli dove la gestione della timeline sa bilanciare obiettivi a breve termine con quelli a medio e lungo termine.
Una visione ad alto livello del progetto dovrebbe essere visibile agli stakeholder, senza entrare troppo nel dettaglio ma condividendo in modo chiaro le milestone di progetto e le aree impattate dalle funzionalità: lo scopo è quello di definire una pianificazione generale delle tempistiche e del budget.
Quando si guarda ad un orizzonte temporale a breve termine, dovrebbero essere visibili e condivisi anche i dettagli relativi all’analisi della funzionalità, la progettazione, l’archittettura. Questo diventa particolarmente importante per le funzionalità in lavorazione nell’iterazione corrente e nelle prossime due. In questo modo team e stakeholder possono lavorare e perfezionare man mano le informazioni.
Il ciclo di vita del software è determinato per la gran parte dalla definizione e messa in atto di un processo; tuttavia la tecnologia è fondamentale per raggiungere una consegna efficiente del software a cadenze regolari: si pensi alla scelta del linguaggio e dei framework di implementazione, ma anche a tutti gli strumenti di continuous integration e ai tool necessari per creare delivery pipelines automatizzate (building, testing, releasing…).
La scelta delle tecnologie più adatte deve sempre essere fatta tenendo presenti la visione e i requisiti. Lo scopo del progetto software è fornire valore all’utente finale e le decisioni tecnologiche che si valutano devono essere le più adatte in relazione alle competenze del team e al risultato che si vuole raggiungere.
Se qualcuno di questi problemi ti suona familiare, può essere utile revisionare il tuo ciclo di vita del software; dedicare del tempo per migliorare il processo può portare a vantaggi tangibili e duraturi.
In ogni team c’è sempre spazio a miglioramenti. Saremo lieti di rivedere insieme a te i tuoi attuali approcci in una sessione strategica con un nostro consulente di technical leadership; scrivici a info@openinnovation.it
