Quando ho pensato a un blog relativo al mondo Agile, ho pensato ad una serie di post correlati tra loro che ne evidenziassero l’applicazione pratica.
Fin ora abbiamo parlato abbondantemente di Architettura, Design e di come esse siano fondamentali anche nel mondo Agile. Ciò ci spinge ad affrontare in modo diretto quello che oggi in letteratura è riportato come il problema water-SCRUM-fall, termine derivato da una ricerca di Forrester intitolata “Water-Scrum-Fall Is The Reality Of Agile For Most Organizationsm Today”.
La ricerca mette in evidenza come la maggior parte delle aziende IT che utilizzano metodo Agili, adottano in realtà un approccio ibrido, in cui ad una specifica metodologia di sviluppo Agile (e qui Scrum la fa da padrone) vengono associate fasi, costrutti e cerimonie tipiche di approcci classici.
water-SCRUM-fall
In pratica Dave West (autore dell’analisi) identifica tre macro fasi nella produzione di una nuova soluzione IT:
. Water-[Scrum-Fall] che definisce le attività iniziali necessarie allo sviluppo di una nuova soluzione IT (Upfront Work). In un approccio Agile puro la fase più tradizionale di Analisi dei Requisiti / Architettura / Planning è ridotta al minimo indispensabile, tendenzialmente si cerca di eliminarla del tutto (ad esclusione di AM). E’ evidente come ciò, soprattutto in ambito enterprise, sia semplicemente improponibile poiché ad essa è associata la valutazione del Rischio e dell’Opportunità di realizzare il sistema stesso. Chiaramente queste attività soffrono dei problemi tipici del modello a cascata, come la “non conoscenza” dei requisiti funzionali reali desiderati dagli stakeholder;
. [Water]-Scrum-[Fall] definisce il Core delle attività di produzione, governando le attività di sviluppo del Sistema;
. [Water-Scrum]-Fall: definisce le attività finali di gestione (produzione) del nuovo sistema e, aggiungo personalmente, la fase di dismissione del sistema stesso.
Fermo restando le release progressive tipiche delle iterazioni di sviluppo, la gestione del servizio in produzione è cosa ben diversa. Essa impatta su tutta una serie di procedure interne all’azienda ed è, tipicamente, gestita dal settore Erogazione/Sistemistico, storicamente molto più legato a procedure che si sono affermate nel corso degli anni e quindi tendenzialmente reticente al cambiamento.
Se si riflette sulla complessità che governa le moderne aziende IT e la mission del Manifesto Agile che è quello di definire dei valori e dei principi e non nuove metodologie, lo scenario descritto da West è assolutamente plausibile e non deve assolutamente far ritenere che Beck e soci abbiano fallito nel loro intento.
Anzi: oggi sono poche le realtà IT di rilievo in cui l’Agile è visto come qualcosa di estraneo (anche se in Italia la situazione è un po’ meno rosea) ma quasi tutte concordano sulla necessità di applicarlo in modo organico al contesto aziendale, sposandone la cultura ed i processi.
Per ora ci fermiamo qui. Nei prossimi post cominceremo a parlare del lavoro di Scott Ambler e Mark Lines che ha portato al framework Disciplined Agile Delivery (DaD), pensato proprio per l’utilizzo di Agile tenendo conto del water-SCRUM-fall.
