AgileIoT

Durante l’evento DevOps@Work 2016¬†abbiamo avuto la possibilit√† di¬†seguire una sessione su AgileIoT, un nuovo standard metodologico elaborato da Felice Pescatore¬†in collaborazione con tanti altri appassionati per poter¬†definire una serie di linee guida utili a gestire progetti e soluzioni basate su IoT.

Per chi si occupa di Agile e gestione di progetti si tratta di una assoluta¬†priorit√†, dato che “gestire” con le metodologie Agile “classiche” un’attivit√†¬†in cui l’impiego di tecnologie e dispositivi che oggi vengono identificati con l’acronimo IoT (Internet of things) pu√≤ rappresentare un fattore di rischio molto elevato ed un possibile insuccesso delle aziende investitrici.

Questa necessità ha portato quindi ad una riflessione molto interessante, e il progetto (open) di AgileIoT è il risultato.

AgileIoT.png

Una metodologia nuova, ancora in via di definizione, aperta a discussione e in cui ognuno di noi, ognuno di voi, può dare il suo contributo, sempre ben accetto.

Abbiamo anche registrato un podcast al riguardo, sempre su dotNET{podcast}, e potete partire da l√¨ o dal sito ufficiale di AgileIoT se volete approfondire l’argomento e/o partecipare alla discussione.

Questo √® solo il primo post dedicato all’argomento,¬†ne parleremo ancora.

AgileIoT

Extreme Programming (XP)

1. Introduzione

La programmazione software rappresenta una delle attivit√† pi√Ļ complesse dello scenario informatico.

Da sempre la realizzazione di software affidabile e funzionale √® stato uno degli obiettivi maggiormente inseguiti delle pi√Ļ grandi aziende del panorama ICT internazionale, e per ben riuscire in questo scopo sono state elaborate moltissime teorie, scritti migliaia di testi, ed √® risultato necessario persino creare una nuova branca dell’ingegneria, appunto l’ingegneria del software.

Da questo lavoro, tutte le problematiche dello sviluppo sono state apparentemente affrontate, portando alla definizione di diverse metodologie di sviluppo software. Tuttavia, ad oggi, non si pu√≤ dire che esista una metodologia pi√Ļ completa o affidabile delle altre, tanto che molte di esse sono state dimenticate col passare del tempo.

Negli ultimi anni una nuova metodologia sembra essersi largamente diffusa, evolvendo al punto tale da potersi definire matura. Stiamo parlando della metodologia che va sotto il nome di Extreme Programming, e nota anche come XP.

Elaborata da Kent Beck, Ward Cunningham e da Ron Jeffries verso la fine degli anni 90, sta diffondendosi tramite la rete, maturando sempre pi√Ļ ampi consensi, grazie alla sua natura estremamente dinamica.

Questa metodologia rientra nelle cosiddette metodologie agili, dove con questo termine si classificano quelle metodologie di sviluppo che hanno alla loro base una elevata reattività ai cambiamenti di requisiti, e un continuo scambio di informazioni tra il cliente e il committente, per ottenere un risultato meglio aderente alle sue reali necessità.

2. Principi e regole fondamentali

Un insieme di regole ben preciso delinea le caratteristiche della metodologia in questione.
Proviamo ad accorparle per riassumerle come segue :

  • la progettazione avviene con il supporto del cliente (o di un suo referente) che contribuisce in maniera continuativa allo sviluppo, verificando e testando, che il prodotto rispecchi le necessit√† espresse; se il cliente √® disponibile, si possono stabilire degli incontri periodici, magari settimanali, per stabilire lo stato di avanzamento dei lavori;
  • progettare entit√† modulari e minime; in questo modo si potranno effettuare refactoring continui dei moduli senza coinvolgere le altre parti che la usano, integrando continuamente i cambiamenti che intervengono e se necessario riscrivendo anche parti fondamentali del modulo;
  • test continui sul codice, su ogni unit√† o modulo realizzato, in modo da intervenire prima possibile per sistemare i bachi trovati;
  • il gruppo di lavoro deve convivere in uno spazio comune (open workspace) per poter meglio interagire; ognuno pu√≤ contribuire alla stesura di codice, su qualunque parte del progetto (propriet√† collettiva del codice); la programmazione va fatta rigorosamente a coppie, con intervalli stabiliti di tempo in cui alternarsi alla tastiera, se possibile formando coppie con livelli di skill differenti o non equivalenti; lavorare non pi√Ļ di 40 ore settimanali (e non meno possibilmente); tutti devono seguire delle linee comuni e degli standard di scrittura del codice, per consentire l’interazione di persone diverse sulla stessa porzione di codice;
  • ogni mattina va fatta una riunione per stabilire cosa si √® fatto rispetto al giorno prima, verificare difficolt√† incontrate e decidere cosa si far√† durante la giornata; queste riunioni sono caratterizzate dal fatto che coinvolgono tutto il gruppo, durano poco (5-10 minuti al massimo) e si svolgono in piedi (non ci devono essere sedie), per evitare di rilassarsi (ci√≤ consente di andare dritti al punto);
  • la documentazione tecnica deve essere ridotta e concreta; per il resto delle informazioni si fa riferimento al codice che ovviamente deve essere ben dettagliato e commentato;

Ci sono tante altre sfaccettature di queste “regole” che per il momento non √® necessario dettagliare.

3. Ambiti applicativi

La metodologia trova il suo miglior terreno di applicazione in gruppi piccoli, composti al massimo da una decina di persone, di cui alcuni con uno skill notevole, in cui esista una figura carismatica del project manager che porti avanti i fili di questa trama; inoltre il gruppo deve elaborare se non tutta l’intera soluzione da realizzare, quantomeno un blocco “chiuso” che non abbia necessit√† di parti esterne realizzate da altri gruppi o aziende.

4. Vantaggi e svantaggi della metodologia

La parola d’ordine √® produttivit√†. E con questa metodologia, la produttivit√† √® certamente elevata. Tuttavia non √® garantito il risultato, molto √® legato alla figura del project leader e alla sua personalit√†.

La metodologia resta comunque una valida alternativa su progetti dinamici, in cui si evidenzi da subito che i requisiti sono o non ben definiti o suscettibili di numerose variazioni in corso d’opera.
E’ applicabile avendo a disposizione risorse dinamiche e motivate.

Per la parte relativa alla programmazione a coppie, √® stato stimato un sostanziale aumento dei tempi di sviluppo, circa il 40%, quando sul progetto vi siano risorse con skill bassi. Questo se da un lato pu√≤ comportare uno svantaggio non indifferente, dall’altro lato pu√≤ risultare utile in progetti futuri, in cui la risorsa poco esperta, lavorando a coppie con una esperta, riesca velocemente a colmare buona parte del gap, acquisendo esperienza sul campo, e studiando/assimilando le tecniche della persona pi√Ļ esperta, in una sorta di full-immersion-training-on-the-job (passatemi il termine).

Inoltre questo divario di tempo sullo sviluppo viene in parte riassorbito dall’aumentata produttivit√† del team, rispetto all’utilizzo delle classiche metodologie non-agili (metodologie pesanti e metodologie iterative).

5. Strumenti per la gestione

Come detto pi√Ļ volte, l’Extreme Programming √® una metodologia. Questo vuol dire che non si lega ad un prodotto o un insieme di prodotti specifici. Esistono tuttavia in commercio soluzioni che consentono la gestione completa del ciclo di sviluppo software con XP.

Mi limito a segnalare XPlanner, una suite open source.
Non l’ho mai provata, lo far√≤ spero a breve.

N.B. : questo post è in-progress, verrà aggiornato ancora.
revision-0 : 2007-10-09 14.25
Extreme Programming (XP)