Vi sono sempre più aziende che tendono a enfatizzare metodologie di questo tipo in progetti BI. Una strada che può portare buoni risultati
by Larissa T. Moss
Autori, esperti, i sostenitori dell’approccio Agile sono convinti che questa logica di sviluppo software possa dare ottimi risultati se applicata a piccoli sistemi stand-alone, dove sono presenti sviluppatori e utenti altamente motivati. Non esiste, invece, alcuna convergenza di pensiero riguardo all’efficacia di queste metodologie in altri contesti, come per esempio quelli che riguardano gruppi di lavoro estesi o progetti di complessità tale che non consentono una ripartizione del carico di lavoro su più gruppi con un limitato numero di persone. E quindi, è corretto o meno utilizzare un approccio Agile in progetti Edw (Enterprise Data Warehouse)/BI?
La differenza della metodologia Agile rispetto alle logiche Waterfall e Spiral
Prima di rispondere a questa domanda è bene esaminare le principali differenze tra le diverse metodologie.Le metodologie Waterfall sono state sviluppate negli anni Settanta per gestire progetti di sistemi operazionali. Sono metodologie organizzate per fasi e basate su tecniche di ingegnerizzazione tradizionali: pianificazione, requisiti, analisi, disegno, creazione e sviluppo. Ciascuna di queste fasi deve essere completata prima di passare alla successiva. La maggior parte del tempo di sviluppo consiste nella creazione di un documento di requisiti, modelli di disegno, specifiche interne e così via. Questo tipo di metodologia, anche nell’ambito di sistemi operazionali di tipo stovepipe, ha più volte evidenziato delle criticità. Molto spesso le stime si sono rivelate inaffidabili, in quanto ogni sistema, ogni team di progetto, ciascun gruppo di utenti presentava proprie specificità. Non va poi dimenticato che, utilizzando questa metodologia, gli utenti hanno modo di vedere il sistema solo dopo la fase di test di accettazione: solo allora possono essere rilevati errori, omissioni che necessitano di aggiornamenti.
Le metodologie Spiral sono invece diventate popolari negli anni Novanta per supportare la creazione iterativa di grandi sistemi. La loro adozione è comune in tutti quei progetti Edw dove le applicazioni BI vengono create una alla volta. Ciò significa che queste metodologie necessitano di attività aggiuntive che possono prevedere il coinvolgimento di stakeholder piuttosto che di utenti dell’applicazione di BI. Tuttavia, a eccezione dello sviluppo iterativo di Edw, le metodologie a spirale seguono, di fatto, una logica Waterfall.
Le metodologie Agile, infine, iniziarono a essere di pubblico dominio agli inizi degli anni Duemila e si diffusero tra gli sviluppatori di sistemi operazionali. Queste metodologie non considerano una richiesta di servizio come l’insieme di requisiti finali, ma la interpretano come una sorta di work in progress. Con la partecipazione degli utenti e degli sviluppatori cercano di associare i requisiti a specifiche feature che vengono inserite in un product backlog. Spetta all’utente il controllo di quest’ultimo, decidere quali feature aggiungere o rimuovere. La stessa assegnazione delle priorità delle feature è responsabilità dell’utente, mentre gli sviluppatori definiscono la prima release di software selezionando alcune delle feature prioritarie. Prima di fare una stima e renderla operativa, viene fatta una stima della tempistica necessaria per realizzare il codice delle feature selezionate. La progressione viene misurata dal numero di feature erogate e non dal numero di task eseguite. Quando risulta evidente che non esiste un allineamento rispetto alla deadline, il progetto viene immediatamente riadattato.
Scrum e XP
Due delle metodologie Agile più popolari sono Scrum e XP. Scrum (mischia) è un termine che deriva dal Rugby mentre XP sta per eXtreme Programming. Gli autori di queste metodologie sono project manager e sviluppatori con una vasta esperienza nello sviluppo di sistemi operazionali stand-alone, per lo più scritti in codice object-oriented. Non hanno nessuna particolare attinenza con sistemi Edw/BI ovvero non sono state sviluppate specificamente per questi ambienti. La scrittura di software per la creazione di sistemi stand-alone operazionali non richiede infatti attività di data integration, come standardizzazione ed enterprise data modeling. L’obiettivo di fondo è creare software di qualità in brevi e precisi intervalli di tempo, senza un particolare riguardo all’architettura dei dati in ottica enterprise.
La metodologia Agile può essere usata per la BI?
Vi sono sempre più aziende che tendono a enfatizzare metodologie di questo tipo in progetti BI. Per la mia esperienza, la maggior parte di queste aziende limitano lo sviluppo alla scrittura di codice per applicazioni BI stand-alone. In altre parole gli sviluppatori non hanno a che fare con standardizzazione e integrazione dati. Molti sono dell’idea che le attività di pulizia dei dati non possono essere soddisfatte con tempistiche sempre più stringenti. Non si rendono però conto che le attività di cleaning sono attività chiave nella realizzazione di applicazioni BI. Tuttavia, poiché l’obiettivo primario consiste nel mettere a punto soluzioni BI separate, per singoli individui o dipartimenti, lo sviluppo Agile, basato su metodologie come Scrum e XP, può risultare ottimale.
Alcuni team di BI preferiscono aspettare che i dati siano pronti in un Edw prima di sviluppare feature BI utilizzando Scrum o XP. Molti di coloro che hanno utilizzato questo approccio sono arrivati addirittura a separare il team di BI da quello Edw. Questo cambiamento può però essere dannoso e creare una competizione sleale tra i due gruppi. Sento spesso quelli della BI lamentarsi per la lentezza del team Edw così come sento questi ultimi lamentarsi perché il team BI non comprende l’importanza della standardizzazione dei dati né il tempo che ci vuole per immettere dati coerenti. L’Edw presuppone un lavoro “data intensive” e non “code intensive”. Le regole prescritte da metodologie come Scrum e XP non sembrerebbero pertanto adatte a essere impiegate in contesti di questo tipo: chi ci ha provato ha spesso fallito.
Agile per l’Edw?
Se volete applicare il metodo Agile in soluzioni end-to-end di BI, dove sono costantemente previste attività quali creazione o estensione di componenti Edw, Scrum e XP non possono funzionare. Ricordate: queste metodologie non sono state create per progetti in cui sono previste specifiche attività di standardizzazione dei dati. Ciò però non significa che non possiate prendere in considerazione l’approccio Agile.
Extreme Scoping
Subito dopo avere completato la definizione di una mia metodologia, nota come Business Intelligence Roadmap, ho sviluppato un approccio Agile, specifico per l’Edw, chiamato Extreme Scoping. Esso include attività di business integration che sono vitali a progetti Edw. Questa metodologia fa uso di tutti i principi Agile che possono essere traslati in un contesto di business integration mentre esclude quelli che hanno poca o scarsa attinenza per questo profilo di attività. Il mio metodo non ha la pretesa di sostituire Scrum e XP, ma vuole essere una sorta di ombrello Agile Edw per l’intero progetto, non soltanto per la scrittura del codice.
Extreme Scoping prevede la pianificazione di più progetti distinti che vengono distribuiti tra team formati da 4-5 persone. Si inizia con l’esaminare la metodologia Edw e a selezionare le task in un WBS preliminare che permette di creare una roadmap di progetto di alto livello con relative stime di tempi, risorse, costi e rischi associati alla realizzazione dell’applicazione di Business Intelligence. Questo serve a determinare il numero esatto di release software, la loro corretta sequenza e le dipendenze tra i requisiti.
Una volta determinata la portata e la sequenza delle release software, e avere definito deadline attendibili, viene creato un piano di progetto dettagliato per la prima release di software con precisi obiettivi settimanali. In questo modo si riesce a monitorare costantemente le attività di progetto e accorgersi in tempo se il campo d’azione è troppo grande per riuscire a rispettare la deadline o se le attività intermedie sono sovrastimate.
Dopo che le attività di progetto della prima release sono state organizzate per obiettivi settimanali, vengono creati più team di lavoro assegnando a essi compiti dettagliati per il raggiungimento degli obiettivi. Questi ultimi possono essere monitorati attraverso uno spreadsheet, o altre opzioni, ed essere modificati giornalmente in modo tale da gestire il cambiamento. Se la prima release viene completata rispettando le scadenze, senza incontrare alcun problema, si può procedere alla pianificazione della seconda release adottando lo stesso metodo seguito fino a quel momento. In presenza di problemi si dovrà invece aggiornare e modificare la roadmap di progetto.
Conclusioni
Extreme Scoping corrisponde a un processo di pianificazione di tipo Agile per progetti Edw basato sulla solida metodologia Business Intelligence Roadmap. Utilizza tutti i principi Agile che funzionano per progetti Edw/BI e non prevede alcuna forzatura nell’utilizzare principi Agile poco adatti a contesti Edw/BI.
———————————————————————————————————————-
Larissa Moss
Larissa Moss è una senior consultant nei settori della Business Intelligence e nel miglioramento della qualità dei Business Information Systems. È fondatrice e presidente della Method Focus Inc. Ha una esperienza di 27 anni nel settore IT, i suoi articoli sul Data Warehousing, Project Management, Information Asset Management e Data Quality sono pubblicati regolarmente su The Navigator, DM Review, Journal of Data Warehousing e Analytic Edge. È co-autrice con Sid Adelman del libro “Data Warehouse Project Management” e con Shaku Atre del libro “BI Roadmap: the complete lifecycle”. È una frequent speaker alle conferenze sul Data Warehousing e Crm negli Stati Uniti, Europa e Asia.
Larissa Moss presenterà a Roma per Technology Transfer il seminario “Approcci Agili al Data Warehousing e alla Business Intelligence” dal 22 al 23 Novembre 2012.
