Sono passati ormai vent’anni da quando il manifesto agile ha indicato una strada alternativa per affrontare i progetti in ambito IT.

Chi bazzica l’informatica da tempo sa che a intervalli regolari essa è attraversata da mode, che pur estremizzando nel primo periodo i concetti, sottintendono una piccola o grande rivoluzione che scaturisce da una reale esigenza del mercato o dei professionisti che vi lavorano.

L’agile è una di queste.

Ma davvero la metodologia agile è la panacea di tutti i mali?

Come sempre non è tutto così semplice…

Un punto di contatto tra lo Sviluppo e il Business

Il principio cardine che sottintende all’agile è quello di avvicinare il business, che solitamente è il committente, alla controparte tecnica che ha il compito di sviluppare il software.

I due principali attori che contribuiscono alla realizzazione di un progetto software, sembravano arrivare da due galassie molto distanti.

• PER LO SVILUPPO, il business era un’entità astratta che forniva requisiti vaghi e non capiva nulla di tecnologia.
• PER IL BUSINESS, gli informatici erano dei personaggi strani, chiusi nella propria bolla tecnica che nulla percepivano del mondo esterno e a cui nulla interessava di creare un ritorno dell’investimento per l’azienda.

La metodologia agile cerca di avvicinare questi due mondi perché questa è l’unica via maestra per creare un reale vantaggio per entrambi.

Il principio quindi risulta di valore inestimabile ed indiscusso!

Detto questo, la strada per raggiungere il traguardo risulta ancora da tarare e non priva di insidie.

Dubbi e considerazioni

Provando ad applicare la metodologia in maniera ferrea mi sono imbattuto in alcuni dubbi e considerazioni che provo a condividere come spunto di riflessione:

Documentazione: ridurre ai minimi termini la documentazione è realmente un vantaggio?

Quando i progetti sono di dimensioni importanti e coinvolgono molti attori e gruppi di lavoro, difficilmente le conoscenze tacite all’interno di ogni team possono coprire la totalità dei processi e l’interazione tra i vari sistemi. Senza condividere una documentazione ben organizzata e strutturata difficilmente sarà possibile definire e guidare il lavoro di tutti verso un obiettivo comune.

Requisiti: i requisiti sono realmente esplicitabili unicamente durante lo sviluppo?

La capacità di essere aperti al cambiamento nel mercato di oggi è un valore importantissimo. Ciononostante, costruire i requisiti durante lo sviluppo potrebbe portare a continui e pesanti ricicli con il rischio di far schizzare tempi e costi di progetto

Visione di insieme: risulta sempre possibile scomporre il progetto in una serie di microfunzionalità auto consistenti senza una visione di insieme?

Nei progetti reali ogni funzionalità o modulo dipende e collabora con altri in maniera fortemente connessa. Senza una visione di insieme chiara si rischia di dover modificare o riscrivere i moduli precedenti durante lo sviluppo dei successivi.

Coinvolgimento di tutti gli attori: la metodologia agile può avere senso se non viene condivisa e adottata da tutti gli stakeholders di progetto?

Ancora in moltissime realtà che sostengono di essere agili non è chiaro che il processo è attuabile solo se tutti gli stakeholders lo comprendono e operano in questa modalità. Il maggior vantaggio dell’agile è “portare a bordo” il business, se questo non accade si trasforma esclusivamente in un mero esercizio stilistico.

Product Owner: esiste realmente la figura del Product Owner in Italia?

La figura chiave di un progetto agile è il Product Owner. Purtroppo, almeno in Italia, una buona parte dei professionisti che ricoprono il ruolo, non hanno la capacità, la formazione o l’esperienza necessaria. Un Product Owner improvvisato di fatto vanifica l’efficacia dell’approccio.

Milestone fisse: risulta sempre vantaggioso definire milestone ad intervalli fissi e regolari?

Realizzare porzioni di codice da condividere con il cliente all’interno di un intervallo temporale fisso e regolare costa molto in termini di effort per rendere il software “presentabile”. In progetti complessi spesso l’incremento attuabile in un intervallo breve non risulta realmente significativo per l’utilizzatore finale. In alcuni casi sarebbe più efficace tarare le milestone in funzione di un incremento reale e significativo del prodotto.

Distorsione a breve termine: è sempre vantaggioso aggiungere nuove funzionalità ad ogni iterazione?

Uno dei principi fondanti dello sviluppo agile esprime la necessità di aggiungere nuove funzionalità ad ogni iterazione. I team devono continuamente decidere tra nuove funzionalità o l’ottimizzazione del software esistente, per evitare il debito tecnico. Questo può a lungo termine andare a discapito della qualità.

Riti e dogmi: il forte utilizzo di riti e dogmi aumenta la produttività?

Mi è capitato più volte di assistere ad una forte insofferenza verso i riti o dogmi imposti dalle varie metodologie di agile applicato. Ogni volta mi sono chiesto se fosse legato alla reticenza al cambiamento,ad atteggiamenti sbagliati delle persone o piuttosto al fatto che molto spesso ció che è imposto come dogma enon si adatta al contesto. o non porta dei vantaggi tangibili è percepito come inutile burocrazia.

Fine attività: nel rapporto con il business è sostenibile non riuscire a definire a priori una data attesa di fine attività?

Per sua natura l’agile affronta l’analisi delle funzionalità durante le iterazioni di sviluppo, questo può rendere difficoltoso stimare a priori l’elapsed di un progetto. Il business vive di time to market e costi. Se la metodologia ha come obiettivo avvicinare il committente, questo fatto difficilmente va nella direzione giusta.

Per concludere: l’agile rappresenta il futuro.

La strada risulta ormai tracciata…Come ogni cosa però possiede vantaggi e svantaggi, non andrebbe quindi adottato come religione.

Il Project Management a tutti i livelli, al di là di teoria e metodologie, è SEMPRE Buon Senso Applicato!