Agile Life

dicembre 2012 - Post

NON FUNCTIONAL REQUIREMENTS in AGILE: Sizing e Costing

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:

  1. 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)?
  2. 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:

  1. FR User Stories, le user stories associate a Requisiti Funzionali. Analogamente FR Themes ed FR Epics;
  2. 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:

  1. As a Tester i want to log code errors;
  2. As a System Administrator I want to log  network errors;
  3. 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 diCreation, 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:

  1. 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;
  2. 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.

 

nfrs tax

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.

Non Functional Requirement in Agile

Normal 0 false 14 false false false IT JA X-NONE

Durante l’Agile Day 2012 (Milano) ho avuto il piacere di chiacchierare con un caro amico ed un collega, entrambi esperti IT, del tema dei Requisiti non Funzionali (NFR, o anche di Qualità).

La questione si è incentrata su una domanda tanto banale quanto cruciale:

“come descrivo i requisiti non funzionali di un sistema, ottenendone l’accettazione del cliente”?

Se vi sembra semplice rispondere a tale domanda, vi invito a rifletterci bene, perché dietro si cela una complessità enorme che spesso non riesce a trovare una risposta semplice ed unica.

Nella discussione, l’amico suggeriva di adottare lo standard ISO 9126 (ISO/IEC 25000 dal 2005) che descrive un modello di qualità del software. Il suggerimento è assolutamente centrato, visto che, opportunamente utilizzato, la specifica in questione permette di comunicare al Cliente (attenzione: notare che si parla di Cliente e non Stakeholder!) sufficienti informazioni riguardo ad aspetti come Manutenibilità e Sicurezza.

Ma lo stesso è adattabile al mondo Agile? E se si, come?

Partiamo da un dato di fatto: lo standard ISO 9126 è nato tenendo conto dei modelli di sviluppo classici, in cui la fase di analisi e definizione dei requisiti è effettuata, in modo imperativo, a monte del ciclo di sviluppo del software.

Si tratta, chiaramente, di un approccio in netto contrasto con quello Agile che, come ben sappiamo, prevede un continuo “aggiustamento” dei requisiti durate le varie iterazione (JIT, Just in Time).

A questo punto qualcuno potrebbe suggerire: “trascriviamo gli NFR in User Story che ne catturano l’essenza”.

Bene, si può sicuramente fare ma bisogna affrontare due sfide interessanti:

1.     La tipica User Story (As a user, i want) è pensata per rientrare in una singola iterazione in modo da essere completata e produrre incrementalmente un sistema pronto per il deploy. Un requisito non funzionale è però spesso un aspetto trasversale che, non è detto possa essere completato in una singola iterazione o splittato efficacemente per essere coperto da più iterazioni. Tipicamente è vero proprio il contrario!

2.     Gli NFR sono, al pari dei Temi di Business (aka Requisiti Funzionali, FR), fondamentali per la definizione dell’Intentional Architecture. Ciò impone di confrontarci con l’Agile Architect Uncertainty Principle [Principio di Indeterminazione delle Architetture Agile]: “Più si affina un aspetto, tanto più l’altro perde di consistenza” [F.P], che contrappone tra loro l’Aspetto Temporale e l’Aspetto Strutturale dell’Intentional Architecture (si veda post).

E’ quindi necessario identificare un approccio per gestire correttamente l’inserimento dei requisiti non funzionali all’interno del Software Development Lifecycle (SDLC), così come suggerito da Scott Ambler che identifica quattro strategie di injection degli NFR all’interno del ciclo di sviluppo del software:

  • ·      Initial requirements and architecture envisioning during Iteration 0 to identify NFRs and constraints;
  • ·      Just in time (JIT) model storming through the construction lifecycle to explore the details;
  • ·      Independent investigative testing throughout the lifecycle to ensure that the system addresses the NFRs and constraints appropriately;
  • ·      Developer education so that they understand the fundamentals of the full range of architectural concerns described in the requirements.

In pratica Ambler suggerisce che gli NFR vengano rivisti in più momenti dell’SDLC e affidati a diverse figure del Team:

E’ interessante evidenziare che, oltre all’autoapprendimento, viene contemplato esplicitamente l’attività di Education, ovvero il coinvolgimento diretto di esperti che sappiano trasferire al Team know-how relativo allo specifico requisito non funzionale.

Inoltre Ambler prevede (così come descritto in DaD) una serie di Test Indipendenti (affidati a persone esterne del Team di sviluppo), atti a stressare il sistema al fine di verificarne sia gli NFR che gli FR.

Fin qui abbiamo preso in prestito una possibile strada da percorre per integrare nel nostro SDLC la gestione dei requisiti non funzionali, ma come applichiamo il tutto concretamente?

Facciamo un esempio relativo all’aspetto della Security.

A luglio di quest’anno, SAFECode ha pubblicato un white paper da titolo “Practical Security Stories and Security Tasks for Agile Development Environments” in cui, partendo dalle esperienze dei propri aderenti e della Community afferente, ha delineato

  • ·      36 security focused stories e relativi task (tab.1) con cui comunicare efficacemente agli stakeholder e al Team gli NFR;
  • ·      17 operational security tasks, ovvero attività non direttamente legate alle User Stories ma che spingono verso una operatività che tenga in conto dei fattori legati alla Security (tab.2);
  • ·      12 advanced security tasks, ovvero le attività che richiesto l’assistenza da parte di un Security Expert (tab.3);

 

No.

Security-focused story

Backlog task(s)

SAFECode Fundamental Practice(s)

CWE-ID

1

As a(n) architect/ developer, I want to ensure AND as QA, I want to verify allocation of resources within limits or throttling

Angel Clearly identify resources. A few examples:

  Number of simultaneous connections to an application on a web server from same user or from different users

  File size that can be uploaded

  Maximum number of files that can be uploaded to a file system folder

[A/D] Define limits on resource allocation.

[T] Conduct performance/stress testing to ensure that the numbers chosen are realistic ( i.e. backed by data ).

[A/D/T] Define and test system behavior for correctness when limits are exceeded. A few examples:

  Rejecting new connection requests

  Preventing simultaneous connection requests from the same user/IP, etc.

  Preventing users from uploading files greater than a specific size, e.g., 2 MB

  Archiving data in file upload folder when a specific limit is reached to prevent file system exhaustion

  Validate Input and Output to Mitigate

Common

Vulnerabilities

  Perform Fuzz/

Robustness

Testing

CWE-770

(CWE-ID: Common Weakness Enumerations http://cwe.mitre.org/)

Tabella 1

No.

Operational Security Task

Requirement/Recommendation

1

Configure bug tracking to track security vulnerabilities

Requirement for software development team

Tabella 2

No.

Security Experts to Help

Frequency of Help

1

Software security training (secure coding and secure testing)

Always

Tabella 3

In conclusione gli NFR vanno associati in modo stringente all’Intentional Architecture in modo da definire i “binari” entro cui sviluppare le caratteristiche specifiche, esattamente come accade per i Temi di Business (RF). La definizione di User Storie specifiche (tab.1) permette di definire con gli stakeholder (e non solo al Cliente!) un “accordo” su cosa si intende per singolo requisito, andando al di la della banalizzazione dello stesso. Fondamentale è, inoltre, l’utilizzo di best-practice che indirizzino il modo di operare del Team per soddisfare gli NFR (tab.2), affidandosi a opportuni Technical Specialist (tab.3) di supporto, sia nello sviluppo della User Story sia nelle pratiche operative.

 

water-SCRUM-fall

 

 

Quando ho pensato a un blog relativo al mondo Agile, ho pensato ad una serie di post correlati tra loro che ne evidenziassero l’applicazione pratica.

Fin ora abbiamo parlato abbondantemente di Architettura, Design e di come esse siano fondamentali anche nel mondo Agile. Ciò ci spinge ad affrontare in modo diretto quello che oggi in letteratura è riportato come il problema water-SCRUM-fall, termine derivato da una ricerca di Forrester intitolata “Water-Scrum-Fall Is The Reality Of Agile For Most Organizationsm Today”.

La ricerca mette in evidenza come la maggior parte delle aziende IT che utilizzano metodo Agili, adottano in realtà un approccio ibrido, in cui ad una specifica metodologia di sviluppo Agile (e qui Scrum la fa da padrone) vengono associate fasi, costrutti e cerimonie tipiche di approcci classici.

 

water-SCRUM-fall


In pratica Dave West (autore dell’analisi) identifica tre macro fasi nella produzione di una nuova soluzione IT:

·         Water-[Scrum-Fall] che definisce le attività iniziali necessarie allo sviluppo di una nuova soluzione IT (Upfront Work).

In un approccio Agile puro la fase più tradizionale di Analisi dei Requisiti / Architettura / Planning è ridotta al minimo indispensabile, tendenzialmente si cerca di eliminarla del tutto (ad esclusione di AM). E’ evidente come ciò, soprattutto in ambito enterprise, sia semplicemente improponibile poiché ad essa è associata la valutazione del Rischio e dell’Opportunità di realizzare il sistema stesso.

Chiaramente queste attività soffrono dei problemi tipici del modello a cascata, come la “non conoscenza” dei requisiti funzionali reali desiderati dagli stakeholder;

·         [Water]-Scrum-[Fall] definisce il Core delle attività di produzione, governando le attività di sviluppo del Sistema;

·         [Water-Scrum]-Fall: definisce le attività finali di gestione (produzione) del nuovo sistema e, aggiungo personalmente, la fase di dismissione del sistema stesso.

Fermo restando le release progressive tipiche delle iterazioni di sviluppo, la gestione del servizio in produzione è cosa ben diversa. Essa impatta su tutta una serie di procedure interne all’azienda ed è, tipicamente, gestita dal settore Erogazione/Sistemistico, storicamente molto più legato a procedure che si sono affermate nel corso degli anni e quindi tendenzialmente reticente al cambiamento.

Se si riflette sulla complessità che governa le moderne aziende IT e la mission del Manifesto Agile che è quello di definire dei valori e dei principi e non nuove metodologie, lo scenario descritto da West è assolutamente plausibile e non deve assolutamente far ritenere che Beck e soci abbiano fallito nel loro intento.

Anzi: oggi sono poche le realtà IT di rilievo in cui l’Agile è visto come qualcosa di estraneo (anche se in Italia la situazione è un po’ meno rosea) ma quasi tutte concordano sulla necessità di applicarlo in modo organico al contesto aziendale, sposandone la cultura ed i processi.

Per ora ci fermiamo qui. Nei prossimi post cominceremo a parlare del lavoro di Scott Ambler e Mark Lines che ha portato al framework Disciplined Agile Delivery (DaD), pensato proprio per l’utilizzo di Agile tenendo conto del water-SCRUM-fall.

 

Posted: 3 dic 2012 13:04 da felice.pescatore | con no comments
Inserito sotto: , ,