Individuazione errori/bug e Testing

Poiché le attività di testing sono performate durante ogni iterazione e non soltanto subito prima del rilascio dell’applicazione, pezzi di codice “difettosi” possono essere individuati molto prima rispetto ad una metodologia rigidamente pianificata. Alla fine di ogni sprint, infatti, il procedimento che si segue è il seguente:

• Chiusura user stories relative allo sprint corrente • Realizzazione build di test

• Attività di testing sulla build di test, secondo i test case e gli acceptance criteria precedentemente riportati sul software Agile utilizzato Target Process

• Comunicazione al team di sviluppo e tracciamento di eventuali bug rintracciati durante i test

49 • Condivisione col cliente della build e invio release note in cui vengono segnalati con

chiarezza quali requisiti e funzionalità il cliente riscontrerà nella nuova build; cosa, eventualmente, non si è riusciti ad introdurre nello scope dello sprint; le issue note, i punti ancora da smarcare e gli improvements.

Questa modalità di testing e di rilascio dell’app in versioni incrementali, è un ottimo rimedio per allineare lo sviluppo ai requisiti di business e per impedire situazioni di emergenza in cui ci si accorge troppo tardi delle problematiche dell’applicazione, sia sotto gli aspetti di scrittura del codice che di design e usabilità: ogni piccolo pezzo di codice in questo modo è testato con maggior precisione e dettaglio su diversi dispositivi e diverse piattaforme e, qualora ci fossero errori o anomalie, risulta molto più semplice intervenire prima che essi peggiorino in severità. Idealisticamente, se questi step vengono eseguiti con precisione, il numero di bug che l’applicazione presenterà al momento immediatamente precedente la pubblicazione ufficiale nello store, sarà minimo se non inesistente. Frequenti feedback derivanti dai test effettuati, risultano d’aiuto anche al team di sviluppatori stesso che ha la possibilità di venire a conoscenza in modo più efficace di imprecisioni e, di conseguenza, riapplicare ciò che si è imparato negli sprint successivi diminuendo drasticamente il ripetere degli stessi e aumentando la qualità dell’app.

Un aspetto interessante che in qualche modo è connesso a questa attività di testing continua e incrementale e che avviene nel progetto cui si fa riferimento, è il ritrovamento di alcune mal funzionalità su alcuni specifici dispositivi.

Avendo molte occasioni prima del rilascio finale per testare l’applicazione, si ha anche modo di scendere nel dettaglio e verificare che i criteri di accettazione previsti per ciascuna user story siano soddisfatti dai dispositivi più diffusi e dalle versioni dei sistemi operativi disponibili. Spesso, infatti, testare l’applicazione solo su un paio di dispositivi, è risultato insufficiente ad offrire una panoramica esaustiva del funzionamento dell’app perché, da test successivi più approfonditi, ci si è accorti di bug prima passati inosservati. Si può osservare quanto appena scritto anche da un’altra prospettiva: bug a cui a prima vista viene attribuito dal Product Owner un livello di severità22 blocking, vengono ridimensionati perché si scopre che si tratta di una

22 _{Su Target Process, il software utilizzato in azienda, i bug presentano un livello di severità chiamato “business}

value”. Esso non indica altro la priorità che il Product Owner assegna per ciascun bug segnalato all’interno dell’applicazione/prodotto. In ordine crescente troviamo: Small, Normal, Critical e Blocking.

50 anomalia relativa specificatamente ad un solo dispositivo e ad una sola, magari vecchia, versione del sistema operativo.

Ne segue che testare di frequente gli avanzamenti dell’applicazione ha inoltre come indubbio vantaggio accorciare i tempi delle attività di testing durante la durata complessiva del progetto: ogni incremento effettuato durante lo sprint viene immediatamente testato evitando di dover testare nuovamente le stesse funzionalità successivamente, eccezion fatta per funzionalità la cui implementazione potrebbe alterare quella di altre già esistenti.

VII.III Comunicazione

L’utilizzo di metodologie Agili non solo favorisce la comunicazione tra l’azienda e i propri clienti ma anche tra i membri del team che lavorano allo stesso progetto. Una comunicazione maggiore contribuisce alla creazione di un miglior clima lavorativo all’interno del team dal momento in cui i membri che ne fanno parte provano una maggiore fiducia nei confronti dei propri colleghi e attribuiscono più valore ai rapporti interpersonali. Lavorando con i precetti previsti da Scrum è altamente probabile che si instauri nel team un dinamismo e una energia compatta che aumenta a sua volta la produttività, trasmettendo alle persone coinvolte la sensazione di far parte di qualcosa di più grande della loro singola individualità e la responsabilità nei confronti dei loro peers della qualità del lavoro che realizzano. Quando la produttività del team come unica entità aumenta si genera una performance superiore rispetto a quella altrimenti ottenuta dalla somma dell’output finale di ciascun membro. Alla base dei vantaggi comunicativi che possono derivare dall’adozione di un approccio come Scrum, devono esserci però dei presupposti tali per cui questi non risultino essere troppo ostacolati. È importante tenere a mente che la corretta e genuina comunicazione in un team di lavoro non può ottenersi aprioristicamente, ma che all’interno dell’azienda devono già esser presenti, ancor prima di utilizzare Scrum, le precondizioni tali per cui il framework sia in grado di dispiegare al meglio le sue potenzialità dal punto di vista della comunicazione tra persone del team. Risulta opportuno che l’azienda incoraggi sempre e a prescindere una fluida e trasparente comunicazione tra i propri impiegati e che questa diventi vero e proprio fattore strategico in grado di portare i frutti nelle performance stesse dei progetti portati a termine.

51 Sin dall’inizio dell’avvio del progetto in Spindox ho percepito come una buona comunicazione e un buon clima lavorativo, non solo tra i membri dello specifico team, ma in senso più ampio il clima aziendale che si respira in azienda, possa contribuire molto alla performance stessa del progetto e all’accorciamento dei tempi di sviluppo e risoluzione delle problematiche.

A supporto di una fluida ed efficace comunicazione all’interno del team interviene anche una piattaforma di messaggistica istantanea nota ormai a numerosissime realtà di business, Slack. Prima dell’avvento di questa app, il modo più diffuso e utilizzato attraverso cui il team si scambiava informazioni sul progetto era attraverso e-mail. Il risultato era uno scambio eccessivo di e-mail anche per comunicazioni e/o richieste di informazioni rapide. È chiaro come servisse un tool al fine di facilitare la comunicazione in tempo reale all’interno del team di lavoro e lo scambio immediato di contenuti multimediali e file.

Slack interviene in questo senso, essendo un’app organizzata in canali (i cosiddetti channels) all’interno dei quali è possibile condividere idee, issue e update real-time sul progetto dedicato allo specifico channel. La comunicazione è ottimizzata e resa più informale, riflettendo semplicemente il modo in cui le persone parlano e comunicano tra loro, rifuggendo la formalità e la rigidità di una e-mail.

Slack si adatta perfettamente ad una realtà aziendale tipica di un’azienda di medio-grandi dimensioni che lavora nel mondo IT e nello sviluppo software: in un contesto del genere, dove chi lavora si destreggia tra un device ed un altro, è fondamentale avere un tool di messaggistica che conferisca una seemless experience su qualunque dispositivo mobile si decida di utilizzare; in un ambiente di lavoro in cui le postazioni lavorative sono organizzate in ampi e luminosi open-space, Slack diventa l’equivalente virtuale della transizione da un ambiente chiuso e diviso ai grandi spazi unici dell’open-space, incoraggiando una comunicazione aperta e un lavoro collaborativo tra chi ne fa uso.

52