Definizione di Agile

Agile è un termine che descrive gli approcci allo sviluppo software che enfatizzano la distribuzione incrementale, la collaborazione tra team, la pianificazione continua e l'apprendimento continuo. Il termine Agile è stato coniato nel 2001 nel Manifesto Agile. Il manifesto ha definito principi per guidare un approccio migliore allo sviluppo di software. Al suo centro, il manifesto dichiara quattro istruzioni valore che rappresentano la base del movimento Agile. Come scritto, il manifesto afferma:

Il valore è stato ottenuto:

• Gli individui e le interazioni più che i processi e gli strumenti.
• Il software funzionante più che la documentazione esaustiva.
• La collaborazione con il cliente più che la negoziazione dei contratti.
• Rispondere al cambiamento più che seguire un piano.

Il manifesto non implica che gli elementi a destra di queste istruzioni non siano importanti o necessari. Piuttosto, gli elementi a sinistra sono semplicemente più valutati.

Metodi e procedure Agile

È importante comprendere che Agile non è una cosa. Non si fa Agile. Agile è invece una mentalità orientata allo sviluppo di software. Poiché non esiste un unico approccio che funziona per tutte le situazioni, il termine Agile è giunto a rappresentare vari metodi e procedure allineati alle istruzioni di valore nel manifesto.

I metodi Agile, spesso chiamati framework, sono approcci completi alle fasi del ciclo di vita di DevOps: pianificazione, sviluppo, recapito e operazioni. Essi prescrivono un metodo per eseguire il lavoro, con linee guida e principi chiari.

Scrum è il framework Agile più comune e quello con cui la maggior parte delle persone inizia. Le procedure Agile, d'altra parte, sono tecniche applicate durante le fasi del ciclo di vita dello sviluppo software.

• Planning Poker è una pratica di stima collaborativa progettata per incoraggiare i membri del team a condividere la loro comprensione di ciò che significa fatto . Molte persone trovano il processo divertente, e si è dimostrato di aiutare a promuovere il lavoro in team e stime migliori.
• L'integrazione continua (CI) è una pratica di progettazione Agile comune che prevede l'integrazione frequente delle modifiche al codice nel ramo principale. Una compilazione automatizzata verifica le modifiche. Di conseguenza, c'è una riduzione del debito di integrazione e un ramo principale continuamente spedibile.

Queste procedure, come tutte le procedure Agile, portano l'etichetta Agile , perché sono coerenti con i principi nel manifesto Agile.

Che cos'è Agile non è

Man mano che Agile ha guadagnato popolarità, molti stereotipi e interpretazione errata hanno fatto un'ombra negativa sulla sua efficacia. È facile dire "Sì, stiamo facendo Agile", senza alcuna responsabilità. Tenere presente questo punto, considerare alcuni aspetti che Agile non è.

• Agile non sta codificando cowboy. Agile non deve essere confuso con un approccio "lo capiremo man mano che andiamo" allo sviluppo di software. Un'idea di questo tipo non poteva essere più lontano dalla verità. Agile richiede sia una definizione di valore fatto che esplicito che viene distribuito ai clienti in ogni sprint. Sebbene l'autonomia dei valori Agile per individui e team, sottolinea l'autonomia allineata per garantire che l'aumento dell'autonomia produci un maggiore valore.
• Agile non è senza rigore e pianificazione. Al contrario, le metodologie e le procedure Agile in genere enfatizzano la disciplina nella pianificazione. La chiave è la pianificazione continua in tutto il progetto, non solo pianificare in anticipo. La pianificazione continua garantisce che il team possa apprendere dal lavoro eseguito. Grazie a questo approccio, ottimizzano il ritorno sugli investimenti (ROI) della pianificazione.

"I piani sono senza valore, ma la pianificazione è tutto." - Dwight D. Eisenhower

• Agile non è una scusa per la mancanza di una roadmap. Questo malinteso ha probabilmente fatto il maggior danno al movimento Agile nel complesso. Le organizzazioni e i team che seguono un approccio Agile sanno assolutamente dove stanno andando e i risultati che vogliono ottenere. Il riconoscimento del cambiamento come parte del processo è diverso dal pivot in una nuova direzione ogni settimana, sprint o mese.
• Agile non è in fase di sviluppo senza specifiche. È necessario in qualsiasi progetto mantenere il team allineato sul motivo e sul modo in cui viene eseguito il lavoro. Un approccio Agile alle specifiche include la garanzia che le specifiche siano di dimensioni corrette e che riflettano in modo appropriato il modo in cui le sequenze del team e forniscono il lavoro.
• Agile non è in grado di gestire il lavoro non pianificato e altre interruzioni. È importante completare gli sprint in base alla pianificazione. Ma solo perché si verifica un problema che tiene traccia dello sviluppo non significa che uno sprint debba avere esito negativo. I team possono pianificare interruzioni designando le risorse in anticipo per problemi e problemi imprevisti. Possono quindi risolvere questi problemi, ma tenere traccia dello sviluppo.
• Agile non è inappropriato per le organizzazioni di grandi dimensioni. Un reclamo comune è che la collaborazione, un componente chiave delle metodologie Agile, è difficile in team di grandi dimensioni. Un altro gripe è che gli approcci scalabili a Agile introducono struttura e metodi che comprometteno la flessibilità. Nonostante questi malintesi, è possibile ridimensionare correttamente i principi Agile. Per informazioni sul superamento di queste difficoltà, vedere Scalabilità agile a team di grandi dimensioni.
• Agile non è inefficiente. Per adattarsi alle esigenze mutevoli dei clienti, gli sviluppatori investono tempo ogni iterazione per dimostrare un prodotto funzionante e raccogliere feedback. È vero che questi sforzi riducono il tempo dedicato allo sviluppo. Ma incorporando le richieste dei clienti prima di risparmiare tempo significativo in un secondo momento. Quando le funzionalità rimangono allineate alla visione del cliente, gli sviluppatori evitano importanti revisioni in linea.
• Agile non è una soluzione adatta alle applicazioni di oggi, che spesso si centrano sullo streaming di dati. Questi progetti in genere comportano più carichi di lavoro di modellazione dei dati e estrazione-trasformazione-caricamento (ETL) rispetto alle interfacce utente. Questo fatto rende difficile dimostrare software utilizzabile in base a una pianificazione coerente e rigorosa. Ma modificando gli obiettivi, gli sviluppatori possono comunque usare un approccio Agile. Invece di lavorare per eseguire attività a ogni iterazione, gli sviluppatori possono concentrarsi sull'esecuzione di esperimenti di dati. Invece di presentare un prodotto funzionante ogni poche settimane, possono mirare a comprendere meglio i dati.

Perché Agile?

Quindi perché chiunque consideri un approccio Agile? È chiaro che le regole di impegno per la creazione di software sono cambiate fondamentalmente negli ultimi 10-15 anni. Molte delle attività sembrano simili, ma il paesaggio e gli ambienti in cui li applichiamo sono notevolmente diversi.

• Confrontare ciò che è come acquistare software oggi con i primi anni '2000. Con quale frequenza le persone guidano al negozio per acquistare software aziendale?
• Valutare il modo in cui i commenti e i suggerimenti vengono raccolti dai clienti sui prodotti. In che modo un team ha capito cosa pensavano le persone sul loro software prima dei social media?
• Considerare la frequenza con cui un team desidera aggiornare e migliorare il software che offre. Gli aggiornamenti annuali non sono più fattibili contro la concorrenza moderna.

Diego Lo Guidice di Forrester dice che è meglio nel suo blog, Transforming Application Delivery (ottobre 2020).

"Tutto è cambiato radicalmente. La sostenibilità, oltre al verde e alla pulizia, significa che quello che costruiamo oggi deve essere facilmente e rapidamente cambiato domani. I piani strategici sono a breve termine e la pianificazione e il cambiamento sono continui." - Diego Lo Guidice, Forrester

Le regole sono cambiate e le organizzazioni in tutto il mondo ora adattano il loro approccio allo sviluppo software di conseguenza. I metodi e le procedure Agile non promettono di risolvere ogni problema. Ma promettono di stabilire una cultura e un ambiente in cui le soluzioni emergono attraverso la collaborazione, la pianificazione e l'apprendimento continui e il desiderio di distribuire software di alta qualità più spesso.

Passaggi successivi

Decidere di seguire il percorso Agile per lo sviluppo di software può introdurre alcune interessanti opportunità per migliorare il processo DevOps. Un insieme chiave di considerazioni è incentrato sul confronto e sul contrasto dello sviluppo Agile con l'approccio corrente di un'organizzazione.