Il successo di un progetto digitale può dipendere dalle architetture usate per svilupparlo e dal metodo di lavoro scelto.
Quando si parla di sviluppare un progetto digitale, come in qualsiasi altro campo, è fondamentale scegliere un metodo e gli strumenti più adatti agli obiettivi che perseguiamo e al modo in cui intendiamo raggiungerli. Dobbiamo stabilire come si svolgerà il nostro flusso di lavoro, in che modo vogliamo creare il prodotto finale e quanta flessibilità concederci all’interno di questo percorso.
Esistono svariate possibilità ed è bene conoscerle e vagliarle con attenzione, perché il successo di un progetto digitale può dipendere dalle architetture usate per svilupparlo e dal metodo di lavoro scelto.
Project control: pianificare e gestire un progetto
Prima di cominciare a lavorare su un progetto, bisogna analizzarlo a fondo per poter determinare in che modo impostare il lavoro. Il project control consiste proprio nello stabilire a che tipologia appartiene il progetto in entrata. Possiamo distinguere principalmente tre tipi di progetto:
- Definito, ossia conosciamo già le risorse, i tempi di sviluppo e i processi necessari per ottenere il risultato desiderato: un valido esempio potrebbe essere una catena di montaggio, che prevede un processo di produzione standardizzato.
- Empirico,quando conosciamo al massimo una delle tre variabili – tempi, processi e risorse da impiegare – mentre le altre due andranno stabilite in corso d’opera, come nel caso dello sviluppo di un software completamente nuovo.
- Statistico, che riguarda i progetti di cui conosciamo almeno due variabili tra tempi, risorse e processi perché abbiamo avuto esperienza di progetti simili, che ci aiutano a fare una stima realistica dello sviluppo del progetto.
Ogni progetto porta con sé obiettivi e necessità differenti, ma l’esperienza, come spesso accade, è di fondamentale importanza per trasformare un progetto empirico in uno definito, poiché permette di passare attraverso una fase statistica grazie allo studio dei progetti precedenti.
Inoltre, un approccio Agile è di grande aiuto per ottimizzare costi e tempistiche e al contempo valorizzare la creatività di chi lavora al progetto, perché la metodologia Agile privilegia il lavoro di squadra, il confronto continuo e l’evoluzione costante, senza imporre paletti rigidi e deadline fissate a priori.
Vediamo più nel dettaglio cosa comporta l’applicazione della metodologia Agile.
Il mondo Agile
La metodologia Agile si basa sulla flessibilità e su una distribuzione continua e rapida, oltre che su una serie di valori che guidano il modo in cui il lavoro procede. In altre parole, i software e le loro modifiche vengono consegnati in piccole dosi rilasciate in tempi brevi, allo scopo di coinvolgere il cliente in ogni fase del progetto.
Inoltre, la metodologia Agile utilizza il lavoro di gruppo come strumento di miglioramento continuo, preferendo le comunicazioni in tempo reale alla produzione di un’estesa documentazione. Le modifiche possono così essere integrate in qualsiasi fase del ciclo di vita del software.
Il manifesto Agile
Formalizzato nel 2001, il manifesto della metodologia Agile rappresenta oggi uno dei modelli più seguiti ed efficaci per la gestione dei progetti di trasformazione digitale. I suoi principi fondamentali sono i seguenti:
- Gli individui e le interazioni più che i processi e gli strumenti
- Il software funzionante più che la documentazione esaustiva
- La collaborazione col cliente più che la negoziazione dei contratti
- Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra, si considerano più importanti le voci a sinistra. Non si tratta quindi soltanto di un metodo per sviluppare siti e applicazioni, bensì di un approccio a tutto tondo, che riguarda sia gli aspetti pratici dello sviluppo software, sia l’obiettivo finale della soddisfazione del cliente.
La consegna frequente e in tempi brevi, infatti, garantisce una maggiore flessibilità e la possibilità di modellare perfettamente il progetto sulle richieste del committente, che possono evolvere nel tempo.
Il fatto che le necessità possano cambiare non vuol dire però ripartire ogni volta da zero; al contrario, le esigenze del cliente vengono messe al centro e comprese a fondo per evitare di sprecare risorse: una delle strategie operative della metodologia Agile è infatti il cosiddetto lean thinking, volto a eliminare gli sprechi di tempo e di risorse, aumentando l’efficienza dei processi.
Lean Thinking
Derivato dal sistema di produzione Toyota, il lean thinking si basa sul miglioramento continuo grazie al contributo di tutte le persone che lavorano sul progetto con un obiettivo comune.
Tutte le metodologie “snelle” puntano a ridurre o eliminare gli sprechi legati alle irregolarità, ai sovraccarichi e alle attività prive di valore aggiunto (a indicare questi sprechi si usano i termini giapponesi Mura, Muri, Muda). Stabilire se una certa attività apporta o meno valore al progetto è quindi fondamentale per impiegare al meglio le risorse a disposizione. Il Lean Thinking si basa su cinque principi fondamentali:
- Definire il valore
- Identificare il flusso del valore
- Far scorrere il flusso
- Far sì che il flusso sia “tirato” dal cliente (pull)
- Ricercare la perfezione
Una volta individuate le attività che portano valore o che sono assolutamente necessarie allo sviluppo del progetto, è necessario mappare il flusso di queste attività, con l’obiettivo di snellire i processi e individuare eventuali sprechi. A questo punto il progetto deve proseguire in un flusso continuo, senza intoppi e distribuendo il lavoro tra le varie risorse in modo che non si creino colli di bottiglia. Inoltre, sempre nell’ottica di evitare sprechi, è bene che sia il cliente stesso ad avanzare richieste precise in modo che il progetto corrisponda perfettamente alle sue esigenze.
Push vs. Pull
Come abbiamo detto, in una metodologia lean si parte dalle richieste del cliente, per evitare di sprecare tempo ed energie in attività non indispensabili per la riuscita del progetto. Questo approccio è noto con il termine pull, ovvero “tirare”, al contrario di un approccio di tipo push in cui si “spinge” una determinata soluzione perché considerata adeguata, indipendentemente dalle esigenze specifiche del cliente.
La logica pull è incentrata sulla comunicazione, sulla condivisione di responsabilità e sulla collaborazione con il cliente: questo permette di ottimizzare tempi e risorse senza dover effettuare previsioni che possono rivelarsi errate. Perché possa funzionare, l’approccio pull deve necessariamente essere basato su un flusso costante di informazioni scambiate con il committente.
Iterativo e incrementale
Nell’ottica di risolvere il problema del cliente nel modo più rapido e meno dispendioso possibile, la metodologia Agile prevede il rilascio di un prodotto in cicli di lavoro brevi e iterativi, in modo da costruire il progetto insieme al cliente, un’iterazione dopo l’altra, rivalutando costantemente priorità ed esigenze. Ogni singola iterazione è una fase autoconclusiva, che comprende analisi, progettazione, implementazione e test.
I feedback frequenti consentono di costruire il progetto in maniera incrementale, ossia partendo da un prodotto “di base” che possiede le caratteristiche fondamentali per rispondere alle necessità del cliente, migliorandolo poi a ogni passaggio, anche per adattarsi a situazioni in rapida evoluzione. Il dialogo tra il team di sviluppo e il committente è continuo, grazie alla brevità dei cicli di lavoro.
Nella metodologia Agile, il software rilasciato nei primi cicli di lavoro è già utilizzabile, ma verrà migliorato nei cicli successivi grazie ai feedback del cliente.
Scrum: valori, ruoli, artefatti ed eventi
Scrum è un framework Agile per la gestione del lavoro, pensato per team di piccole dimensioni che suddividono ogni progetto in porzioni da terminare entro un determinato lasso di tempo, chiamato “sprint”, come previsto dal concetto lean di ottimizzazione dei processi (Muri, Mura, Muda).
Con Scrum, un lavoro di grandi dimensioni viene diviso in sprint da 2-4 settimane in modo da ottenere cicli di feedback che vengono analizzati per adattare e implementare eventuali modifiche. In parole povere, potremmo dire che Scrum è un sistema che aiuta i team a lavorare in condivisione: il framework Scrum invita infatti a imparare dalle esperienze precedenti, a organizzarsi e ad analizzare i risultati ottenuti per migliorare costantemente.
Questo framework si basa su 5 valori fondamentali:
- Impegno: ogni membro del team garantisce di impegnarsi al massimo per raggiungere l’obiettivo comune.
- Concentrazione: per lavorare al meglio è bene concentrarsi su pochi elementi alla volta.
- Apertura: il dialogo è fondamentale per sapere cosa stanno facendo gli altri membri del team e quali sono gli eventuali problemi da risolvere insieme.
- Rispetto: trattandosi di un lavoro di gruppo, è indispensabile rispettare i compagni e il ruolo di ciascuno all’interno del team.
- Coraggio: il lavoro di squadra e il sostegno dei colleghi permette di affrontare anche le sfide più impegnative.
Nel framework Scrum il team si gestisce autonomamente: il cosiddetto Scrum Team, all’interno del quale non esistono gerarchie, si incarica di ogni aspetto del progetto. Le responsabilità sono condivise e ognuno può utilizzare appieno il proprio potenziale: in questo modo si ha un maggiore coinvolgimento di tutti i membri, con un conseguente aumento della produttività e della soddisfazione personale.
Esistono tuttavia alcuni ruoli fondamentali anche all’interno di uno Scrum Team:
- Product Owner: le sue principali responsabilità sono massimizzare il ritorno dell’investimento, definire le priorità e identificare gli obiettivi a lungo termine, interagendo costantemente con gli altri membri del team.
- Scrum Master: aiuta il team a raggiungere efficacemente gli obiettivi, è un facilitatore; il suo compito è rimuovere gli ostacoli che possono compromettere la riuscita del progetto.
- Developer: costruiscono il prodotto richiesto dal cliente o dal Product Owner (talvolta le due figure coincidono).
Uno Scrum Team ha al suo interno tutte le competenze necessarie per portare a termine il progetto: una volta che il Product Owner ha esposto le priorità, il team stabilisce autonomamente su quali attività impegnarsi e le modalità di lavoro per raggiungere l’obiettivo, dando anche suggerimenti al Product Owner stesso per arrivare insieme al prodotto migliore possibile.
Per visualizzare tutte le informazioni utili a sviluppare il progetto, lo Scrum Team utilizza i cosiddetti “artefatti”: si tratta di strumenti che forniscono dati approfonditi sulle prestazioni di ciascuna fase del lavoro. In particolare, si distingue fra:
- Product Backlog: una lista di priorità, funzioni, requisiti o miglioramenti necessari per sviluppare il prodotto.
- Sprint Backlog: un piano di lavoro che comprende un insieme di task da affrontare nel successivo incremento di prodotto.
- Incremento di prodotto: ogni sprint prevede un incremento, ossia una componente del prodotto che costituisce un valore riconoscibile per il cliente e si aggiunge agli incrementi precedenti.
Per ogni artefatto esiste poi un impegno (commitment) attraverso il quale si possono misurare i progressi del team.
- Il commitment del Product Backlog è il Product Goal, ovvero lo stato futuro del prodotto, un obiettivo a lungo termine
- Il commitment dello Sprint Backlog è lo Sprint Goal, ossia il motivo per cui una determinata iterazione aggiunge valore al prodotto, si tratta dunque di un obiettivo a breve termine
- Il commitment dell’Incremento è il Definition of Done, che definisce quando il prodotto è pronto per essere rilasciato al committente.
Un altro aspetto fondamentale di Scrum sono gli eventi, ossia incontri fra i membri del team con una durata definita e un obiettivo chiaro. È grazie agli eventi che i membri del team possono confrontarsi regolarmente e valutare ciò che è stato fatto fino a quel momento allo scopo di evolverlo o correggerlo. I principali eventi sono:
- Sprint Planning: apre ogni singolo sprint e il suo obiettivo è proprio decidere cosa fare nello sprint che sta iniziando, stabilendo quale valore verrà aggiunto al prodotto e come ottenerlo.
- Daily Scrum: si tratta di un breve incontro giornaliero (massimo 15 minuti), nel corso del quale i developer valutano a che punto sono rispetto all’obiettivo dello sprint e se necessario riprogrammano il lavoro da svolgere (secondo la filosofia inspect & adapt, ossia studiare le condizioni attuali ed eventualmente correggere il tiro).
- Sprint Review: in questa fase si mostra al cliente cosa è stato fatto e si sollecita il suo feedback per valutare l’incremento raggiunto e decidere l’evoluzione del prodotto.
- Sprint Retrospective: è l’evento che chiude uno sprint; in questa fase non si analizza il prodotto in sé bensì il metodo di lavoro, per definire eventuali opportunità di miglioramento. Si tratta di uno strumento fondamentale per migliorare l’efficacia delle azioni del team e ottenere i risultati desiderati.
Quando parliamo di Scrum intendiamo quindi una serie di strumenti, ruoli e valori che supportano il team nella gestione del lavoro,e grazie ai brevi cicli di rilascio del software aiuta il team ad adattarsi alle esigenze in costante mutamento dei clienti.
Kanban
Alcuni strumenti considerati Agile sono precedenti alla stesura del manifesto della metodologia, ma vengono comunque considerati Agile perché ne rispettano i valori: è il caso di Kanban, i cui principi risalgono a più di mezzo secolo fa. L’ispirazione deriva infatti sempre dalla Toyota e dai principi lean Mura, Muri, Muda: ridurre gli eccessi senza sacrificare la produttività.
Un team Kanban si concentra esclusivamente sul lavoro che sta svolgendo al momento. Una volta completata una fase, il team sceglie quella successiva: se il Product Owner ridefinisce le priorità, il lavoro non si interrompe, perché eventuali richieste di modifica vengono prese in considerazione solo quando il team è al lavoro su quella fase specifica. Kanban è uno strumento spesso utilizzato in diverse applicazioni della metodologia Agile per visualizzare determinati aspetti del lavoro in corso.
Gli elementi del lavoro vengono infatti visualizzati sulla cosiddetta Kanban board, in modo che i membri del team possano controllare in qualsiasi momento lo stato dell’opera, con l’obiettivo di ottimizzare il flusso di lavoro. La board virtuale, punto imprescindibile di questo metodo, consente la tracciabilità di ogni singola azione, agevola la collaborazione all’interno del team ed è accessibile in qualsiasi momento da diverse posizioni. La board più semplice è composta da tre sole colonne: da fare, in corso e completato, ma ogni team può creare lo schema che meglio si adatta alle sue esigenze.
Una volta visualizzato il flusso di lavoro sulle Kanban card, ossia le schede della board dedicate a ogni singolo task, il team Kanban punterà a limitare la quantità del lavoro in corso (WIP), concentrandosi solo sulle attività che al momento sono necessarie. In questo modo, il ritmo di lavoro è ottimale, più rapido; inoltre è più semplice individuare eventuali elementi che bloccano il processo e non si rischia di superare la capacità di lavoro del team.
Utilizzare uno strumento come Kanban all’interno di un metodo di lavoro che prevede già i principi Agile può essere utile per gestire il flusso di lavoro in modo da rendere espliciti i criteri del processo,così che tutti i membri del team siano allineati, poiché la buona riuscita di ogni progetto è una responsabilità comune.
Scrum vs. Kanban
Sia Scrum sia Kanban vengono utilizzati all’interno della metodologia Agile ed entrambi prevedono la suddivisione del lavoro in unità più piccole, con l’obiettivo di ottimizzare i processi e di consegnare il prodotto il più velocemente possibile. Entrambi si basano su una logica pull, ma presentano anche alcune differenze sostanziali:
- Lo Scrum Team è completamente autonomo, sceglie come sviluppare il progetto e si impegna a rispettare le scadenze; non vi sono compiti imposti “dall’alto” ma esistono ruoli ben precisi (Product Owner, Scrum Master e Developer), mentre in Kanban non ci sono ruoli definiti a priori ma i compiti vengono affrontati in un ordine preciso.
- Scrum prevede una serie di sprint o iterazioni successive volte a migliorare i processi e la loro pianificazione; in Kanban invece il processo di sviluppo è continuo, anche se esiste un limite di elementi inseribili in ogni WIP.
- Scrum è basato su iterazioni di durata fissa: dato che il tempo è predeterminato, in ogni sprint può esserci un numero variabile di elementi da completare; in Kanban, invece, prima di passare al compito successivo bisogna aver completato quello in corso, il che può richiedere più o meno tempo.
- Con Scrum, alla fine di ogni sprint la bacheca di lavoro viene azzerata; la Kanban board invece viene utilizzata in modo continuativo.
Ogni progetto è diverso, per questo non esiste un approccio nettamente migliore di un altro: sia Scrum sia Kanban sono strumenti utili per organizzare il lavoro in maniera Agile.
XP: eXtreme Programming
Un’altra metodologia Agile per lo sviluppo di software, molto diffusa soprattutto tra la fine degli anni ’90 e l’inizio dei 2000, è la programmazione estrema o XP (extreme programming): il suo obiettivo è migliorare la qualità del codice e aumentare la produttività. Essendo una metodologia Agile, prevede il rilascio di software in cicli brevi e con feedback frequenti. Il termine “extreme” si riferisce al fatto che questo approccio porta all’estremo alcune pratiche considerate utili per lo sviluppo di un software.
I valori principali di questa metodologia sono la comunicazione fra tutti i membri del team e il cliente,la semplicità (bisogna risolvere solo il problema che è stato posto; le complicazioni vanno evitate), la verifica (il codice viene provato fin dall’inizio)e il coraggio (se si rendono necessarie delle modifiche, vanno implementate senza il timore di cambiare rotta per raggiungere l’obiettivo).
XP comprende una serie di 12 pratiche per lo sviluppo di software: vediamone alcune tra le più interessanti.
- Pair Programming: ogni postazione di lavoro è occupata da due persone, una con il ruolo di “guidatore”, che scrive materialmente il codice, e l’altra di “navigatore” o osservatore, che individua eventuali errori o problemi. Le due figure hanno le stesse competenze e si scambiano frequentemente i ruoli.
- Test Driven Development: i test vengono scritti ancor prima di cominciare lo sviluppo della parte funzionale, in modo da verificare ogni minima componente del software prima che venga implementata.
- Continuous Integration: l’integrazione continua prevede che i cambiamenti al codice vengano appunto integrati molto di frequente, in modo da prevenire eventuali problemi futuri.
- Refactoring: il software viene sottoposto a continue revisioni con l’obiettivo di renderlo il più semplice e “pulito” possibile, senza aggiungere funzionalità non strettamente necessarie.
Queste e altre pratiche dell’extreme programming hanno l’obiettivo di rispondere velocemente alle richieste di modifica da parte del cliente, rilasciando frequentemente incrementi di prodotto e puntando alla semplicità.
In un team che lavora con XP, tutti i membri del team di sviluppo hanno pari responsabilità e stabiliscono autonomamente la tabella di marcia. L’anello di congiunzione tra gli sviluppatori e il cliente è il manager, il quale si assicura che gli accordi stabiliti vengano rispettati e che la discussione tra le parti sia costruttiva. Similmente a quanto avviene con lo Scrum Master, può essere prevista la presenza di un coach che faciliti il rispetto delle pratiche di XP all’interno del gruppo.
L’XP coinvolge attivamente il cliente in ogni fase della programmazione, e proprio per questo richiede un impegno notevole, ma questa metodologia, se ben applicata, garantisce risultati eccellenti grazie ai test continui e a pratiche come il pair programming, che riducono la possibilità di errori. Il suo approccio minimalistico, inoltre, permette di avere un codice sempre chiaro e di apportare tempestivamente le modifiche necessarie, evitando di implementare funzionalità non necessarie.
Scrum vs. XP
L’extreme programming è precedente alla nascita di Scrum, ma sono entrambi approcci Agile basati su iterazioni brevi e incrementali, puntano all’autonomia del team di lavoro e a una comunicazione trasparente.
A differenza di Scrum, però, XP prevede una serie di pratiche ben precise per lo sviluppo di software e ha quindi un approccio più tecnico, mentre in Scrum sono gli sviluppatori a scegliere, di volta in volta, in che modo affrontare il lavoro e quali pratiche utilizzare.
L’enfasi in Scrum è quindi sull’organizzazione autonoma, mentre in XP il team deve rispettare quanto viene definito “dall’alto”: se lo Scrum Team individua le priorità insieme al Product Owner (o al cliente), in extreme programming è il cliente a stabilirle e il team non può metterle in discussione.
Dall’altro lato, XP ammette che non tutte le pratiche debbano necessariamente essere adottate in ogni singolo progetto, mentre l’approccio Scrum è più rigido, le iterazioni hanno durata fissa e lo Scrum Master si assicura che tutti rispettino gli stessi principi Scrum.
A ogni progetto il suo metodo
In conclusione, all’interno del mondo Agile è possibile scegliere strumenti, framework e metodi di lavoro diversi a seconda di quelli che meglio si adattano al progetto in corso. È però fondamentale che tutti i membri del team lavorino con gli stessi valori e non si creino conflitti o incomprensioni che andrebbero a pregiudicare la buona riuscita del progetto.
I metodi e i framework da applicare quando l’obiettivo è la trasformazione digitale di un’azienda dipendono quindi dalle esigenze del cliente, dal tipo di progetto, dalle competenze necessarie e dall’affiatamento dei team coinvolti, ma anche dalle esperienze precedenti nel caso si siano già affrontati progetti simili.
Se un’azienda non ha le conoscenze necessarie per sviluppare autonomamente un progetto digitale, la soluzione ideale è affidarsi a un partner in grado di fornire una consulenza personalizzata e di consigliare qual è la soluzione migliore per ogni singolo caso: Hermes possiede le competenze per suggerire alle aziende singoli talenti, team e servizi completi in base alle esigenze e al progetto da sviluppare.