Oggi vogliamo dare a chi ci legge la possibilità di conoscere dall’interno la nostra azienda per trasmettere l’importanza di essere flessibili anche nel processo di sviluppo, che deve avvalersi di strumenti che lo rendano più efficace e che non siano di ostacolo.

La metodologia Agile nasce nel nuovo millennio e si basa sullo stretto coinvolgimento del cliente nel processo di sviluppo del software allo scopo di massimizzare la sua soddisfazione.

I pilastri dell’Agile Manifesto sviluppato da Beck, Martin e Fowler sono pochi, semplici e chiari:

1. Persone ed interazioni devono avere priorità rispetto processi e strumenti
2. Il software funzionante deve avere priorità rispetto alla documentazione
3. La collaborazione con il cliente deve avere priorità rispetto al contratto stipulato
4. Rispondere ai cambiamenti deve avere priorità rispetto a seguire a testa bassa la pianificazione

Tutto questo avendo chiaro il valore di processi, strumenti, documentazione, contratti e pianificazione.

Il modo di implementare questi concetti è però fortemente legato alla dimensione aziendale di chi lo applica e dalla tipologia e disponibilità del cliente: non tenere in considerazione questi aspetti può far collassare l’intero business.

Ecco perché è sbagliato adottare strumenti di processo ad occhi chiusi, senza prima calarsi nella propria realtà.

Ci sono diversi modi per implementare i pilastri della metodologia Agile e senza dubbio il più famoso è quello di adottare il processo Scrum.

Le principali attività di tale processo ruotano attorno al concetto di Sprint, della durata di 1-4 settimane, nel corso della quale il team crea porzioni complete di un prodotto da poter presentare al cliente per suscitare commenti e promuovere la collaborazione.

I vari ruoli (Product Owner, Team di sviluppo, Scrum Master, Stakeholder, Manager) attraverso gli eventi (Sprint Planning meeting, Daily Scrum, lavoro di sviluppo, Sprint Review, Sprint Retrospective, Backlog Grooming, Scrum of Scrums) agiscono su un piano di lavoro rappresentato da story (le singole funzionalità) che passano dallo stato di Backlog (definizione della singola story) allo stato di Done (completato).

Aziende composte da team multipli ognuno dei quali dedicato a singoli clienti adottano questo processo nella sua variante più completa.

Fornire prodotti e soluzioni attraverso il modello Agile porta a strutturare i contratti con una remunerazione a tempo, rispetto che a progetto. Un cliente che ha la possibilità di seguire quotidianamente l’operato del fornitore e definire con lui come perfezionare il risultato durante lo sviluppo si trova ad investire sul tempo di un team di consulenti efficaci rispetto che sullo sviluppo di un progetto.

Chiedere però ad un cliente di aderire a questo tipo di rapporto non è semplice, è una pretesa troppo forte per clienti che hanno bisogno di budgettizzare investimenti in anticipo e si trovano per la prima volta di fronte a fornitori che propongono questo tipo di collaborazione ancora fin troppo complessa da integrare per piccole e medie realtà.

È inevitabile la necessità di instaurare prima un rapporto di fiducia, durante il quale il fornitore dimostra la propria responsabilità ed è inevitabile che il cliente abbia le capacità (tempo e risorse) per seguire questo tipo di rapporto. Con un cliente che non riesce a portare sufficientemente contributo alla verifica / supporto del progetto, i vantaggi non emergeranno.

L’impossibilità di donare un intero team ad un cliente è il secondo ostacolo per un’azienda di piccole e medie dimensioni, dove il team ha il compito di gestire più progetti contemporaneamente e la capacità di saltare rapidamente da uno all’altro diventa la skill più importante.

Ma se è vero che risulta difficile per delle PMI stipulare contratti puramente legati al tempo di sviluppo rendendo necessario sin dal principio definire dei costi per le funzionalità richieste, rimane fondamentale essere dinamici in modo da dare priorità alle difficoltà che durante lo sviluppo si incontrano e coinvolgere il cliente nel processo di sviluppo rimane un punto di forza per costruire un rapporto di fiducia.

Adottare tale processo in aziende mono-team come la nostra non è soltanto un vantaggio per aprirsi al cliente ma rappresenta anche uno punto di forza interno per responsabilizzare i componenti del team e allo stesso tempo rafforzarne il legame, portando la chiusura di una sprint, con la soddisfazione del cliente, ad un successo di squadra.

D’altro canto questo processo permette di fare emergere in maniera rapida le eventuali difficoltà che uno o più componenti hanno incontrato pianificando un’azione tempestiva già dalla Sprint successiva.

Per trarre questi risultati, in una realtà con le sue particolarità come la nostra, cerchiamo di vestire la metodologia Agile e il framework Scrum nella maniera più ideale per noi, senza schemi ferrei e con l’apertura mentale di poter modificare il processo nel momento in cui riteniamo sia opportuno farlo.

Ad oggi infatti preferiamo Sprint brevi, 2 settimane al massimo, che ci permettano di cambiare rotta o introdurre aggiustamenti in maniera rapida su più progetti. Ogni Sprint infatti ruota attorno al Team e non al Progetto. Il nostro team si troverà ad implementare story su più progetti, questo ci permette di massimizzare la reattività verso i nostri clienti e di sviluppare anche progetti minori dove lo sviluppo può richiedere solamente qualche mese. Non avere più di 3 progetti in una singola sprint risulta però necessario per non rischiare di aumentare troppo la complessità di saltare in tempi brevi da un dominio all’altro per un singolo componente del team.

Il nostro Team di sviluppo è composto da 4 / 5 componenti e un Product Owner (colui che rappresenta gli interessi del cliente) particolarmente sensibile alle necessità della squadra e che si occupa di essere anche il “guardiano” della sprint, lo Scrum Master.

Gli eventi che abbiamo all’interno di una Sprint sono:

1. Sprint Planning – Assegnazione di gruppo delle story che ogni componente andrà ad affrontare nella sprint che sta per iniziare;
2. Standup – Micro-meeting di gruppo ad inizio giornata dove ogni componente dichiara il lavoro svolto il giorno precedente e le story che affronterà nella giornata che lo aspetta;
3. Lavoro di sviluppo – Attività base di completamento delle story del singolo componente;
4. Backlog grooming – Approfondimento di gruppo delle story della successiva sprint con definizione di tempi e dettagli funzionali;
5. Demo – Presentazione di gruppo al cliente dei risultati della sprint e di una demo da provare con le funzionalità sviluppate sino a quel momento. Confronto con il cliente su eventuali miglioramenti da apportare;
6. Retro – Micro-meeting di gruppo al termine di una Sprint, dove il team si confronta analizzando pro e contro di ciò che è stato fatto, definendo azioni per migliorarsi nella sprint successiva.

Se da una parte tutti questi eventi di gruppo possono sembrare un consumo del tempo di lavoro del singolo componente del team possiamo assicurare che questo processo ci permette di anticipare e prevedere situazioni di allarme con netto anticipo risparmiando tempo speso a risoluzioni di problemi nei momenti meno opportuni.

Senza dubbio il vero vantaggio interno risulta la condivisione del processo da parte di più componenti: con uno sforzo davvero contenuto più componenti/menti contribuiscono a risolvere i problemi di ogni singolo e ciò, in maniera naturale, migliora la sua formazione.

Questo processo ci ha permesso di sviluppare assieme a SpazioTeatro89 una delle app fiore all’occhiello di Mango che continua a crescere nelle sue funzionalità. La continua interazione con il referente del progetto del Teatro ci ha permesso di fare un percorso personalizzato con il cliente per intraprendere le scelte migliori e massimizzare la sua soddisfazione.