Nel precedente post dedicato agli NFRs abbiamo cominciato ad affrontare la trasversalità dei Requisiti Non Funzionali all’interno del contesto Agile.
Vediamo ora di approfondire la discussione inerente, partendo dal presupposto che si sia riusciti a formalizzare in User Stories gli NFRs rilevanti per il proprio sistema (vedasi post precedente). Esistono due questioni cruciali nella definizione/gestione degli NRFs su cui è necessario riflettere:
- Sizing (Dimensionamento): che livello di granularità deve avere la mia User Story affinché sia effettivamente una Unità Minima di Valore (MUV, Minimal Unit Value o anche MMF) che possa essere inserita in una specifica Iterazione e possa essere completata in essa? Cosa succede se non si riesce ad ottenere User Stories sufficientemente compatte/granulari da completarle in una singola Iterazione (over-size)?
- Costing (Costo): che costing associo alle User Stories NFR? Quando sono in regime di over-size, come considero i costi relativi?
Entrambe le questioni sono difficilmente inquadrabili in una specifica soluzione, ma cerchiamo di delineare un possibile approccio, in primis per i nuovi progetti e poi per quelli in essere.
Prima di proseguire, da ora in avanti, definiremo:
- FR User Stories, le user stories associate a Requisiti Funzionali. Analogamente FR Themes ed FR Epics;
- NFR User Stories, le user stories associate a Requisiti Non Funzionali. Analogamente NFR Themes ed NFR Epics.
L’aspetto del Sizing di una NFR User Story richiede una forte comprensione dell’impatto (oltre che del Dominio specifico) che l’NFR relativo avrà sul Sistema. L’effort per raggiungere tale obiettivo può essere ridotto sfruttando quella che Ambler definisce “Education”, ovvero affidandosi a specialist del Dominio specifico, mentre la maturità raggiunta consentirà di splittare l’NFR User Story in una serie di NFR User Story minimali che potranno essere inserite in una specifica iterazione.
Facciamo un esempio: As a System Maintainer i want to log system errors. Tale NFR User Story può essere dettagliata (elevandosi quindi a rango di NFR Themes o un NFR Epics) in:
- As a Tester i want to log code errors;
- As a System Administrator I want to log network errors;
- As a UI delegate I want to log interaction errors;
- …
In questo modo si effettua un drill-down della NFR User Story in modo, appunto, da inserirla in una specifica iterazione.
Ma se non riusciamo a fare tale raffinamento? Beh, a questo punto si potrebbe ipotizzare di utilizzare un approccio Lean e abbattere l’approccio basato su iterazioni time-boxed. Chiaramente questo richiede una maturità del Team non indifferente e quindi è consigliabile sforzarsi nella prima direzione.
Passiamo al Costing.
Essendo un convinto sostenitore del framework Disciplined Agile Delivery (DaD), partiamo dall’assunto che una prima definizione di Business (bassa granularità tecnica) degli NFRs trova un naturale posizionamento nella fase di Inception, ossia di esplorazione del progetto. Questo fa sì che una parte del Costing sia di “definizione” e “scoperta” e non appartenga direttamente alla fase di Creation, ovvero di sviluppo iterativo. Un esempio: As a Secuirty Mananger i want that my data are encrypted.
Un secondo aspetto sempre inerente il Costing è l’effort specifico della fase di Creation, ovvero di sviluppo nelle varie Iterazioni. Abbiamo due possibili valutazioni:
- Esiste una specifica NFR User Story: in tal caso il costo è associato in modo diretto alla NFR User Story, esattamente come quello per le FR User Stories;
- L’NFR è trasversale a più FR User Story: in tal caso il costo è associato indirettamente alle varie FR User Stories, e (come suggerito da Cohn) può essere assimilato ad una Tassa applicata all’Iterazione.
Iterations Tax, nel caso ideale del costo costante per iterazione
Fin qui nell’ipotesi che siamo in fase di start-up di un nuovo progetto. Se, al contrario, si considerano i progetti in essere, l’approccio più plausibile è quello di affidarsi, ancora una volta, a Lean (utilizzando ad esempio Kanban) senza stravolgere il lavoro e traghettando il Team verso un framework DaD like.
L’ipotesi di lavoro che abbiamo ipotizzato è chiaramente raffinabile e migliorabile, ma può essere considerato una buona base per una valida gestione delle NFR User Stories che, come è ormai evidente, è un tema molto più ostico di quello relativo alle FR User Stories.