Cosa c'è di così bello in Agile? Un primer sulla metodologia agile
Agile Definire come sistemi di gestione Agile che sono in circolazione da un po ', ma hanno guadagnato valuta negli ultimi tempi. In effetti, Agile Management presenta costantemente le principali tendenze di Project Management di quasi tutti i blog di Project Management IT ogni anno.
Le applicazioni di Agile nei progetti basati sull'IT sono indiscusse, poiché trovano impiego non solo nei progetti di software IT, ma anche nello sviluppo e nell'innovazione dei prodotti.
Cosa c'è di così straordinario in Agile? Chiedi ai dipendenti che sono passati da un sistema tradizionale ad Agile e potrebbero lamentarsi delle riunioni e degli "incontri sulle riunioni" costanti.
Si scopre che c'è molto di più in Agile oltre a riunioni e feedback. Si concentra sulla responsabilizzazione dei team e sulla rimozione dei modi sequenziali di sviluppo del progetto, in modo che vi sia maggiore flessibilità e innovazione. Sebbene ciò significhi riunioni e risultati più spesso rispetto ai sistemi tradizionali, significa anche che ci sono meno possibilità di iterazioni e modifiche in seguito nel ciclo del progetto.
Viene pubblicizzato come la cura di tutti i problemi comuni che affliggono i progetti IT. Che cos'è esattamente e come è migliore dei sistemi tradizionali?
Necessità di metodologia agile - Pratiche di gestione
Chiunque abbia lavorato sulla metodologia agile nei progetti di sviluppo software avrà qualche idea di alcuni dei soliti problemi che sorgono durante un progetto: cambiamento di portata, scadenze che sembrano impossibili da rispettare e risorse sovraccariche di lavoro.
Le metodologie tradizionali e agili nella gestione dei progetti presentavano molti inconvenienti a causa dei quali non riuscivano a far fronte al mutevole ambiente di business, in particolare nello sviluppo di software, e le situazioni di cui sopra erano, purtroppo, fin troppo comuni. Questo non significa che i metodi tradizionali non siano applicabili da nessuna parte. Sono ancora la scommessa migliore per i progetti in cui l'idea è completamente formata dall'inizio.
Le pratiche di gestione agile sono diventate il bisogno dell'ora perché soddisfacevano le seguenti esigenze di un prodotto lanciato in un ambiente dinamico:
- Necessità di velocità per raggiungere il prodotto sul mercato
- Necessità di flessibilità per adattarsi a più modifiche alle specifiche
- Difetti nello scenario "divisione del lavoro"
- Dilemma del cliente
- Necessità di riduzione dei costi
Necessità di raggiungere rapidamente il prodotto sul mercato:
Viviamo in un ambiente frenetico in cui flessibilità e velocità sono le chiavi del successo.
La tecnologia è uno dei settori in più rapida evoluzione nel settore. C'è un'idea, un prodotto o un'innovazione più nuovi ogni minuto. In questo contesto, il tradizionale approccio di project management non riesce a fornire. Un progetto sequenziale dipende necessariamente dalle fasi della metodologia agile che vengono completate in modo soddisfacente nell'ordine. Le tempistiche dei progetti gestiti tradizionalmente sono sempre un argomento controverso.
Organizzazioni e team che non sono dinamici perderanno la corsa a coloro che si trasformano per adattarsi all'ambiente che cambia.
Necessità di flessibilità per adattarsi a più modifiche nelle specifiche:
Le aspettative e le esigenze dei clienti cambiano spesso nel corso dello sviluppo del prodotto. Prima che i sistemi di gestione Agile diventassero mainstream, i progetti in ambito IT fallivano spesso perché il tradizionale sistema di gestione dei progetti era stato costruito per "approfondire". Se ci sono stati cambiamenti, i clienti hanno spesso sentito il pizzico sui loro portafogli o timeline. Il tradizionale modello di gestione dei progetti, adattato da altri settori, semplicemente non funzionava per un settore dinamico come l'IT.
Divisione del lavoro:
Nel modello tradizionale, ci sono fasi distinte, a partire dall'analisi dei requisiti di sistema e fino al rilascio e alla manutenzione del prodotto. Ciò si traduce in una divisione del lavoro e nell'etichettatura dei membri come "progettisti", "programmatori" o "tester". Ma in realtà, le risorse di oggi sono estremamente interfunzionali e una tale netta distinzione di ruoli non è fattibile nella maggior parte dei progetti.
Dilemma del cliente:
In progetti volatili, molto spesso, i clienti non sono del tutto sicuri di quale debba essere il loro prodotto finale, con tutte le specifiche. Funzionalità e requisiti cambiano spesso man mano che i lavori vengono eseguiti. I modelli tradizionali come il modello Waterfall enfatizzano la chiarezza rispetto al prodotto finale e le deviazioni nei piani mettono a dura prova il sistema. Questo ci porta all'ultimo fattore che ha portato allo sviluppo di sistemi Agile.
Necessità di riduzione dei costi:
Tradizionalmente, i cambiamenti nei requisiti in qualsiasi momento dopo l'avvio del progetto erano scoraggiati. Piuttosto, i costi per qualsiasi componente aggiuntivo erano alti, a volte in modo proibitivo. Era quindi indispensabile includere tutti i possibili scenari nella fase di pianificazione stessa. Ciò significa che sono stati considerati tutti gli scenari e proposta una soluzione. Ma poiché è quasi impossibile sapere con certezza quale parte del prodotto preferirà l'utente, i team hanno spesso sviluppato "versioni gonfiate" di un prodotto. Questo conteneva tutti i possibili scenari, di cui un tipico utente avrebbe utilizzato non più del 20%. Ciò ha comportato costi e sviluppo non necessari.
Inutile dire che ciò significava che tutti i progetti erano globali nella loro pianificazione.
E quando è emerso uno scenario completamente nuovo e non pianificato, c'erano comunque costi aggiuntivi, nonostante tutta la pianificazione.
Un gruppo di persone si è incontrato nel febbraio 2001 per discutere esattamente questo: la necessità di un modello flessibile e agile di sviluppo software che abbia contribuito a sviluppare prodotti che funzionassero effettivamente per il cliente e lo sviluppatore. Ciò che ne è risultato è stato il "Manifesto Agile", che ha beneficiato dello sviluppo di software per metodologie agili, ovvero un insieme di quattro principi tanto semplici quanto descrittivi. Sono stati inoltre sviluppati dodici "principi Agile" che spiegano come i sistemi Agile funzionerebbero effettivamente in un ambiente di progetto.
Attraverso questo lavoro siamo arrivati a valutare:
- Individui e interazioni su processi e strumenti
- Software funzionante su documentazione completa
- Collaborazione con i clienti sulla negoziazione del contratto
- Rispondere al cambiamento seguendo un piano
Cioè, mentre c'è valore negli oggetti a destra, valutiamo di più gli oggetti a sinistra.
I 12 principi agili
I 12 principi Agile sono un insieme di concetti guida alla base del Manifesto Agile che supportano i team di progetto nell'attuazione dei progetti Agile. Loro sono:
- La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software prezioso.
- Accogliere favorevolmente le mutevoli esigenze, anche nella fase avanzata di sviluppo. I processi metodologici agili gestiscono il cambiamento per il vantaggio competitivo del cliente.
- Fornisci frequentemente software funzionante, da un paio di settimane a un paio di mesi, con preferenza alla scala temporale più breve.
- Uomini d'affari e sviluppatori devono lavorare insieme tutti i giorni durante il progetto.
- Costruisci progetti intorno a individui motivati. Offri loro l'ambiente e il supporto di cui hanno bisogno e fidati di loro per portare a termine il lavoro.
- Il metodo più efficiente ed efficace per trasmettere informazioni a e all'interno di un team di sviluppo è la conversazione faccia a faccia.
- Il software di lavoro è la misura principale del progresso.
- I processi di metodologia agile promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.
- L'attenzione costante all'eccellenza tecnica e al buon design aumentano l'agilità.
- La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.
- Le migliori architetture, requisiti e progetti emergono da team auto-organizzati.
- A intervalli regolari, il team riflette su come diventare più efficace, quindi sintonizza e regola di conseguenza il suo comportamento.
Esempio di un progetto che necessita di una gestione agile
Immagina una start-up che sviluppa un'app mobile per un client. Il blocco dell'intero design dell'applicazione prima dell'avvio dello sviluppo potrebbe essere disastroso. C'è anche un tempo limitato per condurre un'indagine di mercato, redigere un piano dettagliato, decidere le varianti che vogliono offrire e quindi sviluppare il prodotto. Oltre all'enorme costo di questo approccio, corrono il rischio che qualche altra azienda possa sviluppare l'app prima di farlo.
La metodologia agile nella gestione dei progetti aiuta a superare questi problemi. Con questo sistema, l'app è sviluppata in più fasi, con l'interazione con il cliente ogni giorno e risultati finali o traguardi del progetto identificati, diciamo, per ogni settimana.
Più team possono anche lavorare sulla stessa app, in modo da ridurre drasticamente i tempi di sviluppo.
Le funzionalità vengono perfezionate ad ogni incontro e il prodotto finale riflette il bisogno finale. Imparano passo dopo passo ciò che funziona per il cliente e improvvisano le offerte fino a ottenere il prodotto desiderato.
Nell'approccio tradizionale alla gestione dei progetti, si dovrebbe pensare a tutte le revisioni prima di rilasciare il prodotto. Ciò comporterebbe scadenze scadute, maggiori carichi di lavoro e inflazione dei costi. Inoltre, il prodotto potrebbe aver perso completamente la sua rilevanza al momento del rilascio.
Come funziona esattamente la gestione agile?
Sebbene la gestione agile sia principalmente definita come un concetto IT, i suoi usi non si limitano al settore IT. Ad esempio, il rivenditore di abbigliamento a catena Zara ha utilizzato i principi di Agile Management per trasformare la propria attività.
Utilizzando i principi Agile, Zara produceva prodotti in piccoli lotti piuttosto che concentrarsi su grandi produzioni prima della nuova stagione. La società ha evitato i costi relativi all'inventario elevato e alle offerte di sconti imprevedibili con questo metodo.
Alcuni degli aspetti chiave di Agile Project Management sono:
- Il Project Management Agile segue un approccio flessibile.
Agile Management accoglie integrazioni e modifiche durante lo sviluppo del prodotto anziché conformarlo alle specifiche originali.
- I progetti agili sono generalmente divisi in blocchi di lavoro separati, con i team coinvolti nello sviluppo di uno o più di questi "pezzi" di lavoro.
Quindi è possibile avere, ad esempio, quattro team che lavorano simultaneamente su diverse parti di un progetto, in modo da ridurre i tempi del progetto. I team si coordinano tra loro e con il cliente su base giornaliera per i risultati finali.
- Ci sono incontri quotidiani sui progressi o blocchi stradali nel progetto con feedback costante.
Dopo aver ricevuto il feedback dei clienti, le modifiche vengono incorporate e i team passano al blocco successivo. Questo processo continua a fornire un prodotto più dinamico e più adatto alle esigenze del cliente.
- Vi è un maggiore coinvolgimento dei membri del team piuttosto che un approccio dall'alto verso il basso.
All'interno del ciclo di vita dello sviluppo software, i membri del team sono coinvolti in tutte le fasi: requisiti, progettazione, sviluppo e test metodologici agili. Poiché vi è una panoramica regolare dell'efficienza dell'attività, i membri del team regolano di conseguenza il comportamento e le procedure.
- Il profilo del project manager in un progetto Agile cambierà da un ruolo tradizionale.
Non sta più impiegando molto tempo a pianificare o monitorare le risorse, ma ora passa più tempo a collaborare con i team e a garantire che il quadro generale sia sempre in vista. Questa non è una transizione facile e i manager che passano ai sistemi Agile devono adattarsi rapidamente affinché il progetto abbia successo.
Qualche parola su Scrum:
Scrum è uno dei framework più popolari per l'implementazione della Metodologia Agile. Cos'è la metodologia agile? Precede Agile ed è stato proposto per la prima volta nel 1986 e implementato nell'industria automobilistica e tipografica.
La metodologia agile con scrum non è sinonimo; ci sono altri framework che possono essere utilizzati per implementare Agile ma Scrum è uno dei più efficaci e probabilmente il più popolare. Che cos'è la mischia? In genere, Scrum ha solo tre ruoli: Product Owner, Team e Scrum master. Il master della metodologia Scrum non è un project manager. Le responsabilità di un ruolo tradizionale di project manager sono suddivise tra i tre ruoli di gestione del progetto Scrum. Il progetto è integrato in una serie di iterazioni a lunghezza fissa chiamate sprint. Il successo di ogni sprint metodologico agile provoca una sensazione di progresso tangibile e ispirazione continua. L'obiettivo di ogni iterazione è produrre un prodotto funzionante che può essere dimostrato agli stakeholder. L'agile maestra di scrum metodologia lavora con il proprietario e il team del prodotto per facilitare il completamento degli obiettivi rimuovendo i blocchi stradali. Il team di sviluppo della metodologia agile è interfunzionale e comprende tester, progettisti e ingegneri operativi oltre agli sviluppatori.
Gestione tradizionale del progetto: The Waterfall
Uno dei sistemi di gestione dei progetti tradizionali più importanti è la cascata. È stato spesso utilizzato dagli anni '70. Esistono diverse metodologie a cascata ben note e ampiamente implementate nei progetti IT. Questi includono PRINCE2, creato dal governo britannico per il suo settore pubblico.
Proprio come suggerisce il nome, è un flusso di lavoro sequenziale. Il prodotto finale è fissato all'inizio del progetto. Quindi le varie fasi del flusso di lavoro vengono completate in sequenza (avvio del concepimento, analisi, progettazione, costruzione, collaudo, implementazione e manutenzione). Una volta completato il passaggio precedente, gli sviluppatori passano al passaggio successivo. Il piano di progetto dovrebbe essere infallibile; una volta completato uno stadio della sequenza, gli sviluppatori non possono rivisitare lo stesso senza ricominciare da capo. È un approccio statico alla metodologia agile nella gestione dei progetti. Non c'è spazio per modifiche o errori e il piano di progetto della metodologia agile deve essere seguito diligentemente.
È possibile tracciare un'analogia tra Waterfall Management e dipingere un capolavoro. L'immagine del capolavoro finale è già nella mente dell'artista e lavora costantemente verso di essa. Se, per qualsiasi motivo, il prodotto finale è diverso da quello che ha visualizzato, non può modificarlo facilmente.
Agile o cascata?
- Che cos'è Agile? Agile è più adatto a piccoli team che lavorano su progetti incrementali ed evolutivi mentre Waterfall è adatto a grandi schemi o progetti di sviluppo. La gestione delle cascate potrebbe essere più adatta ad industrie come l'edilizia. Agile viene utilizzato in progetti più dinamici come quelli del settore IT.
- I sistemi agili richiedono membri del team altamente qualificati in grado di gestire tutte le fasi del progetto. Richiede un cambiamento radicale nel ruolo di project manager. Il processo a cascata è strutturato in un modo più tradizionale, è lineare e forse è più facile da capire per i non sviluppatori e per i neofiti dello sviluppo del software.
- Molte organizzazioni trovano confortante la metodologia Waterfall poiché è meglio documentata. Agile è noto per non aver enfatizzato un'ampia documentazione. È più dipendente dalle persone, il che può essere fastidioso nelle organizzazioni in cui il tasso di logoramento è elevato.
- Piccoli progetti semplici potrebbero non richiedere un framework metodologico Agile e un modello sequenziale Waterfall potrebbe funzionare altrettanto bene.
Dove sta andando tutto questo?
La metodologia di sviluppo agile rappresenta oltre i due terzi di tutti i progetti IT negli Stati Uniti, secondo un sondaggio condotto da HP a maggio 2015.
Ma Agile non è sempre la soluzione "perfetta". Non è una soluzione "adatta a tutti" e di conseguenza molte organizzazioni (24% secondo il sondaggio HP) hanno ora adottato un approccio ibrido.
Un ibrido di metodi Agile e Waterfall potrebbe sfruttare i vantaggi di entrambi. Questo approccio ibrido potrebbe funzionare per progetti complicati con clienti esterni e team di grandi dimensioni. Questo approccio è stato descritto da Erick Bergmann e Andy Hamilton. È un compromesso tra i due metodi, che consente ai team di software di lavorare in modo "agile", mentre i team di sviluppo hardware e i product manager utilizzano il metodo tradizionale.
Mark Fromson, un consulente digitale indica un altro modo in cui un ibrido può funzionare:
Suddividere il progetto in fasi a cascata per consentire la contrattazione a offerta fissa e l'ambito definito in una fase più piccola, ma mantenendo il progetto fluido nel suo complesso.
Indipendentemente dalla forma che assumeranno i futuri team, è chiaro che lo sviluppo della metodologia Agile è qui per restare. Ha consentito vantaggi in termini di flessibilità, tempo e costi, insieme al fattore più importante di tutti: dare un senso di soddisfazione e un'atmosfera motivante alle persone che lavorano a questi progetti.
Fonte:
Per Agile Manifesto e The 12 Agile Principles- www.agilemanifesto.org
Corsi correlati: -
Gestione dei progetti agile - Impara le metodologie agili