Requisiti agili: un ossimoro

Requisiti agili, nel secolo scorso, sarebbe stato un ossimoro (figura retorica che mette insieme due termini opposti, come “un caldo gelato” o uno “zucchero amaro”).

Ma non è così. La storia dello sviluppo software ha dimostrato che i requisiti si possono scoprire in modo progressivo, iterativo e incrementale. Anzi: che il numero di problemi per cui è possibile precisare tutti i requisiti all’inizio di un progetto è molto limitato.

Esprimere requisiti per evolvere e migliorare di un sistema esistente è relativamente semplice. Ma per qualcosa di nuovo, è molto più complesso.

“Spesso, il modo migliore per scoprire requisiti che nessuno ancora conosce è rilasciare il prodotto in modo incrementale. Ogni volta che i clienti ricevono un rilascio tirano fuori decine di altre funzioni che vorrebbero avere. È un dato di fatto che il numero di nuovi requisiti pensati dai clienti è proporzionale al numero di requisiti già soddisfatti. […]

La maggior parte dei manuali sull’ingegneria del software raccomanda di non iniziare la progettazione fino a quando tutti i requisiti non sono concordati.
È un consiglio sbagliato, perché comunque non arriverete mai a conoscere tutti i requisiti, e iniziare presto la progettazione vi servirà probabilmente a scoprire nuovi requisiti.”

(Alan Davis: Just Enough Requirements Management)

“I cambiamenti in corso d’opera per sistemi medio-grandi avverranno sempre. Non è possibile congelare i requisiti per nessuna applicazione reale.
Quindi le aziende migliori sono in grado di gestire i cambiamenti e sono pronte a farlo, facendo in modo che i cambiamenti non impediscano l’evoluzione del sistema. Una qualche forma di sviluppo iterativo è una necessità logica.”

(Capers Jones, Social and Technical Reasons for Software Project Failures, CrossTalk, June 2006)

Requisiti iterativi e incrementali

• Lo sviluppo iterativo (in cui il lavoro sui requisiti non è limitato ad un’unica fase progettuale) è più efficace dello sviluppo a cascata.
• Per scoprire i requisiti il dialogo con il committente, i futuri utenti e gli altri stakeholder va basato il più possibile sull’analisi di concreti scenari operativi e sulla verifica di prototipi, non su ragionamenti astratti. Le astrazioni sono un terreno su cui analisti e sviluppatori software si muovono agevolmente, ma non accade altrettanto per tutti coloro che devono esprimere i requisiti.
• Funziona meglio, in tutti i casi in cui sia praticabile, la strategia di costruire il sistema per incrementi successivi, sottoponendo i risultati concreti agli stakeholder per ottenere riscontri ed ulteriori indicazioni per l’evoluzione del sistema.

I processi agili (“abbracciare il cambiamento”) hanno introdotto tra l’altro una pratica efficace, il triage e la negoziazione dei requisiti.

Triage e negoziazione dei requisiti

I requisiti, nello sviluppo software, non hanno tutti la stessa importanza. Lo dimostra il fatto che mediamente, secondo dati pubblicati da Standish Group nel 2004, il 45% delle funzionalità di un sistema non viene mai utilizzato, mentre il 19% viene utilizzato solo raramente. Lavoro inutile e risorse sprecate.

Alan Davis ha proposto di applicare alla gestione dei requisiti la pratica del triage. Il triage, in campo medico, consiste nella classificazione delle urgenze nei pronto soccorso, in modo che vengano assistiti prima i pazienti più gravi.

Ordinare i requisiti per importanza – priorità è un presupposto per la negoziazione dei requisiti, che consiste nella ricerca dell’accordo, tra committente e fornitore, su quali requisiti debbano essere soddisfatti nei limiti di tempo e di costo definiti dal committente.

In un ipotetico progetto dotato di risorse infinite, tutti i requisiti degli stakeholder del progetto verrebbero soddisfatti – ma la priorità del loro soddisfacimento andrebbe comunque valutata, negoziata e concordata.

Nei progetti veri, comunque, non si lavora a risorse infinite. Ridurre la quantità di requisiti da soddisfare comporta numerosi benefici:

• eliminazione degli sprechi
• semplificazione dei progetti
• validazioni più mirate da parte del committente e degli altri stakeholder
• riduzione del tempo necessario allo sviluppo ed al test (riduzione della durata del ciclo di lavorazione)
• maggiore possibilità di rispondere ai cambiamenti in corso d’opera