Per definire lo scope di un progetto si usano tools (strumenti), templates (modelli) e processi. L'elenco del corso è anche l'indice operativo di questo capitolo e del successivo:
«What your client wants may not be what your client needs. Your job is to make sure that what they want is what they need and that you will deliver what they need.»
Il compito non è quindi «dare al cliente ciò che chiede» né «dare al cliente ciò che secondo noi gli serve»: è far coincidere le due cose e poi consegnare ciò di cui ha bisogno. Per gestire le aspettative del committente è necessario:
Nella definizione dello scope è importante stabilire quali «condizioni» devono essere rispettate per garantirsi il successo del progetto. Le Conditions of Satisfaction (CoS) guidano la definizione dei requisiti e il processo decisionale durante tutto il ciclo di vita del progetto.
Le CoS non coincidono necessariamente con il goal e gli obiettivi del progetto: possono indicare ulteriori condizioni da garantire. Per esempio:
| Conditions of Satisfaction | Acceptance Criteria | |
|---|---|---|
| Che cosa sono | Un processo/documento per determinare «cosa» deve essere il risultato del progetto: in altre parole, quali sono gli obiettivi del progetto. | I fattori che permetteranno di determinare se il risultato del progetto può essere accettato o meno. Hanno impatto determinante sulle modalità di verifica/test della soluzione prodotta. |
| Chi li definisce in Scrum | Il Product Owner, quando presenta nuovi work item al team, per descrivere cosa il committente/utente vuole. | Il Dev Team, che definisce i criteri di accettazione e i relativi test, basandosi sulle CoS e sulle user story definite. |
La distinzione ricalca ancora una volta il confine cosa / come del capitolo 2: le CoS dicono cosa deve risultare, i criteri di accettazione dicono come faremo a dire che è stato fatto. Chi le confonde finisce per far scrivere i test a chi ha espresso il desiderio, oppure per far decidere il risultato a chi scrive i test.
Il project scoping meeting costituisce la prima occasione concreta per incontrare il committente e iniziare a delineare lo scope del progetto.
| Voce | Contenuto |
|---|---|
| Purpose | Documentare i requisiti (RBS) e produrre il Project Overview Statement (POS). |
| Attendees | Project Manager · Client Group · Core Team Members · il Facilitatore e il «Technographer». |
| Deliverables | CoS · Requirements Document (RBS) · best-fit project management life cycle (modello PMLC) · POS. |
Il project scoping meeting può durare anche molte giornate, e può quindi essere costituito da numerose sessioni anche distanti nel tempo. «Riunione» qui non significa un'ora in sala: significa un processo con un'agenda ripetibile.
Le definizioni sono quelle già incontrate nel capitolo 4, e qui vengono usate operativamente. Quella IEEE Std 610.12 distingue tre piani: (A) una condizione o capacità necessaria a un utente per risolvere un problema o raggiungere un obiettivo — il piano dello scope; (B) una condizione o capacità che deve essere posseduta da un sistema per soddisfare un contratto, uno standard, una specifica — il piano della solution; (C) la rappresentazione documentata di (A) e (B).
Quella di Wysocki è più stretta e più utile in fase di scoping: un requisito è uno stato finale desiderato la cui integrazione con successo nella soluzione fornisce all'organizzazione del committente un aumento specifico e misurabile di business value.
| Categoria | Che cosa specifica |
|---|---|
| Functional Requirements | Specificano cosa il prodotto/servizio deve fare. |
| Non-Functional Requirements | Mostrano le proprietà che il prodotto/servizio dovrebbe avere per poter fare ciò che deve essere fatto. |
| Global Requirements | Descrivono i requisiti di più alto livello tra quelli inclusi nel prodotto/servizio; possono essere visti come requisiti generali. |
| Product/Project Constraints | Requisiti che, in superficie, sono assimilabili ai vincoli di progettazione o ai vincoli di progetto. |
Ogni metodo di requirements gathering ha i propri punti di forza e i propri rischi. Nessuno domina gli altri: la scelta dipende dal contesto, e spesso se ne combinano più d'uno.
Strengths. Eventuali problemi vengono risolti con l'aiuto di un facilitatore imparziale; i requisiti vengono immediatamente dettagliati, documentati e verificati; approccio eccellente per i processi inter-funzionali (cross-functional).
Risks. Un facilitatore inesperto potrebbe condurre a risposte negative; il tempo e i costi richiesti per la pianificazione e l'esecuzione potrebbero essere alti.
Strengths. Partecipazione degli utenti finali; descrizione ad alto livello delle funzioni e dei processi forniti.
Risks. Se non si stabilisce una «buona» struttura dell'intervista, gli stakeholder potrebbero non sapere quali informazioni fornire; se l'analista è prevenuto, potrebbero essere ignorati i veri bisogni del committente; le descrizioni possono differire dalle effettive attività, in particolare nei dettagli.
Strengths. Consente descrizioni delle attività/processi osservati molto specifiche e complete; molto efficace quando le attività di routine sono difficili da descrivere.
Risks. Osservare e documentare, anche con filmati, può essere molto dispendioso in tempi e costi, e può implicare problemi di carattere legale e sindacale; informazioni confuse o in conflitto possono richiedere ulteriori approfondimenti; ciò che è osservato può essere male interpretato.
Strengths. I requisiti possono essere generati e rifiniti velocemente; le attività ridondanti di raccolta si riducono; la soddisfazione del committente può essere rafforzata dalla precedente esperienza positiva; aumento della qualità; si minimizzano le occasioni in cui si deve «reinventare la ruota».
Risks. Investimenti significativi per realizzare e mantenere archivi e librerie; può essere violato il diritto d'autore di chi ha sviluppato in passato; le similitudini con altre funzionalità potrebbero essere male interpretate o «forzare» il riutilizzo.
Strengths. Eccellente per i processi inter-funzionali; utilizza la comunicazione visuale; verifica efficace del «what is / what is not».
Risks. L'implementazione dei miglioramenti proposti dipende dall'apertura al cambiamento dell'organizzazione del committente; richiede un buon supporto di facilitatori ed esperti e una buona abilità nella raccolta e interpretazione delle richieste; dispendioso in termini di tempo.
Strengths. Possono essere generate idee innovative; gli utenti possono chiarire cosa vogliono e identificare requisiti che potevano essere ignorati; approccio focalizzato sul committente; verifica anticipata e veloce della fattibilità; stimola il processo mentale.
Risks. Il committente potrebbe volere l'implementazione del prototipo; risulta difficile decidere quando fermarsi; richiede skill specializzati; assenza di documentazione.
Strengths. Lo stato del sistema è descritto prima che il committente interagisca con il sistema, e usando l'insieme completo dei possibili scenari; il normale flusso degli eventi e delle eccezioni è rivelato facilmente; si migliorano soddisfazione del committente e design.
Risks. Le novità potrebbero portare a incongruenze; alcune informazioni potrebbero essere ignorate dalla descrizione degli scenari; potrebbe richiedere lunghe interazioni con il committente; formazione costosa (si veda l'esempio di UML).
Una situazione alla volta: scegli il metodo il cui punto di forza risponde esattamente al problema.
La Requirements Breakdown Structure è la decomposizione gerarchica dei requisiti, dal goal fino alle feature.
Gli ultimi due vantaggi sono la stessa cosa vista da due lati: la RBS misura la propria incompletezza, e quella misura è il criterio per scegliere il modello di ciclo di vita. Se la RBS è completa si può andare Linear; se ha buchi ai livelli bassi, serve un approccio iterativo; se il gap è ampio, servono modelli più aggressivi.
Una volta scritta la RBS, i requisiti vanno passati al setaccio. Le domande da porsi sono quindici.
| Attributo | Domanda |
|---|---|
| Completeness | I requisiti sono completi o è stato dimenticato qualcosa? |
| Clarity | I requisiti sono chiari, oppure sono ambigui o imprecisi? |
| Validity | I requisiti riflettono le intenzioni del committente? |
| Measurability | Esiste un criterio per definire una misura di quanto ciascun requisito soddisfa le richieste? |
| Testability | Può essere definito un criterio per verificare se un requisito fornisce la soluzione necessaria? |
| Maintainability | L'implementazione sarà difficile o semplice da capire e manutenere? |
| Reliability | I requisiti di affidabilità e disponibilità possono essere soddisfatti? |
| Look and Feel | Tutti i fattori relativi alla percezione della soluzione da parte dell'utente sono stati soddisfatti (GUI, ergonomia)? |
| Feasibility | I requisiti possono essere implementati? |
| Precedent | I requisiti sono simili ad altri già implementati in passato? |
| Scale | I requisiti sono articolati e complessi? |
| Stability | Quanto spesso e di quanto i requisiti possono cambiare? |
| Performance | Le prestazioni possono essere soddisfacenti su una base costante? |
| Specifications | La documentazione prodotta è adeguata a supportare progettazione, implementazione e test? |
| Safety | I requisiti di sicurezza possono essere pienamente dimostrati? |
Spunta gli attributi che il tuo insieme di requisiti soddisfa davvero. Il punteggio è un termometro, non un voto.
Perché i requisiti sono difficili? Il corso elenca nove ragioni, ed è un elenco che vale la pena rileggere ogni volta che un progetto sembra «semplice».
Il punto 5 è quello che la definizione di Wysocki attacca alla radice: se «requisito» è solo ciò che porta un aumento specifico e misurabile di business value, il numero non può diventare ingestibile — ne restano 6–8. Tutto il resto scende di livello nella RBS e diventa function, sub-function o feature.
Le user story devono catturare gli elementi essenziali di un requisito rispondendo a tre domande: Who it is for? — What it expects from the system? — Why it is important?
| Elemento | Regole |
|---|---|
| Role | L'utente che interagisce con il sistema. Bisognerebbe essere molto specifici nell'identificarlo. Il team di sviluppo non è un utente. |
| Action | L'azione del sistema richiesta dall'utente. Solitamente si specifica una sola azione per ogni user story; il «sistema» è sempre protagonista implicito; si suggerisce di usare la forma attiva e non quella passiva. |
| Benefits | Uno o più benefici concreti forniti dalla user story. Molte user story potrebbero condividere lo stesso beneficio; il beneficio potrebbe essere destinato a utenti o stakeholder diversi dal protagonista della storia. |
Oltre alle user story si definiscono — su definizioni che, avverte il corso, sono oggetto di dibattito — anche:
Che il dibattito sia vivo lo mostra il caso di Marcel Britsch, citato a lezione: dopo aver pubblicato la sua tassonomia di epic, story, theme e feature, l'ha rimessa in discussione in un secondo articolo, scrivendo che «in my world we have a structure a little bit like this, but keep in mind, that dependent on the scale of your «problem» you may want more levels». La struttura non è un dogma: dipende dalla scala del problema.
Come per la RBS, anche per le user story da inserire nel backlog vanno applicati criteri che supportino il processo. Oltre a quanto già visto per la RBS, che rimane valido, si possono adottare principi pensati apposta. L'esempio più interessante è INVEST:
| Lettera | Criterio |
|---|---|
| I | Independent — user story indipendenti si pianificano più facilmente. |
| N | Negotiable — non devono essere vincolate da specifiche stringenti. |
| V | Valuable — deve fornire valore, possibilmente incrementale. |
| E | Estimable — può essere facilmente stimabile. |
| S | Small — abbastanza piccola da essere completata in una iterazione. |
| T | Testable — deve essere testabile. |
Compila i tre campi e spunta i criteri che ritieni soddisfatti.
Negli approcci agile due concetti sono molto importanti e vanno tenuti distinti.
| Definition of done | Acceptance criteria | |
|---|---|---|
| Che cos'è | Una lista di condizioni usate per definire quando possiamo considerare complete le user story. | Criteri specifici per ogni user story. |
| Quando si definisce | All'inizio del progetto, per ciascuna tipologia di user story; cambia raramente. | All'inizio di ogni iterazione (per esempio lo sprint), ma può cambiare durante lo sviluppo, mentre si definisce quale dovrà essere il risultato finale. |
| Che cosa certifica | Quando le condizioni sono soddisfatte, la user story è completa al 100%. | Quando i criteri sono soddisfatti, il risultato della user story è funzionante («working software»). |
Il corso propone un esempio trovato sul web, con il backlog di un sito di birre: automatic beer selection for the party, choose new beer to taste, order favorite beers again, recommend expensive beers. Il pattern usato per descrivere ogni storia è: Name (nome), Def. (definizione), CoS (le corrispondenti Conditions of Satisfaction).
| Name | Def. | CoS |
|---|---|---|
| Automatic selection | As Jon (busy manager with no time), I want to get beers selected by «Beerer», so that I can impress my friends by variety of rare brands. | Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world. |
| New beers to taste | As Jon I want to see beer catalog so I can choose the some new one to taste. | Jon can see different tastes directly from the catalog page and don't have to go into beer details. |
| Favorite beer order | As returning customer I want to see my favorite beers, so I can order them again. | (lasciata vuota — le conditions of satisfaction sono opzionali). Siete d'accordo? |
| Recommend expensive beers | As Store Owner I want «Berrer» recommend expensive beers, so we increase our profit. | Customers are not feeling under the pressure to spend too much. |
La prima: nella terza storia le CoS sono lasciate vuote perché «opzionali» — siete d'accordo? La seconda, più generale: quando pensate sia opportuno formulare le CoS, prima o dopo la definizione delle user story? Notate che la quarta storia è illuminante: il role è lo Store Owner e il beneficio è il profitto del negozio, ma le CoS proteggono il cliente — cioè uno stakeholder diverso dal protagonista.
«What your client wants may not be what your client needs. Your job is to make sure that what they want is what they need and that you will deliver what they need.» Non si tratta né di eseguire alla lettera né di decidere al posto del cliente: si tratta di far coincidere desiderio e bisogno e poi consegnare il bisogno. Gli strumenti: comprendere correttamente desideri e aspettative, assicurarsi che il cliente abbia capito il deliverable, mettersi nei suoi panni, assegnargli un ruolo attivo nello scoping, coinvolgerlo in modo significativo, tenerlo informato e definire con precisione as-is, to-be e nice-to-have.
Sono le condizioni che devono essere rispettate per garantirsi il successo del progetto; guidano la definizione dei requisiti e il processo decisionale durante tutto il ciclo di vita. Si sviluppano con un ciclo iterato tra request e response, passando per clarify request e agree on response, e si chiudono negoziando l'accordo e scrivendo il POS. Non coincidono necessariamente con goal e obiettivi: possono aggiungere condizioni come una data di completamento, il rispetto di un budget, l'uso di una nuova tecnologia, l'attenzione alla UX, uno standard di qualità, o performance in termini di tempi di risposta.
Le CoS determinano «cosa» deve essere il risultato del progetto, cioè gli obiettivi; in Scrum le definisce il Product Owner presentando i work item al team. Gli Acceptance Criteria riguardano i fattori che determinano se il risultato può essere accettato o meno, e hanno impatto determinante sulle modalità di verifica e test; in Scrum li definisce il Dev Team, basandosi sulle CoS e sulle user story.
Partecipano Project Manager, Client Group, Core Team Members, il facilitatore e il technographer. I deliverable sono quattro: le CoS, il Requirements Document (RBS), il best-fit PMLC model e il POS. Il meeting può durare molte giornate ed essere costituito da più sessioni anche distanti nel tempo.
Il facilitatore conduce lo scopo del meeting e la definizione/documentazione dei requisiti. Il rappresentante del committente descrive lo stato corrente, il problema o la business opportunity, e lo stato finale desiderato. Il project manager conduce la discussione del gap tra stato corrente e stato finale e la scelta del modello PMLC più adatto a chiuderlo. La bozza e l'approvazione del POS coinvolgono l'intero scope planning group.
Facilitated Group Session, Interviews, Observation, Requirements Reuse, Business Process Diagramming, Prototyping, Use Cases. Ciascuno ha punti di forza e rischi: per esempio l'osservazione dà descrizioni molto specifiche ed è efficace quando le attività di routine sono difficili da descrivere, ma è dispendiosa, può implicare problemi legali e sindacali, e ciò che si osserva può essere male interpretato.
Che il committente voglia l'implementazione del prototipo. Gli altri rischi: è difficile decidere quando fermarsi; richiede skill specializzati; produce assenza di documentazione. In compenso genera idee innovative, aiuta gli utenti a chiarire cosa vogliono e a identificare requisiti che sarebbero stati ignorati, è focalizzato sul committente e consente una verifica anticipata e veloce della fattibilità.
Dall'alto: project goal and solution → requirement → function → sub-function → feature, con numerazione gerarchica (1.2.1.3 e simili). La RBS è consistente con le indicazioni PMBOK, è un approccio deliverables-based, è intuitiva e significativa per il committente, consente di mantenere il contatto con lui durante la pianificazione, e potrebbe rappresentare la descrizione di più alto livello della WBS.
Perché rappresenta con estrema accuratezza «quanto» la soluzione è definita con chiarezza: la sua completezza è la misura diretta dell'incertezza sulla soluzione, che è esattamente la variabile su cui si ordinano i cinque modelli PMLC. Una RBS completa consente approcci lineari o incrementali; buchi ai livelli bassi suggeriscono approcci iterativi; un gap ampio richiede modelli più aggressivi.
Completeness, Clarity, Validity, Measurability, Testability, Maintainability, Reliability, Look and Feel, Feasibility, Precedent, Scale, Stability, Performance, Specifications, Safety. Le prime cinque riguardano la qualità della definizione; le altre riguardano ciò che il requisito comporterà in implementazione ed esercizio.
Deve catturare who it is for, what it expects from the system, why it is important — cioè Role, Action, Benefit. Il ruolo va identificato in modo molto specifico e il team di sviluppo non è un utente; si specifica di norma una sola azione, in forma attiva, con il sistema come protagonista implicito; il beneficio può essere condiviso da più storie e può riguardare stakeholder diversi dal protagonista. INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
La definition of done è una lista di condizioni definite all'inizio del progetto per ciascuna tipologia di user story, che cambiano raramente: quando sono soddisfatte la user story è completa al 100%. Gli acceptance criteria sono specifici per ogni user story, definiti all'inizio di ogni iterazione e possono cambiare durante lo sviluppo: quando sono soddisfatti il risultato è «working software».
Un epic è una user story troppo grande per essere completata in uno sprint, che va suddivisa in più user story; un theme/feature è un insieme di user story correlate, per esempio perché costituiscono una funzionalità o un componente. Le definizioni sono oggetto di dibattito: il corso porta il caso di Marcel Britsch, che ha rimesso in discussione la propria tassonomia precedente osservando che, a seconda della scala del problema, si possono volere più livelli.