Gestione del progetto triangolo di ferro e Agile

L'atto di bilanciamento definitivo e come raggiungere il nirvana della gestione dei progetti Agile

Tareq Aljaber Di Tareq Aljaber
Sfoglia tra gli argomenti

Tutti i progetti software Agile hanno degli obiettivi: ciò che il progetto deve fornire, quando deve essere consegnato e quali sono i limiti di budget. Tuttavia, la gestione di questi tre vincoli può comportare un atto di destrezza complesso. Quindi, prendiamo spunto dal pluridecennale triangolo di ferro della pianificazione e scopriamo in che modo il bilanciamento di diverse variabili può aiutare i team di software Agile a raggiungere il nirvana della gestione dei progetti Agile.

Il tradizionale triangolo di ferro

La gestione dei progetti tramite il triangolo di ferro presenta dei vincoli che sono considerati di "ferro" perché non è possibile modificarli senza influire sugli altri. Il triangolo di ferro originale per la gestione dei progetti, proposto dal dottor Martin Barnes nel 1969, segue un approccio a cascata allo sviluppo del prodotto: l'ambito è fisso e le risorse e il tempo sono variabili. Per un team software, questo significa avviare un progetto definendo i requisiti di prodotto per determinare l'ambito di un progetto (un elenco di elementi di lavoro). Le risorse e la programmazione sono variabili e vengono stimate in base all'ambito fisso.

Vincoli del triangolo di ferro
  • L'ambito è il lavoro da svolgere, ad esempio caratteristiche e funzionalità, per fornire un prodotto funzionante.
  • Le risorse includono budget e membri del team che operano in un'ottica di esecuzione e consegna.
  • Il tempo è il momento in cui i team effettueranno la consegna sul mercato di elementi come rilasci e milestone.

Lo scopo della gestione dei progetti tramite il triangolo di ferro è fornire ai team di prodotto le informazioni necessarie per adottare dei compromessi che aiuteranno il business. Ad esempio, se i team devono affrontare un ambito fisso, potrebbero trovarsi a metà di un progetto e rendersi conto che non rispetteranno la data di rilascio. Le uniche variabili con cui possono giostrare sono le seguenti: 1) Tempo: possono accettare una data di rilascio successiva oppure 2) Risorse: possono aggiungere altre persone al progetto, con conseguente aumento dei costi. Con l'evoluzione dello sviluppo del software nel 21° secolo, la necessità di una migliore collaborazione e la capacità di rispondere rapidamente al feedback dei clienti sono diventate cruciali ed è per questo che è nata la metodologia Agile.

Triangolo di ferro a cascata | Agile Coach Atlassian

Mappatura del triangolo di ferro alla metodologia Agile

Se il tuo team utilizza la gestione dei progetti a cascata o non ha familiarità con il nuovo sviluppo Agile, la cosa importante da ricordare è la differenza tra ciò che è fisso e ciò che è stimato. A differenza dello sviluppo a cascata, i progetti Agile hanno una programmazione e risorse fisse mentre l'ambito è variabile. Sebbene l'ambito di un progetto potrebbe cambiare nello sviluppo Agile, i team si impegnano a condurre iterazioni fisse del lavoro: sprint se si utilizza un framework Scrum, limiti WIP se si utilizza un framework Kanban. Si tratta anche di una best practice per mantenere i team fissi durante l'intero processo di sviluppo. Mantenendo la coerenza su un prodotto o un progetto, i team diventano più efficienti grazie alla fiducia e alla continuità che si sviluppano.

A cascata e Agile a confronto | Agile Coach Atlassian

L'idea di ambito è la stessa nello sviluppo Agile: quale software creare e fornire. Tuttavia, Agile si incentra sui requisiti generali invece di fornire subito requisiti approfonditi e dettagliati. L'ambito di un progetto viene regolarmente gestito e curato (in termini di priorità) dal product manager in uno strumento come Jira Software. Il product manager decide quale lavoro deve essere svolto nel prossimo sprint sulla base di feedback qualitativi e quantitativi Agile provenienti da vari canali (condizioni di mercato, feedback dei clienti, concorrenza e così via). Inoltre, poiché le risorse e il tempo sono fissi, è più facile per i team di sviluppo reagire ai cambiamenti del mercato e offrire valore aggiunto ai clienti. Questa trasparenza dei vincoli obbliga i team a rispettare in maniera trasparente una cadenza di rilascio costante e veloce, che è un tenant chiave dello sviluppo Agile; inoltre, esaminando i progetti attraverso il triangolo di ferro, i team sono in grado di adattarsi senza abbandonare un piano.

Gestione dei progetti con il triangolo di ferro e pianificazione Agile a lungo termine

Man mano che le dimensioni dei progetti aumentano, sono necessari più team e i tempi si allungano. Pertanto, fissare risorse e tempo, mentre l'ambito è variabile, non è un approccio valido per tutti i progetti Agile. La pianificazione Agile a lungo termine richiede un triangolo di ferro più flessibile che consenta ai team di pianificare in anticipo e garantisca il raggiungimento degli obiettivi aziendali. Pensa, ad esempio, al movimento di avvio Lean e alla nozione di un prodotto minimo funzionante (MVP). Un MVP è, per definizione, una piccola serie di funzioni (ambito) che offre valore al cliente. Per arrivare a quell'MVP, potrebbe essere necessario per i team attenersi a un ambito fisso, cioè il numero di funzioni, in cui il tempo è l'unica variabile (ad es. non puoi effettuare rilasci senza determinate funzioni, quindi la data di rilascio viene posticipata). Solo dopo aver lanciato l'MVP, i team passano a un ambito variabile.

Indipendentemente dalle differenze tra sviluppo a cascata e Agile, non esiste un modo giusto o sbagliato di utilizzare il triangolo di ferro. Questo strumento è a disposizione per aiutarti ad adottare le decisioni e i compromessi migliori per raggiungere i tuoi obiettivi di business. Uno strumento come Timeline visualizza gli elementi costitutivi di un piano (ambito, persone e tempo) per consentire ai team di pianificare in tempo reale. Puoi modificare facilmente l'ambito, i team e il tempo per pianificare il tuo prossimo rilascio di prodotto, utilizzando i dati esistenti del team in Jira Software.