Quando nasce la Metodologia Agile Project Management?
La gestione agile dei progetti è stata sviluppata nel 2001. Un piccolo gruppo di persone, stanche dell’approccio tradizionale alla gestione dei progetti di sviluppo software, ha progettato il Manifesto Agile. Si tratta di metodo migliorato per gestire l’avanzamento dei progetti software.
Cos’è l’agile nell’ “Agile Project Management”?
Agile Project Management è una metodologia che si basa su uno sviluppo iterativo, ovvero un approccio in cui il lavoro viene suddiviso in piccole parti da completare una alla volta. Questo metodo valorizza molto la comunicazione tra le persone e il feedback continuo, così da potersi adattare facilmente ai cambiamenti in corso d’opera. L’obiettivo principale è ottenere risultati concreti e utilizzabili sin dalle prime fasi del progetto.
In parole semplici, si tratta di un modo per gestire i progetti suddividendoli in fasi più piccole, che possono essere controllate e migliorate costantemente. Queste fasi prendono il nome di sprint, un termine usato in particolare nel framework Scrum, uno dei metodi più popolari dell’universo Agile.
Ogni sprint ha una durata breve – solitamente tra le due e le quattro settimane – e serve a sviluppare una parte specifica del progetto. Alla fine di ogni sprint, il team rilascia un piccolo “pezzo” del lavoro finito, che può essere testato e, se necessario, corretto subito.
Questo approccio permette di ridurre i rischi, perché eventuali problemi vengono individuati e risolti rapidamente, senza aspettare la fine del progetto. Inoltre, grazie ai rilasci frequenti, è possibile verificare passo dopo passo che tutto stia andando nella giusta direzione, aumentando così le probabilità di successo complessivo.
Perché Scrum è importante?
L’importanza di Scrum sta tutta nella sua filosofia di fondo: aiutare i team di sviluppo, in particolare quelli software, a collaborare in modo più efficace. Grazie a questo framework, i team riescono a lavorare in modo rapido, flessibile e di qualità, anche quando le condizioni cambiano, arrivano nuovi feedback o le richieste degli utenti si evolvono.
Scrum promuove un approccio basato sull’apprendimento continuo. I team sono incoraggiati ad auto-organizzarsi, a trovare insieme le soluzioni ai problemi e a riflettere sulle proprie esperienze – sia quelle positive che quelle negative. Questo processo di consapevolezza porta naturalmente a crescere, adattarsi e migliorarsi sprint dopo sprint.
In definitiva, Scrum non è solo un metodo di lavoro, ma una vera e propria cultura: quella del miglioramento continuo, della condivisione e della responsabilità collettiva.
Differenza tra Scrum e la gestione di progetti Agile
La metodologia Scrum è uno dei framework più noti e utilizzati all’interno del mondo dell’agile project management. Si basa su un ciclo continuo di lavoro suddiviso in sprint e momenti di revisione, con l’obiettivo di gestire i progetti in modo rapido, flessibile ed efficace.
Prima di tutto, però, è importante capire che la gestione agile dei progetti non è un semplice insieme di regole da seguire punto per punto. Al contrario, si tratta di un approccio mentale e operativo, un modo di pensare e lavorare. È una filosofia che mette al centro la collaborazione, l’adattabilità e la comunicazione continua.
Cercare di trasformare l’Agile in una procedura rigida, fatta solo di schemi fissi e regole da manuale, significa fraintendere la sua vera essenza. Agile non è sinonimo di documenti infiniti, lunghe catene di email o riunioni interminabili. Anzi, è proprio il contrario: si tratta di ridurre la burocrazia e di favorire il dialogo diretto, il confronto costante tra i membri del team e i clienti.
In sostanza, con Scrum e l’approccio Agile, si lavora meglio perché si comunica meglio. Le decisioni vengono prese rapidamente, le informazioni sono più chiare e i risultati arrivano in modo più efficiente.
Come funziona Scrum?
Una delle caratteristiche più interessanti di Scrum è che inizia dalla fine. Prima ancora di mettersi al lavoro, si parte da una domanda fondamentale:
“Come sarà usato il prodotto finale e quale problema aiuterà a risolvere per i clienti?”
Da questa visione nasce il primo passo operativo: la creazione del Product Backlog. Questo backlog è una lista di tutte le attività e le “storie utente” (cioè le funzionalità descritte dal punto di vista dell’utente) che servono per costruire il prodotto. Il backlog non nasce da solo: viene definito e aggiornato in modo collaborativo dallo Scrum Master, dal Product Owner e dagli stakeholder, ovvero tutte le persone interessate al progetto.
Una volta pronte le attività, i membri del team ricevono la lista aggiornata del backlog e decidono insieme chi farà cosa. Questo perché nella gestione agile, la responsabilità è condivisa, non centralizzata in una sola persona. Ognuno contribuisce alla buona riuscita del progetto, secondo le proprie competenze.
Durante il lavoro, il team passa ciclicamente attraverso tre fasi fondamentali: pianificazione, esecuzione e valutazione. Questo ciclo continuo permette di adattare il progetto anche in corso d’opera, fino a modificare – se necessario – la data di consegna finale, tutto per rispondere meglio ai bisogni reali del cliente.
Il segreto del successo in Scrum è proprio questo: collaborazione costante. Sia tra i membri del team che con tutte le parti coinvolte, così da poter prendere decisioni chiare, condivise e pienamente informate.
Agile Project Management: l’Organizzazione dei Ruoli
Per completare con successo un progetto seguendo l’approccio Agile, serve prima di tutto un team affiatato e collaborativo. In Agile, il lavoro di squadra è davvero al centro di tutto.
Una caratteristica fondamentale di questa metodologia è che i ruoli non sono rigidi o predefiniti come avviene nei modelli tradizionali. Non c’è una gerarchia stretta in cui il capo decide tutto. Al contrario, nell’organizzazione Agile, le responsabilità si distribuiscono in base alle competenze di ciascuno, non al titolo che si ha.
L’obiettivo del team non è quello di “fare bella figura” con il superiore, ma di creare valore reale per il cliente finale. Ogni decisione, ogni attività è orientata al risultato e alla soddisfazione di chi utilizzerà il prodotto o servizio.
Il modo di comunicare, inoltre, è molto diverso da quello classico. L’Agile promuove una comunicazione sia orizzontale che verticale, che significa che tutti possono contribuire con idee, osservazioni e suggerimenti, a prescindere dal loro ruolo. Questo include anche il cliente, che viene coinvolto regolarmente per dare feedback e aiutare il team a migliorare costantemente.
Insomma, si lavora insieme, si cresce insieme, e si decide insieme. È questo il cuore di un progetto Agile ben riuscito.
→ Qui puoi approfondire sul metodo Scrum
Il valore per il cliente e la gestione progetti agile
La metodologia Agile si fonda su una rete viva e dinamica di relazioni umane e professionali. Questa rete si evolve nel tempo, imparando costantemente, adattandosi ai cambiamenti e cogliendo le opportunità che emergono lungo il percorso. L’obiettivo? Generare nuovo valore per il cliente finale, ma anche ottimizzare tempi e metodi di lavoro all’interno dell’azienda.
Quando tutto questo viene fatto bene, il risultato è evidente: prodotti migliori, clienti più soddisfatti e un maggiore ritorno economico per l’azienda.
Uno degli aspetti più interessanti del metodo Agile è la sua capacità di bilanciare due dinamiche fondamentali:
-
Exploitation: ovvero lo sfruttamento efficiente delle risorse e delle conoscenze esistenti.
-
Exploration: la continua esplorazione di nuove idee, approcci e opportunità per creare innovazione.
In un’organizzazione agile, tutti i membri del team sono coinvolti attivamente in questo processo esplorativo. Non si limitano a eseguire compiti, ma cercano costantemente nuove vie per aggiungere valore, risolvere problemi e migliorare l’esperienza del cliente.
All’inizio, molti critici erano scettici. Quando l’Agile Management ha iniziato a diffondersi, c’era chi pensava che fosse destinato a fallire. L’idea che piccoli team autonomi potessero gestire problemi complessi sembrava irrealistica per molti.
Eppure, con il tempo, è emerso l’esatto contrario. Proprio quei piccoli team, grazie alla collaborazione, alla flessibilità e alla trasparenza, si sono dimostrati più agili, più reattivi e più efficaci rispetto ai modelli di gestione tradizionali.
Team Agili
Ma i team agili sono composti da diverse persone e comprendono i seguenti 5 ruoli:
Product Owner
Il product owner è una figura chiave, la persona responsabile di colmare il divario tra il cliente, i business stakeholder e il team di sviluppo. Il product owner (proprietario del prodotto) è esperto del prodotto, così come delle necessità e delle priorità che riguardano il cliente finale. Il product owner lavora quotidianamente con il team di sviluppo per aiutare a far emergere quelle features richieste in merito al prodotto, proteggendone i requisiti in termini di business. Il product owner è a volte chiamato anche ‘il rappresentante del cliente’. In ogni organizzazione funzionante e collaudata, in ogni modo il product owner dovrebbe avere un mandato decisivo, potendo prendere decisioni commerciali strategiche giorno dopo giorno.
I membri del Team di Sviluppo
Il team di sviluppo è composto da persone che si occupano di creare il prodotto. All’interno del team di sviluppo ci sono sviluppatori software, programmatori, tester, designer, UX copywriter, data engineer (ingegneri esperti di analisi dati) e ogni altra figura che abbia un ruolo attivo nello sviluppo del prodotto. Cambiando la tipologia di prodotto, cambiano i membri del team di sviluppo.
L’aspetto essenziale è che i membri del team di sviluppo siano versatili, in grado di contribuire da più parti al raggiungimento degli obiettivi di progetto.
Scrum Master
Lo Scrum Master è la figura responsabile del supporto diretto al team di sviluppo. Colui che si occupa di eliminare tutti quei blocchi e quegli stalli a livello organizzativo, in modo da mantenere coerenza nell’organizzazione agile del processo. Per questa ragione lo scrum master viene anche chiamato il ‘facilitatore di progetto‘. Le figure più adatte a ricoprire il ruolo di scrum master sono leader capaci di servire, e risultano più efficaci quando hanno un peso a livello organizzativo, cioè la capacità di influenzare il cambiamento interno all’organizzazione senza per forza di cose dover rivestire un’autorità formale.
Stakeholder
Stakeholder è chiunque abbia un interesse concreto nel progetto. Gli stakeholders non sono veri e propri responsabili di prodotto, ma sono in grado di fornire input in ingresso e sono influenzati dagli output, dai risultati del progetto. La composizione del gruppo degli stakeholder è variegata e può includere persone afferenti a diversi reparti, o anche provenienti da diverse aziende.
Perché un progetto di agile management abbia successo, gli stakeholder devono essere coinvolti, fornendo regolarmente feedback e supporto al team di sviluppo e al product owner.
Agile Mentor
Il mentor è colui che ha esperienza nell’implementazione del metodo agile project management e può condividere la sua esperienza con un team di progetto. Il mentor agile è una figura chiave: dà feedback e consigli preziosi ai team di progetto appena costituiti ed a quei team di progetto che aspirano a raggiungere un livello più alto di collaborazione.
Anche se gli agile mentor non sono responsabili della fase esecutiva di sviluppo prodotto, a loro si richiede competenza pratica nell’applicazione del metodo e dunque conoscenza diretta di differenti approcci e tecniche di organizzazione agile.
Cos’è un product backlog?
Nel metodo Scrum, uno degli strumenti fondamentali è il Product Backlog. Possiamo immaginarlo come una lista dinamica e ordinata delle attività che il team di sviluppo deve portare a termine. Questa lista nasce dalla roadmap del progetto e dai vari requisiti emersi durante la pianificazione.
Gli elementi presenti nel backlog non sono messi lì a caso: quelli più importanti e urgenti sono sempre in cima alla lista, così il team sa esattamente da dove cominciare e su cosa concentrarsi per primi. Tuttavia, contrariamente a quanto si potrebbe pensare, il team di sviluppo non lavora al ritmo imposto dal Product Owner, né quest’ultimo forza il gruppo in una direzione precisa. L’approccio è molto più collaborativo.
Il Product Backlog è quindi un vero e proprio ponte di comunicazione tra il Product Owner (cioè la figura che rappresenta la voce del cliente e definisce le priorità) e il team di sviluppo. Il Product Owner può aggiornare questa lista in ogni momento, sulla base di feedback reali, modifiche nei requisiti o nuove esigenze emerse durante il percorso.
Ma attenzione: una volta che il team ha iniziato a lavorare su un determinato sprint, è importante evitare cambiamenti improvvisi. Intervenire mentre il lavoro è in corso può causare confusione, ridurre la produttività e abbassare la motivazione del team. Per questo motivo, anche se Agile è sinonimo di flessibilità, serve comunque una disciplina interna per proteggere il flusso di lavoro.
Cosa sono gli sprint?
Uno sprint è un breve periodo di tempo in cui un team scrum lavora per completare un certo quantitativo di lavoro. Lo sprint è il cuore delle metodologie di scrum e di agile project management, e fare bene gli sprint significa aiutare il team di agile project management a rilasciare prodotti migliori.
Molti associano gli sprint di scrum allo sviluppo agile di software, tanto che spesso si pensa che scrum e agile siano la stessa cosa. Ma non lo sono. La gestione agile dei progetti è un insieme di principi e Scrum è un framework.
Sono le molte somiglianze tra i valori del metodo agile project management e i processi di scrum che ci conducono a questa associazione. Gli sprint aiutano i team a seguire il principio base dell’agile project management: “consegnare frequentemente software funzionante“, così come a vivere attraverso il valore base dell’agile management: “rispondere al cambiamento piuttosto che seguire un piano“. I valori scrum sono trasparenza, ispezione e adattamento, complementari alla gestione progetti agile e centrali nel concetto di sprint.
Pianificazione dello sprint
La pianificazione dello sprint è uno degli appuntamenti chiave all’interno del metodo Scrum. Si tratta di un momento che segna ufficialmente l’inizio di uno sprint, cioè di un ciclo di lavoro a tempo determinato, di solito tra due e quattro settimane.
Lo scopo di questo incontro è molto chiaro: decidere cosa il team riuscirà a completare durante lo sprint e come organizzerà il lavoro per riuscirci. È quindi una fase fondamentale per partire con il piede giusto e mettere tutti sulla stessa lunghezza d’onda.
Durante la pianificazione dello sprint, partecipano tutte le figure del team Scrum: lo Scrum Master, il Product Owner e il team di sviluppo. Ognuno ha un ruolo preciso: il Product Owner presenta gli obiettivi e le priorità del Product Backlog, mentre il team valuta la fattibilità e propone soluzioni su come suddividere e realizzare il lavoro.
Insieme, si definisce l’obiettivo dello sprint e si selezionano le attività da svolgere, basandosi sulla capacità del team e sul valore che si vuole generare per il cliente.
Il Cosa
Il product owner descrive l’obiettivo dello sprint e quali elementi del backlog contribuiscono a questo obiettivo. Lo scrum team decide cosa sarà fatto durante lo sprint e cosa nello sprint successivo e in che modo farlo accadere.
Il Come
Il team di sviluppo è chiamato a pianificare il lavoro necessario per raggiungere l’obiettivo dello sprint. In definitiva, il piano di sprint che ne risulta è una negoziazione tra il team di sviluppo e il product owner basata sul valore e sullo sforzo.
Il Chi
La pianificazione dello sprint non può essere fatta senza il product owner o il team di sviluppo. Il product owner definisce l’obiettivo in base al valore che sta cercando. Il team di sviluppo ha bisogno di capire come è possibile o non è possibile raggiungere quell’obiettivo. Se uno di questi due soggetti manca da questo evento, la pianificazione dello sprint diventa quasi impossibile.
Gli input
Un ottimo punto di partenza per pianificare lo sprint è il product backlog, che fornisce una lista di “cose” che potrebbero essere incluse nello sprint corrente. Il team deve conoscere in ogni momento quanto lavoro è stato fatto, quale è l’incremento attuale e avere una visione della capacità produttiva di gruppo.
I Risultati
Il risultato più importante legato alla riunione di pianificazione dello sprint riguarda il fatto che il team può descrivere e aver ben chiaro l’obiettivo dello sprint e come inizierà a lavorare verso quell’obiettivo. Tutto ciò si rende visibile nello sprint backlog.
Cos’è uno stand-up?
Per i team di sviluppo software, lo stand-up è il team huddle. È anche comunemente noto come daily scrum, e rafforza il “noi” per mantenere tutti consapevoli della situazione e dei progressi fatti dal team.
In parole semplici, uno stand-up è una riunione quotidiana dove i partecipanti stanno in piedi. Una riunione che coinvolge il core team: i product owner, gli sviluppatori e lo scrum master.
Ecco alcune delle domande che vengono più frequentemente poste in una riunione stand-up:
- La prima domanda è: su cosa ho lavorato ieri?
- La seconda domanda è: su cosa sto lavorando oggi?
- La terza domanda è: quali problemi mi bloccano?
Queste domande evidenziano i progressi e aiutano a segnalare i passaggi fermi, i blocchi che coinvolgono la squadra. Inoltre, lo stand-up amalgama lo spirito di squadra nel momento in cui tutti condividono i progressi che stanno contribuendo al successo del team.
Cos’è la retrospective?
Per vivere al meglio i valori della gestione progetti agile, i team dovrebbero incontrarsi regolarmente per fare check in e apportare aggiustamenti lungo la rotta. Molti team di sviluppo software applicano questo principio tenendo regolarmente riunioni retrospettive. Di recente inoltre il concetto di retrospectives si è fatto strada al di fuori dei team di sviluppo, in tutti gli ambiti del business e del team working.
Molti dei concetti fondamentali nella gestione progetti agile escono rafforzati dalle riunioni retrospettive.
Test automatizzati
L’implementazione di test automatici formali e approfonditi è una parte vitale del processo agile. I test trovano ed eliminano i difetti alla loro fonte per assicurare che venga consegnato al cliente un pacchetto software funzionante. Gli sviluppatori possono creare il codice di test sotto una rete di sicurezza usando una varietà di framework disponibili mentre sviluppano simultaneamente il codice del software. Questo metodo protegge altre caratteristiche mentre si apportano modifiche al software. È anche un modo più veloce ed efficiente per trovare i bug nel software.
Costruzioni automatizzate
Uno dei principi fondamentali dell’Agile Project Management è avere sempre a disposizione un software funzionante, in ogni fase del progetto. Questo significa che il prodotto deve essere testato, aggiornato e pronto all’uso in qualunque momento, non solo alla fine dello sviluppo.
Per riuscirci, è importante che tutte le fasi del processo – dalla scrittura del codice fino al test – vengano automatizzate il più possibile. Ogni modifica fatta da uno sviluppatore viene subito “verificata” attraverso una serie di passaggi automatici: il codice viene compilato, costruito, distribuito e testato.
Questo processo, noto anche come integrazione continua, avviene più volte al giorno. Ogni volta che uno sviluppatore aggiunge del codice al progetto principale, il sistema esegue controlli automatici per assicurarsi che tutto funzioni correttamente.
In questo modo, il team può intervenire rapidamente in caso di problemi, ridurre gli errori e mantenere sempre alto il livello di qualità del prodotto.
I 12 principi della metodologia agile project management
- Soddisfare il cliente portando continuamente al suo capezzale software di valore.
- I cambiamenti di ambiente vengono abbracciati in ogni fase del processo per fornire al cliente un vantaggio competitivo.
- Consegnare frequentemente software pienamente operativo.
- Gli stakeholder e gli sviluppatori collaborano strettamente su base quotidiana.
- Tutti gli stakeholder e i membri del team rimangono allineati sui risultati migliori del progetto.
- Fare conversazione faccia a faccia quando possibile.
- Il software funzionante è la misura principale del progresso in fase di sviluppo.
- Mantenere un ritmo costante a tempo indeterminato.
- Prestare costante attenzione all’eccellenza tecnica e al buon design.
- La semplicità è un elemento essenziale.
- I team auto-organizzati hanno maggiori probabilità di sviluppare migliori architetture e design, nonché di soddisfare i requisiti.
- Gli intervalli regolari vengono utilizzati dai team per migliorare l’efficienza complessiva attraverso comportamenti di fine-tuning.
Come adottare la metodologia agile project management
Questo metodo è stato progettato originariamente per l’industria del software, ma molte industrie ora fanno affidamento sulla gestione progetti agile quando sviluppano prodotti e servizi. Tutto ciò a causa della natura altamente collaborativa e più efficiente offerta dalla metodologia agile project management. La seguente tabella mostra i tassi di adozione della metodologia di project management agile in una varietà di industrie leader.
Il Tasso di Adozione del metodo agile per industria
Industria/ Tasso di adozione
- Software 25%
- Servizi finanziari 16%
- Servizi professionali 11%
- Assicurazioni 6%
- Assistenza sanitaria 6%
- Governo 5%
- Telecomunicazioni 4%
- Trasporti 4%
- Produzione 4%
Esempi di gestione progetti agile
Sulla gestione progetti Agile sono stati scritti libri – questa metodologia potrebbe essere vista da 100 angolazioni diverse ed essere declinata per raggiungere gli obiettivi di decine e decine di industrie diverse. Quindi, ecco alcuni esempi di Agile project management nel mondo reale.
Calcio
Un allenatore di Serie A deve essere un project manager agile per avere successo.
Ogni stagione è un grande progetto composto da 38 partite di campionato (più le coppe), e ogni partita è un’iterazione di quel progetto. Immaginate se un allenatore di calcio mettesse gli stessi giocatori nelle stesse posizioni, scendendo in campo nello stesso modo, con la solita formazione in tutte partite nonostante gli infortuni, le scarse prestazioni o le sconfitte. Quel manager probabilmente non avrebbe molto successo. Infatti, il metodo agile project management lo si ritrova in tutto il calcio. Si fanno riunioni Scrum a bordo campo sul tipo di gioco, le marcature, la strategia, alla ricerca di un risultato concreto in continuo miglioramento (vittoria o perdita) alla fine di ogni iterazione (partita).
I Genius Bar della Apple
Il Genius Bar di Apple è un grande esempio di gestione Agile dei progetti in azione nel mondo reale. Quando entri con il tuo iPhone o iPad danneggiato, non devi compilare un mucchio di moduli o aspettare in una serie di file. Ciò che colloca il Genius Bar all’interno del processo di gestione agile del progetto è l’attenzione alla comunicazione. Il collaboratore con cui hai a che fare ti fa domande e prende appunti. In altre parole: “individui e interazioni piuttosto che processi e strumenti”.
Philips
Philips è un’altra azienda che ha adottato i principi di gestione agile dei progetti. Dopo numerosi cambiamenti nella struttura di gestione, l’azienda ha introdotto diversi scrum master che sono andati ad implementare i principi Scrum come le schede Scrum e la scomposizione dei team in team più piccoli.
Grazie a cambiamenti come questo, i team hanno potuto reagire alle situazioni problematiche più rapidamente, la burocrazia è stata rimossa, e alla fine è stato più facile per questi team più piccoli assumersi la responsabilità dei loro rispettivi prodotti.
BBVA
BBVA ha iniziato a passare alle pratiche Agile in Spagna. Visto il successo dell’implementazione di Agile in Spagna, BBVA ha deciso di portare la metodologia agile project management in altri paesi come gli Stati Uniti.
Un progetto in cui i principi agili sono stati implementati era un’applicazione che i consumatori potevano usare, chiamata BVA Wallet. L’applicazione permette ai consumatori di gestire le loro carte di pagamento. Il capo del business development team dell’azienda ha continuato a dire che: “Con la metodologia agile, abbiamo potuto sviluppare e avere molto rapidamente nuove versioni” E che grazie ad Agile, BBVA è “uscita con un sacco di altre funzionalità come la capacità di bloccare e sbloccare le carte, la capacità di acquisire una nuova carta o cancellare una carta e la capacità di convertire un pagamento con carta in rate”.
BBVA sta realizzando alcuni dei grandi benefici di Agile Developments che può portare un progetto come la consegna prevedibile e rapida del software, riducendo così il tempo di commercializzazione dei loro nuovi prodotti e servizi.
La risposta è semplice alla domanda perché tutte queste aziende usano Agile? è per migliorare i loro processi di business!
I benefici di Agile
La gestione agile dei progetti è stata originariamente sviluppata per l’industria del software, per snellire e migliorare il processo di sviluppo nel tentativo di identificare e correggere rapidamente criticità e bug.
Agile project management è un modo per gli sviluppatori e i team di consegnare un prodotto migliore, in modo più veloce, attraverso gli sprint. La gestione agile del progetto può aiutare a garantire l’allineamento metodologico e di processo a livello aziendale.
Alcuni dei benefici della gestione agile sono:
- Più trasparenza
- Più flessibilità
- Più produttività
- Consegne di qualità superiore
- Diminuzione del rischio di obiettivi mancati
- Maggiore coinvolgimento e soddisfazione degli stakeholder
Gli svantaggi di Agile
Scrum non è per tutti i team né per tutti i progetti di sviluppo software. Ci sono degli svantaggi nell’implementazione dei progetti Scrum:
- C’è un pericolo di scope creep se le parti interessate continuano ad aggiungere funzionalità al backlog. Questo potrebbe essere incoraggiato dalla scadenza fissa.
- Perdere qualche membro del team può danneggiare il progresso del progetto.
- I team di Scrum non funzionano bene quando lo Scrum Master controlla il loro lavoro.
- Scrum funziona meglio con piccoli team di sviluppatori di software esperti. Devono essere in grado di lavorare velocemente.
- Come ogni altra metodologia, la gestione agile del progetto non è adatta a tutti i progetti, e si raccomanda sempre una sufficiente due diligence per identificare la migliore metodologia per ogni situazione unica.
La gestione agile del progetto può non funzionare come previsto se un cliente non è chiaro sugli obiettivi, il project manager o il team è inesperto, o se non funziona bene sotto una pressione significativa. Durante tutto il processo di sviluppo, la gestione agile del progetto favorisce gli sviluppatori, i team di progetto e gli obiettivi del cliente, ma non necessariamente l’esperienza dell’utente finale.
A causa dei suoi processi meno formali e più flessibili, la gestione agile del progetto può non essere sempre facilmente assorbita all’interno di organizzazioni più grandi e tradizionali dove ci sono quantità significative di rigidità o flessibilità all’interno dei processi, nelle politiche aziendali o nei singoli reparti. Agile può anche dare problemi se usato con clienti che hanno processi o metodi operativi altrettanto rigidi.
Conosciamoci, visitate la pagina relativa alle mie informazioni e inviatemi i vostri feedback, le vostre richieste.