← Ultimi articoli
💻 computer science

A Capacity-Aware Parr Model for Agile Projects

Questo articolo propone un rifacimento del modello classico di Parr orientato alla capacità che integra la domanda di sforzo latente normalizzata con le traiettorie di capacità osservate o pianificate per prevedere il progresso dei progetti agile, i tempi di completamento e i deficit di risorse senza assumere una dotazione di personale illimitata.

Autori originali: Pedro E. Colla

Pubblicato 2026-07-03
📖 4 min di lettura☕ Lettura da pausa caffè

Autori originali: Pedro E. Colla

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di pianificare un lungo viaggio su strada. Hai una mappa che mostra esattamente quanto carburante dovresti consumare in ogni fase del viaggio per arrivare a destinazione in tempo. Questo è ciò che fanno i modelli software tradizionali: disegnano una curva dicendo: "Per completare questo progetto, hai bisogno di un team enorme nel mezzo, meno persone all'inizio e meno persone alla fine".

Ma ecco il problema nel mondo reale (specialmente nei team software "Agile"): non puoi assumere chiunque tu voglia, quando vuoi. La tua azienda ha un team fisso di cinque persone. Magari possono lavorare solo 40 ore a settimana. La mappa tradizionale dice: "Ti servono 20 persone il mese prossimo!" ma il tuo capo dice: "No, ne hai solo cinque".

Questo articolo propone un nuovo modo di guardare quella mappa. Invece di trattare la curva come una regola rigida per le assunzioni, la tratta come una fame nascosta di lavoro.

L'idea Centrale: La "Fame" vs Il "Frigorifero"

L'autore, Pedro Colla, suggerisce di separare due cose:

  1. La Fame (Domanda Latente): Questa è la "Curva di Parr". Rappresenta quanto lavoro il progetto vuole naturalmente completare in un dato momento. È come uno stomaco che ha molta fame a metà giornata e meno fame al mattino e alla sera.
  2. Il Frigorifero (Capacità): Questo è ciò che hai effettivamente a disposizione. Magari hai solo un panino (5 persone) quando lo stomaco vuole un bue (20 persone).

Il Vecchio Modo: I vecchi modelli assumevano che se la curva diceva che avevi bisogno di un bue, dovevi avere un bue, o il progetto falliva. Cercavano di forzare la dimensione del team per adattarsi alla curva.

Il Nuovo Modo (Questo Articolo): Il nuovo modello dice: "Ok, il progetto ha fame di un bione, ma noi abbiamo solo un panino. Mangeremo il panino. Faremo tutto il possibile che il panino ci permette di fare, ma non faremo finta di aver mangiato il bue".

Come Funziona in Parole Semplili

Il modello utilizza una semplice formula matematica per tracciare questa "fame". Pone tre domande:

  1. Quanto è grande l'intero pasto? (Sforzo totale necessario).
  2. Che aspetto ha la curva della fame? (Quando è solitamente più intenso il lavoro del progetto?).
  3. Cosa c'è nel frigorifero oggi? (Quante persone sono effettivamente disponibili questa settimana?).

Il modello calcola quindi:

  • Progresso: Quanto del pasto abbiamo effettivamente mangiato questa settimana?
  • Il Gap: Abbiamo avuto un "deficit di capacità" (avevamo fame ma non avevamo cibo)?
  • Lo Slack (Eccedenza): Avevamo del cibo in eccesso nel frigorifero che non avevamo bisogno di mangiare?

L'Analogia della "Previsione Continua"

Immagina di guidare e controllare il tuo GPS.

  • Vecchio GPS: "Devi guidare a 100 mph per arrivare alle 17:00". (Ignora il traffico o i limiti di velocità).
  • Questo Modello: "Vuoi guidare a 100 mph per arrivare alle 17:00, ma il limite di velocità è 60. Quindi, arriverai più tardi. Ricalcoliamo il tuo orario di arrivo basandoci sui 60 mph".

L'articolo testa questa idea utilizzando i dati di un vero progetto software (un team di 5-8 persone che lavora per 22 settimane). Dividono i dati a metà:

  1. Calibrazione: Hanno usato la prima metà del viaggio per tarare la "curva della fame" per adattarla a quel team specifico.
  2. Predizione: Hanno usato la seconda metà per vedere se il modello poteva prevedere il futuro basandosi solo sulla dimensione effettiva del team, senza sbirciare i risultati finali.

Cosa Hanno Trovato (e Cosa Non Hanno Trovato)

L'articolo è molto onesto su ciò che ha ottenuto:

  • Funziona internamente: Il modello ha tracciato con successo i progressi del team e ha identificato quando stavano "morendo di fame" (mancanza di persone) o avevano "avanzi" (capacità extra).
  • È semplice: Non cerca di spiegare il perché il team sia lento (come la cattiva comunicazione o i bug). Misura semplicemente il divario tra ciò di cui il progetto ha bisogno e ciò che il team può fare.
  • Non è una palla di cristallo magica: Gli autori ammettono di averlo testato solo su un progetto. Non possono affermare che funzionerà per ogni azienda al mondo ancora; devono testarlo su molti più progetti per dimostrare che è una regola universale.

Il Punto Fondamentale

Questo articolo non inventa un nuovo modo per costruire software. Inventa invece una migliore dashboard per i manager.

Smette di dire ai manager: "Devi assumere 20 persone!" e inizia a dire loro: "Il progetto ha fame di 20 persone, ma tu ne hai solo 5. Ecco esattamente quanto rallenterà il progetto, ed ecco esattamente quando finirai se mantieni la dimensione del team a 5".

Trasforma una curva matematica rigida in uno strumento flessibile che rispetta la realtà delle risorse limitate.

Sommerso dagli articoli nel tuo campo?

Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.

Prova Digest →