Time-boxing, il controllo del tempo

0

Introduzione

«Sed fugit interea fugit irreparabile tempus», “Ma fugge intanto, fugge irreprabilmente il tempo” [Virgilio, Gerogiche, III, 284]. Il tempo è l’unica risorsa in natura a non essere accumulabile per poter essere utilizzata successivamente quando serve. Abbiamo imparato che i tre vincoli di un progetto software (e non solo software) – tempi, costi e ambito – condizionano i risultati.
Si è sempre assunto che l’ambito (i contenuti del progetto) fosse “inamovibile” per definizione e che la sfida fosse realizzare tali contenuti nei tempi richiesti e con il budget disponibile. Molti, troppi progetti falliscono tale obiettivo per motivi diversi. Una causa di tali fallimenti (ma non è la sola) è rappresentata dai requisiti poco chiari e instabili, incompleti, variabili nel tempo e, dunque, soggetti a cambiare durante il progetto. La sfida, questa volta, è di gestire tali cambiamenti, incertezze e indeterminazioni sentendo l’inesorabile avvicinarsi delle scadenze e l’impossibilità di attingere a risorse aggiuntive. Una vera frustrazione per i responsabili del progetto. Una sfida impossibile. Una partita persa in partenza.

Figura 1. Modello dei tre vincoli.

Figura 1. Modello dei tre vincoli.

Un secondo fattore di stress per gli addetti ai lavori è costituito dall’accelerazione impressa al business dalla competitività sempre crescente che richiede soluzioni innovative di maggiore qualità a costi più bassi e in tempi più brevi (Better, Chipper, Faster). Richieste spesso impossibili da soddisfare quanto irragionevoli da sottoporre.
I fornitori, stretti dalla morsa di bilanci magri, posti di lavoro da mantenere e ricavi da garantire, sono costretti ad accettare impegni difficili da mantenere. Anche i committenti, persone capaci e sicuramente competenti, chiedono ciò che sanno di non poter avere, rimandando la soluzione dei problemi al futuro, aspettando che i nodi giungano al fatidico pettine. Si accenderanno allora dispute surreali tra richieste concordate e impegni non mantenibili. Un gioco al massacro in cui tutti perdono e nessuno vince. Fissato l’ambito, dunque, e le sue possibili modifiche (cioè la “quantità” di lavoro da realizzare), è necessario agire sulle altre due variabili del sistema: tempi e costi. Ma anche queste sono inamovibili. I tempi sono dettati dal business e i costi rappresentano il maggiore fattore di competitività. Equazione irrisolvibile. A meno di un cambio di paradigma, di una diversa attribuzione della flessibilità dei vincoli.
Se, invece, è il tempo ad essere bloccato, occorrerà agire sui costi (cioè sul numero di risorse da impegnare) e, da questi, determinare l’ambito (i contenuti del prodotto). Si tratta, dunque, di fissare i tempi di rilascio e agire sull’ambito, cioè sui contenuti da sviluppare, una volta che siano definiti i costi dell’operazione, e quindi le dimensioni del gruppo di lavoro.
La tecnica, detta Timeboxing, sembra fornire una via d’uscita dalla situazione imbarazzante descritta prima. Elemento fondamentale dell’approccio Agile scrum, la tecnica si dimostra efficace e i risultati sono più che soddisfacenti.
Semplice nella sua formulazione, la tecnica risulta difficile da adottare in contesti poco flessibili e poco aperti al cambiamento. La proposta recita più o meno così: «pianificando rilasci periodici, per esempio mensili, con l’organizzazione disponbile (per esempio, di 10 persone), possiamo sviluppare i requisiti prioritari il cui impegno per lo sviluppo sia pari alla capacità produttiva del gruppo di lavoro (nel caso citato, pari a 200 giornate lavorative) ». Inoltre, ogni qualvolta ci sia bisogno di aggiungere un nuovo requisito, si rimuove uno di minore importanza per il business ma con lo stesso impegno necessario per la sua implementazione. Quanto rimosso può essere pianificato nel rilascio successivo o accantonato definitivamente. In tale gioco, l’impegno necessario per sviluppare la modifica richiesta equivale alla quantità di lavoro stimata per realizzare le funzionalità rimosse. Può succedere che parte di lavoro già svolto debba essere perso definitivamente. L’approccio, comunque, considera la gestione delle modifiche in corso d’opera una parte integrante del processo di sviluppo e non un disturbo al normale svolgimento del lavoro.
La problematica gestionale è dunque trasferita dallo sviluppo al business: stabilire quali requisiti abbiano maggiore rilevanza e debbano essere inclusi nel prossimo rilascio compatibilmente con la capacità produttiva del gruppo di lavoro. A quest’ultimo, invece, spetta stimare l’impegno richiesto per sviluppare ciascuna richiesta e garantire il rilascio di quanto pianificato entro la data stabilita per il rilascio.
Per gli utenti, spesso, tutti i requisiti hanno pari priorità ed urgenza. Nessuno può essere tralasciato o posticipato. Si capisce bene che ciò non è possibile con risorse limitate come generalmente ci troviamo ad operare.
La tecnica MoSCoW [Must, Should, Could, Won’t] può aiutare il business ad assegnare le giuste priorità ai requisiti.

Metodo Moscow

Detta anche MoSCoW Analysis (1), la tecnica è usata nell’analisi del business e nello sviluppo software per creare una comune comprensione tra tutte le parti interessate (stakeholder) sull’importanza da assegnare ai requisiti. Secondo quanto specificato in A Guide to BABOK (2), le categorie dei requisiti sono:
M-Must: descrive un requisito che deve essere assolutamente soddisfatto nella soluzione finale per poterla considerare di successo.
S-Should: rappresenta un elemento di priorità “alta” che dovrebbe essere incluso nella soluzione, se possibile. Esso costituisce spesso un requisito critico ma che può essere anche soddisfatto in maniera differente, se strettamente necessario.
C-Could: descrive un requisito considerato desiderabile ma non strettamente necessario. Esso sarà implementato se tempo e risorse lo permetteranno.
W-Won’t: (W-Wouldrappresenta un requisito che non deve essere sviluppato nel rilacio pianificato, ma che potrebbe essere preso in considerazione in futuro. In alternativa, il termine “Won’t” può essere sostituito da “Would” (”potrebbe”). Tutti i requisiti sono importanti ma sono sviluppati secondo l’ordine M, S e C.

Timeboxing

Nell’ambito della gestione del tempo, un “Time-box” rappresenta un periodo di tempo assegnato ad un’attività. La tecnica del Time-boxing è utilizzata nello sviluppo software dal responsabile del progetto per scomporre la schedulazione in rilasci successivi cui attribuire i requisiti da sviluppare. Ciascun periodo (Time-box) ha quindi la sua scadenza, il risultato da produrre e il proprio budget.

Alternativa all’ambito fisso

Nel campo del Project Management è noto il concetto dei tre vincoli: tempi, costi e ambito. (Prima i tre vincoli erano: tempi, costi e qualità). Modificare uno dei vincoli richiede rivedere gli altri due.
I progetti sono generalmente pianificati prevedendo l’ambito come variabile “fissa” e richiedendo a tempi e costi di adeguarsi di conseguenza. In realtà, anche la data di consegna è spesso imposta dal business ed i margini di manovra sui costi sono pressocchè nulli e blindati dal budget disponibile. Quando, ad esempio, una fase del progetto riscontra un ritardo occorre ritardare la data di consegna oppure aggiungere risororse, quando possibile, per recuperare. Spesso, in questi casi, a soffrirne maggiormente è la qualità del risultato prodotto. Il più delle volte, quindi, si ottiene un impatto negativo sui tre vincoli: ritardo nei tempi di consegna, aumento dei costi e qualità più bassa di quella attesa.

La tecnica Time-boxing fissa invece la data di consegna costringendo l’ambito a ridursi sulla base delle risorse disponibili e della relativa quantità di lavoro capace di produrre (Capacity). Ciò impone al business di focalizzarsi sulle cose più importanti da fare: i requisiti di priorità più alta, quelli identificati come “Must”. Time-boxing richiede quindi il coinvolgimento diretto del cliente (cioè dei rappresentanti del business) per assegnare le priorità e definire i contenuti del rilascio, utilizzando, per esempio, il metodo MoSCoW.

Gestione del rischio

La tecnica timeboxing può essere utilizzata anche come forma di Risk Management per identificare in maniera esplicita gli elementi della schedulazione (task, durata, impegno) che possono compromettere la riuscita del progetto ritardandone la fine.
I vincoli di tempo imposti al progetto sono un elemento di grande criticità e non devono essere mai cambiati senza effettuare l’analisi dei cammini critici. Ciò è imperativo per poter rispettare le scadenze.
I fattori di rischio che possono compromettere il rispetto di una scadenza sono generalmente identificati in:

  1. errori nelle stime e nella pianificazione;
  2. problemi legati al gruppo di lavoro;
  3. errata esecuzione del piano di lavoro;
  4. altre complicazioni nate a monte del progetto.

Tra queste ultime, in particolare, si possono annoverare i cambiamenti agli obiettivi del progetto o al suo ambito e/o lo scarso supporto del management.
Un errore nella pianificazione può essere generato, a sua volta, da una non corretta scomposizione del lavoro (WBS)(3) che induce una sottostima dell’impegno richiesto e quindi del tempo necessario per completare l’attività. I problemi relativi ai gruppi di lavoro, invece, possono essere generati da relazioni negative all’interno del team o con altri gruppi (problemi, ad esempio, possono nascere a causa di una comunicazione inefficace, di competenze non adeguate, di uno scarso impegno, di una mancanza di responsabilizzazione, di una carenza nella costruzione del gruppo di lavoro, da una gestione non efficace dei conflitti da parte del manager, e così via).
Per rispettare le date di consegna si può agire sui tre vincoli nel modo seguente:

  • Ridurre l’ambito: posticipare i requisiti di minore importanza o di minore impatto sul business (quelli cioè che gli utenti non richiederanno a gran voce quando sapranno che non sono stati sviluppati!);
  • Bloccare il tempo: la data di consegna rappresenta, in questo caso, il vincolo fisso non modificabile;
  • Aumentare i costi: aumentare le risorse per rispettare i tempi di consegna (sempre che si possa fare senza produrre ulteriore ritardo4).

Time-boxing nello sviluppo software

Molti progetti di sviluppo software adottano con successo la tecnica Time-boxing, specialmente quelli di dimensioni minori5. Tuttavia, è importante che le parti in gioco, cliente e fornitore, concordino nel ridurre l’ambito del progetto e non richiedano (implicitamente) l’abbassamento della qualità. Non ci sono, invece, evidenze di utilizzo della tecnica time-boxing in progetti di grandi dimensioni (6). Ufficialmente, le metodologie a me più note che utilizzano tale tecnica sono:

  • Dynamic Systems Development Method (DSDM); Extreme Programming (XP);
  • Srum (Agile);
  • Rapid Application Development (RAD);
  • Lean Software Development (LSD).

Dynamic Systems development Method (DSDM) è un framework consolidato per la gestione e lo sviluppo di progetti agili, nato per aiutare a rilasciare risultati di qualità in tempi brevi. Si concentra sugli obiettivi strategici e sullo sviluppo incrementale di benefici reali per il business tenendo sotto stretto controllo il tempo (Time-boxing), i costi, i rischi e la qualità.
Extrem Programming (XP) valorizza la comunicazione, la semplicità, il feedback e il coraggio. La pianificazione, in particolare, utilizza la tecnica Time-boxing per le iterazioni di 1, 2 o 3 settimane di durata. Il business effettua la valutazione delle user stories prima di ogni iterazione (7) e ne attribuisce le priorità.
Scrum è fortemente influenzato dai concetti di iterazione e dallo sviluppo iterativo in generale. Le unità di tempo, dette “Sprint”, rappresentano le unità di lavoro, tipicamente della durata di un massimo di quattro settimane (30 giorni). Nella terminologia corrente uno Sprint potrebbe corrispondere ad un rilascio mensile.
La tecnica Time-boxing è utilizzata anche per altre attività come, ad esempio, la riunione di pianifcazione iniziale (Sprint Planning), di controllo giornaliero dello stato delle attività (Daily Scrum), di valutazione finale dei contenuti del rilascio (Sprint Review) e di miglioramento del processo di sviluppo (Sprint Retrospective).
RAD utilizza lo sviluppo iterativo e quello prototipale. Secondo Steve Mc Connell, la tecnica Time-boxing di lunghezza 60-120 giorni è una best practice di RAD.

Figura 2. Modello di sviluppo agile (SCRUM).

Figura 2. Modello di sviluppo agile (SCRUM).

Lean Software development (LSD), una metodologia Kanban, utilizza la pianificazione di tipo “pull”, cioè spinta direttamente dalla domanda, e quindi dal business, in opposizione netta alla pianificazione di tipo “push” guidata dalla previsione della domanda (forecasting) (8).
Le metodologie di sviluppo agili spingono per un cambio di paradigma: da “plandriven” a “value-driven”. La qualità e il tempo sono variabili fisse spingendo per la massima flessibilità della variabile “ambito”: un vero terremoto nella cultura software! Rilasciare le funzionalità più importanti per il business il più presto possibile e con la qualità richiesta rappresenta il ritorno d’investimento più alto (ROI). Errori o mancanze nelle specifiche di dettaglio sono spesso il frutto di mancanza di tempo o di scarsa conoscenza del risultato finale da produrre. In molti progetti di sviluppo software risulta difficile, a volte anche impossibile, analizzare e definire con cura tutti i requisiti e le specifiche prima di iniziare la fase di costruzione. In questi casi, la tecnica Time-boxing rappresenta la soluzione ideale per quei progetti che hanno nei tempi di consegna la criticità maggiore unita a requisiti non definiti in maniera completa.

Gestione delle persone

La tecnica Time-boxing, per finire, può essere utilizzata anche dalle singole persone per pianificare le proprie attività. La scala dei tempi è ovviamente ridotta (si specificano ore invece che settimane) così come pure gli artefatti (un modulo invece di un componente software).
Il Time-boxing applicato alla gestione delle persone serve anche ad evitare tendenze verso inutili perfezionismi, non di rado riscontrabili nei progetti software in tecnici innamorati dei dettagli e delle proprie idee. Definendo la data di completamento di un’attività assegnata, la persona è spinta a produrre il risultato invece che a focalizzarsi sul perfezionare il deliverable. Si evita così di procastinare una consegna spingendo le persone, a volte, a far fronte agli impegi assunti attingendo alle proprie risorse di creatività e a focalizzarsi sui risultati.

Conclusioni

Gestire il tempo di un progetto si può. Fissata la variabile tempo (per esempio, fissando la data di conclusione del progetto) è possibile gestire i contenuti da realizzare (l’ambito del progetto) con le risorse a disposizione (budget asseganto). Il problema è solo culturale. Ogni organizzazione vorrebbe avere le mani libere e poter agire, fino all’ultimo momento, sulle tre variabili. Ma ciò non è possibile. Ed il numero di progetti che falliscono è altissimo. L’utilizzo della tecnica Timeboxing, elemento chiave del processo Scrum, all’interno delle metodologie agili, si è dimostrato vincente, aumentando la percentuale di progetti software completati con successo.
p12_orologio-astrologico

Note

  1. Introduzione del Modello MoSCoW da parte di Oracle UK Consulting.
  2. A Guide to the Business Analysis Body of Knowledge (BABOK), Version 2.0, 2012, International Institute on Business Analysis (IIBA).
  3. Work Breakdown Structure (WBS).
  4. Frederick P. Brooks Jr. (1995). The Mythical Man- Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). Addison-Wesley.
  5. Steve Mc Connell. (1986). Rapid Development: Taming Wild Software Schedules. Addison-Wesley.
  6. Capers Jones. (2010). Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies. Mc Graw-Hill.
  7. Kent Beck. (2000). Extreme Programming eXplained: Embrace Change. Addison-Wesley.
  8. Mary and Tom Poppendieck. (2010). Leading Lean Software Development: Results Are Not the Point. Addison- Wesley.

BIBlIOGRAFIA

  • Beck, Kent. (2000). Extreme Programming eXplained: Embrace Change. Addison-Wesley.
  • Brooks, Frederick P. Jr. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). Addison-Wesley.
  • Capers Jones. (2010). Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies. Mc Graw-Hill.
  • Mc Connell, Steve. (1986). Rapid Development: Taming Wild Software Schedules. Addison-Wesley.
  • Poppendieck, Mary and Tom. (2010). Leading Lean Software Development: Results Are Not the Point. Addison- Wesley.
  • Rubin, Kenneth S. (2013). Essential Scrum, A practical Guide To The Most Popular Agile Process. Pearson.

« Tempus fugit» [“time flies, time flies”]. The Time Control‒like many other issues closely related to the quality‒it is still seen as secondary constraint, subject to the project scope. This continues to cause serious problems in achieving the project objectives: on time delivery, cost containment and production of an acceptable quality level. Updated statistics speak for very high percentages of projects that do not reach the goals or achiving them only partially. Only a change of paradigm can reverse a situation so strongly compromised. The “Timeboxing” technique is particularly suited to play the lead role of the new paradigm. This article describes the technique that allows people to manage their own time and the project manager to manage the resources within the team. The resource “time”, so difficult to manage by itself, becomes an ally safe to proceed towards the success of projects releasing quality software on time.

ERCOLE COLONESE

Consulente, Socio AICQ-ci, membro del Comitato Qualità del software e dei servizi IT di AICQ.
ercole@colonese.it
Share.

Comments are closed.