La WBS è una descrizione gerarchica di tutto il lavoro (cioè l'insieme delle attività) che deve essere fatto nel progetto per soddisfare i bisogni del committente. In altri termini: la WBS descrive il lavoro che deve essere fatto per soddisfare la RBS.
Il legame con la RBS non è un dettaglio: la RBS è collegata direttamente con i criteri di successo definiti per giustificare il progetto. Se la WBS è ottenuta direttamente dalla RBS, possiamo ereditare anche il perseguimento dei criteri di successo — un risultato per niente scontato se la WBS è definita con un approccio alternativo.
La WBS ha quattro impieghi fondamentali:
| Impiego | Che cosa fa |
|---|---|
| Thought process tool | Rappresenta un processo mentale: aiuta il project manager e il team a visualizzare esattamente come il lavoro deve essere definito e gestito efficientemente. È un potente strumento per design e planning. |
| Architectural design tool | Rappresenta efficacemente come le diverse attività di progetto sono correlate tra loro. |
| Planning tool | Dà al team una rappresentazione dettagliata del progetto come insieme di attività da completare. Al livello di massimo dettaglio si possono fare le stime di effort, durata (elapsed time) e risorse. |
| Project status reporting tool | Serve a monitorare lo stato di completamento: man mano che le attività di più basso livello vengono completate, si risale a quelle di più alto livello. |
È la stessa struttura che serve a quattro scopi diversi: pensare il lavoro, progettarlo, pianificarlo e riportarne lo stato. Se la WBS è fatta bene, non se ne costruisce una diversa per ogni scopo.
Gli approcci per generare la WBS possono essere diversi, ma uno dei metodi più efficaci consiste nel convertire la RBS nella WBS:
Quando la WBS è completa si distingue tra activity e task, che finora abbiamo trattato come sinonimi. Il task è l'attività di massimo dettaglio individuata nella WBS, per la quale dobbiamo stimare tempi, costi e risorse necessarie.
Per convertire la RBS in WBS si possono usare due approcci:
La WBS si costruisce con lavagne, pennarelli e memo, consentendo a più persone di lavorare assieme in modo efficace (soluzioni software?). Gli aspetti operativi che il corso sottolinea:
Le modifiche dello scope e della soluzione durante la pianificazione sono meno costose di quanto lo saranno in seguito. È la ragione per cui la JPPS e la WBS non possono essere saltate: è il momento in cui cambiare costa meno.
A seconda del livello di incertezza nello scope o nella soluzione si sceglie il modello PMLC più adatto (capitolo 4), e il modello scelto determina quanto completa deve essere la WBS:
| Modello PMLC | Che cosa significa per la WBS |
|---|---|
| Lineare o incrementale | La WBS deve essere necessariamente completa. |
| Iterativo | Funzioni e sotto-funzioni ben definite, ma alcuni aspetti di processi, attività e features non ancora: la WBS va raffinata a ogni iterazione fino a una definizione stabile. |
| Adattivo / più aggressivi | Maggiore incertezza: la WBS ha un gap più ampio che va colmato a ogni iterazione. |
| Approcci Agile | In alcuni approcci Agile non si parla esplicitamente di WBS. Come si fanno stime e pianificazione? Lo si vedrà nelle sezioni 13–14. |
Per determinare quando la WBS è completata si possono applicare sei criteri:
È stato separato dagli altri sei perché riguarda il giudizio del project manager:
In questi casi la WBS è ancora instabile e incompleta, ma al momento non si può ottenere nulla di meglio: servono modelli PMLC che permettano di gestire i cambiamenti.
Ci sono situazioni in cui la WBS può essere considerata completa anche se non tutti i criteri sono soddisfatti: progetti di breve durata, attività difficilmente stimabili, attività soggette a rischi elevati, alta varianza della durata prevista, ecc. L'importante è essere consapevoli che alcuni criteri non sono soddisfatti e che si è disposti ad accettare le eccezioni (e i rischi).
Tre attività mal costruite. Per ciascuna, seleziona i criteri (da 1 a 6) che ritieni violati, poi verifica. Un criterio può essere violato da più attività.
| Famiglia | Approcci |
|---|---|
| Noun-type | Physical components; Functional components. |
| Verb-type | Design-build-test-implement; Objectives. |
| Organizational | Geographic; Departmental; Business process. |
L'esempio «Indented Outline WBS for a House» del corso mostra la stessa struttura in forma di elenco indentato:
Il corso mostra anche una WBS per una metodologia di sviluppo waterfall (Systems Development Project): la radice si divide in Definition (state objectives, clarify request, define requirements, choose SDM, get approval), Design (functional, technical) e Implementation (programming, documentation, installation, testing, training, cut-over, operation, review/audit). È la dimostrazione che la WBS si adatta alla metodologia scelta.
L'uso di template nella costruzione della WBS è raccomandato:
L'uso di template è molto efficace per progetti ricorrenti, come: distribuire una nuova release di un software; installare una rete in uffici; aggiornare un'applicazione con nuove funzionalità; aggiornare o creare materiale per il training.
Prima di stimare bisogna distinguere due quantità che spesso si confondono: elapsed time (la durata) ed effort / labor (la quantità di lavoro). Il corso le mette a confronto con un grafico:
Facciamo due conti: con 8 ore di lavoro a efficienza 75% la durata è 8 / 0,75 ≈ 10,7 ore. Se su quel tempo di clock cadono anche interruzioni non pianificate per il 33%, la durata sale a 10,7 / 0,67 ≈ 16 ore. È questo che il modello vuole rendere evidente: stimare la durata «a lavoro pieno» è un errore sistematico.
Si deve stimare la durata o la quantità di lavoro associata a ciascun task? La risposta del corso è: entrambe, perché servono a cose diverse:
La durata di un task dipende dalla quantità di lavoro e dalle risorse assegnate, ma la relazione non è lineare: raddoppiare le persone non dimezza la durata. Inoltre, durante la stima, entrambe le stime vanno svolte con la stessa metodologia. E gli approcci come Scrum si focalizzano sulla stima della quantità di lavoro — perché è il parametro usato per selezionare le user story di ogni sprint (lo vediamo nella sezione 13).
Il corso illustra la non-linearità con un esempio semplice: portare una sedia fuori dalla porta. Da soli, i passi si incatenano (prendere la sedia, portarla alla porta, appoggiarla, aprire la porta, tenerla aperta con un piede, riprendere la sedia, portarla fuori, posizionarla nel corridoio). Con quattro persone il lavoro si ridistribuisce e la sequenza cambia.
Trascina il cursore sul numero di persone del team: i passi del task si ridistribuiscono e la durata cambia — ma il lavoro totale, in fondo, resta quello.
La durata di un task può variare per diverse ragioni: diversi livelli di esperienza e competenza; eventi inattesi; uso non efficiente del tempo di lavoro; errori e fraintendimenti; e il fatto che tutti i processi hanno una durata variabile per cause comuni.
La stima della durata di un task può essere effettuata con uno dei seguenti metodi:
Questi approcci possono essere usati per stimare anche altre «quantità»: effort, risorse umane, ecc. Il metodo non appartiene alla grandezza stimata, ma alla situazione di stima.
Il metodo Delphi è stato sviluppato dalla Project RAND tra gli anni '50 e '60 da Olaf Helmer, Norman Dalkey e Nicholas Rescher. Richiede a un gruppo di esperti di effettuare le stime in due o più round: a ogni round un facilitatore fornisce un sommario delle stime accompagnate dalle motivazioni (in origine gli autori erano anonimi); ogni esperto è incoraggiato a rivedere la propria stima. Il gap tra le stime dovrebbe ridursi e le stime convergere. Il processo termina al numero massimo di round, al consenso unanime o alla stabilizzazione del risultato; la media o la mediana delle stime rappresentano il valore finale.
La Three-Point Method combina tre stime — O (Optimistic), M (Most Likely), P (Pessimistic) — nella formula:
Inserisci le tre stime (in giorni) e osserva E. Il widget applica la formula del corso: E = (O + 4M + P) / 6.
Negli approcci Agile sono proposte diverse tecniche di stima consensus-based; in metodologie come SCRUM spesso si usa il planning poker.
Nella metodologia SCRUM i requisiti (funzionali e non) sono definiti in termini di user story, inserite in un Product Backlog. A ogni iterazione di durata prefissata — lo sprint — si selezionano le user story da implementare, tenendo conto del carico di lavoro e delle risorse disponibili.
La stima non è fatta sul carico di lavoro in termini di giorni/uomo: si stima la complessità di sviluppo (development complexity) delle user story, misurata in story point. Gli story point sono adimensionali — e negli approcci agile sono preferiti a misure legate a tempo e spazio. I membri del team assegnano gli story point basandosi su esperienza e conoscenza del dominio.
I metodi di stima usati in Scrum (come il planning poker) devono stabilire come quantificare gli story point: valori numerici (es. la sequenza di Fibonacci: 1, 2, 3, 5, 8, 13, 21…) o non numerici (es. taglie delle T-shirt: XS, S, M, L, XL, XXL). L'uso degli story point è favorito dalla necessità di pianificare ogni sprint di durata prestabilita, selezionando il sottoinsieme di user story da mettere in produzione usando gli story point disponibili nello sprint.
Sei user story in ordine di complessità. Prima stima ogni story in story point (sequenza di Fibonacci), poi seleziona le story da mettere in uno sprint da 20 punti.
In letteratura sono proposti anche altri metodi per misurare il carico di lavoro:
Tra le tante tecniche, il corso cita la Pomodoro Technique, proposta originariamente da Francesco Cirillo. L'idea di base interessante è combinare il metodo di «gestione del tempo» con il metodo di «misura del tempo»: blocchi di 25 minuti (pomodoro session) in cui si lavora senza interruzioni e distrazioni, intervallati da pause di 5 minuti (o più lunghe dopo un certo numero di blocchi). Il vantaggio immediato è aumentare la produttività dando riferimenti precisi allo sviluppatore; e se il tempo è gestito correttamente, è ragionevole misurare il tempo con il numero di sessioni (pomodori) necessarie.
Notate la logica: la Pomodoro rende l'unità di misura coerente con il modo di lavorare. È lo stesso principio degli story point — l'unità di misura nasce dal metodo, non viceversa.
Chiudiamo con l'immagine con cui il corso chiude la parte sulle stime: anche le stime hanno un ciclo di vita. Man mano che il progetto avanza, la conoscenza cresce e il range di incertezza si restringe — fino a diventare, a progetto finito, il valore reale.
È la frase che il corso mette sotto il grafico del ciclo di vita delle stime: domani saprai più di oggi, quindi le stime vanno riviste quando la conoscenza cresce — non difese per coerenza. Questo è anche il fondamento della pianificazione iterativa dei modelli non lineari.
La WBS è una descrizione gerarchica di tutto il lavoro che deve essere fatto per soddisfare i bisogni del committente — cioè il lavoro che soddisfa la RBS. Se la WBS è ottenuta direttamente dalla RBS, si eredita anche il perseguimento dei criteri di successo, perché la RBS è collegata direttamente con i criteri di successo che giustificano il progetto.
Thought process tool (visualizzare come il lavoro va definito e gestito), architectural design tool (come le attività sono correlate), planning tool (base per le stime di effort, durata e risorse) e project status reporting tool (monitorare lo stato di completamento risalendo dai livelli più bassi).
La decomposizione si ferma quando si raggiunge un livello adeguato: l'attività è sufficientemente dettagliata per un'agevole stima di tempo, costi e risorse — senza eccedere, perché il lavoro di gestione diventerebbe eccessivo. Il task è l'attività di massimo dettaglio, quella per cui si stimano tempi, costi e risorse.
1) Stato e completamento misurabili (definizione del done); 2) attività ben delimitate (inizio e fine definiti); 3) ogni attività ha un deliverable; 4) tempi e costi facilmente stimabili; 5) durata entro un limite accettabile; 6) task senza interruzioni e lavoro definito in modo indipendente dagli altri task.
È di natura diversa: riguarda il giudizio del project manager. È soddisfatto quando il cliente non ha partecipato quanto atteso, il project manager ha una sensazione di disagio (non è convinto che sia tutto chiaro), o ritiene probabili modifiche anche rilevanti dello scope. In questi casi la WBS è ancora instabile e incompleta, e servono modelli PMLC che gestiscano i cambiamenti.
In progetti di breve durata, con attività difficilmente stimabili o soggette a rischi elevati, o con alta varianza della durata, la WBS può considerarsi completa anche se non tutti i criteri sono soddisfatti. L'importante è essere consapevoli delle eccezioni e accettare i rischi corrispondenti.
L'elapsed time (durata) è il tempo di calendario che il task occupa; l'effort (quantità di lavoro) è il lavoro effettivo richiesto. La durata serve per la schedula e le milestone; l'effort per i costi e l'assegnazione delle risorse. La relazione non è lineare, e il modello del corso assume efficienza al 75% e interruzioni non pianificate per il 33% del tempo di clock.
Un gruppo di esperti stima in due o più round; a ogni round un facilitatore fornisce il sommario delle stime con le motivazioni (autori anonimi), e ogni esperto rivede la propria stima. Le stime convergono; si termina per numero massimo di round, consenso unanime o stabilizzazione, e media o mediana danno la stima finale. Fu sviluppata alla Project RAND negli anni '50–'60 da Helmer, Dalkey e Rescher.
E = (O + 4M + P) / 6, dove O è la stima ottimistica, M la più probabile e P la pessimistica. Il «most likely» pesa quattro volte perché è il valore con più informazione; gli estremi O e P temperano il risultato. La wide-band Delphi combina il processo Delphi con la stima a tre punti.
Si stima la complessità di sviluppo in story point, valori adimensionali (sequenza di Fibonacci o taglie di T-shirt), invece dei giorni/uomo. Gli story point sono preferiti perché servono a pianificare sprint di durata prestabilita selezionando le story da mettere in produzione in base ai punti disponibili. Nel planning poker il team assegna i punti con un meccanismo consensus-based.
È la tecnica di Francesco Cirillo: blocchi di lavoro di 25 minuti senza interruzioni, intervallati da pause di 5 minuti. Combina gestione e misura del tempo: se il tempo è gestito correttamente in sessioni da 25 minuti, si può misurare il tempo in numero di pomodori. L'unità di misura nasce dal metodo di lavoro.
Che il range di incertezza delle stime si restringe man mano che la conoscenza cresce — «you will be smarter tomorrow than you are today». Le stime vanno quindi riviste quando si impara di più, e la pianificazione iterativa dei modelli non lineari si fonda proprio su questo.