Il Web 2.0 e l'innovazione nella PA

"La vita è quello che ti succede mentre sei impegnato in altri progetti” (J.L.)

Lo sviluppo del software secondo un approccio collaborativo

with 7 comments

Ferdinando Gorga (linkedin)

Ciascuno di noi è cosciente di come la disponibilità di Internet e della sua architettura ha modificato sostanzialmente e, si spera definitivamente, il modo di utilizzare i computer e l’informatica.  Nel corso degli ultimi quindici anni le aziende innovative hanno progressivamente adottato questa novità tecnologica, sfruttando la possibilità di veicolare facilmente informazioni e flussi di denaro per le esigenze di un business sempre più dinamico.

Oggi è difficile immaginare che qualcuno di noi, possessori di PC o notebook, non si connetta in qualche modo ad Internet; lo facciamo sempre più numerosi, anche con dispositivi nuovi come i nostri smartphone, per accedere ai servizi di posta elettronica e di messaggistica, o ai servizi offerti nelle modalità innovative del Web 2.0 e del Social Networking.  Lo facciamo sempre di più in tempo reale, in ogni momento della giornata, anche quando siamo lontani dalla nostra scrivania: Internet e i suoi servizi sono diventati ‘tascabili’.

Se Internet ha così radicalmente cambiato la concezione, l’approccio e l’utilizzo dell’informatica, è possibile ipotizzare un cambiamento altrettanto epocale, derivante dalle stesse tecnologie, anche nel settore dello Sviluppo del Software?

La risposta a questa domanda è assolutamente positiva se pensiamo alla tecnologia attuale e alla disponibilità commerciale di soluzioni adatte. Purtroppo invece è fatalmente negativa se pensiamo alla consuetudine operativa e alle prassi vigenti in un gran numero di progetti di sviluppo software.   

Vediamo brevemente due scenari di lavoro in un’organizzazione che sviluppa il software in modo tradizionale e in un’altra che lo fa ricorrendo a strumenti di collaborazione mutuati dall’esperienza Internet sopra accennata.

Uno scenario tradizionale

Il modo di lavorare tradizionale che perdura da alcune decine di anni, indipendentemente dalle specifiche tecnologie adottate, è quello che vede i vari ruoli del processo di  sviluppo – analisti, programmatori, tester, tecnici, gestori dell’esercizio, ecc. – operare in contesti separati e, talvolta, addirittura con obiettivi contrastanti.

Ci si riferisce a questa modalità con la locuzione di sviluppo organizzato a ‘silos’ sottolineando proprio la separazione e l’isolamento dei ruoli, tra i quali la comunicazione  avviene spesso soltanto seguendo delle vie ufficiali e a tempi stabiliti – come le milestone, le riunioni di progetto o i collaudi – e per lo più utilizzando linguaggi, cultura e rituali differenti.

Può quindi accadere con assoluta probabilità che:

  • l’analista o l’amministrativo esperto delle problematiche di business dichiari in poche righe o poche pagine le sue aspettative e necessità ad alto livello, utilizzando il suo linguaggio, e rifiutandosi di partecipare a successive riunioni di dettaglio e armonizzazione con il team di sviluppo;
  • gli sviluppatori siano costretti, prima di scrivere i programmi, a rifare l’analisi funzionale introducendo involontariamente degli errori, costretti a fare assunzioni su contesti che non conoscono a fondo;
  • i tester aspettino inoperosi l’arrivo della build (ottenuta faticosamente) e inizino a testare l’applicazione senza la documentazione appropriata;
  • la funzione di esercizio, pressata dall’urgenza, metta l’applicazione in produzione in tutta fretta, lasciando all’utente finale l’ingrata scoperta dei difetti più nascosti.

Questo è un quadro semplificato ma tristemente realistico di molte realtà aziendali. In questo contesto ogni ipotesi di cambiamento o di perturbazione dello status quo viene interpretata come eresia e quindi evitata. Si perdura in queste abitudini cercando di supplire alle inefficienze con la buona volontà ed il lavoro straordinario, rifiutando le innovazioni ed il cambiamento di visione e accettando come ineluttabili i ritardi di consegna e il pagamento di penali per mancato adempimento.

L’approccio collaborativo

Con l’aiuto della moderna tecnologia, i progetti software possono essere gestiti e condotti in modo assai diverso, incentivando dei comportamenti di ampia collaborazione che promuovono il successo aziendale nella soddisfazione di tutti.

Il cardine di questa tecnologia è l’integrazione tra strumenti diversi che ricalca gli schemi di comunicazione tra i vari ruoli del progetto. In questo modo la collaborazione viene facilitata e resa spontanea, evitando la sindrome da ‘silos’, e tutti i membri del progetto formano di fatto un unico team.

Le nuove piattaforme per lo sviluppo collaborativo devono pertanto offrire capacità di:

  • Integrazione dei dati: elaborati e altre informazioni (annotazioni, richieste, ecc.) vengono raccolti in un unico repository che costituisce la fonte autorevole di documentazione dell’intero progetto.  Inoltre i singoli elaborati possono essere via via associati (link) a quelli correlati così da essere facilmente raggiungibili da coloro che devono utilizzarli: ad esempio, un tester che prepara un caso di test, lo deve collegare ai requisiti che il test stesso serve a validare.
  • Collaborazione avanzata per scambio di informazioni, richiesta di modifiche, inoltro di commenti, revisioni o approvazioni, in modo sia sincrono che asincrono, e comunque nel rispetto dei ruoli e delle responsabilità assegnate. 
  • Automazione di tutte le attività che non richiedano l’intervento umano creativo (ad esempio: la produzione di report, la predisposizione di metriche e documentazione sullo stato di avanzamento del progetto, la rapida identificazione dei file modificati a fronte di richieste di intervento) e in generale a tutte le attività ripetitive (per esempio le build).  

Tale approccio prende il nome di Collaborative Application Lifecycle Management (C/ALM) e facilita l’adozione di altre pratiche virtuose come per esempio la metodologia ‘Agile’ dello sviluppo del software.  Su questi principi è nato il progetto Jazz.

 

Jazz(1)

Jazz è un’infrastruttura software che implementa nativamente capacità di collaborazione.   e su cui sono stati sviluppati diversi strumenti per lo sviluppo dei progetti software.  

Il progetto Jazz  include:

  • Scenari per il C/ALM: forniscono all’utente la possibilità di reperire le informazioni necessarie al loro ruolo e task seguendo le esigenze del momento.
  • OSLC – Open Services for Lifecycle Collaboration: sono i servizi per far circolare le informazioni normalmente blindate nei singoli tool di sviluppo.
  • JIA – Jazz Integration Architecture: è un insieme di specifiche e di tecnologie interconnesse, ad esempio specifiche API, servizi comuni, sottosistemi. Il core di questa architettura sono i Jazz Foundation Services (JFS) che consentono la comunicazione tra gruppi di tool ed il loro utilizzo integrato.
  • Jazz Foundation: un’implementazione di JFS e di un toolkit per facilitare la costruzione di applicazioni basate su Jazz.

Il progetto Jazz integra e coordina l’architettura (JIA), i servizi (OSLC) e gli scenari C/ALM per consentire la fruizione coordinata di flussi delle informazioni essenziali al successo del progetto.

Uno scenario di sviluppo “collaborativo”

Osserviamo ora un team che lavora alla costruzione di un nuovo sistema software  utilizzando la tecnologia Jazz e i tools basati su di esso.

La definizione dei requisiti

Il product owner ha la responsabiltà di definire le esigenze di business del progetto in corso e di armonizzare le esigenze di vari stakeholder. 

Quotidianamente egli comunica con molti stakeholder dislocati sul territorio, ne recepisce le esigenze, si sforza di trovare punti di contatto e avvia attività di negoziazione per ottenere convergenza verso una soluzione soddisfacente.

Uno strumento collaborativo per la definizione dei requisti di business gli permette di effettuare questa attività di intervista e negoziazione non più tramite telefonate, scambi puntuali di email o costose riunioni, ma con una modalità di lavoro “asincrona”, in una “continua riunione virtuale” di progetto, in cui i partecipanti intervengono di volta in volta secondo i propri tempi, rispondendo a ‘commenti’ richiesti da altri, inserendo spontanemante informazioni e dettagli, sottoponendo nuove richieste. 

Alcuni stakeholder devono valutare gli impatti che il sistema in corso di sviluppo avrà sulle altre procedure ambientali; essi possono modificare di conseguenza i diagrammi di business (Business Process Diagram) che li rappresentano, e sottoporre le modifiche per ulteriore discussione o validazione.

Coloro che rappresentano gli utenti finali del sistema devono esprimere i requisiti e validare le interfacce utente.  Quando ricevono una richiesta di parere sulla nuova interfaccia delineata dagli analisti, essi, anche da sedi remote, devono semplicemente aprire la richiesta tramite una GUI per visualizzare l’outline dell’interfaccia e del suo schema di navigazione; possono apportare le modifiche opportune e rispondere alla richiesta esprimendo le proprie opinioni.  Con la stessa facilità l’analista apre la risposta e visualizza l’outline dell’interfaccia modificata; se, per valutare correttamente i cambiamenti, volesse confrontarla l’outline originale, una funzione di “history” gli permetterebbe di risalire alle  versioni precedenti.  Quando infine c’è accordo sulla forma finale, l’analista chiude la richiesta e crea i requisiti d’interfaccia – legandoli anche ai widget consolidati – che verranno trasmessi al team di sviluppo per la realizzazione.

Un altro aspetto importante è il collegamento con i casi d’uso; l’analista ha a disposizione le funzioni “collaborative” per informare coloro che stanno lavorando alla definizione dei casi d’uso delle modifche recentemente approvate e descrivere le nuove caratteristiche del sistema.

La gestione dei requisti, dei cambiamenti e dei rilasci

Il product owner, dalla sua postazione, ha visibilità e controllo dell’avanzamento del progetto ed evidenza degli aggiornamenti che vengono effettuati. 

La definizione dei nuovi requisiti lo porta ad un’analisi approfondita per verificare se tra essi ce ne sia qualcuno con caratteristica di urgenza; ad esempio un requisito potrebbe essere già legato alla data della prossima sprint(2); in questo caso egli lo può marcare con la denominazione della sprint desiderata, nella quale dovrà essere implementato, e creare un work item(3) per passare l’incarico al laboratorio di sviluppo.

Il processo di sviluppo viene svolto e governato tramite la piattaforma collaborativa di Software Delivery, che affianca alle tradizionali funzionalità di gestione dei work item, Source Control Management (SCM) e gestione delle build, delle funzionalità collaborative di comunicazione (eventi, feeds, chat integrate, ecc.) e di integrazione (tracciatura automatica, condivisione di documenti, monitoraggio comprensivo delle attività, ecc.) che permettono ai diversi attori di operare in modo armonico e produttivo.

Poiché al termine del ciclo di lavorazione dovrà essere effettuato un test di accettazione e il collaudo di quanto sviluppato, il product owner, già all’atto della creazione del nuovo work item, segnala il tag della sprint al gruppo di test, affinché, in parallelo, possa essere prodotto il piano di test che copre i requisiti oggetto del lavoro.

La gestione della qualità

Il responsabile della Qualità che prende in carico il nuovo work item, tramite una dashboard personale, identifica il collaboratore meno impegnato nel suo team; apre un nuovo work item – di test – per la redazione del piano di test della sprint e glielo assegna.  La persona che riceve il work item ha accesso immediato ai requisiti, precentemente linkati al work item, li analizza e crea un piano di test. 

Al completamento di questa attività, il product owner riceve una notifica; può quindi controllare, usando la sua dashboard, l’eventuale completezza della copertura dei requisiti da parte dei casi di test contenuti nel piano e predisporre il collaudo.

In qualsiasi momento egli necessiti di conoscere lo stato di avanzamento del progetto, non dovrà chiedere nessuna informazione al suo team (bloccandone il lavoro per alcuni giorni!) ma vedrà tutte le informazioni necessarie, in tempo reale, sulla sua dashboard personalizzata.

Conclusioni

La descrizione degli scenari ha messo in evidenza quei cambiamenti che più incidono sul  processo di sviluppo del software rendendolo più snello, dinamico, efficiente e produttivo:

  • Robustezza e Convergenza: la possibilità di collaborazione continua permette il confronto esaustivo su idee, principi e scelte implementative e il consolidamento di decisioni largamente riconosciute alla base di un’analisi funzionale più robusta.
  • Ottimizzazione ed Eco-compatibilità: gli strumenti di collaborazione permettono di ridurre trasferte e riunioni plenarie, con benefici sul piano dei costi e dei tempi; requisiti più robusti richiedono meno rifacimenti e correzioni in corso d’opera; la condivisione e lo scambio “strutturato” di informazioni evita il proliferare di mail, appunti e spreadsheet che inevitabilmente porta a perdita di conoscenza, incoerenza, disallineamenti. 
  • Team e Sinergia: Le funzionalità collaborative hanno fatto cooperare in modo integrato e naturale tutti gli attori (product owner, analisti,  stakeholder, tester, sviluppatori); le informazioni fluiscono attraverso gli strumenti verso i destinatari opportuni e vengono accedute in modalità user-friendly; i singoli hanno visibilità più ampia sullo svolgimento del progetto.  Tutto ciò porta ad un aumento delle sinergie, del livello di motivazione dei singoli e della produttività.

 

Note:

(1) Sito ufficiale del progetto Jazz: www.jazz.net.  IBM ha dato vita al progetto Jazz, poi rilasciato alla comunità open.  Diverse aziende e sviluppatori hanno già creato componenti software free o prodotti commerciali sulla piattaforma Jazz.  IBM ha rilasciato su Jazz molti prodotti commerciali (http://www.ibm.com/software/rational/), tra cui Rational Requirement Composer, Team Concert e Quality Manager che coprono molte delle funzionalità auspicate nello scenario collaborativo.

(2) Sprint Backlog: nomenclatura utilizzata dal processo iterativo SCRUM, è una collezione di argomenti ed item pianificati per essere processati nel corso di un’iterazione.

(3) Work Item: in generale è una richiesta, o esigenza di lavorazione che un ruolo assegna ad un altro ruolo.  Un WorkItem è sempre composta dalla richiesta e da uno stato. Lo stato cambia durante il ciclo di lavorazione, seguendo il processo adottato dall’azienda.

L’autore: Ferdinando Gorga, laureato in Scienze dell’Informazione, è esperto di ingegneria del software, di gestione dei requisiti e di metodologie di sviluppo. Lavora in IBM, è un technical sales ed evangelist delle soluzioni IBM Rational.

Annunci

Written by Pietro Monti

30 settembre 2010 a 1:36 PM

7 Risposte

Subscribe to comments with RSS.

  1. Il mio commento prende in esame solo aspetti di carattere organizzativo e metodologico.
    Sono d’accordo con Ferdinando quando dice che lo sviluppo organizzato a “Silos” è ormai superato grazie alle nuove tecnologie, i nuovi prodotti ed una cultura sempre più “social network”.
    L’approccio “collaborativo”, così ben descritto da Ferdinando, è sicuramente più snello e produttivo. Credo sia semplice adottarlo nelle fasi di progettazione, realizzazione e test perché svolte principalmente da personale tecnico informatico. Non credo sia altrettanto semplice utilizzarlo nelle fasi di rilevazione delle esigenze e formalizzazione dei requisiti. In queste fasi, infatti, sono pesantemente coinvolti gli stakeholder, ancora abituati ad esprimere le proprie esigenze tramite interviste e riunioni.
    La sfida deve comunque essere raccolta perché i vantaggi di una tale organizzazione sono enormi. Disporre di un unico repository dei documenti di progetto è indispensabile per la “governance” dell’IT. Ad esemppio, poter individuare velocemente i test da eseguire per verificare un requisito è fondamentale quando tale requisito verrà modificato.
    L’approccio “collaborativo” è ancora più utile quando intervengono più gruppi di lavoro, magari appartenenti a diversi fornitori. O quando il responsabile della progettazione di una applicazione è diverso dal responsabile che la gestisce. Quest’ultimo argomento è molto attuale in INAIL, in quanto ci accingiamo ad adottare una tale organizzazione. Suddividendo il processo di sviluppo applicativo per ambiti funzionali (fasi del Ciclo di Vita del Software) e non più per linee prodotto (o applicazione).

    In sostanza un approccio “collaborativo” a mio avviso migliora la circolarità delle informazioni.

    Patrizio Galasso

    1 ottobre 2010 at 4:52 PM

  2. In questi giorni ho letto un articolo su ZDNet a proposito di self-evident-computing.

    La tesi dell’autore è: oggi le applicazioni vincenti sono quelle che permettono un’esperienza utente semplice, quasi immediata.

    L’articolo mette bene in luce le differenze di approccio progettuale fra un “vecchio” modo di concepire le applicazioni, cariche di funzionalità spesso sconosciute e quindi inutili alla maggior parte degli utenti, e un nuovo modo ispirato dalla filosofia KISS (Keep It Simple, Stupid, ossia “falla semplice, stupido”).

    L’argomento non è banale, al pari di quanto trattato dall’articolo che commento, e, dal mio punto di vista, si sposa perfettamente con quanto presentato dall’approccio collaborativo.

    L’obiezione più comune è che è facile creare un’interfaccia semplice quando il compito che essa deve svolgere è poco complicato, ma rendere semplice l’automazione di processi complessi è tutt’altro che banale.

    Ho pensato anche ad alcuni che sviluppano applicazioni gestionali, per i quali l’andare nel web vuol dire solo mettere l’applicazione nel browser, non cogliendo un cambiamento in atto, quasi una rivoluzione degli utenti finali, che dopo essere stati vessati per anni da applicazioni complicate, incomprensibili e non amichevoli, ora le vogliono semplici e scelgono in massa il modello applicativo dell’iPhone, da cui tutti gli altri stanno copiando.

    Altro aspetto che spesso mi trovo a gestire è la VISIONE sempre parziale dell’argomento che ci troviamo ad affrontare. Raramente mi è capitato di trovare interlocutori disposti a spingersi in una analisi complessiva del processo generale di cui la parte che si deve automatizzare rappresenta un pezzo dell’intero puzzle. La volontà politica e gli adeguati strumenti a supporto potrebbero consentire di sviluppare le nostre attività specifiche senza perdere la visione d’insieme, coinvolgendo tutti i soggetti interessati dall’intero processo.

    Concludo che quanto detto non accade dal giorno alla notte. Si tratta invece di un processo che potrebbe durare anni, ma, permettetemi di affermare, è inarrestabile.

    Paolo Guidelli

    6 ottobre 2010 at 1:45 PM

  3. Mi occupo di sviluppi SAP da molti anni ormai e trovo questo articolo molto interessante. Non ho ancora approfondito bene l’argomento ma a giuducare dall’articolo di Ferdinando e la documentazione sul web, ricavo la convinzione dell’enormo potenzialità dell’argomento/prodotto. Nel mio caso specifico trovo importanti spazi di miglioramento nella gestione delle risorse “global” (team delocalizzati in paesi emergenti) che ormai pervadono molti progetti.
    Sarebbe da approfondire fra l’altro un importante argomento che è quello degli aspetti sociali e psicologici che costituiscono una forza motivazionale e talvolta l’unico elemento di inclusione e di appartenenza al gruppo di lavoro di persone di altre culture. Entriamo in un campo legato alle dinamiche di gruppo da cui dipende sempre il successo di un progetto che è indissolubilmente legato al fattore umano che mi prefiggo di approfondire.
    Grazie Ferdinando.

    Paolo ferrentiino

    Paolo ferrentino

    20 dicembre 2010 at 1:13 PM

  4. Thanks for a marvelous posting! I actually enjoyed reading it,
    you happen to be a great author.I will always bookmark your blog and will come back later on.
    I want to encourage that you continue your great writing, have a nice day!

    Nila

    11 marzo 2013 at 10:01 AM

  5. I know this web page offers quality dependent articles or reviews and extra data, is there any other web page which offers these kinds of
    stuff in quality?

    fusevision seo company

    2 maggio 2013 at 8:09 AM

  6. I’ve been surfing online more than 3 hours today, yet I never discovered any attention-grabbing article like yours. It is beautiful worth enough for me. Personally, if all web owners and bloggers made excellent content as you probably did, the internet will likely be a lot more useful than ever before.

    virtual office

    13 luglio 2013 at 12:01 AM

  7. Nice weblog here! Additionally your site lots up fast!
    What web host are you using? Can I am getting your affiliate hyperlink to your host?
    I want my site loaded up as quickly as yours lol

    desk space

    3 agosto 2013 at 12:10 AM


Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: