Technical User Story: scenario complesso

Continuiamo il nostro viaggio nel mondo delle Technical User Story (TUS), ovvero la rappresentazione dei constraints non funzionali, fondamentali per la realizzazione di una soluzione di qualità in linea con le aspettative dell’utente.

Nel precedente post ci si è concentrati sullo “scenario semplice”, ovvero sul caso in cui la TUS sia strettamente legata ad una singola User Story, diventandone un’Acceptance Criteria che ne condiziona lo sviluppo e il passaggio in “Done State” in modo stringente. Più comunemente, però, i constraints non funzionali sono cross-User Story, rappresentando un aspetto trasversale del sistema e ponendo tutta una serie di problemi, sia nella loro gestione sia “nel quando” diventa possibile considerare una User Story in “Done State”

Cross User Story constraints

Nello scenario cross-User Story è fondamentale individuare uno scope più ampio da considerare per lo sviluppo delle TUS, che, quasi sicuramente, non possono essere “contenute” in una singola iterazione. Per supportare in modo ottimale tale attività, è opportuno dividere il “generico” constraint introdotto precedentemente in due tipologie ben delineate:

• Rule: è un constraint che limita la libertà nella scelta del come sviluppare la soluzione. Si tratta di un vincolo difficilmente percepibile da parte dell’utente finale.
  • Simplicity, Maintainability, Testability, Portability, Extensibility, ecc…
• Restriction: più che porre limiti, contribuisce a definire i livelli di qualità annessi all’esecuzione della soluzione, inquadrabili come “vincoli” architetturali. È evidente che tale aspetto è percepito in modo diretto dall’utente.
  • Correctness, Performance, Reliability, Scalability, Security, Usability, ecc…

Per esplicitare meglio le differenze tra le due tipologie di constraint, si considerino i seguenti scenari-tipo annessi alla Simplicity e alle Performance:

Tab.1: Simplicity

Tab.2: Performance

La differenza sostanziale tra le due tipologie di constraint è ben leggibile nello Scenario annesso alla Simplicity (tab.1). In esso si evidenzia come sia estremamente difficile, se non impossibile, definire in modo univoco la “Misura della Risposta” e i possibili test per la verifica della “Risposta” del sistema, essendo lo “Stimolo” non meccanizzabile. Ciò porta all’impossibilità di asserire in modo sistematico che la User Story è completata e far evolvere il suo stato in “Done State”. Tale condizione di incertezza non persiste, invece, per lo scenario Performance (tab.2) che esplicita elementi misurabili e direttamente testabili.

Nonostante queste profonde differenze, da un punto di vista schematico, i constraint cross-User Story possono essere visti esattamente come quelli single-User Story, ovvero come vincoli al Dominio di riferimento funzionale.

Rule & Restriction Constraints

Cosa diversa è, invece, la loro rappresentazione e gestione all’interno di strumenti di ALM, e in particolare di Visual Studio Online.
Nel caso delle Rule, esse sono assimilabili a dei Global Work Item a cui vanno collegate le varie Feature da realizzare: sarebbe inutile legare le Rule ai singoli PBI (singole User Story), perché impattano l’intero ciclo di sviluppo della soluzione e devono essere viste come uno stimolo al continuo refactoring durante le iterazioni, in funzione del raggiungimento dell’optimo relativo.  È del tutto evidente, quindi, che una Rule Feature ha un ciclo di sviluppo assimilabile a quello della soluzione (Release, Increment, ecc…).

In VSO, non essendo ancora contemplata la possibilità di modificare il Process Template e creare specifici Work Item type, possiamo utilizzare un item di tipo Feature per definire una Rule Feature, caratterizzata da una specifica naming convention del tipo: RULE::Name e con la Value Area settata ad Architecture.

RULE Feature

Successivamente si potrà procederà a “linkare” direttamente come “reference” la singola Feature alla Rule Feature:

RULE PBI Linking

Nel caso delle Restriction, i work item di riferimento sono le User Story che in VSO sono genericamente rappresentate sotto forma di PBI. Anche qui, per ora, è necessario adattare un PBI generico con una specifica naming convention: Restriction::Name, dando vita ad un Restriction PBI con la Value Area sempre settata ad Architecture.

Restriction PBI

A questo punto i PBI vanno linkati, come per le Feature, alla Restriction PBI che le vincola nel loro sviluppo, come accade per lo scenario semplice descritto per il post precedente. Se è vero, però, che il PBI va completato nella singola iterazione, lo stesso non vale per la Restriction PBI che resterà “In Progress” finché tutte le User Story/PBI annesse saranno completate. Da ciò risulta fondamentale la granularità della definizione degli Scenari di qualità al fine di non avere Restriction PBI che durino l’intero ciclo di sviluppo, difficilmente giustificabili e tollerabili, a differenza delle Role Feature.

Operando con una naming convention di riferimento è possibile, inoltre, costruire delle query ad-hoc che consentono di tenere sempre evidenza di quelle che sono le Rule e le Restriction attive nel sistema, andando anche eventualmente a “pinnare” il risultato sulla home.

Simple Restriction query

Simple Restriction query “pin”

Va puntualizzato che nel caso di Team Foundation Server, essendo possibile modificare il Process Template, è opportuno creare appositi Work Item in grado di rispecchiare in modo specifico le caratteristiche delle Rule e delle Restriction.

Stay tuned!