Introduzione di “Metodologie Agile” nel processo produttivo software di una factory Rosario Turco Una metodologia qualsiasi ha bisogno

a supporto di una nuova mentalità, un’organizzazione adeguata e degli strumenti. La metodologia va “calata” e “customizzata” a seconda del progetto, del gruppo di requisiti considerati e delle tecnologie in gioco nel progetto, che possono spostare il “focus” metodologico su due grossi filoni: progettazione a componenti (palette, etc) o progettazione a classi (C++/PHP/Java/Dot net). Nel seguito sottolineeremo i “punti di forza” delle metodologie Agile su cui far leva e faremo qualche considerazione sul “come” e “cosa” introdurre nel processo produttivo.

Ogni metodologia Agile ha come obiettivo primario di: 1. ridurre i rischi 2. gestire, in modo efficace ed efficiente, il cambiamento dei requisiti 3. gestire l’analisi/progettazione/sviluppo/test facendo tesoro di tecniche di progettazione opportune: applicazione dei Design Pattern come strumento per gestire il cambiamento, software auto-testante unitario, automazione dei test per la regressione funzionale. 4. alleggerire il processo produttivo con l’automazione di determinate attività, senza però annullare la documentazione minima necessaria 5. mantenere i costi ridotti, mantenendo una buona qualità 6. creare e testare processi produttivi e organizzativi in modo che siano efficaci e light I rischi in generale sono essenzialmente:          Chiusura del progetto; Degrado del sistema; Numero dei difetti alto; Skill non adeguati; Tecnologie nuove; Fraintendimento delle finalità; Cambiamento continuo degli obiettivi; Funzionalità inutili; Rotazione continua del personale;

Per ridurre i rischi non si usano processi in cascata o Waterfall, ma processi iterativi ridotti; dove ogni processo va spezzato in vari task, con task che prevedono internamente delle iterazioni di refactoring per miglioramento del software, prima della consegna. I requisiti vanno suddivisi secondo la priorità di importanza; questo riduce gli slittamenti e permette la consegna della parte di “prodotto core” a maggior valore, su cui il team si concentra e ne fa il motore trainante futuro.

Questa è la fase in cui è fondamentale presidiare i requisiti, innanzitutto in ingegneria; vanno presidiati i requisiti sia laddove si pensa al business e dove si concerta l’analisi di alto livello; fondamentale è la comunicazione continua tra software factory e ingegneria per i chiarimenti ed il coinvolgimento del cliente, come parte integrante del team. Molta attenzione è da porre ai requisiti non funzionali, che condizionano architetture e infrastrutture, le metodologie SOA, etc. L’organizzazione in generale deve considerare tutte le sfumature e gli aspetti che sono governati dalla teoria dell’organizzazione aziendale *4+. E’ da favorire anche l’addestramento al management, con continui aggiornamenti. L’organizzazione, per essere efficace, richiede spesso che esista un’organizzazione di ingegneria (esperta sull’analisi e sui processi di business), una software factory (esperta di prodotti, architetture e sviluppo) e dei Program Manager (PM) trasversali di software factory, che abbiano la visibilità unificata di una catena di business, in modo che avvenga:  una analisi dei dati dei “flussi integrati end to end” eventualmente con strumenti a supporto per il test teorico dell’integrazione. Potrebbe essere necessario anche ridurre, laddove possibile, le ridondanze a minor impatto attuali sui SID, BVI etc. Si dovrebbe evitare di inoltrare in termini di dati “tutto a tutti e ridondante”. Occorre fare molta attenzione alle diverse astrazioni di uno stesso concetto: la data di emissione ad esempio potrebbero essere due date diverse, come data emissione CRM e data emissione fattura. Sono importanti le revisioni (miglioramento continuo) Una analisi funzionale integrata di business con una mentalità di miglioramento continuo con specifiche funzionali e di interfacce ben esplicitata (well formed) Una analisi infrastrutturale per nuove architetture per chiarire scenari , volumi, scopi dei flussi e solo dopo individuare tecnologie e prevedendo anche revisioni architetturali per verificare eventuali miglioramenti da introdurre (miglioramento continuo) Una pianificazione coerente come effort e capacità produttiva del singolo progetto, tra esigenze, sviluppo, collaudo, esercizio. Per il processo agile possono essere scelti strumenti RAD a secondo del progetto. Le specifiche dei requisiti utenti o le specifiche funzionali vanno verificate dalla software factory come copertura delle funzionalità e devono avvenire feedback verso le ingegnerie coinvolgendole nel processo lavorativo. Le specifiche tecniche di progettazione vanno fatte un minimo, in modalità light, soprattutto per esplicitare quei dettagli che altrimenti potrebbero non essere noti. Il controllo delle tempistiche di collaudo.

 

 

Se si lavora in ambito Object Oriented le fasi di Analisi, Progettazione, Sviluppo e test il vantaggio è insito nelle compattamento tipico dell’OO, non solo come metodologia, ma anche come organizzazione. Sono, quindi, meglio favorite in tal caso organizzazioni che vedono ingegnerie e sviluppo localizzate insieme e nella stessa factory. In generale l’organizzazione interna per la software factory dipende dal numero di progetti in gioco e dalla capacità lavorativa umana necessaria. Nella situazione “a molti progetti” serve una organizzazione gerarchica almeno a due livelli. Nella situazione “a un progetto” dipende se il numero di aree e persone è alto o meno. Se il numero di persone è alto l’organizzazione inevitabilmente è gerarchica, è più semplice allineare o comunicare ad aree. Nel caso di pochissime aree, una organizzazione non gerarchica è

apparentemente più motivazionale, ma mette in evidenza le caratteristiche empatiche “buone” o “cattive” del team leader. Occorre far attenzione ai ruoli e alla diversa valenza ed importanza che hanno le figure di project manager, team leader e di coach: tutte importanti e necessarie ma che lavorano su livelli lavorativi differenti; in grossi progetti è difficile che si possano concentrare, per gli impegni lavorativi, in una sola persona. Per progetti molto piccoli di 4-5 persone i tre ruoli possono essere riassunti anche da una sola persona. Un project manager, quindi, nasce dalla gerarchia organizzativa. Egli si occupa soprattutto di gestione del cliente, di gestione economica e di capacità produttiva dei team, di pianificazioni e scadenze, di comprensione del business aziendale, di budget interni/esterni e dell’assenso ai pagamenti. Con un paragone calcistico è una sorta di “mister” della squadra che lavora dalla panchina, tracciando gli schemi strategici necessari, entro i quali deve sapersi muovere tatticamente la squadra. Un buon team leader è, invece, una sorta di regista in campo, che tatticamente lavora nell’ambito della strategia ed è continuamente presente sulle attività di sviluppo al 100% come riferimento-faro e permette di far avanzare lo sviluppo del progetto con facilità, ottenendo di continuo una facile sintonia tra obiettivi aziendali e delle singole persone; riuscendo ad aggregare le persone di caratteristiche, personalità, skill e background diversi. La leadership nasce, qui, innanzitutto per la sua forte capacità dialogativa ed empatica. Un buon coach ha una leadership che gli discende dalla competenza metodologica e tecnologica; spesso diventa automaticamente, per caratteristiche naturali, il riferimento/consulente sulle attività di metodologia, architettura, sviluppo, test e installazione prodotti. Spesso è anche DBA e sistemista. E’ nato, quindi, per lavorare di continuo sul team di sviluppo alla ricerca di continue soluzioni: in poche parole è una “figura completa”. Spesso un team leader può anche essere un coach e viceversa. Se i ruoli sono in tre persone distinte, è necessario che ognuno si attenga ad esso, senza invadere o limitare il ruolo dell’altro, non solo perché sarebbe “poco disciplinato tatticamente”, un errore molto controproducente, ma non permetterebbe la giusta maturazione di responsabilità dei diversi ruoli e la crescita professionale delle persone. Il rapporto di fiducia è fondamentale; se non esistesse allora è meglio che il project manager si scelga in questi ruoli altre persone per il proprio team, anziché rovinare l’equilibrio psicologico del team. Meglio avere un team con le “persone giuste”, come carattere e professionalità. Qualunque sia il ruolo però la filosofia è quella di “non mettere il carro davanti ai buoi” e favorire l’iniziativa del ruolo stesso, altrimenti il progetto “non va da solo”, non c’è “squadra”, non scatterà la sinergia del capirsi a volo tra ruolo e squadra. Mantenere i costi e ottenere buona qualità è una possibile pratica se si riesce a far leva sui concetti di:      scelta oculata dei prodotti e del processo lavorativo (revisione e check, progetto per progetto) sinergia umane o trasversalità di determinati sviluppi (simulatori, parti infrastrutturali, test integrati etc) riuso dei prodotti sviluppati competenza e specializzazione su sviluppo o prodotti automazione.

Una organizzazione che favorisce sinergia, riuso, automazione, prodotti RAD e un processo agile ha sicuramente costi minori al variare del tempo.

Un progetto del filone progettazione a classi nell’analisi/sviluppo/test può adottare uno strumento RAD con plugin per il linguaggio prescelto (Java, C++/Dot Net) come ArgoUML, Rational Rose, Together, Eclipse; in modo da modellare il progetto così da passare dal Dominio del Problema (analisi/progettazione) al dominio della soluzione (progettazione/sviluppo) con introduzione di classi di servizio e Design Pattern, fino alla generazione di software e alla implementazione dei soli mattoncini elementari del linguaggio finale. Un RAD semplifica le fasi analisi/progettazione/sviluppo/test. Il RAD consente NON solo il forward ma anche il reverse, in questo modo il progetto è auto-documentato. La documentazione è semplificata dal RAD stesso. Un progetto del filone progettazione a componenti può adottare uno strumento RAD con plugin per il linguaggio prescelto (BusinessStudio per i Workflow di iProcess, Designer per BusinessWorks etc). Anche qui c’è progettazione/sviluppo con semplificazione con le palette (componenti) ed il progetto è autodocumentato. In questo caso viene eliminato anche la necessità del reverse. La facilità di sviluppo a componenti introduce qualche rischio: il focus qui è spostato sull’attenzione dei Pattern Architetturali per evitare problemi prestazionali o di soluzioni semplici e non adatte. Per i cambiamenti introdotti da campi introdotti nei flussi (SID, BVI etc), quindi stiamo parlando dell’evoluzione del business, il problema non è costituito molto da campi in più nel flusso (a meno del sistema che li deve trattare per il mapping o per il business); nè dai campi eliminati nei flussi che non impattano le validazioni dei flussi, anche se vanno eliminati con attenzione, specie se ciò costituisce un valore di semplificazione ed eliminazione della ridondanza. Per cui è un problema solo di contenere la variazione e spesso gli impatti dei cambiamenti nei flussi dipendono dalla tecnologia del progetto e dalla soluzione adottabile per rendersi “dipendenti al minimo”. Tra gli strumenti a supporto vanno intesi anche l’addestramento interno/esterno sulle tecnologie o i prodotti RAD, con soluzioni da scegliere in base ad un piano, o anche introducendo nel team persone che le hanno usate o le usano. In termini di metodologia, invece, Agile e Capability Maturity Model (CMM) sono coerenti e vanno nella stessa direzione. L’Agile si preoccupa di far comprendere all’IT che è possibile alleggerire o automatizzare determinate attività (documentazione, regressione dei test, ridondanze, specifiche) che richiederebbe troppo sforzo in termini di numero di persone. Sia Agile che CMM richiedono nel ciclo iterativo quattro fasi logiche: Pensare, Fare, Verificare e dare feedback (i ritorni sui miglioramenti). I check devono essere utili al miglioramento del processo produttivo e del prodotto sviluppato. L’altro tema importante è il test. Molto spesso le anomalie “pesano” soprattutto su requisiti vecchi per cui potrebbe essere poco efficace la Regressione dei test. Se si usa un a tecnica “Continuos System Test” (anche oltre le consegne) si possono aggiungere file di test e nuovi software per test agli attuali simulatori. Lo sviluppatore deve consegnare al System Test i propri file di test e contribuire ad aumentare il numero di test da poter rieseguire ad ogni KIT in modo automatico e auto-documentate (Su file, su DB). In tal modo ci si concentra solo sui KO. Il concetto vincente è l’automazione dei test con simulatori anche auto-sviluppati. Esistono, tuttavia, molti prodotti open source che permettono anche qui a costo prodotto nullo l’automazione (uno tra tanti è SOAPUI, con ruolo client o server e iniettore di test anche nei Load Test adatto alle architetture SOA, per Webservice SOAP http/https o JMS).

Una organizzazione di Testing è costituita da varie parti, trasversali o interne ai progetti:    configuratori dei framework di test (con prodotti come SOAPUI) che, dispongono il framework di test di sistema o di Load Test (automatico per catene di test) ; installatori di ambienti e esperti di prodotti (Oracle, TIBCO IProcess, etc); progettista/tester;

Spingere la tipologia di test anche all’integrazione tra i sistemi può essere un altro elemento chiave di abbattimento dei difetti, ma può portare alla necessità di una squadra parallela sui processi di business ritenuti maggiormente critici. Sebbene con l’automazione l’efficienza della copertura non è totale, per un fatto che dipende dal tipo di cambiamento del business o che determinati controlli possono essere fatti solo dall’uomo, c’è un efficace riduzione almeno del 70% degli errori di regressione. Molte aziende nella “progettazione del dato integrato nei flussi end to end”, stabiliscono o progettano in partenza i file di prova dei flussi importanti e utili al test (distribuendoli anche agli sviluppatori) e definiscono l’importanza o la gravità in termini di business sui campi in modo da fornire una priorità/gravità dei campi e dei test. In questo modo i test sono subito concentrati all’inizio sui campi di importanza notevole su cui si faranno il maggior numero di test e via via scemando verso i campi di importanza minore. Il refactoring (“Continuos Refactoring”) può essere continuamente introdotto e testato, dal team di sviluppo, almeno per le parti che si consegnano al collaudo e che comunque devono essere testate da quest’ultimo. Il collaudo dovrebbe adottare un Continuos System Integration, verificando anche requisiti pre-esistenti e strumenti di regressione integrata massiva dovrebbero essere introdotti. Per strumenti di Configuration Management, dipende dal progetto e se gli strumenti RAD possono adottarli e/o dai collaudi in gioco. Attualmente non esiste un vero problema sugli strumenti. Ne esistono molti anche open source e molto validi (SVN e CSV tra tutti). Sicuramente non vanno adottate duplicazioni. Potrebbero essere distinti gli strumenti di consegna del runtime (ad esempio PVCS) e quello di configurazione dei sorgenti e dei make (es. SVN, XMLCANON etc), magari per uno scopo di copyright aziendale (qualora fossero coinvolti gruppi esterni), oppure potrebbe essere uno solo per entrambe le attività di versioning e consegna. L’importante è che il concetto di versioning sia demandato allo strumento. L’organizzazione del progetto richiede che almeno gli interni introducano la metodologia, gli strumenti e il metodo di lavoro sul progetto, che avvenga poi l’utilizzo e ci sia un monitoraggio a scopo di un continuo miglioramento. Gli effetti si possono monitorare sul numero di anomalie e la gravità di esse, sugli scostamenti dalla metodologia impiegata, sulla quantità di refactoring vista in termini di quantità di Function Point, sulla quantità di Design pattern o Pattern Architetturali usati o non usati (revisione architettura di progetto ogni x mesi).

Tutti i processi Agile si equivalgono: XP, Scrum, Feature Driven Development (vedi [1]), etc. L’importante è introdurli e ottenere risultati efficaci: è la filosofia cinese del ”WU WEI” del “Minimo sforzo ma grande risultato”. Parafrasando la filosofia è possibile ottenere basso effort con buona qualità, che è l’optimum che si desidera in generale.

[1] http://it.wikipedia.org/wiki/Metodologia_agile [2] http://en.wikipedia.org/wiki/Capability_Maturity_Model [3] Organizzazione aziendale – Richard L. Daft - APOGEO

Sign up to vote on this title
UsefulNot useful