agile manifesto understanding agile values
Introduzione al Manifesto Agile:
Il nostro precedente tutorial su Metodologia Agile ci ha spiegato in dettaglio i modelli e le metodologie Agile.
Ma fino ad ora non ci siamo preoccupati del motivo per cui era necessario innanzitutto agile e di come agile superasse le carenze delle metodologie di sviluppo software esistenti come il modello a cascata.
In questo tutorial, approfondiremo i dettagli di agile e del manifesto agile. Vedremo cosa dice il manifesto e quali sono i valori e i principi in esso contenuti.
Cosa imparerai:
introduzione
Come abbiamo visto nel nostro tutorial precedente , le metodologie di sviluppo precedenti richiedevano troppo tempo e quando il software era pronto per l'implementazione, i requisiti aziendali sarebbero cambiati, quindi non soddisfacendo le esigenze attuali.
La velocità del cambiamento che mancava in quel momento stava causando molti problemi. Quando i leader delle diverse metodologie di sviluppo si sono incontrati per decidere la via da seguire, sono stati in grado di concordare un metodo migliore e sono stati anche in grado di finalizzare la formulazione del manifesto.
Questo è stato catturato come 4 valori e 12 principi al fine di aiutare i professionisti a comprenderlo, fare riferimento ad esso e metterlo in pratica. E a quel punto, nessuno di loro avrebbe potuto immaginare l'impatto che ciò avrebbe avuto sul futuro della gestione del progetto.
Agile Manifesto
Il manifesto è stato formulato con molta attenzione per catturare l'essenza dell'agile in parole minime e si legge come di seguito:
“Stiamo scoprendo modi migliori per sviluppare un software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati al valore seguente:
- Individui e interazioni su processi e strumenti.
- Software funzionante su documentazione completa.
- Collaborazione con il cliente nella negoziazione del contratto.
- Rispondere al cambiamento piuttosto che seguire un piano.
Cioè, anche se c'è valore negli elementi a destra, noi diamo più valore agli elementi a sinistra '.
Come possiamo vedere, queste sono dichiarazioni piuttosto concise e semplici e rendono molto chiaro ciò che i fondatori volevano promuovere. Di solito, i piani di progetto tradizionali sono rigidi e enfatizzano le procedure e le tempistiche, ma il manifesto agile propaga esattamente le cose opposte.
Preferisce:
- Persone
- Prodotto
- Comunicazione e
- Reattività
Esploreremo questo nuovo paradigma che i fondatori volevano promuovere in dettaglio ottenendo una comprensione più profonda dei valori e dei principi agili.
I 4 valori Agile
I quattro valori insieme ai 12 principi guidano la distribuzione agile del software. Discuteremo ora ciascuno dei valori in dettaglio.
strumenti di test di automazione per applicazioni web
# 1) Individui e interazioni su processi e strumenti
Gli individui e le interazioni sono preferiti ai processi e agli strumenti perché rende il processo più reattivo. Se le persone sono allineate e una volta che si sono capite, il team può risolvere eventuali problemi con gli strumenti o i processi.
Ma se i team insistono per attenersi ciecamente ai processi, ciò potrebbe causare incomprensioni tra gli individui e creare blocchi stradali inaspettati con conseguente ritardo del progetto.
Ecco perché è sempre preferibile avere interazioni e comunicazioni tra i membri del team piuttosto che dipendere ciecamente dai processi per guidare la via da seguire. Uno dei modi per ottenere questo risultato è avere un Product Owner coinvolto che lavora e può prendere decisioni in collaborazione con il team di sviluppo.
Consentire alle persone di contribuire da sole consente loro anche di mostrare liberamente ciò che possono portare in tavola. Quando queste interazioni di squadra sono dirette alla risoluzione di un problema comune, i risultati possono essere piuttosto potenti.
# 2) Software funzionante su documentazione completa
La gestione tradizionale del progetto prevedeva una documentazione completa che richiedeva un ritardo di mesi. Questo ha avuto un impatto negativo sulla consegna del progetto e i ritardi risultanti erano inevitabili.
Il tipo di documentazione creata per questi progetti era molto dettagliata e sono stati creati così tanti documenti che a molti di essi non è stato nemmeno fatto riferimento durante lo stato di avanzamento del progetto. Questo era un male inutile con cui convivevano i team del progetto.
Ma questo ha anche esacerbato i problemi di consegna. L'attenzione si è concentrata sulla documentazione a tal punto perché i team volevano ottenere un prodotto finito che fosse al 100% come da specifiche. Ecco perché l'obiettivo era catturare tutte le specifiche nei dettagli.
Tuttavia, il prodotto finale era abbastanza diverso dalle aspettative o avrebbe perso rilevanza. Questo è il motivo per cui Agile afferma che un software funzionante è un'opzione molto migliore per valutare le aspettative dei clienti rispetto a un mucchio di documentazione.
Ciò non implica che la documentazione non sia necessaria. Significa solo che un prodotto funzionante è un qualsiasi giorno un migliore indicatore di allineamento alle esigenze e alle aspettative del cliente rispetto a un documento creato mesi fa. Implica anche che i team siano reattivi e pronti ad adattarsi ai cambiamenti come e quando richiesto mentre mostrano il software funzionante al cliente quando lo sprint finisce.
Il mancato test del prodotto durante gli sprint richiede molti costi e sforzi nello sprint successivo. Una volta implementata la funzionalità, il costo di queste modifiche aumenta ulteriormente in misura significativa.
3. Collaborazione con il cliente sulla negoziazione del contratto
Negoziazione significa che i dettagli sono ancora in fase di acquisizione e non sono stati finalizzati. C'è ancora spazio per la rinegoziazione. Ma una volta che la trattativa è finita, non ci può essere discussione su di essa. Quello che dice Agile è che invece di negoziare, scegli la collaborazione.
La collaborazione implica che ci sia ancora spazio per la discussione e la comunicazione sia in corso.
Non una cosa una tantum. Ciò che fa è che offre un duplice vantaggio: mentre aiuta il team a fare una correzione del percorso se richiesto in una fase precedente, aiuta il cliente anche a perfezionare la propria visione e ridefinire le proprie esigenze se richiesto durante il corso del progetto.
L'altro aspetto è che mentre i modelli di sviluppo software tradizionali coinvolgono il cliente prima che lo sviluppo inizi durante la fase di documentazione e negoziazione, e non sono coinvolti durante lo sviluppo del progetto.
Una volta che i requisiti sono stati congelati, possono vedere solo il prodotto, una volta che il prodotto è pronto. Agile supera anche questa barriera consentendo il coinvolgimento dei clienti durante l'intero ciclo di vita.
Questo aiuta i team agili ad allinearsi meglio alle esigenze del cliente. Uno dei modi per raggiungere questo obiettivo è attraverso un Product Owner dedicato e coinvolto che può aiutare il team in tempo reale per chiarimenti e allineare il lavoro con le priorità del cliente
4. Rispondere al cambiamento rispetto a un piano
Il processo di pensiero standard è che i cambiamenti sono un affare costoso e dovremmo evitare i cambiamenti a tutti i costi. Questo è ciò che è inutile concentrarsi sulla documentazione e sui piani elaborati da fornire attenendosi alle scadenze e alle specifiche del prodotto.
Ma come ci insegna anche l'esperienza, i cambiamenti sono per lo più inevitabili e invece di scappare da esso dovremmo cercare di abbracciarli e pianificarli.
Agile ci permette di fare questa transizione. Quello che pensa Agile è che il cambiamento non è una spesa, è un feedback gradito che aiuta a migliorare il progetto. Non è da evitare ma, invece, aggiunge valore.
Con i brevi sprint proposti da Agile, i team possono ottenere un rapido feedback e modificare le priorità con un breve preavviso. Nuove funzionalità possono essere aggiunte da iterazione a iterazione.
Perché lo facciamo? Perché la maggior parte delle funzionalità sviluppate utilizzando l'approccio a cascata non vengono mai utilizzate. Questo perché il modello a cascata segue il piano mentre quella è la fase in cui sappiamo meno.
Anche Agile pianifica, ma segue anche l'approccio just in time in cui la pianificazione viene eseguita quanto basta quando necessario. E i piani sono sempre aperti a cambiare con il progredire degli sprint.
I 12 principi Agile
Ci sono 12 principi agili che sono stati aggiunti dopo la creazione del manifesto al fine di aiutare e guidare i team nella transizione verso l'agile e verificare se le pratiche che stanno seguendo sono in linea con la cultura agile.
Di seguito è riportato il testo dei 12 principi originali, pubblicati nel 2001 da Agile Alliance:
# 1) La nostra massima priorità è soddisfare il cliente attraverso la consegna tempestiva e continua di un software prezioso.
#Due) Benvenuto ai requisiti in evoluzione, anche in fase avanzata di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.
# 3) Fornisci software funzionante frequentemente, da un paio di settimane a un paio di mesi, con una preferenza per un periodo di tempo più breve.
# 4) Gli uomini d'affari e gli sviluppatori devono lavorare insieme ogni giorno durante tutto il progetto.
qual è la migliore email da avere
# 5) Costruisci progetti attorno a persone motivate. Fornisci loro l'ambiente e il supporto di cui hanno bisogno e affidati a loro per portare a termine il lavoro.
# 6) Il metodo più efficiente ed efficace per trasmettere informazioni al e all'interno del team di sviluppo è una conversazione faccia a faccia.
# 7) Il software funzionante è la principale misura del progresso.
# 8) I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente.
# 9) La continua attenzione all'eccellenza tecnica e al buon design aumentano l'agilità.
# 10) Semplicità: l'arte di massimizzare la quantità di lavoro non svolto è molto essenziale.
#undici) Le migliori architetture, requisiti e progetti emergono da team auto-organizzati.
# 12) A intervalli regolari, il team riflette su come diventare più efficace, quindi sintonizza e adatta il proprio comportamento di conseguenza.
Questi principi agili forniscono una guida pratica per i team di sviluppo.
Un altro modo per organizzare i 12 principi è considerarli nei seguenti quattro gruppi distinti:
- Soddisfazione del cliente
- Qualità
- Lavoro di squadra
- Gestione di progetto
# 1) La nostra massima priorità è soddisfare il cliente attraverso la consegna tempestiva e continua di un software prezioso - I clienti saranno ovviamente entusiasti di vedere un software funzionante che viene consegnato ad ogni sprint, piuttosto che dover passare attraverso un periodo di attesa ambiguo al termine del quale solo loro potranno vedere il prodotto.
Qui il cliente può essere definito come lo sponsor del progetto o la persona che paga per lo sviluppo. Anche l'utente finale del prodotto è un cliente, ma possiamo distinguere tra i due in quanto l'utente finale viene definito utente.
#Due) Benvenuto ai requisiti in evoluzione, anche in fase avanzata di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente - Le modifiche possono essere incorporate senza troppi ritardi nelle scadenze generali.
Poiché i team agili credono nella qualità prima di tutto, preferiscono incorporare le modifiche e fornire secondo i requisiti del cliente piuttosto che evitare modifiche e fornire un prodotto che non soddisfa le esigenze aziendali.
# 3) Fornisci software funzionante frequentemente, da un paio di settimane a un paio di mesi, con una preferenza per un periodo di tempo più breve - Questo è curato dai team che lavorano negli sprint. Poiché gli sprint sono iterazioni time-boxed e forniscono un software funzionante alla fine di ogni sprint, i clienti hanno regolarmente un'idea del progresso
# 4) Gli uomini d'affari e gli sviluppatori devono lavorare insieme ogni giorno durante tutto il progetto - Le decisioni migliori vengono prese quando entrambi lavorano insieme in modo collaborativo e c'è un ciclo di feedback costante tra i due per la correzione della rotta e l'agilità del cambiamento. La comunicazione tra gli stakeholder è sempre la chiave dell'agile.
come rimuovere un valore da un array java
# 5) Costruisci progetti attorno a persone motivate. Offri loro l'ambiente e il supporto di cui hanno bisogno e affidati a loro per portare a termine il lavoro - Devi supportare, fidarti e motivare le squadre. Un team motivato ha maggiori probabilità di avere successo e fornirà un prodotto superiore rispetto a team insoddisfatti che non sono disposti a dare il meglio.
Uno dei modi per farlo è consentire al team di sviluppo di auto-organizzarsi e prendere le proprie decisioni.
# 6) Il metodo più efficiente ed efficace per trasmettere informazioni al e all'interno del team di sviluppo è una conversazione faccia a faccia - La comunicazione è migliore e più efficace se i team si trovano nella stessa posizione e possono incontrarsi faccia a faccia per le discussioni. Aiuta a creare fiducia e porta la comprensione tra le varie parti interessate.
# 7) Il software funzionante è la principale misura del progresso - Un software funzionante batte tutti gli altri KPI ed è il miglior indicatore del lavoro svolto.
# 8) I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente - Viene sottolineata la coerenza della consegna. Il team dovrebbe essere in grado di mantenere il ritmo per tutta la durata del progetto e non esaurirsi dopo i primi sprint.
# 9) La continua attenzione all'eccellenza tecnica e al buon design aumentano l'agilità - Il team dovrebbe avere tutte le competenze e un buon design del prodotto per gestire i cambiamenti e produrre un prodotto di alta qualità pur essendo in grado di incorporare i cambiamenti
# 10) Semplicità - L'arte di massimizzare la quantità di lavoro non svolto è essenziale ed è appena sufficiente per soddisfare la definizione di fatto.
#undici) Le migliori architetture, requisiti e progetti emergono da team auto-organizzati - I team auto-organizzati hanno potere e si assumono la responsabilità del proprio lavoro. Ciò porta a una comunicazione aperta e alla condivisione regolare di idee tra i membri del team.
# 12) A intervalli regolari, il team riflette su come diventare più efficaci, quindi sintonizza e adatta il proprio comportamento di conseguenza - L'auto-miglioramento porta a risultati più rapidi e rielaborazioni minori.
Conclusione
La centralità del cliente e l'attenzione alla comunicazione hanno portato al successo di Agile che è visibile oggi.
È una tecnica collaudata con implicazioni non solo nella fornitura di software ma anche in altri settori e oggi è diventata un'industria a sé stante.
Il nostro prossimo tutorial di questa serie spiegherà di più sullo Scrum Team insieme ai loro ruoli !!
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Quiz online su Agile Scrum: prova la tua conoscenza di Agile Scrum
- Il cambiamento di mentalità di un tester Agile: in linea con il Manifesto Agile
- Kanban vs Scrum vs Agile: un confronto dettagliato per trovare le differenze
- Come fornire funzionalità software di alto valore in un breve periodo di tempo utilizzando Agile Scrum Process
- Tutorial SAFe Agile: Cos'è Scaled Agile Framework
- 4 passaggi verso lo sviluppo della mentalità di test agile per una transizione di successo al processo agile
- Tutorial JIRA Agile: come utilizzare JIRA in modo efficace per la gestione di progetti Agile
- Pratica DevOps basata su Agile Manifesto (Parte 2 - Blocco 1)