È da qualche mese che lavoriamo ai progetti dei nostri clienti con il sistema Agile, con una metodologia adeguata a noi. Agile è un flusso di lavoro da seguire nello sviluppo di progetti che ci porta a prediligere l’interazione con clienti e collaboratori per rispondere ad ogni richiesta che garantisca lo sviluppo di un software di qualità. E questo è un modo di lavorare completamente in linea con la nostra mission e vision.

Brevi cenni su Agile

Un po’ di storia

La filosofia Agile deriva in qualche modo dal Lean, impiegata in Giappone dalla Toyota per lo sviluppo industriale dell’automobile alla metà del secolo scorso. In risposta alla catena di montaggio negli Stati Uniti della Ford, Toyota ha studiato metodi che consentissero una migliore gestione degli approvvigionamenti di materiale, del personale e delle sue mansioni. In poche parole tutto era pensato per ridurre gli sprechi e garantire un miglioramento sistematico dei processi. Tutto questo portò a superare rapidamente il sistema della catena di montaggio fordiana garantendo migliore qualità, migliorie costanti al processo produttivo, e garantì una vita migliore per chi lavorava in fabbrica. Il sistema era vincente anche nel sistema che era diventato variegato e competitivo.

Agile accetta buona parte del manifesto Lean ma predilige la flessibilità e la risposta rapida al cambiamento rispetto alla sostenibilità su cui si basa Lean.

Agile nasce a cavallo degli anni 2000 per lo sviluppo del software da un gruppo di sviluppatori e teorici che durante una vacanza sulla neve hanno posto le basi della nuova filosofia di lavoro.

Negli ultimi anni è stato adottato con variazioni di metodo ad altri settori.

Il manifesto

Il manifesto di Agile riesce a condensare tutta la filosofia in pochissime righe. Attraverso le diverse metodologie di applicazione poi si mettono in pratica i principi chiave.

Ci preme sottolineare che nel manifesto non si vuole negare l’importanza di strumenti, documentazione, contratti e di un piano di azione. Si riconosce l’importanza di questi sottolineando la priorità che devono avere gli individui e le interazioni, il software funzionante, la collaborazione con il cliente e la risposta al cambiamento.

Tanti metodi, un solo Agile

Dalla filosofia e dal manifesto Agile sono derivate diverse metodologie che differiscono tra loro per l’applicazione pratica dei diversi principi. Ciò che le accomuna è il binomio leggerezza / flessibilità. Sono framework tutti molto documentati dai loro ideatori e sostenitori: Scrum, Extreme programming, Feature Driven Development, Lean software development, …

Il “nostro Agile” è una declinazione del metodo SCRUM.

Glossario Agile (scrum)

• Backlog – Lista di requisiti a cui assegnare la priorità. Si dice Product Backlog l’insieme dei requisiti che compongono l’applicazione. Lo Sprint Backlog è invece l’insieme dei requisiti pianificati per un’interazione.
• Product Owner – Gestisce le priorità del Product Backlog ed è responsabile del ritorno dell’investimento e della definizione del valore del lavoro svolto dal Team.
• Scrum Master – supporta il team, ottimizza e ne facilita il lavoro per raggiungere gli obiettivi. Lo Scrum Master (SM) risolvere gli impedimenti del team e lo protegge dalle interferenze.
• Sprint (iterazione) – Periodo di tempo fissato e concordato che va in genere dalle 2 alle 4 settimane, in cui si realizzano tutte le fasi di sviluppo del software.
• User story – Definizioni ad alto livello delle specifiche e dei requisiti del software, scritte dal punto di vista di chi richiede la funzionalità (es. Come cliente vorrei poter moderare un commento con un click).
• Retrospectives –  Incontro di revisione tra team, SO e SM sull’ultima presentazione al cliente.

Com’è cambiato il nostro modo di lavorare

Negli anni abbiamo sviluppato diversi progetti software importanti. Questi progetti richiedono parecchie giornate di sviluppo: oggi però si muove tutto molto velocemente e può capitare che durante il lavoro ci si accorga che le specifiche iniziali del clienti non siano più valide o che siano superate da nuove esigenze.

Agile, in questi casi, è fondamentale perché da la possibilità di individuare anche in corso d’opera nuove specifiche (backlog) e nuovi obiettivi che si sono manifestati durante la lavorazione. Leggerezza e flessibilità.

Ovviamente lavorare Agile non è semplice. C’è bisogno di una metodologia perché funzioni. Regole, strumenti, ritmo sono importanti e per riuscire a lavorare agile bisogna imparare a conoscersi come azienda e come persone. Dobbiamo capire come funziona la nostra produttività in modo da pianificare, insieme col cliente e il team, il percorso di lavoro migliore.

Con la metodologia Agile dobbiamo conoscere l’obiettivo del nostro cliente e lo scopo per cui il progetto viene sviluppato. Dettagli e specifiche di ogni funzionalità vengono invece definiti al meglio solo poco prima dello sprint.

Sembrerà strano a chi è abituato a dover leggere risme di specifiche, ma per capirne il motivo basta pensare a quante volte capita di leggere complessi dettagli per una funzionalità ad inizio progetto e poi doverli rileggere (e capire) nuovamente solo settimane dopo, quando la funzionalità viene davvero implementata.

Inoltre le specifiche dettate ad inizio progetto non è detto che siano ancora valide nel momento della lavorazione: pensate a quante volte cambiano API e collegamenti ai social network, a terze parti in genere o quante volte il cliente stesso possa cambiare idea in corso d’opera perché sono cambiati alcuni presupposti validi al momento della progettazione e non più oggi.

Se state pensando che questo è un modo per correre dietro a idee estemporanee del cliente, vi rassicuro. Nulla di tutto questo. L’incontro che anticipa lo sprint serve proprio a fare il punto su quello che serve necessariamente e che si svilupperà nelle successive 2 settimane. Discutere le funzionalità nel momento in cui devi svilupparle è consigliabile e funzionale per la buona riuscita del progetto.

Tutti insieme appassionatamente

Con Agile la progettazione non è più a carico di una persona che ne decide ogni caratteristica.

Sviluppatori, esperti UI e UX diventano parte integrante del progetto e possono offrire la loro expertise in maniera diretta.

Lavorare Agile comporta una responsabilizzazione di tutti i partecipanti al progetto che si sentono parte integrante e pensante di un progetto. Molte delle scelte che nascevano (e spesso restavano chiuse a chiave) nella testa di un project manager, sono condivise, pensate e messe in pratica dal gruppo di lavoro.

Chi sviluppa Agile ha maggiore coscienza del prodotto e del risultato che deve ottenere, lo ha condiviso e ha tempi concordati e certi per metterlo in produzione. A beneficio del progetto e di chi lavora.

Dicevamo che il ritmo e la condivisione sono fondamentali: le riunioni non durano più giornate all’inizio del progetto ma sono soprattutto brevi incontri quotidiani, pochi minuti davanti all’intefaccia o bevendo il caffè chiarendo cosa si è fatto e come si intende procedere.

Rilasciare Software funzionante

Poco più di un anno fa, nei dettagli di aggiornamento dell’APP Facebook per il mio smartphone ho letto: “da oggi ci impegniamo a rilasciare ogni due settimane novità e miglioramenti per la tua applicazione.”

Subito ho pensato a quando si attendeva la nuova release di Photoshop per correggere bug della versione precedente o per qualche nuova funzionalità. Sembra un secolo fa, c’era il supporto fisico (uno o più CD), non esisteva il software in abbonamento.

Oggi Adobe rilascia mensilmente nuove feature per i suoi software, chiedendo direttamente agli utenti attraverso blog e forum cosa maggiormente desiderino per migliorare i suoi strumenti. (come nel caso di XD).

Tutto ciò non sarebbe possibile se gli utenti non avessero già il software a disposizione per usarlo sui loro progetti in produzione. Le idee migliori nascono generalmente dall’utilizzo pratico: può averle lo sviluppatore, l’utente finale, il capo progetto.

Fornire il software funzionante con rilasci graduali vuol dire avere anche il miglior tester per il progetto l’utilizzatore finale.

Il cliente vede come il suo strumento cresce sprint dopo sprint, prende coscienza di quanto lavoro ci sia dietro una funzionalità e ha la percezione di avere tutto sotto controllo. Anche questo è un buon motivo di crescita lavorativa per tutti.

L’importanza delle priorità = aperti al cambiamento

Il concetto di priorità in Agile è fondamentale, sia per la definizione degli sprint backlog (lista delle cose da fare nel prossimo sprint) che, non meno importante, per la definizione di una offerta economica.

Il cliente potrà di volta in volta concordare con il PO cosa avere attivo nel software al termine dello sprint. L’offerta iniziale in pratica dovrà garantire un numero di sprint pesati sulle indicazioni iniziali dell’analisi fatta con il  cliente.

All’inizio può sembrare approssimativo e poco digeribile dal cliente che presenta una lista della spesa con un budget fissato al centesimo. L’esperienza nostra e delle grandi aziende che utilizzano queste metodologie invece garantisce come sia del tutto naturale realizzare da subito le cose indispensabili, poi a seguire quelle importanti, infine eventualmente quelle opzionali se non sono intervenute priorità e/o idee differenti che hanno preso il loro posto. Questo significa avere occhi aperti al cambiamento e alle reali necessità del cliente. Una volta sperimentato l’agile il cliente non vuole più tornare indietro, l’agenzia diventa parte integrante dei suoi processi che traggono evidente beneficio dalla collaborazione di tutti.

Agile a misura di Dot Next

Ci sono agenzie con certificazioni Agile, ma in una realtà come Dot Next al momento non si può raggiungere un Agile “perfetto”.

Noi siamo molto vicini al framework Scrum, forse il più adottato, certamente il più vicino alle nostre esigenze e sensibilità. Come abbiamo spiegato in precedenza, un team agile è formato da due figure (Product Owner e Scrum Master) più il team operativo.

Ogni metodologia va attuata da persone, da gruppi di persone in questo caso, e quindi è giusto studiarla inizialmente e farla propria conservando i punti chiave.

I progetti dove usare Agile saranno quelli a priorità di sviluppo software, user experience, User interface e non le parti dove la parte di creatività la fa da padrona. Non conviene strutturarsi e impostare un team Agile per il progetto di un semplice sito web, con poche giornate di sviluppo, né per la creazione dell’immagine coordinata di un’azienda.

Per agenzie con un organico come Dot Next diventa difficile pianificare attività con metodologie Agile particolarmente ortodosse, ma resta valido il nostro obiettivo di strutturarci al meglio per fornire un prodotto migliore al cliente. Adattarci alla metodologia e adattare un po’ la metodologia a noi.

In particolare facciamo riunioni quasi quotidianamente per gestire lo sprint backlog. Abbiamo meeting interni ogni settimana e incontri con clienti ogni due settimane.

Un’unica figura si interfaccia con il gruppo di lavoro e con il cliente. In questo caso, dovendo compiere il doppio ruolo (SM + PO), bisogna stare attenti a percepire le necessità e le esigenze del gruppo di progetto per modalità e tempi di sviluppo, interfacciandosi con il cliente costantemente, mediando e cercando di tirar fuori dalla sua esperienza diretta nuove idee, lista delle priorità e il massimo della collaborazione da parte di tutti.

Una release ogni 15 giorni

In Dot Next, ci organizziamo per rilasciare la nuova versione del software (o un’app o un sito web) ogni 15 giorni. Tutto molto diverso rispetto alla metodologia “Waterfall” con un’unica analisi e un’unica raccolta delle specifica iniziale e una fase di sviluppo che dura fino alla consegna finale.

Per i progetti a cui stiamo lavorando ci siamo tarati su questo arco di tempo ma non c’è una regola fissa se non quello della costanza e del ritmo. Come per gli atleti che fissano i giorni di allenamento in maniera costante… stesso concetto, stessa filosofia.

Spesso si tende a chiedere al cliente un lavoro di astrazione difficile, se non impossibile. I tecnici siamo noi, loro sono gli esperti del loro specifico settore. Proprio per questo le stories (specifiche di sviluppo) sono scritte dal punto di vista del cliente. Con l’aggiornamento e l’utilizzo continuo del software possiamo davvero capire cosa funziona e cosa è meglio cambiare o aggiornare. Lo possiamo capire noi grazie all’esperienza nello sviluppo e lo capisce il cliente.

Ovviamente rilasciare un software funzionante ogni due settimane implica impostare il lavoro in modo completamente diverso dal solito. Il software deve essere da subito sicuro, il database non può essere resettato ogni volta che viene eseguito un rilascio.

Con Agile non ci si può improvvisare, tutto va fatto col giusto metodo.

Il cliente giusto

È indispensabile che il cliente sia aperto a questo tipo di lavoro collaborativo, perché Agile entra anche nella parte amministrativa ed economica di un progetto. La definizione dei costi diventa più capillare, perché si ha il controllo sullo stato di avanzamento lavoro.

In questo senso il concetto di software abbonamento (as a service), di cui abbiamo parlato spesso in relazione con l’App Economy, si sposa bene con il concetto di Agile.

Ma ovviamente questo può anche portare a dei costi imprevisti: le cose cambiano in corsa, come detto, quindi alcune funzionalità possono essere rimosse e/o aggiunte: cambiando quindi il preventivo iniziale del progetto.

Rispetto ai progetti gestiti in “waterfall” dobbiamo riconoscere che i clienti, una volta entrati attivamente nel processo progettuale e realizzativo, percepiscono meglio il peso di tali variazioni e sono più coscienti e propensi ad individuare su cosa abbia senso investire e cosa no.

Dalla mia tesi di Laurea ai progetti di Dot Next

Personalmente Agile non è qualcosa di nuovo. Il mio primo incontro con il sistema Agile infatti è stato durante la mia tesi di laurea nel “lontano” 2001.

Cicli di revisione, design, lavoro, studio delle funzionalità: affrontavo lo sviluppo del mio lavoro con questa metodologia durante i miei incontri settimanali con il mio relatore. All’epoca non avevo capito ancora il potenziale, lo ritrovo ancora più valido e funzionale nel mio lavoro oggi.

Come detto in precedenza questa metodologia di lavoro si sposa bene con i valori di Dot Next che è fatto di prodotti di qualità e di relazioni con le persone. “Gli individui e le interazioni più che i processi e gli strumenti” dice il manifesto Agile.

Ci stiamo lavorando. Insieme.

I benefici del sistema Agile

• La qualità è la parte centrale del lavoro, definita come risposta immediata e ottimale alle necessità e al cambiamento.
• Crei fiducia, perché puoi vedere il lavoro subito.
• Riesci a tirare fuori il meglio da tutte le persone che intervengono sul progetto
• La Costumer Experience è altissima: il cliente è parte del progetto durante ogni fase di sviluppo
• Migliora le performance