Approcci agile e a cascata

• I requisiti dettagliati del prodotto e la documentazione consentono ai nuovi programmatori di eseguire l'onboarding in modo rapido e semplice.
• La documentazione fornisce un ambito chiaro del progetto, consentendo ai project manager di comunicare budget, tempistiche e traguardi chiave alle parti interessate.

• I clienti possono avere difficoltà a delineare tutte le loro esigenze all'inizio del progetto, con conseguenti lacune nella documentazione.
• Una collaborazione minima con il cliente durante il processo di sviluppo può portare a modifiche costose se il prodotto non soddisfa le aspettative.
• I tester segnalano problemi e bug in una fase successiva del processo, che avrebbero potuto informare un'architettura di programma alternativa.

A differenza dello sviluppo a cascata, lo sviluppo agile è caratterizzato dal suo approccio iterativo alla gestione dei progetti. Invece di redigere lunghi requisiti di progetto all'inizio, un team agile suddivide il prodotto in caratteristiche specifiche e affronta ognuna di esse in base a un vincolo di tempo specifico, noto come sprint.

La gestione agile dei progetti richiede un team interfunzionale e auto-organizzato, composto in genere da cinque a nove membri. Insieme, sviluppano un software utilizzabile durante ogni sprint, che si combina con altro codice funzionale delle iterazioni precedenti. Entro la fine del timebox dello sprint, il team presenta il proprio lavoro agli stakeholder per ottenere feedback, permettendo così maggiore flessibilità nel loro approccio allo sviluppo software. Poiché il team ha accesso a feedback frequenti, può adattare la roadmap del prodotto durante il ciclo di vita dello sviluppo per garantire che la funzionalità soddisfi davvero le aspettative degli utenti. In un approccio a cascata, il coinvolgimento del cliente coincide tipicamente con la consegna del prodotto finale, che può essere costoso quando i requisiti vengono interpretati in modo errato o documentati in modo errato.

Ci sono state 17 persone che hanno trovato il sistema di gestione dei progetti a cascata altamente inefficace e, nel 2001, le loro idee sul processo di sviluppo software hanno portato a un lavoro noto come "Agile Manifesto". Questo documento evidenzia valori e principi specifici a cui dare priorità nei flussi di lavoro di sviluppo software e ha prodotto una serie di framework agili popolari, come Scrum, Kanban, Feature Driven Development (FDD) ed Extreme Programming. Da allora, lo sviluppo agile del software ha acquisito sempre più popolarità, soprattutto se confrontato con il modello a cascata.

Ispirato al gioco del rugby, il metodo Scrum agile enfatizza il lavoro di squadra per raggiungere i risultati, in modo simile al modo in cui i giocatori devono lavorare insieme in una mischia per entrare in possesso di un pallone da rugby. Le competenze del team Scrum agile variano, ma di solito includono i seguenti ruoli:

• Product owner: questo membro del team rappresenta le esigenze del cliente e dell'azienda. Creando storie utente, il team può capire come una richiesta di caratteristiche può aiutare a risolvere un problema specifico e queste storie formulano il backlog di attività che il team deve affrontare. Questa persona dà priorità anche alle storie in base al loro valore per il cliente, il che dovrebbe, in teoria, tradursi in valore per l'azienda. Sebbene il product owner guidi il team in questo modo, non stabilisce scadenze né istruisce il team su come fornire il lavoro.
• Scrum master: questo membro del team facilita l'intero processo di sviluppo agile. Simile a un project manager, questa persona mantiene il team impegnato, assicurando che il team rimanga concentrato durante il progetto. Può anche agire come parte neutrale per mediare i disaccordi tra i membri del team. Ad esempio, i membri del team potrebbero non essere d'accordo su quanto affrontare in un determinato sprint. I product owner, in particolare, possono esercitare pressioni sui team affinché si impegnino a consegnare più di quanto possano effettivamente realizzare nel tempo a disposizione. In questi casi, gli Scrum master possono ricordare ai membri del team l'ambito del loro ruolo nel team.

Gli altri membri del team di un team agile possono variare, ma in genere includono utenti di diverse discipline, come progettazione, analytics, controllo qualità e sviluppo. Queste persone collaborano insieme per decidere quanto lavoro intraprendere e come completarlo.

Le metodologie agili sono definite anche dalle modalità con cui il team si unisce. Ci sono riunioni specifiche che aiutano a facilitare il workflow in tutto il team. Tra queste rientrano le seguenti:

• Pianificazione dello sprint: durante questo incontro, il team si riunisce per determinare quali storie faranno parte dello sprint corrente. Il product owner darà priorità alle storie utente, ma il resto del team dovrà concordare quante e quali storie utente potrà completare durante quel periodo di tempo prestabilito.
• Daily standup: questi brevi incontri sono noti anche come "daily scrum". In questi momenti di allineamento, ogni membro del team aggiorna sugli avanzamenti personali, sulle prossime attività e su eventuali blocchi o dipendenze che potrebbero creare ritardi.
• Demo: questo incontro mostra il software funzionante che il team ha completato nel corso dello sprint, che può variare da due a quattro settimane. Il product owner determinerà se una storia utente soddisfa la definizione di "completata". In caso contrario, il backlog di prodotti potrebbe essere modificato per tenere conto di eventuali lacune. Questa è anche un'opportunità per il team di presentare agli stakeholder il feedback.
• Retrospettiva: questo tempo è riservato all'introspezione del team, in cui il team identifica come migliorare il workflow per ottenere migliori risultati in futuro

• La progettazione in team facilita una maggiore collaborazione.
• Lo sviluppo del prodotto adotta un approccio di progettazione adattiva.
• Poiché il codice viene testato a ogni iterazione nella fase di sviluppo, i difetti del codice possono informare la progettazione futura del software.
• Tende a garantire una maggiore soddisfazione del cliente poiché un feedback frequente porta a dare maggiore priorità alle esigenze del cliente.
• Consente l'integrazione continua poiché ogni caratteristica è un software utilizzabile a sé stante.
• Questo tipo di sviluppo software lean può portare a una riduzione dei costi in quanto vi è meno rischio di disallineamento tra clienti e prodotti.

• Un approccio agile può non disporre di una documentazione completa. Questo rende difficile l'inserimento di nuovi sviluppatori, le tempistiche dei progetti per gli stakeholder e la fornitura di stime accurate dei costi.
• Può essere difficile da scalare.

Sebbene i team di sviluppo abbiano avuto successo con entrambi gli approcci di gestione dei progetti, c'è sicuramente più slancio intorno ai processi agili. Non è difficile capirne il motivo quando osserviamo i benefici che può offrire alle aziende oggi. Sebbene esistano diversi strumenti di gestione dei progetti che possono aiutare i team a tenere traccia dei progressi, IBM può anche fornire sistemi per consentire agli sviluppatori di codificare in modo più agile.