RE@Agile

Appunti presi durante lo studio per la certificazione RE@Agile. Per la certificazione ho usato l’handbook disponibile gratuitamente in inglese dal sito IREB.

Premessa

Dopo il fallimento dell’introduzione di pratiche agili nel contesto lavorativo, ho constatato la sostanziale incapacità di seguire anche approcci tradizionali in modo sensato. Rilevo al momento il gap maggiore nella gestione dei requisiti, quindi ho cercato ispirazione in IREB (International Requirement Engineering Board). Tuttavia, le tecniche classiche di requirement engineering richiedono una disciplina che mal si concilia con la realtà in cui lavoro. L’approccio RE@Agile mi sembra più fattibile… just enough requirement engineering.

Requirement Engineering & Agile?

Il Requirement Engineering (RE nel seguito) e i principi dell’Agile sono compatibili? La risposta breve é sì. Solo una lettura superficiale dei principi dell’Agile manifesto puo’ far pensare il contrario. I requisiti sono un modo per concordare con gli stakeholder quanto verrà prodotto prima che lo sia. Questa necessità sussiste che si lavori in modo incrementale, iterativo o waterfall. L’agile manifesto recita “Working software over comprehensive documentation”, sottolineando come il software funzionante sia più importante della “carta”… ma in qualche modo, chi quel software lo deve sviluppare deve sapere cosa i commitenti si aspettano. La parola chiave é “over”: l’unica vera misura del progresso di un’iniziativa é il software funzionante, ma questo non significa che non sia necessario fare anche altro prima di arrivare al prodotto finale.

Vediamo come i principi base del RE non siano in contraddizione rispetto all’Agile:

Conoscere i requisiti rilevanti, raggiungere il consenso tra gli stakeholder e documentare i requisiti secondo un certo standard, rivedendoli all’occorrenza.
Conoscere e documentare i desideri degli stakeholder
Gestire e specificare i requisiti in modo da minimizzare il rischio di deliverare un sistema che non risponde alle esigenze degli stakeholder.

nessuno dei tre punti é incompatibile con l’Agile. La differenza sostanziale tra un approccio Agile e quello tradizionale sta nell’adozione di un metodo empirico e nel minimizzare il work in progress. Tuttavia, che tu stia capendo cosa fare per il prossimo sprint o per un progetto di 2 anni, in qualche modo avrai a cuore i tre punti sopra.

RE@agile é un approccio cooperativo, iterativo e incrementale che si prefigge il raggiungimento di 4 obiettivi

Conoscere i requisiti rilevanti ad un adeguato livello di dettaglio (per le varie fasi dello sviluppo)
Raggiungere un accordo sui requisiti tra gli stakeholder
Catturare e documentare i requisiti secondo i vincoli dell’organizzazione
Effettuare tutte le attività legte ai requisiti secondo un approccio agile

L’approccio é cooperativo, ovvero richiede la partecipazione di tutti gli stakeholder. Iterativo sottolinea il concetto di just in time tipico dell’agile. Incrementale, si riferisce invece al concetto di MVP e di delivery di valore al termine di ogni sprint, concetto condiviso con Scrum.

RE@Agile introduce il concetto di “definition of ready” (cosa non presente in Scrum) per definire i requirement pronti per essere lavorati.

Il terzo punto, quello della documentazione dei requisiti, acquisisce particolare rilevanza in quei settori in cui vincoli normativi impongono un certo livello di tracciabilità.

Le attività legate ai requisiti negli approccio tradizionali si calano in modo diverso in un approccio agile. Ad esempio, il versionamento dei requisiti puo’ diventare meno oneroso negli approcci in cui ogni iterazione porta a software funzionante: quanto vuoi che cambino i requisiti in due settimane?

Una partenza pulita

RE@Agile suggerisce tre attività per partire bene in un progetto agile.

Definizione della vision o dei goal del sistema

La vision (secondo la dicitura più in voga nel mondo Agile) o i goal (secondo la dicitura ri RE@Agile) rappresenta l’obiettivo di alto livello da raggiungere. Una nuova vision puo’ nascere a seguito di una situazione non soddisfacente, di cambi nel contesto o di nuove opportunità.

La vision dovrebbe rappresentare un outcome desiderato (il cosa, non un deliverable o una funzionalità (il come). La vision rappresenta un obiettivo a lungo termine e puo’ essere spezzata in goal più a medio termine. Ogni vision dovrebbe avere un orizzonte temporale associato.

Tecniche di specifica della Vision/Goal

1- Requisiti SMART (Specific, Measurable, Achievable, Relevant, Time-Bound). Puo’ essere usato come template o come checklist.

2- PAM, ovvero rispondere a queste tre domande: Quale é lo scopo (Purpose)? Qual é il vantaggio business (Advantage)? Come misuriamo il vantaggio (Measure)? Questo approccio non considera l’aspetto temporale, cosa che puo’ essere utile nelle fasi iniziali di definizione di un obiettivo.

3- Product Vision Box. Si effettua un workshop in cui i diversi partecipanti devono creare una scatola per il prodotto che vogliono realizzare. La scatola, come se dovesse essere esposta in un punto vendita reale, deve descrivere i benefici del prodotto ed invogliare all’acquisto. La scatola creata viene esposta ad un pubblico senza alcuna spiegazione, per vedere le reazioni. Questo approccio costringe a mettersi nei panni dell’utente finale. Non si presta a tutti i tipi di progetti.

4- News from the future. Si chiede di scrivere un articolo sul proprio prodotto come se questo articolo venisse da un giornale del futuro. Si possono prendere diverse prospettive, ad esempio, un articolo sul successo del prodotto, sul decimo anniversario del lancio, su un fallimento disastroso del prodotto. Questo articolo puo’ essere il punto di partenza per la definizione della vision.

5- Vision board. Una vision board é una rappresentazione strutturata grafica di una vision. La VB rappresenta la vision con focus su contenuto e/o tempistiche. E’ considerata un artefatto mutabile ed é la fonte autoritativa per la vision. Esistono diversi schemi.

6- Canvas Techniques. Simili alle vision boards, ma con uno scope più ampio rispetto alla sola vision. Esempi sono la Business Model Canvas e la Opportunity Canvas.

Cambiamento della vision

La vision puo’ cambiare per diverse ragioni. Quando ciò accade, il cambiamento e i razionali dello stesso devono essere tracciati. Questo permette di riflettere sui cambiamenti in seguito e di valutare la frequenza del cambiamento. Troppi cambiamenti, soprattutto a lavori inoltrati, possono indicare una scarsa chiarezza nella direzione del prodotto.

Scope, Context e Boundary

Non sto a definire i termini Scope, Context e Boundary, sono quelli classici del RE. La definizione dello scope puo’ essere effettuata discutendo queste domande:

Quali features devono essere fornite dal sistema e quali dal Context
Quali interfacce tecniche devono essere fornite dal sistema al Context
Quali aspetti del Context sono rilevanti/irrilevanti per il Sistema
Quali aspetti del sistema e del Context possono essere modificati.

Il sistema, il suo context e le interazioni possono essere rappresentati attraverso dei context diagram come mostrato sotto.

Alternativamente o in aggiunta, si puo’ usare il linguaggio naturale, diagrammi UML degli use cases o una story map. Una story map organizza le stories secondo due assi: l’asse orizzontale rappresenta il processo complessivo, mentre l’asse verticale fornisce dettagli per ogni parte del flusso, cosi come una separazione delle item secondo la sequenza di sviluppo.

Lo scope cambia sempre, é inevitabile. Per questo, la definizione e il mantenimento dello scope é un’attività importante: senza di essa, determinare le variazioni é impossibile, non hai una baseline rispetto alla quale misurare il cambiamento.

Stakeholder Management

Stakeholder (SH nel seguito), secondo IREB, é chiunque influenzi i requisiti direttamente o indirettamente. La mancata o incompleta identificazione degli SH puo’ portare alla tardiva scoperta di requisiti importanti. Un modo per identificare gli SH é il modello a cipolla (Onion Model). Questo modello categorizza gli SH in tre categorie:

SH del sistema: quelli direttamente impattati, come utenti, operations, etc…

SH del Surrounding context: quelli indirettamente impattati, come managers, sponsors, etc…

SH del wider context: quelli con una relazione indiretta col sistema, come agenzie non governative, NGO, etc…

Questo modello puo’ essere usato per identificare gli SH, come supporto a workshop di identificazione e come linea guida durante interviste.

Gli utilizzatori finali del sistema sono tra gli SH più importanti. Gli utilizzatori possono essere volontari (open environment, dove l’utilizzatore puo’ scegliere se usare il sistema) o obbligati (close environment, dove l’utilizzatore non puo’ scegliere; ad esempio, back office). Nel secondo caso si tende a trascurarne l’importanza.

Se gli utenti non sono noti, una tecnica utile per ragionare sulle loro esigenze é l’uso di Personas, ovvero stereotipi significativi. In aggiunta, si possono usare strumenti di analitica per scoprirne il comportamento.

A parte gli SH, esistono altre sorgenti di requisiti, ad esempio un sistema precedente in caso di sistemi che rimpiazzano un legacy; le interfacce con altri sistemi; altri sistemi simili;

User stories

Un modello usato per le user stories é quello delle “3 C”: card, conversation, confirmation. La parte più importante é a mio parere la terza, ovvero gli acceptance criteria.

Solitamente le user stories sono formulate per contenere tre elementi: chi vuole la funzionalità (who), cosa vuole (what) e soprattutto perché (why). Questo porta alla classica formulazione “as a <who>, I want to <what>, so that <why>”.

Una buona user story segue i criteri INVEST. E’ quindi:

Indipendent, dalle altre stories
Negotiable, quindi oggetto di una conversation
Valuable, per qualcuno
Estimated
Small enough per stare in un’iterazione
Testable, perché se non é testabile non é neanche realizzabile

Una user story puo’ contenere testo, ma puo’ essere anche specificata attraverso formalismi diversi, come BPMN, Macchine a stati, etc…

Spezzettare e aggregare

Le storie devono essere piccole abbastanza da fittare un’iterazione e grandi abbastanza per avere un valore. Il problema é di solito come spezzare un’attività grosse. Alcune strategie:

Workflow: se la storia descrive un workflow, si puo’ spezzare la storia in modo da definire lo step iniziale e finale e poi aggiugere il resto, oppure cercare di fare flussi end to end.
Operazioni multiple, si possono spezzare in story diverse.
Business rules variations, se ci sono varianti nelle regole di business, si possono spezzare in US diverse.
Data variations, se ci sono varianti dovute a dati differenti, si possono spezzare
Variazione di interfaccia
Major effort
Simple/Complex: se la story ha un core semplice che esplica la maggior parte del valore, si puo’ estrarre quella sub-story e rimandare il resto.
Defer performance: si puo’ fare una prima versione senza rispettare i vincoli di performances?
Break out a spike: se non sai dove partire, fa uno spike e guadagna conoscenza (e poi riprova)

Quando si lavora un workflow, bisogna cercare di implementare un end to end. Se é complesso, si puo’ tralasciare alternative (ad esempio, eccezioni) oppure opzioni (cose non strettamente necessarie) o step che possono essere fatti manualmente.

La decomposizione delle stories crea gerarchie di requisiti, che hanno la loro radice nella vision. I diversi livelli assolvono compiti diversi: quelli più bassi, dove il dettaglio é maggiore e lo scope minore, servono per indirizzare lo sviluppo. I livelli più alti sono utili per altri stakeholder. La scomposizione dall’alto livello al basso puo’ seguire diversi approcci:

suddivisione in funzioni logiche
seguire suddivisioni precedenti
suddivisione per cliente o utilizzatore
suddivisione per hardware
suddivisione su base geografica
suddivisione per oggetto di business domain
suddivisione per processo con trigger esterno

Il settimo approccio parte dal contesto, mentre i primi sei partono dalla struttura del prodotto. E’ il metodo preferibile perché porta naturalmente a ragionare sul valore, quindi sulle user stories. Per attuarlo, si suggerisce di ragionare sugli eventi che accadono, siano essi causati da un agente esterno o da eventi temporali.

Le gerarchie di requisiti possono essere rappresentate con una story map, come descritto in precedenza.

Il raffinamento dei requisiti deve continuare fino a che ci sono elementi sufficienti per una stima, quando le assunzioni principali sono state chiuse. Se una storia è strutturata seguendo l’INVEST, le ultime tre condizioni dovrebbero essere soddisfatte: deve essere possibile stimare la story, devono fittare uno sprint (idealmente dovrebbero starcene 6-10 in uno sprint) e devono essere definiti gli acceptance criteria.

Acceptance criteria

Gli acceptance criteria possono essere specificati con linguaggi tipo Gherkin (given-when-then), che tuttavia puo’ risultare difficile da usare per utenti business. In RE@Agile, esiste il concetto di Definition of Ready: lo stato in cui deve trovarsi il requisito affinché il team possa raggiungere la DoD. Il raggiungimento della DoR richiede tempo, che deve essere investito prima del planning, tipicamente nei refinement meetings.

Documentazione dei requisiti

Il backlog costituisce la sorgente dei requisiti per i team agili. Ci sono 4 ragioni principali per documentare i requisiti:

a scopo di comunicazione
per pensare
a scopo legale
a scopo di conservare informazioni

Tipicamente il backlog assolve bene le prime due funzioni, non altrettanto le ultime due. La scelta di cosa documentare e come dipende da molti fattori, tra cui la natura degli SH, vincoli legali, le dimensioni del progetto.

Quality requirements e vincoli

I quality requirement si riferiscono sempre a requisiti funzionali. I vincoli di prodotto, si riferiscono a requirement di qualità o funzionali. I vincoli di processo invece si riferiscono al processo stesso e non al prodotto.

Le tassonomie di quality requirement piu usate sono la ISO 25010 – Software product quality (per i dati invece si usa la ISO 25012) e il VOLERE template.

I quality requirement possono essere inizialmente vaghi, ma devono essere poi resi non ambigui e verificabili. Per dettagliarli e renderli meno vaghi, esistono due strade: dettagliarli o decomporli.

Uno strumento utile per strutturare i quality requirement é il quality tree, che struttura i requisiti in un albero con una radice etichettata come “specific quality”, mentre al primo livello troviamo le categorie (ad esempio, performances), al secondo livello troviamo le sotto categorie (ad esempio, latenza), mentre le foglie sono scenari (ad esempio, il sistema deve rispondere in meno di 2 secondi nel 95% dei casi in condizioni di carico nominale).

Anche i quality requirement devono avere degli acceptance criteria.

Nei contesti agili, poiché i quality requirement fanno sempre riferimento ad uno o più requisiti funzionali, la cosa più semplice è collegarli alle item del backlog in qualche modo (direttamente nella item o come item linkata). Un’alternativa é mettere i quality requirement nella DoD.

Vincoli

I vincoli (constraint in inglese) limitano lo spazio delle soluzioni. E’ importante rispettarli, ma anche evitare di fare assunzioni limitanti.

I vincoli possono essere di prodotto (scelte tecnologiche, ambiente operativo, riuso di componenti esistenti, vincoli ambientali, fisici, etc…) o di processo (budget, tempistiche, skills, compliance, etc…).

Anche i vincoli dovrebbero avere degli acceptance criteria e un razionale che giustifichi la loro presenza.

Prioritizzazione dei requisiti

Le metodologie agili mirano ad ottimizzare il delivery di valore e a produrre un incremento potenzialmente shippable in ogni iterazione. La prioritizzazione dovrebbe quindi avvenire con il valore come driver principale.

Valore puo’ avere diversi significati. Ci sono diversi aspetti da considerare parlando di valore: puo’ essere valore per il cliente e stakeholder, valore per l’organizzazione, puo’ essere una feature la cui assenza mette a repentaglio l’organizzazione o il prodotto, puo’ essere il valore economico associato ad una feature, il raggiungimento di una certa milestone, il cost of delay (ovvero il costo di non avere una certa feature) o il time to market.

Anche alcuni requisiti di qualità aumentano il valore, in particolare usabilità, robustezza, il costo di manutenzione.

Un altro approccio é quello basato sul rischio. Un rischio si puo’ gestire in 4 modi: evitandolo (a discapito di perdere opportunità legate ad esso); mitigarlo, cioé prendere misure ridurne l’impatto quando il rischio diventa una realtà; ridurlo, ovvero lavorare per abbassarne la probabilità; oppure non fare nulla e sperare per il meglio.

Tecniche di prioritizzazione

Esistono diverse tecniche.

Il criterio MoSCoW (must, should, could, won’t) categorizza i requisiti in 4 categorie secondo la loro necessità. I must dovrebbero esser in cima al backlog, seguiti dagli should, quindi i could e per finire i won’t (che a mio parere non dovrebbero proprio essere nel backlog). Il livello di dettaglio dovrebbe essere direttamente correlato alla posizione nel backlog, con le item in cima molto dettagliate e lavorabili.

Alcuni applicano un numero da 1 a 100 alle item del backlog. Questo numero indica il business value e più é alto, maggiore é il valore. Il numero puo’ essere determinato in diversi modi, ad esempio usando pesi diversi per diverse dimensioni.

Stime

Le stime servono principalmente per forecasting. Le stime sono alquanto controverse, soprattutto nelle culture burocratiche e patologiche. Nei metodi agili, le stime sono fatte da chi deve poi fare il lavoro effettivo (e ci mancherebbe). Inoltre, tutto il team dovrebbe essere partecipare alla definizione delle stime. Si suggerisce inoltre l’uso di misure relative e l’uso di story point.

Tra le tecniche, si suggerisce il T-shirt sizing e il planning poker (non spendo altre parole su questo). Il planning poker ha il difetto di richiedere molto tempo, quindi si suggerisce l’uso di tecniche approssimate, come la creazione di bucket.

Strategie di sviluppo

MVP, minimum viable product, é il set di feature che ci permette di imparare qualcosa sugli utilizzatori col minimo sforzo. Potrebbe anche non essere un oggetto deployabile. Lo scopo é ridurre il rischio.

MMP, minimum marketable product, indica il prodotto col set di feature minimo in grado di soddisfare le esigenze di early adopters.

Nell’MVP, il focus é sull’apprendimento, sul ridurre l’incertezza. Nell’MMP, il focus é sulla produzione.

Un altro criterio da considerare é il kano model, che categorizza le feature come fattori base (o igienici), fattori di performance (satisfiers) e i fattori di excitement (deighters).

Per finire, un altro criterio (che sconfina nella prioritizzazione) é il WSJF, che é dato da cost of delay/durata. Il CoD é a sua volta calcolato come somma di business value, time criticality e Risk reduction/Opportunity Enablement.

Scaling RE@Agile

Questo capitolo effettua una superficiale comparazione dell’approccio ai requisiti , al backlog e al ruolo del product owner dei principali framework scaled agile. I framework considerati sono SAFe, Nexus, LeSS, Scrum@Scale, BOSSA Nova e Scrum of Scrums.

Scalare comporta sempre un’aggiunta di complessità, quindi va fatto solo quando ci sono delle buone ragioni. Le tre dimensioni che possono portare a valutare uno scenario scaled sono la complessità del prodotto, esigenze di time to market e la distribuzione geografica dei team.

Un approccio scaled rende particolarmente rilevante la necessità di strutturare i requisiti a diversi livelli di dettaglio. I diversi framework usano nomi differenti per i requisiti di alto livello, mentre i requisiti a basso livello sono sempre chiamate user stories. Nell’ambito di RE@Agile si parla genericamente di alto, medio e basso livello.

Alcuni framework sono piuttosto prescrittivi (come il mio amato SAFe), altri sono più laschi. SAFe definisce 4 livelli, dal più alto al più basso: Epic, Capability, Feature e Story, definendo termini specifici per gli acceptance criteria ai vari livelli e dando indicazioni sulla durata massima delle feature e delle story.

L’accountability dei requisiti nelle strutture scalate segue diversi approcci secondo il framework.

Al di la di nomi e ruoli, i framework concordano su due aspetti:

un unico backlog
chiara accountability dei requirement

Tutti i framework scaled definiscono due tipi di cicli iterativi: uno breve, detto sprint, e uno più lungo, spesso detto release, pensato per integrare gli sforzi di diversi team.

Negli approcci scalati, occorre bilanciare diverse forze: da un lato, per rispondere rapidamente al cambiamento, le decisioni devono essere portate più vicino possibile al team. Dall’altro, le decisioni devono essere condivise a livello di prodotto, ma senza scendere in dettagli eccessivi.

Il refinement dei requisiti deve essere fatto cercando di minimizzare le interdipendenze tra team: ogni team dovrebbe idealmente avere responsabilità di delivery di una funzionalità end to end. Una divisione per use case o business process é l’ideale. Quando non é possibile, sorge la necessità di allineare diversi team ad una visione comune del requisito, identificando e gestendo le dipendenze. Se i team sono distribuiti geograficamente, su fusi orari differenti e magari parlano lingue e appartengono a culture differenti, la complessità aumenta.

Il product owner deve gestire la roadmap. La roadmap organizza il backlog su un asse temporale. E’ utile per comunicare obiettivi strategici. La roadmap é il risultato di un esercizio di pianificazione. La pianificazione richiede un backlog ordinato e stimato.

Nella creazione di una roadmap, il product owner deve considerare il classico triangolo “tempo-scope-risorse”, dove la variabile su cui agire é lo scope. La roadmap, nella sua dimensione temporale, considera il concetto di cono dell’incertezza in due forme: da un lato, nelle prime iterazioni non c’è una buona confidenza nella capacity del team. Dall’altro, le iterazioni più lontane nel tempo sono meno definite nei contenuti, quindi meno certe.

La rappresentazione della roadmap dipende dall’uso. In SAFe, si parla di solution roadmap, divisa in program increments. Ogni program increment ha poi una sua roadmap. Altri framework sono meno prescrittivi, ma non escludono l’uso di roadmap. Usare item di basso livello come le story per le roadmap puo’ rendere difficile la lettura a stakeholder interessati alla visione di alto livello a causa dell’eccessivo dettaglio.