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 contro-
producente, 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 è auto-
documentato. 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