Per aumentare ulteriormente il coinvolgimento degli utenti nelle funzionalità di un prodotto, trovo che il metodo delle tre carte di Crystal Orange sia molto interessante e ben studiato.
Lo scopo è quello di assorbire l’impatto di un cambiamento rispetto alla visione originaria del progetto, ancora di più rispetto a quanto si fa normalmente.
In Scrum infatti l’utente può visionare il prodotto dell’incremento a cadenza tipicamente bisettimanale e gli elementi della funzionalità non rispondenti vengono presi in carico e sviluppati nell’iterazione successiva.

Crystal Orange, diversamente dagli altri approcci agili, consiglia di programmare una dimostrazione intermedia con l’utente, ancora prima del termine dello sprint (indicativamente a partire dalla prima metà dell’iterazione in poi). Questa dovrebbe consentire al gruppo di lavoro di reagire prontamente ai feedback che dovessero arrivare ad introdurre modifiche di scopo o comunque a cambiamenti strutturali. E l’utente in questo modo avrebbe piena libertà di deviare dall’idea iniziale.

A completare il doppio momento dimostrativo con l’utente, Crystal Orange prevede che ogni User Story sia sviluppata in maniera incrementale ed iterativa (una sorta di sprint nello sprint, di fatto).
Per ogni User Story infatti Crystal Orange consiglia la creazione di tre cards. Una relativa all’implementazione della prima fase, la seconda relativa alle modifiche che necessarie provengono dal feedback da parte dell’utente finale e la terza relativa alla revisione finale della User Story, attività propedeutica alla messa in produzione e consegna della funzionalità finite e pronta per l’uso.

All’interno di questo modello, alcuni gruppi di lavoro preferiscono spostare la maggior parte del lavoro nella prima card, in modo da presentarsi alla dimostrazione con l’utente con un semilavorato molto simile a come si presenterà nella versione finale. In questo modo le due fasi successive saranno necessariamente più leggere.
Altri gruppi invece si trovano meglio a fare il minimo indispensabile nella fase preliminare, per poi avere la libertà di rivedere e rifattorizzare la funzionalità, se necessario.

Come organizzare operativamente le tre carte? Alistair Cockburn prevede alcune varianti rispetto ad una versione base che prevede, appunto, di creare tre cards per ogni User Story. Nella prima card ci sarà la descrizione lato utente della funzionalità, nella seconda card ci sarà la descrizione delle variazioni richieste dall’utente, e nella terza rientreranno le attività di fine-tuning e per la messa in produzione.

In una delle varianti le tre cards sono collassate in una sola, che nella fase IN PROGRESS dovrà però attraversare più stati prima di andare in DONE, ad esempio FASE 1, FASE 2 e FASE 3.

Infine, le tre cards dovranno essere stimate singolarmente per poter entrare nella pianificazione dello sprint:: si può ad esempio prevedere un peso per l’implementazione della funzionalità così come la si conosce in fase iniziale (la prima card), si può poi riservare un peso alla card dei cambiamenti in base a quanto si prevede che la specifica potrà cambiare (es: un quarto della stima iniziale), e per finire un peso alla card finale, con la previsone delle attività da effettuare perché la funzionalità sia immediatamente utilizzabile dall’utente.