Il Manifesto Agile Spiegato e Come Applicarlo
Il Manifesto Agile è un documento che definisce modi di lavorare che promuovono adattabilità, reattività e flessibilità nello sviluppo software.
Almeno, questo era il suo intento originale. Oggi, i metodi di lavoro agili si sono diffusi ben oltre il mondo tecnologico e sono utilizzati in innumerevoli altri settori.
Ma… cosa significa davvero? E come si traduce un manifesto nel lavoro che svolgi ogni giorno? Scopriamolo insieme.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Cos'è il Manifesto Agile?
Il Manifesto Agile è una dichiarazione scritta che comprende quattro valori e 12 principi finalizzati a migliorare i modi di lavorare nello sviluppo software.
Più filosofico che prescrittivo, il Manifesto era pensato per essere adattabile a una varietà di dimensioni di team, obiettivi e condizioni.
I 4 Valori del Manifesto Agile
L'ufficiale Manifesto Agile si compone di questi 4 valori:
- Individui e interazioni più che processi e strumenti
- Software funzionante più che documentazione esaustiva
- Collaborazione con il cliente più che negoziazione dei contratti
- Rispondere al cambiamento più che seguire un piano
È interessante notare che gli autori hanno seguito i valori con questa dichiarazione chiarificatrice: "Cioè, mentre c'è valore negli elementi a destra, valorizziamo maggiormente quelli a sinistra."
Questo sottolinea l'idea che il Manifesto Agile non riguarda il seguire un certo processo o utilizzare uno specifico strumento agile. Si tratta di adottare una mentalità specifica.
I 12 Principi del Manifesto Agile
Oltre ai quattro valori, il Manifesto Agile elenca 12 principi di supporto che spiegano come interpretare e applicare i valori nei progetti agili.
1. Metti il cliente al primo posto
La priorità più alta è soddisfare il cliente mediante una consegna precoce e continua di software di valore.
2. Accogli il cambiamento
Accogli i requisiti che cambiano, anche in fase avanzata di sviluppo. I processi agili sfruttano il cambiamento per offrire un vantaggio competitivo al cliente.
3. Consegnare frequentemente
Consegnare spesso software funzionante, da un paio di settimane ad un paio di mesi, preferendo tempi più brevi.
4. Collaborare tra i team
Persone di business e sviluppatori devono lavorare insieme quotidianamente durante tutto il progetto.
5. Coltiva il talento
Costruire i progetti intorno a individui motivati. Fornisci loro l'ambiente e il supporto di cui hanno bisogno, e fidati che porteranno a termine il lavoro.
6. Dialoga
Il metodo più efficiente ed efficace per comunicare informazioni al team di sviluppo e al suo interno è la conversazione faccia a faccia.
7. Misura ciò che conta
Software funzionante è la principale misura di progresso.
8. Dai ritmo al lavoro per evitare il burnout
I processi agili promuovono uno sviluppo sostenibile. Sponsor, sviluppatori e utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente.
9. Focalizzati sulla qualità per lavorare più rapidamente
L'attenzione continua all'eccellenza tecnica e al buon design aumenta l'agilità.
10. Semplifica
Semplicità – l'arte di massimizzare la quantità di lavoro non svolto – è fondamentale.
11. Non essere un micro-manager
Le migliori architetture, requisiti e design emergono da team auto-organizzati.
12. Rifletti e adatta
A intervalli regolari, il team riflette su come diventare più efficace, quindi affina e adatta il proprio comportamento di conseguenza.
Storia, autori e origine dell'Agile Manifesto
Nel mondo tecnologico, l’Agile Manifesto viene discusso con la stessa reverenza e irriverenza di qualsiasi testo sacro tramandato nel tempo.
Nel febbraio 2001, 17 professionisti del software che si autodefinirono “The Agile Alliance” si riunirono nello stato dello Utah, negli Stati Uniti, per sviluppare quello che chiamarono un “Manifesto per lo Sviluppo Software Agile”. Il documento, che mette in risalto quattro valori e 12 principi, è ora conosciuto come Agile Manifesto.
Gli autori dell’Agile Manifesto sono spesso denominati Agile Alliance e includevano rappresentanti di vari processi di sviluppo, tra cui extreme programming, Scrum e Crystal.
Un rapido sguardo al sito web ufficiale del manifesto ritrae gli autori in un contesto che potrebbe ricordare una società segreta o un raduno di padri fondatori. Era chiaro che la loro intenzione fosse quella di creare qualcosa che avrebbe lasciato un segno duraturo nell’industria. E così è stato.
Sebbene le persone che si incontrarono nello Utah non fossero i pionieri dei principi agili in generale, esse hanno però consolidato i valori che da tempo stavano emergendo, seppur in secondo piano, nel mondo dello sviluppo software.
Oggi la metodologia agile ha permeato quasi tutti i settori.
Gli autori includevano:
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Perché l’Agile Manifesto è (ancora) importante
L’Agile Manifesto è ancora attuale grazie al suo focus su modi di lavorare incentrati sulle persone e alla sua capacità di garantire flessibilità.
I rapidi cambiamenti tecnologici spesso comportano l’evoluzione dei requisiti di progetto. L’Agile Manifesto consente ai project manager di dare priorità all’adattabilità e alla collaborazione, creando un ambiente di progetto reattivo e resiliente in grado di portare avanti il lavoro, innovare e cambiare direzione quando necessario.
Promuove inoltre un approccio orientato al cliente dando più valore alle soluzioni funzionanti che alla documentazione completa. Questo permette ai project manager di raccogliere feedback precoci e di migliorare continuamente il proprio lavoro, garantendo che il progetto si allinei in modo ottimale alle esigenze degli utenti. Questo approccio iterativo e basato sul cliente aumenta il tasso di successo e la soddisfazione dei progetti.
Come applicare l'Agile Manifesto
Approfondiamo ora ciascuno dei quattro valori dell’agile manifesto. Esaminando i valori fondamentali, esploreremo anche i 12 principi a cui ciascuno si collega.
Valore #1: Persone e interazioni prima di processi e strumenti
Il nucleo dell’agile è costituito dalle persone. Agile enfatizza il lavoro di squadra, la stretta collaborazione e le decisioni prese in autonomia. Agile non consiste nel dire a un team cosa fare o cosa costruire.
Nei progetti agili, la comunicazione deve essere fluida e continua, non definita e programmata. Lavorare in compartimenti stagni non è ciò che prevede la filosofia agile.
Valuta la comunicazione del team
Chiediti: tu e il tuo team parlate faccia a faccia? Oppure vi affidate esclusivamente a email, documenti e alcuni strumenti di messaggistica molto amati (non citiamo nomi qui)?
Anche lavorando da remoto, una conversazione faccia a faccia può accelerare le cose. Soprattutto quando un team si sta formando, la comunicazione sincrona favorisce la fiducia, l’apertura e aiuta a rafforzare le relazioni.
Sii meno ossessionato dal controllo
Ci siamo passati tutti almeno una volta. Ma, la fiducia è fondamentale nell’agile. Cerchi qualcosa che puoi mettere in pratica da subito? NON FARE MICROMANAGEMENT (sì, volevo urlarlo apposta).
È facile lasciarsi tentare dal suddividere i compiti in modo dettagliato, distribuirli al team e poi monitorarli fino alla scadenza prevista (o meno), così da avere il controllo su tutto. Tuttavia, per dare davvero potere al tuo team, devi fare un passo indietro e lasciare che abbiano la responsabilità del loro lavoro!
Incoraggia un team auto-organizzato
Qui non si tratta di gestire, ma di guidare e facilitare. Un team auto-organizzato è un gruppo che sceglie come portare a termine il proprio lavoro nel modo migliore. Devono decidere come trasformare il backlog di attività in codice rilasciabile. Tuttavia, non bisogna cadere nell’estremo opposto fornendo zero aiuto o guida—il team necessita ancora di una visione, motivazione e supporto nel risolvere eventuali blocchi.
In questo caso, come si fa ad abbandonare la distribuzione dei compiti e invece capire come facilitare il lavoro del team?
Non preoccuparti troppo del processo o dello strumento
Lo so, lo so—si parla sempre di strumenti di project management e software di project management agile nel mondo del PM agile.
Ma ecco la verità: al tuo cliente non interessa il tuo processo di agile workflow interno. Né dovrebbe interessargli.
L’approccio agile consiste nel mettere il cliente al primo posto e permettere al tuo team di fornire un lavoro migliore e più prezioso. Torneremo più avanti sull’approccio customer-first!
Elimina i silos
I silos ostacolano la collaborazione e quindi si allontanano dai valori agili.
Per superare i silos, considera questi suggerimenti:
- Colloca il team nello stesso spazio: Sì, di nuovo questo punto. È positivo se i designer possono sedersi vicini e parlare di design, ma non è forse meglio se parlano con gli sviluppatori della realizzazione di questo fantastico prodotto? So che può essere complesso da attuare in una grande organizzazione o in contesti di lavoro da remoto, ma anche solo condividere un canale Slack o pianificare sessioni coworking dove tutti si dedicano al lavoro profondo, in modo simultaneo e remoto, può mantenere il team più connesso.
- Evita i passaggi di consegne tra reparti: Il più rigido approccio a cascata, in cui ogni reparto lavora in fasi (prima UX, poi design, poi sviluppo, infine QA), può spesso causare problemi di comunicazione e aumentare gli sprechi su un progetto. Prova a far lavorare il team insieme sulle funzionalità anziché passarsele uno dopo l’altro. Anche se lavori con sprint ma con una fase di design iniziale, coinvolgi gli sviluppatori già nel design sprint—sono loro che poi dovranno costruire il tutto!
Valore #2: Software funzionante più importante della documentazione completa
Ricorda che il manifesto non dice di eliminare la documentazione—semplicemente dà maggior valore agli elementi a sinistra rispetto a quelli a destra. Questo significa che la documentazione esiste comunque. Ad esempio, Scrum utilizza le user story per informare gli sviluppatori su come iniziare lo sviluppo.
Ma cosa puoi fare per allontanarti dalla documentazione pesante e dispersiva e passare subito a qualcosa di concreto?
Snellisci la documentazione che utilizzi
Individua eventuali blocchi o punti dolenti nel tuo processo. Sei troppo orientato alla documentazione? Ci metti una vita a creare il documento perfetto dei requisiti, poi spendi molto tempo nello scoping funzionale e alla fine ti manca il tempo per realizzare il prodotto? Riduci la documentazione non necessaria facendo così:
- Concentrandoti su attività di design e sviluppo che arricchiscano davvero il prodotto stesso, invece di produrre documenti scritti che finiranno per non essere usati
- Organizza workshop iniziali per definire requisiti e passaggi successivi invece di scrivere documenti infiniti. Documenta e condividi gli esiti con foto e note sintetiche.
Passa subito alla fase di sviluppo
Scrivere chilometri di documentazione dei requisiti è un modo per tracciare i bisogni di business, cliente e utente finale. Ma, alla fine, vedere qualcosa che funziona, si comporta e reagisce è molto più utile.
Valuta alcune delle seguenti strategie per far progredire rapidamente il tuo progetto:
- Riduci il tempo dedicato alla discovery o alla definizione iniziale: Limitare il tempo dedicato alla fase di definizione e analisi ti permette di arrivare rapidamente a una base su cui designer e sviluppatori possono lavorare. Puoi velocizzare il processo con queste domande per la sessione di discovery.
- Organizza workshop: Organizzare workshop di team porta le persone chiave a prendere decisioni più rapidamente.
- Cambia il tuo piano di progetto: Hai previsto la definizione, poi il design e poi lo sviluppo in modo sequenziale? Prova ad anticipare lo sviluppo coinvolgendo designer e sviluppatori nella realizzazione di qualcosa in collaborazione, fin da subito.
Utilizza metodi di prototipazione invece di design piatti
Invece di considerare il progresso come un documento di definizione o un design piatto che è solo una casella da spuntare per l'approvazione del cliente, mostra loro qualcosa che entrerà a far parte del prodotto finito.
Usa la prototipazione rapida per ottenere qualcosa di funzionante e utilizzabile—e, cosa ancora più importante, qualcosa che puoi testare con i clienti. Raccogliere feedback su un prototipo diventa un modo utile per monitorare i progressi, invece di affidarsi a un deliverable che non ha il vantaggio di essere parte del prodotto finale.
Puoi creare prototipi con diversi livelli di fedeltà:
- Bassa fedeltà: Design cliccabili. Serve quando hai bisogno di creare velocemente un esempio da testare con i clienti, più che altro una prova dell'aspetto visivo e delle semplici interazioni.
- Media fedeltà: Utilizzo di movimento o animazione.
- Alta fedeltà: HTML funzionante. Utilizzato per interazioni complesse, ma può essere trasformato in codice pronto per la pubblicazione.
I prototipi ad alta fedeltà sono più vicini a un “software funzionante” rispetto agli altri tipi, ma sono più dispendiosi in termini di tempo. I prototipi a bassa o media fedeltà offrono indicazioni migliori agli sviluppatori rispetto ai design piatti.
Consegna qualcosa rapidamente all'utente finale o al cliente
Questa è davvero importante.
Con rilasci frequenti di software funzionante, il cliente può già utilizzare eventuali nuove funzionalità che sono state rilasciate. Invece di aspettare la fine del progetto per un lancio "big-bang", consegnare valore prima al tuo cliente è fondamentale per ottenere un prodotto migliore.
Come si può raggiungere una consegna più frequente nella tua organizzazione?
- Rivedi il piano di progetto o la roadmap di progetto: Hai pianificato di completare lo sviluppo e poi lanciare solo alla fine del progetto? Invece, lavora con il tuo team per suddividere il lavoro in funzionalità o fasi che possono essere rilasciate indipendentemente lungo il percorso.
- Concentrati sulle difficoltà: Una parte fondamentale del tuo ruolo è aiutare il team a superare i blocchi quando si presentano problemi. Come puoi aiutarli a consegnare più efficientemente? Ci sono modi di lavorare che rallentano i rilasci? Condurre una retrospective di sprint con il tuo team può far emergere opportunità di miglioramento dei processi.
- Automatizza: Se nella tua organizzazione si impiega molto sforzo per i rilasci, automatizza i processi dove possibile. Ad esempio, test automatici e deployment automatizzato possono ridurre il lavoro manuale e lo sforzo richiesto per ogni rilascio. Parla con il tuo team di sviluppo agile dei processi che usano e delle possibilità di automatizzazione.
Valore n. 3: Collaborazione con il cliente rispetto alla negoziazione del contratto
Invece di creare un contratto estremamente specifico all'inizio di un progetto che dettaglia consegne, ambito, budget e tempistiche precisi, mantieni il tuo contratto agile il più generale possibile. Prendi le decisioni durante il progetto collaborando strettamente con i tuoi clienti e stakeholder.
Agile non significa spendere molto tempo definendo i requisiti in anticipo. Significa iniziare un progetto e imparare strada facendo grazie ai test e ai feedback dei clienti ottenuti tramite software funzionante.
Adotta un approccio orientato al cliente
Adoro questa frase tratta da un articolo di Neil Killick:
“Un pensatore agile si chiede continuamente: 'Qual è il modo più semplice/più veloce per portare valore al cliente?' Ti fai questa domanda ogni giorno? Se la risposta è no, questo è il primo passo da compiere.”
Non sono solo designer e sviluppatori a doverlo pensare—anche i project manager dovrebbero farlo. Siamo anche noi responsabili di fornire al cliente il miglior prodotto o servizio possibile. Il tuo cliente, l’utilizzatore del tuo prodotto o servizio, deve essere al centro di tutto ciò che fai.
Metti il cliente finale al centro del piano
Invece di pianificare in base a deliverable e stime, pianifica tenendo presenti gli obiettivi di valore per il cliente. Cosa vogliamo che faccia il cliente, e perché? Come misureremo che questo funziona?
Riformula la conversazione per concentrarti su quale valore abbiamo portato al cliente piuttosto che su quanti task abbiamo consegnato.
Coinvolgi attivamente il tuo cliente
Invece di tenere una riunione settimanale di aggiornamento e poi presentare i risultati a cliente e stakeholder alla fine di un certo periodo, lavora per coinvolgere il cliente nel progetto quotidianamente.
Se stai seguendo un processo più vicino allo Scrum, fai in modo che il cliente sia il product owner. Il product owner è responsabile di riunire i requisiti aziendali, tecnici e del cliente. Ottenere il coinvolgimento e la collaborazione del cliente fin dalle prime fasi, e farlo spesso, è fondamentale per evitare ritardi. In definitiva, ciò genera un prodotto o servizio migliore per il cliente finale.
Coinvolgi un cliente distante
Se il tuo cliente non ha il tempo di contribuire al progetto o comunque non è coinvolto, assicurati che qualcuno nel team rappresenti il cliente. È fondamentale che qualcuno tenga in considerazione le esigenze dei clienti e dell’azienda.
Anche se il cliente non è coinvolto quotidianamente, assicurati di comunicare regolarmente con lui e, almeno, di includerlo in ogni pianificazione agile e nelle discussioni sulla definizione delle priorità. Lavora con lui per dimostrare i vantaggi della sua partecipazione.
Realizza una roadmap di prodotto
Considera l’uso di una roadmap di prodotto per tracciare la traiettoria evolutiva del tuo prodotto. Una roadmap comunica il piano relativo al prodotto e visualizza le funzionalità previste per la consegna. Una roadmap non è fissa all’inizio di un progetto; evolve nel tempo per riflettere i cambiamenti di priorità.
Assicurati di parlare con i tuoi utenti finali o clienti
Non posso sottolinearlo abbastanza: devi cercare di testare il tuo prodotto con utenti finali e clienti il prima possibile e con frequenza.
I test portano molti vantaggi:
- Puoi assicurarti che il tuo prodotto soddisfi le esigenze dei clienti, cioè che sia effettivamente utile ai clienti e dunque per il business. Questo ti aiuta a valutare l’aderenza al mercato del prodotto.
- Puoi integrare il feedback dei clienti nel processo di design e sviluppo, ottenendo così un prodotto finale migliore.
- Puoi ottenere spunti utili per alimentare il lavoro futuro.
- Il problema spesso citato riguardo ai test con i clienti è il budget, poiché possono essere costosi. Ecco alcuni modi per testare indipendentemente dal budget a disposizione:
Guerrilla testing: Adoro questa modalità perché è economica e semplice. Offri alle persone un vero (o virtuale) caffè se si rendono disponibili a rispondere a qualche domanda sui tuoi design o sul prototipo. È più difficile specificare chi risponde, ma ottenere un feedback rapido può essere utile per testare l’aspetto grafico o le interazioni semplici.
Sondaggi: Per raccogliere dati quantitativi da un pubblico più ampio, puoi creare un sondaggio per valutare il design o approfondire il comportamento dei clienti.
Siti come usertesting.com: Puoi caricare i tuoi design su uno di questi siti e reclutare persone tramite la piattaforma (utilizzando criteri specifici, se necessario). Gli utenti effettueranno i test sui tuoi design, registreranno le loro impressioni e risponderanno alle domande.
Test di persona: Sì, questa può essere una soluzione più costosa, perché probabilmente dovrai reclutare le persone e riconoscere loro un incentivo; tuttavia può essere davvero preziosa se testi interazioni complesse o funzionalità ad alto rischio.
Valore n. 4: Rispondere al cambiamento piuttosto che seguire un piano
Progetti agili e waterfall non potrebbero essere più diversi da questo punto di vista. Nei progetti di sviluppo software tradizionali, i requisiti, i costi e i tempi sono fissati in anticipo, mentre l’agile consente e accoglie il cambiamento.
Il cambiamento è positivo! Non è un male! Quanti piani di progetto sono andati esattamente come li avevi previsti all’inizio? Pochi, immagino (io ho lavorato su progetti che avevano decine di versioni del piano di progetto).
I piani sono la migliore ipotesi in un certo momento, che puoi dettagliare e approfondire nel tempo; tuttavia, spesso non consentono di gestire i cambiamenti. Cosa succede se cambiano le esigenze del cliente? Se l’azienda cambia direzione? Se il cliente rivede le priorità? Se la funzionalità prevista risulta più complessa di quanto pensassi?
I metodi agili abbracciano l’incertezza grazie alla pianificazione adattiva (come il planning poker). Ad esempio, nello Scrum il team pianifica il lavoro sprint dopo sprint. Prima di iniziare ogni periodo di lavoro a tempo fisso, i team agili selezionano gli elementi dal backlog e li assegnano come prioritari per lo sviluppo.
Anche se spesso ci si sforza di fissare costi, tempi e ambito all’inizio di un progetto, essere più realistici sulle incertezze che si affrontano porta spesso a un risultato finale di qualità molto superiore. In definitiva, è proprio questo ciò che dovresti desiderare tu, il cliente e i tuoi stakeholder.
Ecco alcuni modi per iniziare a introdurre la flessibilità nei tuoi progetti e favorire un approccio più aperto al cambiamento:
Crea un piano "leggero" per soddisfare gli stakeholder
"Ma un piano ci serve!", gridano i tuoi stakeholder. Invece di spaventarli dicendo: "Sorpresa, non c’è nessun piano!", prepara un piano di rilascio leggero per dar loro fiducia in questo approccio un po’ meno formale.
Se stai facendo project management agile con processi Scrum, avrai una lista di user story prioritarie e stimate nel tuo backlog. Lavora con il product owner per raggrupparle in rilasci approssimativi e mappale sulla roadmap del prodotto.
Cerca di non pianificare tutto nei dettagli, vanificando così i benefici derivanti dall’utilizzo della metodologia Scrum. Mostra agli stakeholder cosa hai pianificato per i primi due o tre rilasci, poi spiega come il ripianificare sia parte centrale del modo di lavorare agile e che comunicherai aggiornamenti e ulteriori rilasci man mano che il progetto avanza. Speriamo che questo dia loro la fiducia di cui hanno bisogno!
Accompagna il team verso un approccio basato sugli sprint
Mike Cohn, nel suo articolo “Introducing an agile process to an organization”, suggerisce di aiutare i team a introdursi gradualmente nello Scrum definendo una serie di tipologie di sprint, ad esempio:
- Prototipazione
- Raccolta dei requisiti
- Analisi e progettazione
- Implementazione
- Stabilizzazione
Ecco come descrive come questo possa essere d’aiuto:
“Lavoriamo poi con i team per definire gli artefatti che risulteranno da ciascun tipo di sprint. L’introduzione di tipologie di sprint introduce il giusto livello di formalità che consente ai team di vedere più chiaramente il percorso da compiere durante il progetto. Con l’aumentare della confidenza dei team con l’informalità del processo agile, gradualmente abbandonano il concetto di tipologie di sprint.”
Questa è un’altra modalità per strutturare il tuo piano di rilascio. Se associ una “tipologia” a ogni sprint, i tuoi stakeholder possono vedere come prende forma il piano, senza che tu debba garantire funzionalità specifiche. Anche il tuo team avrà una visione migliore su cosa andrà a lavorare.
Allontanati dalle scadenze fisse
Dare al tuo team una scadenza o comunicare una data fissa al cliente sono strategie destinate a fallire o, quanto meno, a generare stress lungo il percorso. Coltivare la fiducia tra te e il tuo team, il tuo cliente o stakeholder è fondamentale per dimostrare che riuscirai a consegnare, e a consegnare valore, al cliente finale.
Ricorda, il tuo obiettivo è ridurre la necessità di numerosi checkpoint e approvazioni. Introdurre scadenze nel tuo progetto non ti aiuterà a raggiungere questo scopo. Inoltre, non è utile stare col fiato sul collo al team, inseguendolo per il lavoro che "aveva promesso" di consegnare.
Come ho accennato sopra, le roadmap e i piani di rilascio possono essere un buon meccanismo per allontanarsi da un approccio basato su date fisse. Dare agli stakeholder un’idea di ciò che verrà rilasciato nel prossimo futuro può rassicurarli sul fatto che esista un piano.
Utilizza un ambito basato su tempo e materiali
Se hai un ambito a prezzo fisso e consegne fisse, sarà difficile lavorare in modo più agile. Puoi decisamente adottare alcune delle tecniche che ho già menzionato, come promuovere un team più collaborativo. Tuttavia, sarai comunque limitato nel modo in cui potrai rispondere e adattarti ai cambiamenti, lasciare al team la scelta su cosa lavorare, o adottare un approccio più centrato sul cliente.
Collabora con il tuo team interno e il cliente per istituire un ambito basato su tempo e materiali—cioè, il cliente paga per un team, piuttosto che per consegne fisse. All’inizio, i clienti possono essere nervosi se non sanno esattamente cosa riceveranno.
Per affrontare questa preoccupazione, puoi includere nell'ambito un backlog di attività o compiti che potrebbero essere considerati per il lancio. Specifica nel contratto che il team ripianificherà e priorizzerà il backlog con il coinvolgimento del cliente man mano che il progetto procede (anche se non affronterai ogni singolo elemento).
Per gestire meglio le priorità mutevoli e le consegne, i team possono fare affidamento su software di gestione agile per riorganizzare continuamente il backlog e su strumenti di collaborazione per lo sviluppo software per coordinare la collaborazione tra funzioni trasversali.
In questo modo, non ti impegni su un ambito fisso, ma il cliente ha comunque meno incertezze su come sarà il prodotto finale.
Continua a monitorare i progressi
Monitorare e visualizzare i progressi non viene messo da parte in assenza di un piano di progetto formale. Mantenere i progressi visibili per il team e per gli stakeholder non solo ti assicura di non perdere di vista potenziali blocchi e colli di bottiglia, ma consente anche agli stakeholder di essere sempre aggiornati.
Usare una board Kanban WIP (work in progress) o dashboard agili funziona bene per i progetti agili. Una volta visualizzato il tuo processo, puoi iniziare a mappare le attività e i task di supporto. Questo ti aiuta a individuare i colli di bottiglia che puoi sbloccare per rendere più rapida la consegna al cliente.
Critiche al Manifesto Agile
Come qualsiasi altra metodologia di gestione dei progetti, agile non è perfetto. I critici sottolineano che gli autori del Manifesto Agile erano un gruppo omogeneo che potrebbe non aver considerato approcci alternativi al lavoro, come i benefici del lavoro da remoto o come applicare agile al di fuori dell’ambito dello sviluppo software.
Se portato all’estremo, agile potrebbe significare decisioni prese da un comitato, rallentando così il ritmo del lavoro. La mancanza di documentazione potrebbe finire per danneggiare la consegna del progetto, specialmente in un ambiente remoto dove la comunicazione asincrona è fondamentale.
Se decidi di adottare agile nei tuoi progetti, assicurati di consultare i valori e i principi agili. Sono una guida utile per tenere sotto controllo le peggiori tendenze dell’approccio agile.
Leggi di più sul dibattito se agile sia una metodologia o una mentalità qui.
Agilità, non Agile
Un ultimo pensiero: ricorda la retrospettiva! Come afferma il Manifesto:
A intervalli regolari, il team riflette su come diventare più efficace, quindi affina e adatta il proprio comportamento di conseguenza.
Qualunque sia il tipo di processo che stai seguendo, la retrospettiva è un modo efficace per verificare come stai lavorando e ottimizzare per il successo. Assicurati di includere regolarmente le retrospettive di progetto in qualunque processo tu utilizzi—e di avere un meccanismo per integrare ciò che hai imparato! PS: È importante far parlare anche i membri più silenziosi del team durante le retrospettive—ecco come.
E ora?
Per saperne di più su come implementare modalità di lavoro agili e imparare dai migliori project manager del settore, dai un’occhiata alle nostre opzioni di iscrizione DPM.
