Siamo tutti più Agili

Agile, Agile Manifesto, Continuous Improvement, CrowdM, Kanban, Metodo empirico, Project Management, Scrum, Team, Valore, XP /

ottobre 20, 2014

Ormai è diventata una moda, tutte le aziende parlano di Agile e dicono di praticarlo, ma è davvero così? In questo articolo cercherò di dare alcuni fondamentali in merito a queste discipline. In rete si trovano molti articoli e documentazione su questi argomenti dove potrai approfondire i concetti se riuscirò ad incuriosirti.

Va bene iniziamo.

Manifesto Agile

Il manifesto agile è un insieme di principi che sono il sunto di un incontro fatto nel 2001 da un insieme di guru dello sviluppo del software. Essi hanno deciso di mettere a fattor comune e formalizzare delle discussioni sui temi della gestione dei team e dello sviluppo software che venivano fatte dagli stessi nei forum su cui si confrontavano.

Alla fine dell’incontro hanno redatto quello che è il Manifesto per lo Sviluppo Agile di Software.

Manifesto Agile

“Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:
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, consideriamo più importanti le voci a sinistra.”

Partirò da queste considerazioni per introdurre questo mondo.

Ecco che già qui si può capire quanto di Agile ci sia nelle aziende gestite da manager che sbandierano tanto la parola agile: collaborazione col cliente più che negoziazione dei contratti.

In Italia purtroppo la maggior parte dei manager IT lavorano a budget e quindi chiedono per un servizio un preventivo che poi diventerà il prezzo pagato alla fine a prescindere dalle variazioni in corso d’opera. Ed ecco che cominciano i primi problemi di fondo.

Il triangolo… di ferro

Si non parliamo della famosa canzone di Renato Zero, ma della rappresentazione visiva di una relazione di un principio economico.

Il triangolo di ferro

Il triangolo che è una figura semplice e stabile, permette di rappresentare il collegamento che c’è tra 3 parametri fondamentali di un progetto. L’ambito, ovvero gli obiettivi che ci si prefigge, il tempo per realizzarli ed il costo che si deve spendere per raggiungerli tutti in quel tempo.

Al variare di una di queste grandezze devono per forza variare anche le altre, altrimenti la figura non sarà più un triangolo equilatero.

Quindi se si fissa un budget e si vuole spendere poco come accade quasi sempre nelle richieste dei manager IT italiani, bisogna ridurre l’ambito (o scopo, dal termine inglese Scope).

Esiste anche una quarta grandezza che fa parte di questa rappresentazione che è la qualità. Essa può essere rappresentata dall’area del triangolo.

Questo perchè a seconda del progetto e dell’azienda committente il concetto di qualità può essere differente.

L’aspetto fondamentale da capire è che essa però è influenzata dalle altre tre grandezze.

Legato a queste grandezze è il team e la sua preprazione. Maggiore è la forza del team, maggiore è la qualità del risultato finale.

Il Team

Il gruppo di lavoro o team è alla base del lavoro. Anche nelle aziende che utilizzano un approccio tradizionale il team è fondamentale.

Nelle metodologie agili è al centro del lavoro. La collaborazione all’interno del team è fondamentale. Questo perchè porta a persone che sono soddisfatte di quello che fanno, di conseguenza maggiormente motivate. La condivisione porta allo scambio e al confronto delle competenze, così da avere una crescita dei singoli membri del team che mettono a fattor comune le proprie qualità al fine di raggiungere l’obiettivo.

Questo è un aspetto difficile da ottenere in un team perchè spesso entrano in gioco gelosie e motivazioni personali che rappresentano un ostacolo.

Per questo all’interno di ogni team (o in affiancamento ad esso) ci deve essere la figura del coach che ha il compito di rimuovere gli ostacoli che il team trova durante il lavoro.

Il team può così concentrarsi sulle attività da effettuare rispettando quelli che sono i tempi e costi previsti e consegna valore alla fine di ogni iterazione.

Approfondiremo tra poco cosa sia una iterazione e cosa si intenda per consegna di valore.

Un ultimo aspetto che mi preme di sottolineare in merito al team è la sua preparazione. I team agili sono in generale più preparati dei team tradizionali proprio perchè le informazioni circolano e le persone le condividono.

Vengono fissati degli incontri di condivisione ed inoltre tutti i membri del team vengono preparati attraverso una formazione costante per farli crescere.

Possiamo ora passare al modo di lavorare all’interno del team.

Il processo

Come anticipato poco sopra lo scopo del team è quello di consegnare valore alla fine di ogni iterazione. Siamo al secondo punto del manifesto agile, software funzionante piuttosto di documentazione esaustiva.

Nei processi tradizionali waterfall oppure i successivi RUP e altre metodologie simili, il problema che ha portato al fallimento di una percentuale considerevole dei progetti è la distanza tra ciò che il cliente aveva in mente e ciò che è stato realizzato.

L’obiettivo che ogni fornitore deve avere è la soddisfazione del proprio cliente. Per raggiungere questa soddisfazione il fornitore deve riuscire a consegnare al cliente un prodotto che soddisfi i suoi criteri di valutazione e che quindi abbia un valore per lui.

Per riuscire in questo obiettivo il processo di lavoro si basa sull’utilizzo di iterazioni alla fine delle quali viene consegnato qualcosa che il cliente percepisce come di valore e che lo renda soddisfatto. Nel mondo agile esistono vari framework che possono essere utilizzati, e che possono differire in alcuni approcci, ma non li voglio approfondire in questa sede di carattere più generale. Ne cito alcuni per chi volesse approndire: Scrum, Kanban, eXstreme Programming (XP).

Il concetto di consegna di valore attraverso delle iterazioni di lavoro è comunque condiviso da tutti.

Nell’approccio tradizionale, viene redatta una analisi approfondita di quelli che sono i requisiti dell’applicazione. Questi soddisfano le necessità raccolte presso il cliente attraverso le interviste fatte alle persone di riferimento, cioè gli stakeholder (una precisazione in merito, gli stakeholder sono tutte le figure che il prodotto deve soddifare, quindi non è detto siano solo le persone intervistate). Raccolti i requisiti si passa alla fase di analisi e disegno, si scrive la documentazione che viene condivisa con il cliente e rappresenta il “contratto” di realizzazione. Si passa poi alla realizzazione, alla fase di testing e quindi alla consegna del prodotto stesso.

Lineare. Ma allora dove stà il problema? Nella natura umana e nella nostra incapacità di comunicare senza ambiguità, a mio avviso.

Durante le fasi iniziali di un progetto le persone hanno un’idea vaga di quello che vogliono, quindi raccogliere e mappare tutte le richieste è difficile. Scappa sempre qualcosa, anche ai migliori analisti. Alla fine dell’analisi viene consegnato un documento scritto, che molto spesso ha un linguaggio ambiguo e che viene interpretato in modo diverso dai vari lettori (ad esempio stakeholder e sviluppatore che realizza le singole funzionalità). Questo documento è di solito molto corposo e guarda caso nessuno dal cliente lo legge in modo approfondito, però viene approvato. Si prosegue quindi con la fase di realizzazione.

Finita questa, viene dato in testing al cliente e qui cominciano i dolori.

Le persone che hanno fatto da interfaccia e a cui sono state fatte le interviste hanno la loro idea in testa e vedendo il funzionamento del prodotto cominciano a chiedere modifiche: “non ci siamo capiti bene”, “non è quello che avevamo chiesto” delle frasi ricorrenti. In questa fase vengono coinviolte anche altre persone che fino a quel momento non lo erano direttamente. Ad esempio comincia ad essere dato in uso ad altre figure aziendali che saranno gli utilizzatori finali e con cui il fornitore non aveva mai parlato. Ah già, spesso i fornitori hanno il filtro dell’ufficio IT del cliente che commissiona il lavoro e raccoglie le necessità dai propri utenti.

Inizia così un problema di tempi e costi perchè comincia tutta una fase di modifiche nella quale il cliente non vuole sentire ragioni in merito a variazioni di prezzo; il fornitore si trova in difficoltà dato che ha realizzato quello che c’era nel documento di analisi approvato e quindi ha rispettato il contratto e non è giusto paghi la differenza di costi. Quindi tutti alla fine sono insoddisfatti.

L’idea di utilizzare le iterazioni e consegnare valore alla fine di ognuna di essa è quella di anticipare i tempi di confronto il prima possibile. Si definisce una iterazione temporale che abbia una dimensione abbastanza soddisfacente per entrambi, sia cliente che fornitore. Ad esempio una settimana, quindici giorni, un mese (quindici giorni è quello considerato più ragionevole in generale). In questo lasso di tempo si definiscono le funzionalità che il prodotto rilasciato dovrà avere. Si comincerà a realizzare le funzionalità che hanno maggiore valore per il cliente, cioè quelle che gli serviranno prima. Alla fine di ogni iterazione il prodotto potrà essere visionato da tutte le figure preposte e le variazioni necessarie potranno essere apportate. Qual è la differenza con l’altro approccio? Che le funzionalità realizzate sono in numero limitato e non sono tutte quelle del prodotto. Man mano che il prodotto è visibile ed utilizzabile tutti gli stakeholder cominciano ad acquisire coscienza di come utilizzarlo e migliorarlo e si chiariscono le idee iniziali che avevano. Magari si rendono anche conto che certe funzionalità che avevano in mente all’inizio in realtà non sono necessarie e magari gli era sfuggito qualche aspetto che è molto più importante. Ma analizzandoli successivamente questi aspetti possono essere soddisfatti appieno.

Alla fine di ogni iterazione sono previsti degli incontri di discussione e confronto anche con il cliente per capire cosa non ha funzionato nell’iterazione migliorare nella prossima, cercando di eliminare gli ostacoli incontrati durante il lavoro.

Si capisce che l’approccio cambia e che alla fine del progetto tutti saranno più soddisfatti degli obiettivi raggiunti. E se un cliente è soddisfatto è anche più ben disposto quando paga le fatture.

Non dimentichiamoci che alla fine tutti facciamo business e alla fine del mese abbiamo bisogno di entrate per poter proseguire nel nostro lavoro.

L’ultimo aspetto che mi piacerebbe trasmettere è l’utilizzo del metodo empirico per migliorare.

Metodo empirico… ma siamo impazziti?

L’accezione della parola “empirico” è sinonimo di incertezza. E questo è qualcosa che fa paura a tutti, specie a chi deve pagare per un servizio.

Il metodo empirico è però un approccio importante per la risoluzione di problemi complessi e non noti.

In tutte le attività della natura umana esistono delle situazioni che sono codificabili facilmente, mentre altre no. Quando viene commissionato un prodotto ad hoc (sia esso un software gestionale che un sito web) questo sarà diverso da tutti quelli realizzati in precedenza. Le variabili in gioco sono diverse, cambia il cliente, i suoi valori, i suoi parametri valutativi, le sue esigenze. Come comportarsi? Non può esserci una soluzione univoca che soddisfi tutti.

Ecco che entra in gioco il metodo empirico. Si applicano le soluzioni utilizzate in precendenza e che hanno funzionato, ma queste devono essere ricalibrate sulla singola situazione. Cioè impariamo dagli errori commessi in precedenza e cerchiamo di migliorarci e adattarci alla nuova situazione.

Si capisce che in sistemi complessi e nuovi è difficile utilizzare un approccio ripetitivo e replicabile come avviene in altre scienze dell’ingegneria.

Su questo concetto e sul concetto di team mi piacerebbe chiudere con una frase di Charles Darwin:

“Nella lunga storia del genere umano (e delle specie animali, anche) coloro che hanno imparato a collaborare e improvvisare più efficacemente hanno prevalso.”

Questo per dire che comunque sono convinto che il cambiamento è possibile in qualsiasi azienda, basta averne la volontà e l’umiltà di affrontare il cambiamento.

Alla prossima

Glauco

Alcuni approfondimenti

http://agilemanifesto.org/

http://office.microsoft.com/it-it/project-help/il-triangolo-del-progetto-HA010351692.aspx

http://www2.mokabyte.it/cms/article.run?permalink=mb165_metodoagile-1

http://martinfowler.com/

https://www.youtube.com/watch?v=oMTUcUoaKF8

http://www2.mokabyte.it/cms/article.run?articleId=L6D-LDX-V2R-N6V_7f000001_33025293_003c41b8

Libri

Agile Software Development, Principles, Patterns, and Practices di Robert C. Martin

Clean Code: A Handbook of Agile Software Craftsmanship di Robert C. Martin