- Il Coach agile
- Manifesto Agile
Scrum
- Panoramica
- Sprint
- Pianificazione dello sprint
- Cerimonie
- Backlog
- Revisioni degli sprint
- Riunioni stand-up
- Scrum Master
- Retrospettive
- Scrum distribuito
- Ruoli
- Scrum-of-scrum
- Artefatti Agile Scrum
- Metriche Scrum
- Scrum di Jira Confluence
- Agile e Scrum a confronto
- Guida alla raffinazione del backlog
- Confronto tra Scrum Master e project manager
Gestione dei progetti Agile
- Panoramica
- Introduzione alla gestione dei progetti
- Flusso di lavoro
- Epic, story, temi
- Epic
- Storie utente
- Stima
- Metriche
- Diagramma di Gantt
- Confronto tra la gestione dei programmi e la gestione dei progetti
- Baseline di progetto
- Miglioramento continuo
- Principi Lean
- I 3 pilastri di Scrum
- Board Scrum
- Metodologia a cascata
- Velocity in Scrum
- Cos'è la Definition of Ready
- Lean e Agile a confronto
- Scrumban
- Metodologia Lean
- Backlog dello sprint
- Grafico burn-up
- 4 principi Kanban
- 4 metriche Kanban
- Program manager e project manager
- Esempi di diagrammi di Gantt
- Definizione di "completato"
- Backlog grooming
- Miglioramento dei processi Lean
- Riunioni di raffinamento del backlog
- Valori Scrum
- Ambito del lavoro
- Strumenti Scrum
- Strumenti
- Software di automazione dei flussi di lavoro
- Modelli
- Tracker dei task
- Automazione del flusso di lavoro
- Report sullo stato
- Grafico del flusso di lavoro
- Roadmap di progetto
- Programmazione di progetto
- Software di tracciamento
- Strumenti per la roadmap
- Roadmap tecnologica
- Software per la programmazione dei progetti
- Strumenti di gestione del backlog
- Comprendere le strategie di gestione del flusso di lavoro
- Esempi di flussi di lavoro
- Crea una roadmap del progetto
- Strumenti di Pianificazione sprint
- Demo dello sprint
- Software per la creazione di timeline dei progetti
- I migliori strumenti di gestione dei task
- Backlog di prodotto e backlog dello sprint a confronto
- I migliori strumenti di gestione dei flussi di lavoro
- Dipendenze del progetto
- Guida alla dashboard dei task
- Cadenza dello sprint
- Fast tracking
Gestione del prodotto
- Panoramica
- Roadmap prodotto
- Product manager
- Suggerimenti per i nuovi product manager
- Roadmap
- Suggerimenti per la presentazione delle roadmap di prodotto
- Requisiti
- Analisi del prodotto
- Sviluppo del prodotto
- Gestione remota dei prodotti
- Prodotto minimo funzionante
- Esplorazione del prodotto
- Specifiche di prodotto
- Strategia di sviluppo del prodotto
- Software per lo sviluppo del prodotto
- Processo di sviluppo di nuovi prodotti
- KPI di gestione prodotti
- Net Promoter Score (NPS)
- Critica del prodotto
- Framework di definizione delle priorità
- Caratteristiche del prodotto
- Strumenti di gestione dei prodotti
- Gestione del ciclo di vita del prodotto
- I 9 migliori software per roadmap per i team
- Checklist per un lancio di prodotto
- Strategia di prodotto
- Ingegneria di prodotto
- Product Operations
- Gestione del portfolio
- Intelligenza artificiale e gestione dei prodotti
- Gestione dei prodotti per la crescita
- Metriche di prodotto
- Rilascio del prodotto
- Richiesta di funzionalità
- Lancio del prodotto
- Pianificazione del prodotto
- Evento per il lancio di un prodotto
- Gestione dei flussi di valore
Agilità su larga scala
- Panoramica
- Gestione di un portfolio Agile
- Gestione snella del portfolio
- OKR
- Pianificazione Agile a lungo termine
- Che cos'è SAFe?
- Modello Spotify
- Introdurre l'approccio Agile nell'organizzazione con Scrum@Scale
- Triangolo di ferro Agile
- Il framework Large-Scale Scrum (LeSS)
- Utilizzo della metodologia Kata del miglioramento a sostegno dell'approccio Lean
- Whitepaper Beyond the basics (Oltre le basi)
Sviluppo software
- Panoramica
- Sviluppatore
- Development manager e Scrum Master a confronto
- Git
- Creazione di branch
- Video sulla creazione di branch Git
- Revisioni del codice
- di Git
- Debito tecnico
- Test
- Risposta agli imprevisti
- Continuous integration
- Sdlc
- Valutazione dei bug: definizione, esempi e best practice
- Distribuzione del software
- DevOps
Tutorial su Agile
- Panoramica
- Perfezionamento degli sprint in Jira e Confluence
- Come utilizzare Scrum con Jira
- Scopri come utilizzare Kanban con Jira
- Scopri come utilizzare gli epic in Jira
- Scopri come creare una board Agile in Jira
- Scopri come utilizzare gli sprint in Jira
- Impara a utilizzare le versioni con Jira
- Scopri come utilizzare i ticket con Jira
- Impara a usare i grafici burn-down con Jira
- Creazione automatica di sottotask e aggiornamento dei campi in Jira
- Come assegnare automaticamente i ticket con Jira Automation
- Come sincronizzare epic e story con Jira Automation
- Escalation automatica dei ticket scaduti in Jira
Informazioni su Agile Coach
- Tutti gli articoli
Il Manifesto Agile è ancora valido?
di Claire Drumond
di Claire Drumond
Claire Drumond è una marketing strategist, relatrice e scrittrice per Atlassian. Inoltre, è autrice di numerosi articoli pubblicati sui blog di Trello e Atlassian e una contributrice attiva di varie pubblicazioni su Medium, tra cui HackerNoon, Art+Marketing e PoetsUnlimited. Partecipa come relatrice a conferenze tecnologiche in tutto il mondo su agile, analisi dei silos e sviluppo dell'empatia.
Inizia gratis con il modello di roadmap Agile
Semplifica il progetto, oltre a pianificare, monitorare e gestire facilmente il lavoro tra uno sprint e l'altro.
Nel pieno della rivoluzione tecnologica, ci ritroviamo a chiederci se il Manifesto Agile debba ancora essere la nostra guida mentre ci muoviamo in un mondo definito dalla continua innovazione. Questo breve ma rivoluzionario documento ci ha aiutato a passare dal un rilascio di prodotti paragonabile alla spedizione su navi merci all'equivalente di una consegna in giornata con droni. Oggi, tuttavia, siamo meno pionieri e più esploratori dei mari del miglioramento continuo, ciò ci porta chiedere se non sia arrivato il momento di migliorare anche il Manifesto.
La storia delle origini
All'inizio del 2001, sullo sfondo delle Wasatch Mountains, a Snowbird (Utah), 17 persone si sono incontrate per parlare del futuro dello sviluppo software. I membri del gruppo condividevano un senso di frustrazione per lo stato attuale delle cose, anche se non convergevano su cosa fare per porvi rimedio.
Su un punto erano d'accordo: il problema risiedeva nel fatto che le aziende erano così concentrate su un'eccessiva pianificazione e documentazione dei cicli di sviluppo software da perdere di vista ciò che contava davvero: la soddisfazione dei clienti.
Le aziende divulgavano valori aziendali come "eccellenza" e "integrità", ma questi valori facevano ben poco per guidare le persone, in particolare gli sviluppatori software, verso un modo migliore di operare. Era necessario un cambiamento. Molti dei 17 partecipanti al summit di Snowbird avevano già delle idee su come inaugurare la nuova era dello sviluppo software. Il viaggio in montagna ha rappresentato per loro l'opportunità di discuterne.
Da questo lungo fine settimana è nato il Manifesto Agile, un breve documento di sole 68 parole che ha cambiato per sempre lo sviluppo software. Nei quasi due decenni trascorsi dalla sua creazione, queste parole (e i 12 principi che seguono) sono stati adottati, in varia misura, da innumerevoli persone, team e aziende.
I 12 principi del Manifesto Agile: definizione di una cultura
Il panorama Agile di oggi può sembrare zeppo di metodologie che promettono di trasformare in realtà gli ideali Agile. Tuttavia, la follia metodologica di oggi non è affatto una novità.
Il Manifesto stesso è nato dalla necessità di trovare un terreno comune tra Scrum, Extreme Programming, Crystal Clear e altri framework.
"Cominciavano a capire che stavano facendo qualcosa insieme. Ma all'epoca erano in forte competizione, quanto meno a livello di pensiero", ha dichiarato Ian Buchanan, Principal Solutions Engineer per DevOps di Atlassian. "Contestualizzando la situazione, il fatto di riuscire a concordare su alcuni punti è davvero straordinario".
I 17 partecipanti del summit di Snowbird volevano vedere se i rappresentanti delle loro diverse discipline riuscissero a mettersi d'accordo su qualcosa, qualunque essa fosse. E con loro grande sorpresa, ci sono riusciti. Si sono accordati su una serie di valori che definivano una cultura.
Ecco quali sono i valori:
Manifesto per lo sviluppo software Agile
Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:
Individui e interazioni rispetto a processi e strumenti
Software che funziona rispetto a una documentazione completa
Collaborazione con il cliente rispetto alla negoziazione dei contratti
Risposta al cambiamento rispetto alla semplice applicazione di un piano
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
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 Robert Schwaber Jeff Sutherland Dave Thomas |
I dodici principi del software Agile, anch'essi frutto del summit di Snowbird, ampliano i concetti espressi dalle poche frasi che costituiscono i valori.
Tutto qui. Da allora, il sito del Manifesto Agile è rimasto praticamente invariato, ma il mondo che ruota attorno ad Agile non potrebbe essere più diverso.
Il grande dibattito su Agile
I 17 partecipanti al summit di Snowbird sono riusciti a unificare i loro diversi punti di vista sotto alcuni principi fondamentali, ma il dibattito non è finito lì. In un certo senso, Agile si è frantumato in molti più modi di operare rispetto a quelli con cui i visionari si sono riuniti al tavolo la prima volta. È come se ognuno avesse una propria opinione su Agile.
Oggi c'è SAFe. C'è LeSS. Sono disponibili applicazioni Agile che non hanno nulla a che fare con lo sviluppo del software, anche se la frase iniziale del Manifesto dice: "Stiamo scoprendo modi migliori per sviluppare software, creandolo e aiutando gli altri a fare lo stesso".
Dave West, CEO di Scrum.org, che visita varie organizzazioni osservando pratiche Agile, ha chiamato un team di ricerca che sta utilizzando Agile per sviluppare una cura per la cecità genetica usando i virus.
Di fatto, l'adozione di Agile al di fuori dell'ambito del software ha preso piede, ma non è necessariamente ciò che intendevano gli ideatori del Manifesto.
"Non è che non possa essere usato per altro, ma è necessaria una comprensione più profonda per assicurarsi che le idee siano tradotte in modo fedele", ha detto Buchanan. Questa comprensione più profonda non è sempre disponibile, persino nell'ambito dello sviluppo di software.
Il complesso industriale Agile
Molti sostengono che il "falso Agile", come viene anche chiamato, e il suo gemello cattivo, il "dark Agile", sono esacerbati dalla monetizzazione della formazione e della consulenza Agile. Alcuni arrivano addirittura a definire le organizzazioni che stanno dietro questa monetizzazione "Il complesso industriale Agile".
"È presente un Agile da culto del cargo dove si fanno e si dicono le cose giuste, ma non si comprendono i principi fondamentali. Non si ottengono i risultati", ha affermato Buchanan.
Alcuni, e sono in molti a farlo, danno la colpa ad Atlassian poiché i nostri strumenti mettono a disposizione framework Agile come Scrum e Kanban, ma la nostra convinzione è che la metodologia Agile sia un valore culturale e che i team debbano avere gli strumenti necessari per lavorare nel modo che ritengono più opportuno. I framework Agile funzionano insieme ai valori culturali, ma se alla base non c'è l'elemento culturale, ciò che si fa potrebbe rivelarsi fallace sin dall'inizio.
Che venga definito "falso", "dark" o "culto del cargo", questo sovvertimento della metodologia Agile spesso determina situazioni che vanno contro le intenzioni del Manifesto, tra cui, per citare i casi più eclatanti, microgestione, ritmo del tasso di burnout, consegne mancate e, soprattutto, fedeltà al processo più che ai principi, anche se i professionisti si presentano con un certificato in mano. Purtroppo, queste esperienze di dark Agile inducono alcune persone a rinunciare del tutto alla metodologia Agile (o a riscrivere i processi per riflettere quella che è stata la propria esperienza nel mondo reale).
Ron Jeffries, uno degli Snowbird 17, ha cercato di affrontare queste aberrazioni con questa affermazione: "Qui e in altri testi, uso la parola citata "Agile" per riferirmi ai molti esempi, approcci e processi che usano la parola "Agile" per descrivere se stessi, ma che non necessariamente aderiscono alla lettera o allo spirito dello sviluppo di software Agile di cui abbiamo parlato nel Manifesto Agile. A volte parlo di "falso Agile" o di "dark Agile" per enfatizzare e descrivere i cosiddetti approcci "Agile" che hanno portato a risultati negativi. Potrei riferirmi al "Manifesto Agile" per indicare le idee fondamentali del Manifesto, in cui credo ancora".
Tuttavia, considerata l'adozione estesa, e talvolta errata, di Agile, è possibile affermare che il Manifesto Agile sia ancora un documento a cui valga la pena fare riferimento?
Il Manifesto è ancora pertinente?
Dopo aver parlato con centinaia di clienti Atlassian, Agile Coach interni ed esterni, utenti appassionati e che lo utilizzano con entusiasmo, per non parlare della quantità eccessiva di tempo che impieghiamo nella lettura di contenuti dedicati all'argomento sui social media, posso affermare con certezza che la risposta è sì. Il Manifesto è ancora pertinente, forse oggi più che mai.
I miei colleghi Dan Radigan, Senior Enterprise Agile Coach, e Ian Buchanan, che lavorano quotidianamente con i clienti, hanno entrambi confermato di parlare regolarmente del Manifesto con i nuovi clienti.
Anche Tanner Wortham, Agile Coach e Senior Technical Program Manager di LinkedIn, afferma di citarlo spesso. Wortham, che ha trascorso 10 anni nei Marines, ha detto di aver iniziato a mettere in pratica Agile prima ancora di sapere che questo approccio avesse un nome. Per lui, si chiamava solo "guidare i Marines", ma dare un nome a qualcosa è per Wortham, un grande primo passo per affrontarlo.
"Finché non si può dare un nome a qualcosa, non si sa cosa farne. Penso che sia ciò che ha fatto il Manifesto. Gli ha dato un nome. E lo ha chiamato Agile. A mio avviso l'approccio veniva già applicato, ma dandogli un nome è stato possibile iniziare a identificarlo più facilmente".
Il CEO di Scrum.org West osserva che i principi Agile non sono affatto nuovi. Sono solo applicati in un modo diverso.
"I principi alla base del Manifesto non sono stati inventati da noi", ha detto West. "Sono i principi del metodo scientifico. Li usava Galileo. Li usava Archimede."
Forse il più grande risultato raggiunto dal Manifesto Agile è la codifica di un modo di pensare che non era ancora stato utilizzato per lo sviluppo software, il che non è certo un'impresa da poco.
Cosa significa esattamente?
Quindi, i principi Agile esistevano prima ancora del Manifesto Agile. Le persone li hanno applicati allo sviluppo software. Questi valori sono stati acquisiti nel Manifesto Agile e le persone hanno in seguito iniziato ad applicare i principi del Manifesto al proprio lavoro. Con tutto il riciclo di idee in corso, è giunto il momento di aggiornare il Manifesto Agile?
Non necessariamente.
Quando arriva qualcosa di così importante dal punto di vista culturale come il Manifesto, sarà anche possibile reinterpretarlo, ma nulla può competere con l'originale. Quindi, invece di provare ad aggiornarlo ufficialmente, forse è preferibile capire come applicarlo a te stesso, al tuo team o alla tua organizzazione.
"Per molti versi il Manifesto è la base di una conversazione", ha detto Wortham. "Io lo interpreto così. Tu come lo interpreti? Bene, cerchiamo di capire come lavorare insieme".
In questo senso, forse ciò che conta non è un documento su cui tutti possano essere d'accordo, ma capire se un gruppo di persone (un team o un'intera organizzazione) possa applicare le idee del Manifesto alla propria situazione specifica senza perdere di vista il suo spirito. E se riusciamo a farlo bene, le possibilità sono illimitate.
"Penso che, se lo facciamo bene, il mondo potrebbe essere straordinario. Possiamo sconfiggere il cancro. I miei figli probabilmente vivranno fino a 150 o 175 anni", ha affermato West. "Penso che possiamo farcela e che lo faremo".
Un ringraziamento speciale ad Amanda O'Callaghan, Ian Buchanan, Dan Radigan, David West e Tanner Wortham per aver condiviso le loro conoscenze ed esperienze su questo argomento.
- Il Coach agile
- Manifesto Agile
Scrum
- Panoramica
- Sprint
- Pianificazione dello sprint
- Cerimonie
- Backlog
- Revisioni degli sprint
- Riunioni stand-up
- Scrum Master
- Retrospettive
- Scrum distribuito
- Ruoli
- Scrum-of-scrum
- Artefatti Agile Scrum
- Metriche Scrum
- Scrum di Jira Confluence
- Agile e Scrum a confronto
- Guida alla raffinazione del backlog
- Confronto tra Scrum Master e project manager
Gestione dei progetti Agile
- Panoramica
- Introduzione alla gestione dei progetti
- Flusso di lavoro
- Epic, story, temi
- Epic
- Storie utente
- Stima
- Metriche
- Diagramma di Gantt
- Confronto tra la gestione dei programmi e la gestione dei progetti
- Baseline di progetto
- Miglioramento continuo
- Principi Lean
- I 3 pilastri di Scrum
- Board Scrum
- Metodologia a cascata
- Velocity in Scrum
- Cos'è la Definition of Ready
- Lean e Agile a confronto
- Scrumban
- Metodologia Lean
- Backlog dello sprint
- Grafico burn-up
- 4 principi Kanban
- 4 metriche Kanban
- Program manager e project manager
- Esempi di diagrammi di Gantt
- Definizione di "completato"
- Backlog grooming
- Miglioramento dei processi Lean
- Riunioni di raffinamento del backlog
- Valori Scrum
- Ambito del lavoro
- Strumenti Scrum
- Strumenti
- Software di automazione dei flussi di lavoro
- Modelli
- Tracker dei task
- Automazione del flusso di lavoro
- Report sullo stato
- Grafico del flusso di lavoro
- Roadmap di progetto
- Programmazione di progetto
- Software di tracciamento
- Strumenti per la roadmap
- Roadmap tecnologica
- Software per la programmazione dei progetti
- Strumenti di gestione del backlog
- Comprendere le strategie di gestione del flusso di lavoro
- Esempi di flussi di lavoro
- Crea una roadmap del progetto
- Strumenti di Pianificazione sprint
- Demo dello sprint
- Software per la creazione di timeline dei progetti
- I migliori strumenti di gestione dei task
- Backlog di prodotto e backlog dello sprint a confronto
- I migliori strumenti di gestione dei flussi di lavoro
- Dipendenze del progetto
- Guida alla dashboard dei task
- Cadenza dello sprint
- Fast tracking
Gestione del prodotto
- Panoramica
- Roadmap prodotto
- Product manager
- Suggerimenti per i nuovi product manager
- Roadmap
- Suggerimenti per la presentazione delle roadmap di prodotto
- Requisiti
- Analisi del prodotto
- Sviluppo del prodotto
- Gestione remota dei prodotti
- Prodotto minimo funzionante
- Esplorazione del prodotto
- Specifiche di prodotto
- Strategia di sviluppo del prodotto
- Software per lo sviluppo del prodotto
- Processo di sviluppo di nuovi prodotti
- KPI di gestione prodotti
- Net Promoter Score (NPS)
- Critica del prodotto
- Framework di definizione delle priorità
- Caratteristiche del prodotto
- Strumenti di gestione dei prodotti
- Gestione del ciclo di vita del prodotto
- I 9 migliori software per roadmap per i team
- Checklist per un lancio di prodotto
- Strategia di prodotto
- Ingegneria di prodotto
- Product Operations
- Gestione del portfolio
- Intelligenza artificiale e gestione dei prodotti
- Gestione dei prodotti per la crescita
- Metriche di prodotto
- Rilascio del prodotto
- Richiesta di funzionalità
- Lancio del prodotto
- Pianificazione del prodotto
- Evento per il lancio di un prodotto
- Gestione dei flussi di valore
Agilità su larga scala
- Panoramica
- Gestione di un portfolio Agile
- Gestione snella del portfolio
- OKR
- Pianificazione Agile a lungo termine
- Che cos'è SAFe?
- Modello Spotify
- Introdurre l'approccio Agile nell'organizzazione con Scrum@Scale
- Triangolo di ferro Agile
- Il framework Large-Scale Scrum (LeSS)
- Utilizzo della metodologia Kata del miglioramento a sostegno dell'approccio Lean
- Whitepaper Beyond the basics (Oltre le basi)
Sviluppo software
- Panoramica
- Sviluppatore
- Development manager e Scrum Master a confronto
- Git
- Creazione di branch
- Video sulla creazione di branch Git
- Revisioni del codice
- di Git
- Debito tecnico
- Test
- Risposta agli imprevisti
- Continuous integration
- Sdlc
- Valutazione dei bug: definizione, esempi e best practice
- Distribuzione del software
- DevOps
Tutorial su Agile
- Panoramica
- Perfezionamento degli sprint in Jira e Confluence
- Come utilizzare Scrum con Jira
- Scopri come utilizzare Kanban con Jira
- Scopri come utilizzare gli epic in Jira
- Scopri come creare una board Agile in Jira
- Scopri come utilizzare gli sprint in Jira
- Impara a utilizzare le versioni con Jira
- Scopri come utilizzare i ticket con Jira
- Impara a usare i grafici burn-down con Jira
- Creazione automatica di sottotask e aggiornamento dei campi in Jira
- Come assegnare automaticamente i ticket con Jira Automation
- Come sincronizzare epic e story con Jira Automation
- Escalation automatica dei ticket scaduti in Jira
Informazioni su Agile Coach
- Tutti gli articoli
Il Manifesto Agile è ancora valido?
di Claire Drumond
di Claire Drumond
Claire Drumond è una marketing strategist, relatrice e scrittrice per Atlassian. Inoltre, è autrice di numerosi articoli pubblicati sui blog di Trello e Atlassian e una contributrice attiva di varie pubblicazioni su Medium, tra cui HackerNoon, Art+Marketing e PoetsUnlimited. Partecipa come relatrice a conferenze tecnologiche in tutto il mondo su agile, analisi dei silos e sviluppo dell'empatia.
Inizia gratis con il modello di roadmap Agile
Semplifica il progetto, oltre a pianificare, monitorare e gestire facilmente il lavoro tra uno sprint e l'altro.
Nel pieno della rivoluzione tecnologica, ci ritroviamo a chiederci se il Manifesto Agile debba ancora essere la nostra guida mentre ci muoviamo in un mondo definito dalla continua innovazione. Questo breve ma rivoluzionario documento ci ha aiutato a passare dal un rilascio di prodotti paragonabile alla spedizione su navi merci all'equivalente di una consegna in giornata con droni. Oggi, tuttavia, siamo meno pionieri e più esploratori dei mari del miglioramento continuo, ciò ci porta chiedere se non sia arrivato il momento di migliorare anche il Manifesto.
La storia delle origini
All'inizio del 2001, sullo sfondo delle Wasatch Mountains, a Snowbird (Utah), 17 persone si sono incontrate per parlare del futuro dello sviluppo software. I membri del gruppo condividevano un senso di frustrazione per lo stato attuale delle cose, anche se non convergevano su cosa fare per porvi rimedio.
Su un punto erano d'accordo: il problema risiedeva nel fatto che le aziende erano così concentrate su un'eccessiva pianificazione e documentazione dei cicli di sviluppo software da perdere di vista ciò che contava davvero: la soddisfazione dei clienti.
Le aziende divulgavano valori aziendali come "eccellenza" e "integrità", ma questi valori facevano ben poco per guidare le persone, in particolare gli sviluppatori software, verso un modo migliore di operare. Era necessario un cambiamento. Molti dei 17 partecipanti al summit di Snowbird avevano già delle idee su come inaugurare la nuova era dello sviluppo software. Il viaggio in montagna ha rappresentato per loro l'opportunità di discuterne.
Da questo lungo fine settimana è nato il Manifesto Agile, un breve documento di sole 68 parole che ha cambiato per sempre lo sviluppo software. Nei quasi due decenni trascorsi dalla sua creazione, queste parole (e i 12 principi che seguono) sono stati adottati, in varia misura, da innumerevoli persone, team e aziende.
I 12 principi del Manifesto Agile: definizione di una cultura
Il panorama Agile di oggi può sembrare zeppo di metodologie che promettono di trasformare in realtà gli ideali Agile. Tuttavia, la follia metodologica di oggi non è affatto una novità.
Il Manifesto stesso è nato dalla necessità di trovare un terreno comune tra Scrum, Extreme Programming, Crystal Clear e altri framework.
"Cominciavano a capire che stavano facendo qualcosa insieme. Ma all'epoca erano in forte competizione, quanto meno a livello di pensiero", ha dichiarato Ian Buchanan, Principal Solutions Engineer per DevOps di Atlassian. "Contestualizzando la situazione, il fatto di riuscire a concordare su alcuni punti è davvero straordinario".
I 17 partecipanti del summit di Snowbird volevano vedere se i rappresentanti delle loro diverse discipline riuscissero a mettersi d'accordo su qualcosa, qualunque essa fosse. E con loro grande sorpresa, ci sono riusciti. Si sono accordati su una serie di valori che definivano una cultura.
Ecco quali sono i valori:
Manifesto per lo sviluppo software Agile
Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:
Individui e interazioni rispetto a processi e strumenti
Software che funziona rispetto a una documentazione completa
Collaborazione con il cliente rispetto alla negoziazione dei contratti
Risposta al cambiamento rispetto alla semplice applicazione di un piano
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
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 Robert Schwaber Jeff Sutherland Dave Thomas |
I dodici principi del software Agile, anch'essi frutto del summit di Snowbird, ampliano i concetti espressi dalle poche frasi che costituiscono i valori.
Tutto qui. Da allora, il sito del Manifesto Agile è rimasto praticamente invariato, ma il mondo che ruota attorno ad Agile non potrebbe essere più diverso.
Il grande dibattito su Agile
I 17 partecipanti al summit di Snowbird sono riusciti a unificare i loro diversi punti di vista sotto alcuni principi fondamentali, ma il dibattito non è finito lì. In un certo senso, Agile si è frantumato in molti più modi di operare rispetto a quelli con cui i visionari si sono riuniti al tavolo la prima volta. È come se ognuno avesse una propria opinione su Agile.
Oggi c'è SAFe. C'è LeSS. Sono disponibili applicazioni Agile che non hanno nulla a che fare con lo sviluppo del software, anche se la frase iniziale del Manifesto dice: "Stiamo scoprendo modi migliori per sviluppare software, creandolo e aiutando gli altri a fare lo stesso".
Dave West, CEO di Scrum.org, che visita varie organizzazioni osservando pratiche Agile, ha chiamato un team di ricerca che sta utilizzando Agile per sviluppare una cura per la cecità genetica usando i virus.
Di fatto, l'adozione di Agile al di fuori dell'ambito del software ha preso piede, ma non è necessariamente ciò che intendevano gli ideatori del Manifesto.
"Non è che non possa essere usato per altro, ma è necessaria una comprensione più profonda per assicurarsi che le idee siano tradotte in modo fedele", ha detto Buchanan. Questa comprensione più profonda non è sempre disponibile, persino nell'ambito dello sviluppo di software.
Il complesso industriale Agile
Molti sostengono che il "falso Agile", come viene anche chiamato, e il suo gemello cattivo, il "dark Agile", sono esacerbati dalla monetizzazione della formazione e della consulenza Agile. Alcuni arrivano addirittura a definire le organizzazioni che stanno dietro questa monetizzazione "Il complesso industriale Agile".
"È presente un Agile da culto del cargo dove si fanno e si dicono le cose giuste, ma non si comprendono i principi fondamentali. Non si ottengono i risultati", ha affermato Buchanan.
Alcuni, e sono in molti a farlo, danno la colpa ad Atlassian poiché i nostri strumenti mettono a disposizione framework Agile come Scrum e Kanban, ma la nostra convinzione è che la metodologia Agile sia un valore culturale e che i team debbano avere gli strumenti necessari per lavorare nel modo che ritengono più opportuno. I framework Agile funzionano insieme ai valori culturali, ma se alla base non c'è l'elemento culturale, ciò che si fa potrebbe rivelarsi fallace sin dall'inizio.
Che venga definito "falso", "dark" o "culto del cargo", questo sovvertimento della metodologia Agile spesso determina situazioni che vanno contro le intenzioni del Manifesto, tra cui, per citare i casi più eclatanti, microgestione, ritmo del tasso di burnout, consegne mancate e, soprattutto, fedeltà al processo più che ai principi, anche se i professionisti si presentano con un certificato in mano. Purtroppo, queste esperienze di dark Agile inducono alcune persone a rinunciare del tutto alla metodologia Agile (o a riscrivere i processi per riflettere quella che è stata la propria esperienza nel mondo reale).
Ron Jeffries, uno degli Snowbird 17, ha cercato di affrontare queste aberrazioni con questa affermazione: "Qui e in altri testi, uso la parola citata "Agile" per riferirmi ai molti esempi, approcci e processi che usano la parola "Agile" per descrivere se stessi, ma che non necessariamente aderiscono alla lettera o allo spirito dello sviluppo di software Agile di cui abbiamo parlato nel Manifesto Agile. A volte parlo di "falso Agile" o di "dark Agile" per enfatizzare e descrivere i cosiddetti approcci "Agile" che hanno portato a risultati negativi. Potrei riferirmi al "Manifesto Agile" per indicare le idee fondamentali del Manifesto, in cui credo ancora".
Tuttavia, considerata l'adozione estesa, e talvolta errata, di Agile, è possibile affermare che il Manifesto Agile sia ancora un documento a cui valga la pena fare riferimento?
Il Manifesto è ancora pertinente?
Dopo aver parlato con centinaia di clienti Atlassian, Agile Coach interni ed esterni, utenti appassionati e che lo utilizzano con entusiasmo, per non parlare della quantità eccessiva di tempo che impieghiamo nella lettura di contenuti dedicati all'argomento sui social media, posso affermare con certezza che la risposta è sì. Il Manifesto è ancora pertinente, forse oggi più che mai.
I miei colleghi Dan Radigan, Senior Enterprise Agile Coach, e Ian Buchanan, che lavorano quotidianamente con i clienti, hanno entrambi confermato di parlare regolarmente del Manifesto con i nuovi clienti.
Anche Tanner Wortham, Agile Coach e Senior Technical Program Manager di LinkedIn, afferma di citarlo spesso. Wortham, che ha trascorso 10 anni nei Marines, ha detto di aver iniziato a mettere in pratica Agile prima ancora di sapere che questo approccio avesse un nome. Per lui, si chiamava solo "guidare i Marines", ma dare un nome a qualcosa è per Wortham, un grande primo passo per affrontarlo.
"Finché non si può dare un nome a qualcosa, non si sa cosa farne. Penso che sia ciò che ha fatto il Manifesto. Gli ha dato un nome. E lo ha chiamato Agile. A mio avviso l'approccio veniva già applicato, ma dandogli un nome è stato possibile iniziare a identificarlo più facilmente".
Il CEO di Scrum.org West osserva che i principi Agile non sono affatto nuovi. Sono solo applicati in un modo diverso.
"I principi alla base del Manifesto non sono stati inventati da noi", ha detto West. "Sono i principi del metodo scientifico. Li usava Galileo. Li usava Archimede."
Forse il più grande risultato raggiunto dal Manifesto Agile è la codifica di un modo di pensare che non era ancora stato utilizzato per lo sviluppo software, il che non è certo un'impresa da poco.
Cosa significa esattamente?
Quindi, i principi Agile esistevano prima ancora del Manifesto Agile. Le persone li hanno applicati allo sviluppo software. Questi valori sono stati acquisiti nel Manifesto Agile e le persone hanno in seguito iniziato ad applicare i principi del Manifesto al proprio lavoro. Con tutto il riciclo di idee in corso, è giunto il momento di aggiornare il Manifesto Agile?
Non necessariamente.
Quando arriva qualcosa di così importante dal punto di vista culturale come il Manifesto, sarà anche possibile reinterpretarlo, ma nulla può competere con l'originale. Quindi, invece di provare ad aggiornarlo ufficialmente, forse è preferibile capire come applicarlo a te stesso, al tuo team o alla tua organizzazione.
"Per molti versi il Manifesto è la base di una conversazione", ha detto Wortham. "Io lo interpreto così. Tu come lo interpreti? Bene, cerchiamo di capire come lavorare insieme".
In questo senso, forse ciò che conta non è un documento su cui tutti possano essere d'accordo, ma capire se un gruppo di persone (un team o un'intera organizzazione) possa applicare le idee del Manifesto alla propria situazione specifica senza perdere di vista il suo spirito. E se riusciamo a farlo bene, le possibilità sono illimitate.
"Penso che, se lo facciamo bene, il mondo potrebbe essere straordinario. Possiamo sconfiggere il cancro. I miei figli probabilmente vivranno fino a 150 o 175 anni", ha affermato West. "Penso che possiamo farcela e che lo faremo".
Un ringraziamento speciale ad Amanda O'Callaghan, Ian Buchanan, Dan Radigan, David West e Tanner Wortham per aver condiviso le loro conoscenze ed esperienze su questo argomento.
Consigliata per te
Modelli
Modelli Jira già pronti
Sfoglia la nostra raccolta di modelli Jira personalizzati per vari team, reparti e flussi di lavoro.
Guida al prodotto
Un'introduzione completa a Jira
Usa questa guida dettagliata per scoprire le funzionalità essenziali e le best practice che ti aiutano a massimizzare la produttività.
Guide
Comprendere le nozioni di base di Git
Questa guida relativa a Git può essere utilizzata da tutti, dai principianti agli utenti più esperti, per imparare le basi attraverso utili tutorial e suggerimenti.