Come produciamo il software che ci chiedete: il modello Agile e il metodo Scrum

“Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso..” cit. Bob Martin, Snowbird, Utah

Alcuni giorni fa ho iniziato a raccogliere del materiale per fare un post sul 20° anniversario del Manifesto Agile, una metodologia adottata in tutto il mondo per lo sviluppo del software (e non solo).

Personalmente ho iniziato ad utilizzare alcune parti del modello inconsapevolmente e solo dopo ho scoperto che quello che facevo era stato codificato nella metodologia Agile in cui mi sono subito ritrovato. Oggi io e il dev team della Softing applichiamo questo metodo di sviluppo in tutte le applicazioni che produciamo (in una versione rivista e adattata alle nostre dimensioni)!

Nel 2021 “Agile” è molto più un sostantivo, e viene utilizzato nella formazione, nel coaching, nella consulenza, nel marketing ed in molti altri settori. Il Manifesto è stato tradotto in più di 60 lingue.

NdA: Mentre raccoglievo testi e spunti per scrivere questo articolo, questa mattina su LinkedIn un Project manager (con la P maiuscola) ha postato un video che spiega alla perfezione tutto il metodo Agile, inserendolo nel contesto più adatto che è il Project Management. Se siete interessati all’argomento non ve lo perdete! Per quanto mi riguarda lo terrò tra i miei video preferiti e lo farò vedere ad ogni cliente che mi chiederà in che modo sviluppiamo il software perchè non sarei mai capace di descriverlo meglio. Grazie Marco Caressa. (Il video è in fondo all’articolo).

Se invece preferite leggere, provo a descrivere il modello:

Che cos’è Agile? e Scrum?

La parola Agile viene utilizzata per la prima volta nel 2001 con la pubblicazione del Manifesto per lo sviluppo Agile del software. Mentre la parola Scrum venne già utilizzata nell’articolo “The New New Product Development Game” del 1986 pubblicato dalla Harvard Business Review nel quale gli autori, Nonaka e Takeuchi, spiegano una modalità di lavoro in team per sviluppare nuovi prodotti che ricorda la mischia del rugby, lo Scrum, dove l’intero team decide come muoversi al momento e in modalità auto-organizzata.

In sostanza Agile è prima di tutto un mindset, quindi una filosofia, un modo di pensare, un paradigma organizzativo descritto da 4 linee guida che ne costituiscono la filosofia e definito da 12 principi.

Il Paradigma

“UN PARADIGMA È UN INSIEME DI TEORIE, MODUS OPERANDI, METODOLOGIE, ASSUNTI, MODELLI OPERATIVI, IDEE E CREDENZE CHE PERMETTE DA UNA PARTE DI AVERE UNA LETTURA DELLA REALTÀ, DALL’ALTRA FORNISCE GLI STRUMENTI OPERATIVI PER AGIRE SU QUELLA REALTÀ.”

Molti aspetti della realtà oggi sono complessi. Ogni contesto complesso è definito V.U.C.A. ovvero: Volatile, Imprevedibile (Unpredictable), Complesso e Ambiguo. In questi contesti la velocità di adattamento è l’unica risposta possibile. Agile è la capacità di rispondere in modo rapido anche ad aspetti complessi e non pianificati. O meglio, è la capacità di ripianificare continuamente che cosa fare per cogliere le opportunità che emergono dall’ambiente in cui si opera.

Lo schema

Agile e Scrum non sono la stessa cosa. Scrum è una delle tante metodologie Agile, sicuramente la più popolare, ed è per questo che viene spesso associato ad Agile.

Il modello Agile è un concetto astratto, una filosofia che se fosse materiale sarebbe allo stato liquido e prenderebbe le sembianze dell’acqua di cui parla Bruce Lee nel famoso aforisma “Senza forma, senza limiti, come l’acqua”.

Il metodo Scrum è un framework costituito da un insieme di pratiche che suddividono i processi di gestione del progetto in base alle esigenze del cliente.

Questo schema si presta perfettamente ai nostri progetti, visto che nasce proprio in contesto informatico per la produzione di software.

Il metodo Agile Scrum

In una società e in un contesto produttivo in continuo mutamento questa filosofia si contrappone all’approccio dove un progetto viene definito prima e poi mandato in produzione, ma “sfida” l’approccio tradizionale e lineare suddividendo i progetti in piccole parti da realizzare in brevi periodi denominati sprint.

Ogni sprint è caratterizzato dal rilascio di un semilavorato di valore, funzionante e apprezzabile dal cliente, che viene testato dal cliente stesso così da verificarne la congruenza con le sue aspettative e che così interagisce con il team di sviluppo e valida, propone o apporta modifiche al progetto.

Ciò permette al metodo Scrum di avere un approccio incrementale in cui ogni Sprint migliora quello precedente avvicinandosi sempre più al risultato atteso dal cliente e attenuando in questo modo il rischio di fallimento del progetto stesso.

I 3 pilastri della filosofia Scrum

  • Trasparenza: chiunque partecipi al progetto conosce il proprio scopo e quello degli altri;
  • Ispezione: verifica di ogni iterazione ed incremento attraverso metriche di misurazione che consentono un alto grado di adattabilità e piena libertà di modifica;
  • Adattamento: in base ai risultati dell’ispezione il progetto viene continuamente revisionato per migliorare le performance e garantire il maggior valore possibile al cliente finale

I 3 ruoli inclusi nello Scrum Team che lavorano fianco a fianco

  • Scrum Master: il responsabile del processo che garantisce il rispetto della metodologia Scrum, elimina ostacoli e organizza meeting di confronto;
  • Product Owner: l’interfaccia tra business e cliente, massimizza il valore del prodotto e gestisce gli interessi di tutti i stakeholder;
  • Team di Sviluppo: il gruppo che si occupa dello sviluppo del prodotto, testa le funzionalità e organizza le priorità in task da completare.

I 3 artefatti utili a massimizzare trasparenza, ispezione e adattamento

  • Product Backlog: documento che contiene la lista di tutti requisiti necessari per la realizzazione del progetto;
  • Sprint Backlog: documento che definisce tutti i task da completare nei singoli sprint;
  • Incremento: la somma di tutti gli elementi del Product Backlog completati durante uno sprint e durante gli sprint precedenti.

I 4 eventi Scrum programmati per ridurre sprechi e ritardi

  • Sprint Planning: il momento in cui il Product Owner stila il Product Backlog, descrive gli item più importanti e l’obiettivo da raggiungere;
  • Daily Scrum: confronto giornaliero tra Team di Sviluppo e Scrum Master in cui si annota il lavoro svolto il giorno precedente e si crea un piano per le prossime 24 ore per prevedere e sincronizzare le attività;
  • Sprint Review: una revisione alla fine di ogni sprint per valutare i risultati in cui partecipa anche il committente;
  • Sprint Retrospective: analisi retrospettiva per valutare come migliorare ulteriormente le performance nello sprint successivo.

Gli appuntamenti operativi

Le Cerimonie (incontri stabiliti) che compongono ogni Sprint:

  1. Sprint Planning: Ogni 2 settimane, solitamente il lunedì, pianifichiamo le attività da svolgere;
  2. Rilasci: Ogni 2 settimane, solitamente il giovedì, avviene l’aggiornamento delle funzionalità delprogetto;
  3. Sprint Review: Ogni 2 settimane, solitamente il venerdì, il team di sviluppo mostra ai clienti il lavoro svolto e le novità implementate;
  4. Sprint Retrospective: Ogni 2 settimane, solitamente il venerdì, ci confrontiamo su cosa ha funzionato e cosa no.

Ogni giorno un breve Stand Up Meeting (Daily Scrum) permette di allinearci internamente su cosa si è fatto il giorno precedente, il programma giornaliero e gli obiettivi da completare nel giorno.

Lavorare in blocchi operativi per raggiungere gli obiettivi dei vari step e condividere con il cliente l’intero progetto permette di creare un rapporto di fiducia e garantire un vantaggio competitivo caratterizzato da efficienza e qualità.

Perché SOFTING utilizza il metodo Agile Scrum

Alla SOFTING abbiamo sposato il metodo Agile Scrum perché a nostro avviso offre numerosi vantaggi che permettono di lavorare in maniera trasparente ed efficiente, garantendo il risultato ai nostri clienti.

Da quando utilizziamo questo metodo abbiamo beneficiato di numerosi vantaggi, diffusi su più livelli:

  • Siamo soddisfatti per la relazione fortificata con i clienti e la loro soddisfazione per il nostro lavoro;
  • Il team è maggiormente motivato perché ha il pieno controllo sul lavoro svolto con conseguente responsabilizzazione;
  • I clienti sono soddisfatti perchè comprendono cosa facciamo, verificano l’efficienza della pianificazione e il rispetto delle tempistiche, gradiscono l’interazione con il team di sviluppo ed apprezzano la possibilità di correggere le funzionalità in corso d’opera. E soprattutto vedono trasformare il proprio investimento economico nella soluzione che desideravano!

Siamo convinti che la perfezione non esiste ma vada sempre ricercata, per questo da anni continuiamo ogni giorno a studiare per migliorarci continuamente e comprendere al meglio l’applicazione di questo fantastico schema.

NdA: siamo firmatari del Independent Signatories of The Manifesto for Agile Software Development (https://agilemanifesto.org/display/index.html) alla pagina #138 nel Febbraio 2009 (http://agilemanifesto.org/display/000000138.html)

Manifesto per lo Sviluppo Agile di Software

4 linee guida

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati a valorizzare:

  1. Individui e interazioni su processi e strumenti
  2. Software funzionante su documentazione completa
  3. Collaborazione con il cliente sulla negoziazione del contratto
  4. Risposta al cambiamento rispetto a un piano

Cioè, mentre c’è valore negli elementi a destra, diamo più valore agli elementi a sinistra.

I principi sottostanti al Manifesto Agile

12 principi

  1. La nostra priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
  2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
  3. Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  4. Committenti e sviluppatori devono lavorare insieme per tutta la durata del progetto.
  5. Fondiamo i progetti su individui motivati. Confidiamo nella loro capacità di portare il lavoro a termine.
  6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
  7. Il software funzionante è il principale metro di misura di progresso.
  8. I processi agili promuovono uno sviluppo sostenibile. I manager, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
  10. La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
  11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
  12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Buon Anniversario, Manifesto Agile! 20 anni portati bene!

Grazie per aver letto fino qui. Se non ne avete abbastanza.. buona visione!

Il video di Marco Caressa su Agile




Powered by Softing Consulting | Digital Technology | Privacy e Cookie policy | Social Wall | Check | OWA | FILE | ERP