Naviga tra le sottosezioni
Quando la produzione di una nuova applicazione ha livelli di incertezza dovute a scelte progettuali che richiedono della sperimentazione per essere validate, è opportuno procedere con l’approccio del Design Thinking. Questo prevede sinteticamente i seguenti passi.
- Si realizza un MVP, in uno sprint di (2-4) settimane.
- Si verifica l’efficacia dello MVP.
- Si analizzano i risultati e si individuano i miglioramenti da eseguire. Tali miglioramenti possono essere nella empatia degli utilizzatori con dell’applicazione, nei requisiti, nell’ideazione della soluzione o in una combinazione di questi.
- Si assesta il backlog di prodotto.
- Si riparte con il passo n.1.
Questo processo consente di avvertire gradualmente, mentre si sta realizzando l’applicazione, che qualcosa deve cambiare perché generi i valori attesi dalle parti interessate, sia efficace per l’uso che se ne deve fare e sia adeguabile alle esigenze dei suoi utilizzatori nonostante queste cambino frequentemente nel tempo. Perciò, si cerca di rilevare eventuali difetti in uno di questi aspetti il più presto possibile e non solo dopo che è stato realizzato l’intero prototipo, quando cioè ripararli diventa molto costoso e comunque implica la cancellazione di qualcosa che è stato già fatto. In altri termini, questo approccio modera la creazione di sprechi.
DESIGN THINKING NELLA PRODUZIONE DI AURBRD
Per gestire il BRD Legacy è stato necessario un sistema informatico opportunamente progettato. Tale sistema è denominato AURBRD.
AURBRD deve soddisfare i seguenti bisogni:
Produzione del BRD Legacy;
Estrazione dal BRD Legacy delle caratteristiche interessate dal progetto da eseguire che compongono il BRD di Progetto;
Aggiornamento del BRD Legacy dopo la V&V dei BRD di Progetto.
Facendo riferimento allo standard del BRD adottato in AURIGA si rilevano alcune sezioni che sono dipendenti esclusivamente dalle richieste di cambiamento del cliente e sono indipendenti dallo stato attuale del sistema in esercizio, altre che invece modificano il sistema in esercizio; queste ultime sezioni possono essere supportate dal BRD Legacy.
Pertanto i requisiti di AURBRD sono:
- Gestire ogni sezione del BRD Legacy autonomamente.
- Ogni sezione deve contenere tutte le caratteristiche necessarie a descrivere compiutamente l’aspetto che deve essere contenuto nella stessa sezione.
- Per ogni aspetto contenuto nelle sezioni dello BRD Legacy deve essere registrato il contenuto secondo un modello che deve essere conforme allo standard adottato per BRD.
- Per ogni aspetto di ogni sezione esisterà nessuno o un solo modello associato ad un cliente che descrive come è realizzato quell’aspetto nel sistema in esercizio presso lo stesso cliente. Lo stesso modello può essere associato a molti clienti ma ci saranno modelli diversi per clienti distinti, anche diversificati per piccoli particolari.
- Ogni modello deve avere il contenuto strutturato secondo lo standard della corrispondente sezione del BRD
- Le sezioni, anche se gestite autonomamente, devono essere in relazione tra loro attraverso l’identificatore del cliente così che si possa ricostruire il BRD Legacy per ogni cliente e per un qualsivoglia insieme di aspetti.
- Devono essere previste regole di storicizzazione dei modelli, con possibilità di ripristinare vecchie versioni;
- Devono essere previste regole d’accesso per l’utenza del sistema (lettura o modifica)
- Deve essere prevista la possibilità di effettuare ricerche di vario tipo (cliente, feature, componente, misto)
AURBRD deve essere prodotto rapidamente, pertanto si è deciso di fare uso di strumenti di LOW CODE (cfr: Documentazione di AURBRD).
Poiché il sistema è innovativo ha una notevole quantità di incertezze, per esempio:
- Quali sezioni considerare per avere il maggior riuso dei modelli da costruire?
- Come caratterizzare ogni sezione in modo che i modelli da costruire siano i meno onerosi possibile?
- I requisiti definiti sono sufficienti per raggiungere efficacemente lo scopo per cui si sta costruendo AURBRD?
Premesso tutto ciò le sperimentazioni da fare sono:
Q7.1 - Quanto evolve l’applicazione in usabilità?
La usabilità si misura attraverso indagini qualitative fatte con 6 TAM di Auriga. Si utilizza il System Usability Scale, come è stato descritto precedentemente.
I risultati rilevati sono riportati in figura 7.1.
Figura 7.1.a Risposte SUS dei partecipanti per AURBRD (I MVP)
Figura 7.1.b . Punteggio SUS dei partecipanti per AURBRD (II MVP)
Media Punteggio SUS= 43,75
Facendo riferimento alla figura 5.1.b il punteggio SUS rivela che la usabilità di questo primo MVP è in campo “scarso.
Analizzando i commenti degli utilizzatori circa le motivazioni dei loro punteggi si è addivenuti alla constatazione che alcune funzioni realizzate non sono molto utili mentre ne manca qualcuna considerata molto utile nel riuso dei BRD Legacy. Inoltre, talune funzioni molto utilizzate richiedono un percorso di navigazione molto lungo.
Pertanto sono state apportate alcune correzioni all’interfaccia per mettere maggiormente in evidenza e rendere più rapido l’accesso alle funzioni più utili. Inoltre, sono state realizzate le funzioni che erano state richieste come importanti per facilitare il riuso.
È stato fatto un altro sondaggio con gli stessi utilizzatori. Il risultato è mostrato nelle figure 7.3.
Figura 7.2.a Risposte SUS dei partecipanti per AURBRD (II MVP)
Figura 7.2.b Punteggio SUS dei partecipanti per AURBRD (II MVP)
Media Punteggio SUS= 69,58
Le modifiche hanno portato l’usabilità in campo “buona”.
La consultazione degli utilizzatori con gli MVP prodotti da sprint intermedi hanno consentito di eliminare funzioni inutili, quando la loro eliminazione era più semplice perché l’architettura del sistema non aveva ancora acquisito la complessità finale. Inoltre, sono state inserite nuove funzioni che non erano state concepite durante l’analisi e che valorizzano notevolmente il tool dal punto di vista degli utilizzatori.
Q7.2 - Quanto evolve l’applicazione in UX?
La UX, anche in questo caso, è misurata attraverso indagini qualitative fatte con i 6 soggetti sperimentali di prima. Si è utilizzato lo User Experience Questionnaire (UEQ) che è stato utilizzato come descritto in precedenza.
I risultati rilevati sono riportati da figura 7.3.a a figura 7.3.e sono riportati i dati riferiti ai 6 utilizzatori che in questo caso sono TAM di Auriga.
Figura 7.3.a Dati grezzi rilevati dal sondaggio in AURBRD (I MVP)
Figura 7.3. b. Trasformazione in punteggi dei dati rilevati in AURBRD (I MVP)
Figura 7.3.c. Media e varianza per ogni partecipante in AURBRD (I MVP)
La figura 7.3.d. mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura (cfr. 5.2c). Di qui si evince che: tutte le componenti sono in campo “Bad”. Pertanto devono essere apportati dei miglioramenti per consentire che la UX migliori notevolmente.
Figura 7.3.d. Confronto grafico con le soglie da letteratura in AURBRD (I MVP)
Figura 7.3.e. Risultati per ognuno dei quesiti in AURBRD (I MVP)
Per decidere le iniziative di miglioramento che sono opportune intraprendere, la figura 7.3.e consente di valutare l’influenza di ogni quesito sul risultato finale.
Analizzando i commenti degli utilizzatori dopo l’uso del sistema, si è verificato che le modifiche effettuate per il punto precedente possono superare alcuni dei punti di debolezza dello UX, Inoltre si sono fatte le seguenti modifiche aggiuntive; spostamento di alcuni bottoni nelle posizioni in cui gli utilizzatori hanno dichiarato di attenderseli; modifiche degli sfondi, dei colori e delle rappresentazioni grafiche dei bottoni e delle funzioni in modo che il sistema risulti più attrattivo ed innovativo.
Nelle figure da 7.4.a a 7.4.d sono mostrati i risultati dopo le modifiche
Figura 7.4.a Dati grezzi rilevati dal sondaggio in AURBRD (II MVP)
Figura 7.4. b. Trasformazione in punteggi dei dati rilevati in AURBRD (II MVP)
Figura 7.4. b. Trasformazione in punteggi dei dati rilevati in AURBRD (II MVP)
Figura 7.4.d. Confronto grafico con le soglie da letteratura in AURBRD (II MVP)
La figura 7.4.d. mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura (cfr. 5.2c). Di qui si evince che le componenti sono salite in campo “Good” o “Excellent”. Pertanto le modifiche hanno apportato un miglioramento consistente.
In conclusione lavorando con gli MVP si individuano il più presto possibile le modifiche da effettuare, ovvero quando queste ultime costano meno.
Inoltre, l’uso dello UEQ consente di ottimizzare il numero di modifiche nel senso che supporta la decisione di individuare le modifiche più appropriate per superare i punti di debolezza della UX.
Q7.3 - Quanti requisiti cambiati in uno sprint sono stati realizzati in sprint precedenti?
Nessuno.
Pertanto l’approccio crea economia.
Q7.4 - Quanti requisiti sono stati cancellati dopo essere stati realizzati?
Nessuno
Pertanto l’approccio ha eliminato eventuali sprechi.
Q7.5 - Quanti requisiti sono stati cancellati prima di essere stati realizzati?
Due funzioni previste nell’analisi sono state eliminate dal confronto con gli utilizzatori.
Pertanto l’approccio ha evitato possibili sprechi.
Q7.6 - In ogni sprint quanto tempo persona è speso per la rilavorazione di ciò che era stato già realizzato?
La rilavorazione di un software già scritto è uno spreco, quindi si vuole rilevare se l’approccio DT fa rimanere relativamente piccola questa dimensione.
I dati rilevati:
Sprint numero identificativo dello sprint
TS= Tempo speso sullo sprint (hh-persona)
TR= Tempo speso sulla regressione (hh-persona)
TAR = Tasso di regressione = TR/TS*100
Il TAR, esprimendo il TR in percentuale sul tempo-persona complessivo speso nello sprint, consente di confrontare sprint di diverse dimensioni eseguiti in progetti diversi.
Figura 7.5. Costo della regressione in AURBRD
Le percentuali di regressione risultate sono sufficientemente piccole per affermare che l’approccio e la progettazione dell’applicazione ha funzionato bene nel ridurre l’impegno persona richiesto per rilavorazioni del software prodotto.
Design Thinking nella produzione di SDK
Durante la progettazione e realizzazione dello SDK i rischi nella definizione dei requisiti e nella progettazione del tool sono molti, pertanto è opportuno utilizzare l’approccio design thinking per moderare i rischi e minimizzare gli sprechi. Le misure necessarie per verificare il vantaggio dell’approccio sono descritte di seguito.
Q7.7 - Quanto evolve l’applicazione in usabilità?
La usabilità è stata misurata con il questionario SUS utilizzato come descritto precedentemente sottoposto a 12 soggetti sperimentali. Allo stesso modo di prima sono stati calcolati i punteggi.
In questo caso sono stati confrontati i punteggi dello SDK modernizzato su due sprint sequenziali (SPRINT 7, SPRINT 8). I risultati sono mostrati rispettivamente nelle figure 7.4, 7.5, 7.6.
Figura 7.4.a. Risposte SUS dei Partecipanti per SDK Modernizzato, I Gruppo
Figura 7.4.b. Punteggio SUS dei Partecipanti per SDK Modernizzato, I Gruppo
Media Punteggio SUS= 72,5
Figura 7.5.a. Risposte SUS dei Partecipanti per SDK Modernizzato, II Gruppo
Figura 7.5.b Punteggio SUS dei Partecipanti per SDK Modernizzato, II Gruppo
Media Punteggio SUS= 74,37
Figura 7.6.a Risposte SUS dei Partecipanti per SDK Modernizzato, III Gruppo
Figura 7.6.b Punteggio SUS dei Partecipanti per SDK Modernizzato (III Gruppo
Media Punteggio SUS= 76,25
Le modifiche apportate sono state quelle descritte nella sezione 5.5 che in questo caso sono state affinate più volte.
Sicuramente la rilevazione fatta per MVP ha comportato dei miglioramenti che sono costati relativamente poco perché erano inerenti essenzialmente alle parti di SDK che erano state appena costruite ed hanno comportato relativamente poche rilavorazioni.
La valutazione della usabilità mostra che la usabilità si è mantenuto in campo “buona” (cfr. tav. 5.1) migliorando dopo ogni modifica ma con incrementi non rilevanti. Probabilmente ciò significa che esiste un limite ai miglioramenti di questa caratteristica che dipende dallo scopo del tool, dal modello concettuale del suo comportamento e da come è concepita l’interazione con il suo utilizzatore che non possono essere modificate agendo sulla struttura, sul codice e sulle interfacce del tool.
Quest’ultima considerazione rafforza la convenienza a produrre e valutare per MVP, il più frequentemente possibile, in modo che anche il cambiamento del modello concettuale del comportamento e dell’interazione costi relativamente poco.
Q7.8 - Quanto evolve l’applicazione in UX?
Qui si riportano le stesse rilevazioni eseguite per Q5.10 ma l’analisi dei risultati mira a comprendere se ed in che misura l’approccio Scrum & Designi Thinking sia efficace.
Figura 7.7.a Dati grezzi rilevati dal sondaggio in SDK
Figura 7.7. b. Trasformazione in punteggi dei dati rilevati in SDK
In figura 7.7.c mostra la media raggiunta per ogni persona in ognuno degli aspetti componenti la UX. Com’è stato detto, tra i soggetti sperimentali non ci sono persone particolarmente severe o particolarmente tolleranti.
Figura 7.7.c Media per ogni partecipante in SDK
La figura 7.7.d. mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura (cfr. 5.2c). Di qui si evince che: tutte le componenti sono “sopra il valore “media” ed il valore “buona”.
Figura 7.7.d. Benchmark della UX con la letteratura in SDK
Per decidere le iniziative di miglioramento che sono opportune intraprendere, la figura 7.7.e consente di valutare l’influenza di ogni quesito sul risultato finale.
Figura 7.7.e Risultati per ognuno dei quesiti in SDK
Sono state fatte alcune iniziative di miglioramento: migliorate le icone per esprimere le scelte che il sistema propone agli utilizzatori così che il sistema risulti meno noioso; per le funzioni più frequentemente usate sono stati diminuiti il numero di scelte necessarie per accedervi così che gli utilizzatori avvertano una maggiore apprendibilità del sistema e quindi si è passato a nuove misure; è stata fatta qualche modifica strutturale per rendere il sistema più efficiente.
Da figura 7.8.a 7.8.c sono riportati i risultati essenziali del sondaggio effettuato avendo come oggetto sperimentale un secondo rilascio (da SPRINT 9).
La figura 7.8.c mostra che le modifiche effettuate hanno portato ad un miglioramento significativo della UX. Questo è di particolare interesse per Auriga perché questo tool deve essere molto utilizzato dagli sviluppatori per accelerare ed economizzare la produzione delle future modifiche di WWS.
Figura 7.8.a Dati grezzi rilevati dal sondaggio in SDK
Figura 7.8. b Trasformazione in punteggi dei dati rilevati in SDK
Figura 7.8.c. Confronto grafico con le soglie da letteratura per il secondo rilascio in SDK
Q7.9 - Quanti requisiti cambiati in uno sprint sono stati realizzati in sprint precedenti?
I cambiamenti di requisiti dopo la loro realizzazione creano sprechi. Pertanto il minor numero di questi requisiti evidenzia che l’approccio crea economia.
I dati rilevabili sono:
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NC = numero di requisiti cambiati dopo essere stati implementati
Note= motivazioni dei cambiamenti
In figura 7.9 sono riportati i dati inerenti lo SDK per gli sprint eseguiti.
Figura 7.9. Requisiti modificati dopo la loro realizzazione in SDK.
È visibile come l’approccio consente di elicitare la necessità di fare miglioramenti tempestivamente, quando il software è più semplice da modificare perché è più probabile che l’impatto della modifica sia relativamente piccolo.
Q7.10 Quanti requisiti sono stati cancellati dopo essere stati realizzati?
Le cancellazioni di requisiti dopo la loro realizzazione creano sprechi. Pertanto il minor numero di questi requisiti evidenzia che l’approccio crea economia.
I dati rilevabili sono
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NDA = numero di requisiti cancellati dopo essere stati implementati
Note= motivazioni dei cambiamenti
In figura 7.10 sono riportati i dati inerenti lo SDK per gli sprint eseguiti.
Figura 7.10 Requisiti cancellati dopo la loro realizzazione in SDK
L’approccio ha consentito di cancellare pochi requisiti dopo essere stati realizzati, quindi ha ridotto gli sprechi.
Q7.11 - Quanti requisiti sono stati cancellati prima di essere stati realizzati?
Ogni requisito cancellato prima di essere stato realizzato è uno spreco evitato.
I dati rilevati sono:
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NDB = numero di requisiti cancellati prima di essere stati implementati
Note= motivazioni dei cambiamenti
In tavola 7.11 sono riportai i risultati della misurazione.
Figura 7.11 Requisiti cancellati prima della loro realizzazione in SDK
L’approccio consente di rilevare incrementalmente requisiti che non risultano utili all’utente e/o all’efficiente comportamento del software.
Q7.12 - In ogni sprint quanto tempo persona è speso per la rilavorazione di ciò che era stato già realizzato?
La rilavorazione di un software già scritto è uno spreco, quindi si vuole rilevare se l’approccio DT fa rimanere relativamente piccola questa dimensione.
I dati rilevati:
Sprint numero identificativo dello sprint
TS= Tempo speso sullo sprint (hh-persona)
TR= Tempo speso sulla regressione (hh-persona)
TAR = Tasso di regressione = TR/TS*100
Il TAR, esprimendo il TR in percentuale sul tempo-persona complessivo speso nello sprint, consente di confrontare sprint di diverse dimensioni eseguiti in progetti diversi.
I risultati della misurazione sono riportati in tavola 7.12 in SDK.
Figura 7.12 Costo della regressione in SDK
Anche se il tempo speso per la regressione è relativamente alto negli sprint in cui si verifica, si rileva che il numero di volte in cui è implicata la regressione è piccolo. Infatti complessivamente il tempo speso per regressione è pari a 16 hh-persona contro 360 hh-persona, quindi un tasso di regressione complessivo pari a 4,44%, compatibile con il rischio di errore in un progetto.
Design Thinking nella produzione della nuova Console
Q7.13 - Quanto evolve l’applicazione in usabilità?
Qui si confrontano le due versioni successive della nuova console. Per entrambi sono impegnati 5 utenti a cui viene sottoposto il questionario SUS.
Il risultato del sondaggio per la versione in esercizio, il è riportato nelle figure 7.13 e le figure 7.14.
Figura 5.13.a Risposte SUS dei Partecipanti - Nuova versione (I rilascio)
Figura 7.13.b. Punteggio SUS dei Partecipanti - Nuova versione (I rilascio)
Punteggio SUS= 63
Con riferimento alla figura 5.1.b. la usabilità è nella fascia insufficiente.
Per migliorare il coefficiente di usabilità complessivo, sono state apportate delle modifiche al prodotto, suggerite dalle evidenze di feedback e dai test eseguiti. Sono state analizzate insieme le evidenze dai sondaggi dell’usabilità e della UX, descritta più avanti. Le modifiche eseguite che sono servite per entrambe le caratteristiche sono state:
In particolare:
- è stata revisionata la parte dei colori delle interfacce
- introdotto uno stile di default di tutte le videate
- utilizzo di parti standard ripetute nelle videate della stessa tipologia (filtri, ordinamenti, bottoni nelle stesse posizioni)
- migliorie nelle schermate dashboard
Nelle figure 7.14.a,7.14.b sono riportati i risultati del successivo sondaggio da cui si ricava che il SUS complessivo è migliorato notevolmente e si è portato in campo “buona”, con riferimento sempre alla tavola 5.1
Figura 7.14.a. Risposte SUS dei Partecipanti - Nuova versione (II rilascio)
Figura 7.14.b. Punteggio SUS per partecipante - Nuova versione (II rilascio)
Media Punteggio SUS= 70,5
Con il primo MVP si è scoperto che il valore della usabilità era in campo “insufficiente” e grazie alle modifiche si è portato in campo “buona” .
Q7.14 - Quanto evolve l’applicazione in UX?
In questo quesito si confrontano i valori della UX nelle due versioni sottoposta a sondaggio.
Per l’indagine sono stati utilizzati due rilasci del prototipo sperimentale, prodotti da due sprint; questi sono stati sottoposti a 5 utilizzatori che hanno risposto al questionario UEQ.
I risultati rilevati sono riportati nelle figure 7.15.a, 7.15.b.
Figura 7.15.a Dati grezzi rilevati dal sondaggio ( I rilascio) Nuova Console
Figura 7.15. b Trasformazione in punteggi dei dati rilevati (I rilascio) Nuova Console
In figura 7.15.c mostra la media raggiunta per ogni persona in ognuno degli aspetti componenti la UX. Da questa si evince che tra i soggetti sperimentali non ci sono persone particolarmente severe o particolarmente tolleranti. Se ci fossero bisognerebbe trattarli come outlier e fare le analisi necessarie senza le loro risposte.
Figura 7.15.c. Media per ogni partecipante (I rilascio). Nuova Console
La figura 7.15.d mostra il grafico del punteggio complessivo di ogni componente e lo confronta con le esperienze di letteratura. Di qui si evince che molti aspetti della UX sono tra il campo “bad” e quello “sotto la media”. In conclusione la UX deve essere migliorata.
Figura 7.15.d. Benchmark della UX con la letteratura (I rilascio) Nuova Console
Per decidere le iniziative di miglioramento che sono opportune intraprendere, la figura 7.15.e consente di valutare l’influenza di ogni quesito sul risultato finale.
Figura 7.15.e. Risultati per ognuno dei quesiti. (I rilascio) Nuova Console
Dopo aver apportato le modifiche di cui si è detto prima è stato fatto un secondo sondaggio che ha dato i risultati riportati nelle figure 7.16
Figura 7.16.a Dati grezzi rilevati dal sondaggio (II rilascio) Nuova Console
Figura 7.16.b Trasformazione in punteggi dei dati rilevati (IIrilascio) Nuova Console
7.16.c Benchmark della UX con la letteratura (II rilascio) Nuova Console
7.16.d Benchmark della UX con la letteratura (II rilascio) Nuova Console
Il miglioramento che si è ottenuto è notevole. Si conferma che gli MVP consentono di scoprire il più presto possibile i punti di debolezza del prodotto e, di conseguenza, farli superare quando il costo dei cambiamenti è meno costoso.
Q7.15 - Quanti requisiti cambiati in uno sprint sono stati realizzati in sprint precedenti?
I cambiamenti di requisiti dopo la loro realizzazione creano sprechi. Pertanto il minor numero di questi requisiti evidenzia che l’approccio crea economia.
I dati rilevai sono
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NC = numero di requisiti cambiati dopo essere stati implementati
Note= motivazioni dei cambiamenti
In figura 7.17 sono riportati i dati inerenti la nuova console per gli sprint eseguiti.
Figura 7.17. Requisiti modificati dopo la loro realizzazione in Nuova Console.
Le modifiche che gli MVP rilevano sono relative a ciò che gli stessi mostrano. Le modifiche da apportare tendono ad aumentare con il numero d’ordine degli MVP perciò è opportuno che i primi MVP realizzino gli aspetti del software che siano i più critici rispetto agli obiettivi che si pone lo stesso software.
Q7.16 - Quanti requisiti sono stati cancellati dopo essere stati realizzati?
Ogni requisito cancellato dopo essere stato realizzato è uno spreco.
I dati rilevati sono:
Sprint = numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NDA = numero di requisiti cancellati dopo essere stati implementati
Note= motivazioni dei cambiamenti
I dati rilevati sono riportati in figura 7.18
Figura 7.18. Requisiti cancellati dopo la loro implementazione in Nuova Console
Si conferma che l’approccio DT diminuisce notevolmente la probabilità di realizzazione di requisiti inutili o mal specificati diminuendo così gli sprechi.
Q7.17 - Quanti requisiti sono stati cancellati prima di essere stati realizzati?
Ogni requisito cancellato prima di essere stato realizzato è uno spreco evitato.
I dati rilevabili sono:
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NDB = numero di requisiti cancellati prima di essere stati implementati
Note= motivazioni dei cambiamenti
I dati rilevati sono riportati in figura 7.19
Figura 7.19. Requisiti cancellati prima della loro implementazione in nuova Console
L’approccio consente di scoprire nelle prime fasi dello sviluppo del software i requisiti che risultano essere inutili facendo diminuire i costi della parte inutilmente realizzata o azzerando totalmente i costi della loro implementazione, in sintesi facendo diminuire notevolmente gli sprechi.
Q7.18 - In ogni sprint quanto tempo persona è speso per la rilavorazione di ciò che era stato già realizzato?
La rilavorazione di un software già scritto è uno spreco, quindi si vuole rilevare se l’approccio DT fa rimanere relativamente piccola questa dimensione.
I dati rilevati:
Sprint numero identificativo dello sprint
TS= Tempo speso sullo sprint (hh-persona)
TR= Tempo speso sulla regressione (hh-persona)
TAR = Tasso di regressione = TR/TS*100
Il TAR, esprimendo il TR in percentuale sul tempo-persona complessivo speso nello sprint, consente di confrontare sprint di diverse dimensioni eseguiti in progetti diversi.
I risultati delle misurazioni sono riportati in figura 7.20
Figura 7.20. Costo della regressione in Nuova Console
La percentuale di rilavorazione complessiva risulta essere di 4,43% che è compatibile con il rischio di rilavorazione di un progetto industriale.
I tempi di rilavorazione non aumentano con il numero d’ordine degli sprint, ciò significa che l’impatto di una modifica rimane più o meno costante nonostante la dimensione del software su cui impatta sia sempre più grande. Questo significa che l’accoppiamento tra le parti implementate con gli sprint successivi è relativamente piccolo. Si potrebbe dedurre che l’approccio DT favorisce il basso accoppiamento tra le parti del software.
Design Thinking per lo sviluppo del Versamenti
Come è stato già detto Versamenti è di servizio al WWS e non ha alcun impatto sulle interfacce con gli utilizzatori, pertanto non è opportuno rilevare quale sia la sua influenza sulla usabilità e sulla UX.
Q7.21 - Quanti requisiti cambiati in uno sprint sono stati realizzati in sprint precedenti?
I cambiamenti di requisiti dopo la loro realizzazione creano sprechi. Pertanto il minor numero di questi requisiti evidenzia che l’approccio crea economia.
I dati rilevati sono:
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NC = numero di requisiti cambiati dopo essere stati implementati
Note= motivazioni dei cambiamenti
I risultati sono riportati in figura 7.21
Figura 7.21. Requisiti modificati dopo la loro realizzazione in Versamenti
Trattandosi di un refactoring i requisiti erano ben definiti a priori e non sono cambiati in corso d'opera. Questo il motivo per cui i valori sono tutti nulli.
Q7.22 - Quanti requisiti sono stati cancellati dopo essere stati realizzati?
Ogni requisito cancellato dopo essere stato realizzato è uno spreco.
I dati rilevati sono:
Sprint= numero d’ordine dello sprint
NR = numero requisiti realizzati cumulativi sino alla fine dello sprint
NDA = numero di requisiti cancellati dopo essere stati implementati
Note= motivazioni dei cambiamenti
I risultati dono riportati in figura 7.22
Figura 7.22 Requisiti cancellati dopo la loro implementazione in Versamenti