Pensare globale, agire locale, anche per lo sviluppo software e app

Questa massima può valere anche nell’ambito del lavoro di sviluppo?
Raccontiamo della creazione di un flusso di lavoro che ha visto la collaborazione di team distanti più di 10.000 chilometri.

Quando una multinazionale in ambito finanziario-assicurativo affida a più soggetti la progettazioni di servizi innovativi digitali, diverse realtà si trovano a collaborare insieme. Ma gli attori coinvolti non differiscono solo per competenze e ruoli: capita infatti che ci si trovi molto lontano geograficamente. Questo perché, per raggiungere il massimo della competitività in termini di qualità, utilizzo delle risorse e attenzione per il prodotto finale, si decide di creare una rete di fornitori, cercando un po’ in tutti gli angoli del mondo.

Il team internazionale è entrato in gioco, nel caso qui trattato, per lo sviluppo di un’applicazione il cui scopo e’ stipulare polizze assicurative in modo rapido e sicuro, seguendo il cliente dalla raccolta dei dati personali sino alla firma di queste.

Per gestire al meglio la collaborazione da remoto, ancora prima dello sviluppo, è fondamentale costruire un metodo di lavoro ad hoc. Antreem, in questo tipo di dinamiche, oltre a occuparsi della consulenza e della ricerca delle migliori soluzioni da sviluppare, è in grado di mettere in piedi un flusso di gestione del lavoro su misura.

Le criticità da gestire ovviamente, quando i propri colleghi si trovano a grande distanza, sono diverse. Dalla immediata barriera linguistica al problema dei diversi fusi orari: per poter lavorare al meglio è necessario strutturare molto bene il flusso di lavoro, onde evitare problemi sia in fase di sviluppo sia a posteriori, in produzione.

Per questo motivo è stato ideato un modello di lavoro circolare, basato sul controllo qualitativo di ogni singolo step di sviluppo.

Il ciclo parte con lo sviluppo, immediatamente seguito dal controllo “4eye”: questo è il primo step di controllo qualitativo che viene eseguito, appunto, a quattr’occhi dallo sviluppatore e un QA (quality assurance) che, di solito tramite applicazione VOIP, controllano insieme che l’applicazione si comporti nel modo previsto. Se si riscontrano problemi di qualsiasi tipo (sia relativi allo sviluppo appena eseguito, sia accidentali regressioni) si reiterano questi due step fino a che tutto non funziona come previsto.

Terminato il ciclo di sviluppo si esegue quello che viene chiamato “Code Freeze”: una sorta di check-point, dove l’applicazione viene congelata allo stato attuale e sul quale il team di QA prima e il cliente poi eseguono dei test approfonditi a tutto tondo per verificare il funzionamento completo dell’applicazione e, nel caso, notificare eventuali difetti che non siano stati rilevati negli step precedenti.

Una volta effettuato il rilascio di una nuova versione dell’applicazione si ricomincia con la nuova fase di sviluppo.

Questo metodo sicuramente richiede uno sforzo maggiore in termini di tempo (specialmente nelle fasi iniziali), ma ha un enorme vantaggio che lo ripaga ampiamente: tiene monitorata costantemente la qualità del progetto e il rispetto delle specifiche richieste dal cliente. Tramite appositi tool e’ infatti possibile controllare quanto spesso falliscono i 4eye, quanti difetti vengono rilevati a ciclo avanzato ecc… Con metriche simili è possibile ottenere dei grafici che valutano la qualità del progetto col passare del tempo: se si ha quindi come obiettivo quello di avere un sempre minor numero di difetti nel progetto una modalità simile è estremamente consigliata.

Soprattutto quando i colleghi non sono nella scrivania di fianco e sarebbe difficile fare questo tipo di monitoraggio in un’altra maniera.