Software Quality Attributes in Agile with Visual Studio Online

Lo sviluppo di una soluzione software è finalizzato alla creazione di Valore per il cliente, e, più in generale, per tutti gli stakeholders collegati. Proprio il Valore è l’elemento portante su cui si basa l’intera azione di deploy del prodotto, guidandone le varie fasi di realizzazione e di supporto.

Le varie metodologie Agili ci portano ad “osservare” la nostra soluzione dal punto di vista funzionale, andando a creare un Product Backlog (PB) contenente Epic o User Story che rispondono alla forma: “As a USER… I Want… So…”, mettendo al centro del discorso l’utente finale e, appunto, la sua visione funzionale del sistema.

Questo approccio è assolutamente valido per rappresentare il Valore della soluzione in funzione alle aspettative del cliente, ma trova dei profondi limiti quando si vuole andare a rappresentare i requisiti qualitativi/non-funzionali (NFR) del sistema.

In un post specifico (NFR: come definire correttamente uno scenario) si è già affrontato l’argomento che riguarda una possibile definizione formale degli NFR attraverso Scenari composti da 6 elementi lineari:

  • Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
  • Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
  • Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
  • Environment (Contesto), il contesto in cui si verifica lo stimolo;
  • Response (Risposta), come il sistema risponde allo stimolo;
  • Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

specify nfr 

Figure 1 - Quality Scenario

Messo che gli scenari siano stati definiti, ragionando in chiave Agile evitando un Big Design Up Front (BDUF), come è possibile rappresentarli correttamente all’interno del processo Agile utilizzato, ad esempio Scrum? come è possibile sfruttare Visual Studio Online (o TFS) per tenerne traccia e farli convivere con le User Story?

Per trattare correttamente la tematica, la discussione verrà improntata su “scenari semplici”, in cui il requisito non funzionale è legato esclusivamente solo ad una sola User Story, e su “scenari complessi”, in cui l’NFR è cross-User Story.

 

Technical User Story: scenario semplice

Come detto, le User Story sono direttamente legate agli aspetti funzionali:

            “Essendo un Operatore di Sportello, voglio potermi loggare in modo da assistere il cliente

Esse coinvolgono, idealmente, diversi aspetti tecnici del sistema che ci si approccia a realizzare, poggiandosi sull’Intentional Architecture di riferimento.

In Agile si è abituati a lavorare in funzione del cliente, ma spesso ciò viene portato all’estremo e la presenza di riferimenti di tipo tecnico vengono banditi dal Product Backlog. Ma se si guarda alla definizione stessa di Product Backlog:

“The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product.”

si nota che non viene fatto nessun riferimento esplicito a User Story o a requisiti funzionali, ma ad una lista generica di funzionalità che si desidera avere nel prodotto. Un PB può quindi avere:

  • Features;
  • Bugs;>
  • Technical work;
  • nowledge acquisition;
  • ecc…

in pratica, il PB contiene tutto quello che il Product Owner, coadiuvato dal team, ritiene utile inserire per raggiungere l’obiettivo in funzione del cliente. È bene, quindi, non confondere il Product Backlog con “il documento dei requisisti”… sono due cose completamente differenti!

Nessun problema, quindi, nell’avere delle Technical User Story (TUS) che rappresentino i requisiti non funzionali della soluzione in essere. Inoltre, non vi è alcun vincolo relativamente alla forma che essi debbano avere. In generale è più facile pensare alle TUS se si ha una visione complessiva della soluzione che si sta realizzando, discutendone durante un Story Brainstorming Workshop (rif. Mike Cohn) o un Release Planning, che consentono di andare al di là della singola iterazione di sviluppo.

Le TUS possono essere di vario tipo:

  • Quality Requirements: sono dedicate agli aspetti qualitativi/non funzionali della soluzione;
  • Product Infrastructure: di supporto allo sviluppo dei requisiti funzionali. Si pensi ad esempio all’individuazione di una libreria per la compressione dei dati, che va provata, testata ed integrata nella soluzione;
  • Team Infrastructure: si tratta di sperimentare strumenti che sono di supporto alle attività del team. Si pensi ad una nuova piattaforma ALM;
  • Refactoring: di supporto alle attività di refactoring. Da non intendersi solo relativamente al codice, ma anche all’Intentional Architecture, al Desing, ecc;
  • Bug Fixing: di supporto alla risoluzione di bug o di malfunzionamenti olistici;
  • Spikes: sono una particolare categoria che evidenzia la necessità di apprendere know-how relativamente a uno qualsiasi degli aspetti della soluzione, sperimentando le ipotesi sul campo.

Nel contesto specifico della discussione in essere, ci si concentrerà sui Quality Requirements.

Si ipotizzi che l’Intentional Architecture di riferimento preveda un NFR che declini la Security in funzione dell’accesso al sistema, rappresentato secondo il seguente Scenario:

Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Utente esterno chiede di utilizzare il sistema
Stimoli Richiesta di accesso alle funzionalità del sistema
Artefatti Intera soluzione
Ambiente Erogazione
Risposta L’utente deve autenticarsi attraverso una 2-phase authentication
Misura delle Risposta Reazione in funzione di un numero massimo di tentativi errati

Lo Scenario, è, di conseguenza, un constraints di Dominio, secondo quanto rappresentato dalla figura seguente (fig. 2):

functional vs nonfunctional

Figure 2 – Scenario constraints

Partendo da questi elementi, come è possibile inserire tale requisito all’interno del Product Backlog? La cosa non è fonte di particolare problemi, potendolo esprimere in linguaggio naturale:

Un utente per poter accedere alle funzionalità del sistema deve autenticarsi con una procedura di tipo 2phase authentication: inserendo le credenziali statiche e poi il pin che viene inviato al proprio cellulare.

o anche nel formato che contraddistingue una tipica User Story:

Essendo un utente voglio potermi autenticare tramite una 2phase authentication con credenziali statiche e poi con pin inviato al mio cellulare, per poter accedere alle funzionalità del sistema.

È evidente che quest’ultima forma è una forzatura e sacrifica la chiarezza del linguaggio naturale in favore di una forma standard-de-facto. Se proprio si vuole utilizzarla, potrebbe essere opportuno non esprimerla in funzione dell’utente, ma di una fantomatica personas di sistema, ad esempio l’Amministratore:

Essendo l’Amministratore del sistema, voglio che gli utenti si autentichino tramite una 2phase authentication con credenziali statiche e poi con pin inviato al proprio cellulare, per poter accedere alle funzionalità del sistema.

In fondo, però, l’Agile non deve semplificare al massimo il processo e rendere chiaro cosa fare? Per questo la prima forma è fortemente consigliata. L’NFR riportato non è casuale, ma può essere considerato alla base della User Story di login presentata pocanzi (fig. 3):

login functional vs nonfunctional 

Figure 3 - Login constraint

In pratica, in questo caso, la TUS si configura come un nuovo Acceptance Criteria della User Story che ne vincola lo sviluppo a un requisito non funzionale definito tramite uno Scenario contemplato dall’Intentional Architecture. Tale definizione può avvenire sia ad inizio del percorso di sviluppo sia durante una delle sue revisioni periodiche.

Ma la TUS stessa ha un set di Acceptance Criteria che deve essere opportunamente definito e convalidato, prima di poterla considerare completa. Tornando all’esempio, una sua possibile definizione potrebbe essere la seguente:

  • Verificare che la fase di login avvenga in 15 secondi;
  • Verificare che dopo tre tentativi errati l’accesso per l’utente venga inibito;
  • Verificare che il messaggio di risposta arrivi nell’arco di 5 secondi;
  • ecc….

Bene, il requisito specifico di Sicurezza è ora espresso in modo diretto all’interno del PB, con tanto di criteri di accettazione, la possibilità di creare test automatici di validazione e tracciarne lo sviluppo. Si tratta di un risultato non di poco conto, che consente, inoltre, di parallelizzare le attività di sviluppo della User Story di login.

Resta un ultimo dubbio, però: quando si può considerare conclusa la User Story di login? Ebbene la User Story può ritenersi in “Done state” solo quando la stessa TUS è in “Done State”, essendo doveroso inserire nei relativi criteri di accettazione qualcosa tipo:

  • Tutti i constraints devono trovarsi in “Done” state.

Quanto detto può essere facilmente gestito in Visual Studio Online. Seguendo l’ordine di cui sopra, si crei la login User Story:

login user story 

Figure 4 - Login User Story

Notare che la Value Area è di tipo Business e che negli Acceptance Criteria si è specificato la necessità di superare i constraints. Si crei ora la login TUS di Security:

login tus 

Figure 5 - Login TUS

nessuna sorpresa che la Value Area sia di tipo Architectural.

L’ultimo passaggio è quello che lega la login User Story alla login TUS:

login us link 1

Figure 6 - Link login User Story to login TUS

da cui si ottiene il risultato seguente:

login us link 2

Figure 7 - login User Story linked to login TUS

Per avere anche una indicazione “visuale” della differenza tra i due PBI, è possibile creare una swimlane sulla Board di tipo “Constraints” che, una volta presi in carico sia la login User Story che la login TUS, le daranno un aspetto simile al seguente:

login us link 3

Figure 8 - Constraints swimlane

Si conclude qui la prima parte dell’approfondimento dedicato alle Quality Attributes in chiave Agile. Nel prossimo post verrà affrontato il caso in cui un NFR sia cross-User Story.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme