L'industria dei computer è piena di linguaggio ambiguo, gergo duro e idee complesse che sono difficili da capire e possono mandare la tua mente in una frenesia di buffering computazionale.
Cascata? Mischia? Agile?
Se queste frasi ti sono completamente estranee, non preoccuparti; il tuo utile team di fanatici della tecnologia HashDork è qui per aiutarti a capire le distinzioni tra queste fasi cruciali del processo di sviluppo in modo che tu possa diventare informato.
Le tecniche agili, di mischia e a cascata saranno tutte trattate in questo post del blog, insieme a come ciascuna può aiutare il tuo team nel suo insieme.
Cominciamo con l'agile e porteremo con noi il resto.
Cos'è Agile?
Lo sviluppo agile del software segue un approccio iterativo e incrementale. Piuttosto che una preparazione approfondita all'inizio di un progetto, le tecniche Agile sono flessibili alle mutevoli esigenze nel tempo e promuovono un feedback continuo da parte degli utenti finali.
I team interfunzionali lavorano sulle iterazioni del prodotto nel tempo e questo lavoro è classificato in un backlog e classificato in base al valore aziendale o del cliente. Lo scopo di ogni iterazione è creare un prodotto utilizzabile.
La leadership promuove la cooperazione, la responsabilità e la comunicazione faccia a faccia nelle metodologie Agile.
Gli stakeholder e gli sviluppatori aziendali devono collaborare per garantire che il prodotto soddisfi le esigenze del consumatore e gli obiettivi dell'azienda.
L'espressione "sviluppo agile" si riferisce a una varietà di metodi e strutture che si basano sugli ideali e sui principi delineati nel Manifesto Agile.
Gli esperti consigliano di aderire a principi e valori agili e di utilizzarli come guida per decidere le azioni giuste da intraprendere in un particolare ambiente mentre ci si avvicina allo sviluppo del software.
Il team collaborativo e auto-organizzato sono le principali aree di interesse per la comunità di sviluppo software agile.
I team possono decidere autonomamente come affrontare un particolare progetto, ma ciò non significa che i supervisori siano inesistenti. I team agili sono quindi interfunzionali.
In un paradigma agile, i manager sono ancora necessari. Si assicurano che ogni membro del team abbia o acquisisca le capacità necessarie per il progetto.
I manager in un quadro agile operano favorendo un'atmosfera che fa emergere il meglio nella squadra. Ma invece di prendere il comando, spesso passano in secondo piano e lasciano che la squadra decida come consegnare le cose.
I manager vengono coinvolti solo quando i team cercano ripetutamente di risolvere i problemi senza successo.
Ciclo di sviluppo agile
Di seguito sono elencate le fasi del ciclo di sviluppo Agile. È fondamentale ricordare che queste fasi non dovrebbero svolgersi in ordine perché sono flessibili e in continua evoluzione. Molte di queste fasi si svolgono simultaneamente.
- Pianificazione: Dopo che un team di progetto ha deciso che un'idea è pratica e realizzabile, inizia a cercare le caratteristiche. Questa fase mira a dare priorità a ciascuna caratteristica e assegnarla a un'iterazione dopo aver suddiviso l'idea in pezzi più piccoli (le caratteristiche).
- Analisi dei requisiti: per determinare i requisiti aziendali, questo passaggio prevede diverse discussioni con i gestori, le parti interessate e gli utenti. Chi utilizzerà il prodotto e come lo utilizzerà sono tra i dettagli che il team deve raccogliere. Questi standard devono essere specifici, applicabili e quantitativi.
- Design: I requisiti trovati nella fase precedente vengono utilizzati per preparare il sistema e la progettazione del software. Le considerazioni sull'aspetto del prodotto o della soluzione devono essere fatte dal team. Il team di test sviluppa anche una strategia o un piano per il test.
- Implementazione, codifica o sviluppo: l'obiettivo di questa fase è la creazione e la valutazione delle funzionalità e la pianificazione dell'implementazione delle iterazioni (seguendo l'approccio di sviluppo iterativo e incrementale [IID]). Poiché non vengono fornite funzionalità, inizia l'iterazione 0 del periodo di sviluppo. Completando attività come appalti, impostazione di impostazioni e finanziamenti, questa iterazione fornisce le basi per la crescita futura.
- Testing: Dopo che il codice è stato creato, viene testato rispetto ai requisiti per garantire che il prodotto soddisfi realmente le richieste degli utenti e soddisfi gli obiettivi aziendali. In questa fase vengono eseguiti test di unità, integrazione, sistema e accettabilità.
- Distribuzione: Dopo il test, il prodotto viene inviato ai clienti in modo che possano utilizzarlo. Tuttavia, il progetto non è terminato dopo la distribuzione. I clienti possono riscontrare ulteriori problemi dopo aver iniziato a utilizzare il prodotto, che richiederà al team di progetto di trovare una soluzione.
Vantaggi
- Consegna più veloce e di qualità superiore: suddividendo il progetto in iterazioni (unità gestibili), il team è in grado di concentrarsi su collaborazione, sviluppo e test di qualità superiore. Quando il test viene eseguito a ogni iterazione, i problemi vengono rilevati e risolti più rapidamente. Inoltre, con continue e successive revisioni, questo software di alta qualità può essere fornito più rapidamente.
- Il cambiamento è benvenuto: Sebbene i cicli di pianificazione siano più brevi, è semplice accettare e accogliere le modifiche in qualsiasi momento del progetto. Il backlog può sempre essere migliorato e ridefinito le priorità, consentendo ai team di apportare modifiche al progetto in un paio di settimane.
- L'obiettivo finale potrebbe non essere noto: Agile è eccellente per i progetti in cui l'obiettivo finale non è chiaramente definito. Man mano che il progetto avanza, gli obiettivi diventeranno chiari e lo sviluppo sarà in grado di soddisfare prontamente queste mutevoli esigenze.
- Miglioramento continuo: i programmi agili promuovono l'input dell'utente e del team in tutte le fasi del progetto, consentendo l'applicazione di quanto appreso per migliorare l'iterazione successiva.
- Le opinioni dei clienti sono apprezzate: Ci sono diverse opportunità per i clienti di guardare il completamento del lavoro, offrire feedback e influenzare davvero il risultato finale. Interagendo così intimamente con il team di progetto, potrebbero sviluppare un senso di appartenenza.
- Forte lavoro di squadra: Agile sottolinea il significato della comunicazione regolare e degli incontri di persona. Le persone possono assumersi responsabilità e possedere determinati componenti del progetto quando lavorano in team.
Svantaggi
- I membri del team devono avere conoscenzae: I team Agile sono spesso piccoli. Pertanto, i membri del team devono avere una vasta gamma di abilità. Inoltre, devono comprendere e sentirsi a proprio agio utilizzando la tecnica Agile selezionata.
- La pianificazione potrebbe essere meno precisa: A volte potrebbe essere difficile determinare una data di consegna esatta. Agile si basa su consegne prestabilite e i project manager spesso riorganizzano le priorità delle attività. Pertanto, è probabile che alcuni dei risultati finali inizialmente programmati per la consegna non vengano completati in tempo. Inoltre, è possibile aggiungere più sprint in qualsiasi momento durante il progetto, allungando l'intero programma.
- La documentazione può essere ignorata: Alcuni membri del team potrebbero ritenere che concentrarsi sulla documentazione sia meno cruciale poiché il Manifesto Agile privilegia il software funzionante al di sopra della documentazione completa. I team agili dovrebbero trovare l'equilibrio ideale tra documentazione e dialogo, anche se una documentazione completa non può garantire da sola il successo del progetto.
- L'output finale potrebbe differire notevolmente: Potrebbe non esserci stata una strategia chiara per il progetto Agile iniziale, e quindi il risultato finale potrebbe cambiare notevolmente rispetto a quanto inizialmente previsto. Un output finale sostanzialmente diverso può derivare dall'aggiunta di nuove iterazioni in base alla modifica dell'input del client, poiché Agile è così adattabile.
- Impegno di tempo degli sviluppatori: Il team di sviluppo deve essere pienamente impegnato nel progetto affinché agile sia efficace. Il metodo Agile, che richiede più tempo di un approccio convenzionale, richiede una partecipazione e una cooperazione attiva costanti. Inoltre, implica che gli sviluppatori devono impegnarsi per l'intera lunghezza del progetto.
Cos'è la cascata?
L'iterazione più popolare del ciclo di vita di sviluppo del sistema (SDLC) per progetti di ingegneria del software e IT è nota come "approccio a cascata", che segue una procedura lineare e sequenziale.
Per pianificarlo viene occasionalmente utilizzato un diagramma di Gantt, una forma di grafico a barre che mostra le date di inizio e fine di ogni lavoro.
Il team di sviluppo avanza al livello successivo al termine di una delle otto fasi. La squadra non è in grado di tornare a una fase precedente senza dover riavviare l'intera procedura.
Inoltre, il cliente potrebbe dover valutare e accettare i requisiti prima che il team possa passare al livello successivo.
Il modello a cascata è stato sviluppato negli ambienti altamente organizzati dei settori manifatturiero e delle costruzioni, dove gli adeguamenti potrebbero essere proibitivi o addirittura impossibili.
La tecnica della cascata è così chiamata perché è pensata per fluire in una sola direzione, verso il basso, proprio come una cascata. Le sue fasi includono analisi, avvio, test, progettazione, costruzione, distribuzione, manutenzione e test.
La tecnica a cascata ha diversi vantaggi, proprio come qualsiasi altra strategia. Uno è che le fasi di progettazione e progettazione sono più consolidate.
I clienti e il team di sviluppo sono più allineati quando si tratta di risultati del progetto durante l'utilizzo dello sviluppo di software a cascata. Poiché sei a conoscenza dell'ambito del progetto sin dall'inizio, lo sviluppo a cascata semplifica anche il monitoraggio dell'avanzamento.
Il processo a cascata utilizza specialisti, sviluppatori, analisti e tester per concentrarsi sui loro lavori nel progetto, piuttosto che fare in modo che l'intero team enfatizzi un passaggio.
Fasi della cascata
I sei passaggi della Cascata devono avvenire tutti uno dopo l'altro:
- Requisiti di raccolta e archiviazione: Dovresti accumulare una conoscenza approfondita di ciò che questo progetto richiede in questo momento. Esistono diverse tecniche per raccogliere questi dati, tra cui interviste, sondaggi e brainstorming collaborativo. Le esigenze del progetto dovrebbero essere evidenti al termine di questa fase e il tuo team dovrebbe aver ricevuto una copia del documento dei requisiti.
- Il progetto di un sistema: Il sistema è progettato dal tuo team utilizzando specifiche predeterminate. Durante questa fase, non viene eseguita alcuna codifica, ma il team stabilisce i requisiti per l'hardware o il linguaggio di programmazione.
- Implementazione: Questa fase prevede la codifica. I dati della fase precedente vengono utilizzati dai programmatori per creare un prodotto utilizzabile. Il codice è spesso implementato in piccoli blocchi che vengono combinati alla conclusione di una fase o all'inizio di un'altra.
- Testing: Il prodotto può iniziare a essere testato dopo il completamento del codice. Eventuali problemi vengono meticolosamente rilevati e segnalati dai tester. Il tuo progetto potrebbe dover tornare alla fase uno per la rivalutazione se si presentano problemi significativi.
- Consegna/distribuzione: il prodotto è terminato a questo punto e il tuo team invia i risultati finali per la distribuzione o il rilascio.
- Assistenza: Il cliente ha ricevuto il prodotto e lo sta utilizzando. Il tuo team potrebbe aver bisogno di sviluppare correzioni e aggiornamenti quando si presentano problemi per risolverli. Anche in questo caso, problemi significativi possono richiedere un ritorno al passaggio uno.
Vantaggi
- Semplice da usare e gestire: L'approccio Waterfall è semplice da usare e da comprendere poiché ogni progetto viene gestito nello stesso modo sequenziale. Prima di iniziare un progetto Waterfall, al team non è richiesta alcuna esperienza o formazione pregressa. L'approccio a cascata è molto rigoroso; ogni fase ha una serie di risultati finali e una revisione, semplificando l'amministrazione e la manutenzione.
- È necessaria una metodologia ben documentata: La documentazione richiesta dalla metodologia a cascata aiuta a chiarire il ragionamento alla base dei test e del codice. Inoltre, crea una traccia cartacea nel caso in cui le parti interessate desiderino ulteriori informazioni su una determinata fase o per iniziative future.
- Applicazione della disciplina: ogni fase di un progetto a cascata ha un inizio e una fine, semplificando la comunicazione dei progressi agli stakeholder e ai clienti. Il team può ridurre la possibilità di perdere una scadenza inserendo i requisiti e il design prima di produrre il codice.
Svantaggi
- Può essere difficile raccogliere requisiti precisi: Parlare con i consumatori e le parti interessate per determinare le loro esigenze è una delle fasi iniziali di un progetto Waterfall. In questa fase iniziale del progetto, potrebbe essere difficile accertare i loro requisiti particolari. I clienti vengono spesso a conoscenza delle loro esigenze man mano che il progetto si sviluppa piuttosto che esprimerle in anticipo.
- I cambiamenti sono difficili da accogliere: L'equipaggio non può riprendere il lavoro dopo aver terminato una fase. È molto difficile e costoso tornare indietro e ripararlo se durante la fase di test vengono a sapere che la funzionalità mancava durante il processo dei requisiti.
- Il software viene fornito dopo la data di scadenza: Prima che la codifica vera e propria possa iniziare, devono essere completate da due a quattro fasi del progetto. Di conseguenza, le parti interessate non vedranno il software funzionale fino alla fine del ciclo di vita.
Cos'è Scrum?
Uno dei framework di processo più apprezzati per mettere in pratica Agile è Scrum, che è un sottoinsieme di Agile.
È un paradigma iterativo per la gestione della creazione di software e prodotti complessi. Gli sprint, che sono iterazioni di durata fissa che durano da una a due settimane, consentono al team di rilasciare il software in base a una pianificazione regolare.
Le parti interessate e i membri del team si riuniscono per discutere i prossimi passi dopo ogni sprint. I ruoli, le responsabilità e gli incontri in Scrum rimangono costanti.
Ad esempio, Scrum specifica la pianificazione dello sprint, lo stand-up giornaliero, la demo dello sprint e la retrospettiva dello sprint come i quattro rituali che forniscono la struttura di ogni sprint.
Il team utilizzerà artefatti visivi come schede attività o grafici di burndown durante ogni sprint per dimostrare i progressi e ottenere feedback incrementali.
In Scrum, il team e il product owner lavorano a stretto contatto per identificare e dare priorità alle funzionalità del sistema. Raggiungono questo obiettivo creando un product backlog, che contiene tutte le attività necessarie per produrre software che funzioni come previsto.
Le patch di bug, i requisiti non funzionali e le funzionalità dovrebbero essere tutti inclusi nella coda. I team interfunzionali devono stimare e registrarsi per fornire incrementi software durante Sprint continui, che in genere durano 30 giorni, una volta stabiliti gli obiettivi.
Solo il team può aggiungere funzionalità allo Sprint dopo aver commesso il backlog per quello sprint.
Next Sprint delivery, il product backlog viene valutato e, se necessario, ridefinito le priorità e il seguente set di deliverable viene scelto per far parte dello sprint successivo.
Processo di mischia
- Arretrato del prodotto: Per ordinare gli articoli nel product backlog, il Product Owner e lo Scrum Team si incontrano (il lavoro sul product backlog deriva dalle storie e dai requisiti degli utenti). Il product backlog è un elenco di tutte le funzionalità desiderate per il prodotto piuttosto che un elenco di attività che devono essere completate. Successivamente, il team di sviluppo seleziona le attività dal product backlog da eseguire durante ogni sprint.
- Pianificazione dello sprint: prima di ogni sprint, il Product Owner consegna al team gli elementi principali del backlog in una riunione di pianificazione dello sprint. Il gruppo seleziona quindi gli elementi dal product backlog che possono completare durante lo sprint e li sposta nello sprint backlog (che è un elenco di attività da completare nello sprint).
- Affinamento/grooming del backlog: per garantire che il backlog sia preparato per lo sprint successivo, il team e il product owner si incontrano alla conclusione di uno sprint. Il team può scartare le storie degli utenti che non sono più pertinenti, aggiungerne di nuove, rivedere l'ordine in cui dovrebbero essere affrontate o dividere le storie degli utenti in attività più piccole. Durante questo incontro di “grooming”, ci si assicurerà che il backlog comprenda solo cose pertinenti, approfondite e in linea con gli obiettivi del progetto.
- Riunioni Scrum ogni giorno: In un incontro stand-up di 15 minuti chiamato Daily Scrum, ogni membro del team discute i propri obiettivi e gli eventuali problemi sorti. Ogni giorno durante lo sprint, il team partecipa al Daily Scrum, che tiene tutti al lavoro.
- Incontro per valutare lo sprintt: Il team presenta il proprio lavoro a uno sprint review meeting alla conclusione di ogni sprint. Invece di una relazione o di una presentazione PowerPoint, questo incontro dovrebbe includere una vera dimostrazione.
- Riunione sprint retrospettiva: Il team discute tutte le modifiche che devono essere apportate nello sprint successivo e il modo in cui Scrum sta lavorando per loro alla conclusione di ogni sprint. Il team può discutere gli aspetti positivi, gli aspetti negativi e le aree di miglioramento dello sprint.
Vantaggi
- Più responsabilità da parte della squadra: Non esiste un project manager che istruisca lo Scrum Team su cosa fare e quando. Il lavoro che si può portare a termine in ogni sprint viene invece deciso dalla squadra nel suo insieme. Tutti cooperano e si danno una mano l'un l'altro, migliorando il lavoro di squadra e promuovendo l'individualità in ogni membro del team.
- Migliore visibilità e trasparenza del progetto: Ci sono meno incomprensioni e incertezze poiché tutti i membri del team sono consapevoli delle proprie responsabilità grazie ai frequenti incontri in piedi. Il team può affrontare i problemi prima che sfuggano al controllo poiché i problemi vengono individuati in anticipo.
- Maggiore riduzione dei costi: La comunicazione costante tiene informato il team di eventuali problemi o modifiche non appena si verificano, il che aiuta a risparmiare sui costi e migliorare la qualità. I blocchi di funzionalità più piccoli forniscono un feedback continuo e consentono la correzione anticipata degli errori prima che gli errori più grandi diventino troppo costosi da correggere.
- Semplice da adattare ai cambiamenti: È più semplice affrontare e adattarsi ai cambiamenti quando ci sono frequenti cicli di feedback e brevi sprint. A titolo illustrativo, se il team si imbatte in una storia utente nuova di zecca durante uno sprint, può aggiungere rapidamente quella funzionalità allo sprint successivo durante la riunione di perfezionamento del backlog.
Svantaggi
- Osserva il pericolo di scorrimento: A causa della mancanza di una data di completamento prestabilita, alcuni progetti Scrum potrebbero subire un'oscillazione dell'ambito. Gli stakeholder potrebbero essere indotti a continuare a richiedere più funzionalità se non c'è una scadenza per il completamento.
- Un cattivo Scrum Master può far deragliare tutto: Un project manager non è lo stesso di uno Scrum Master. Lo Scrum Master deve fidarsi del team che sta supervisionando e non dare loro mai istruzioni. Lo Scrum Master non ha potere sulla squadra. Il progetto fallirà se lo Scrum Master tenterà di gestire il team.
- Problemi di precisione potrebbero derivare da attività dichiarate male: Se le attività non sono chiaramente specificate, le spese e le pianificazioni del progetto non saranno accurate. La pianificazione diventa impegnativa e gli sprint possono richiedere più tempo del previsto se gli obiettivi iniziali non sono definiti.
- Esperienza e dedizione sono necessarie per una squadra: Affinché la squadra abbia successo, i ruoli e i doveri devono essere chiaramente definiti. Lo Scrum Team richiede membri del team con competenze tecniche perché non ci sono ruoli ben definiti (tutti fanno tutto). Il team deve anche impegnarsi a partecipare alle sessioni quotidiane di Scrum e restare unito per tutta la vita del progetto.
Agile vs Scrum
Anche se Agile e Scrum utilizzano la stessa metodologia, ci sono alcune variazioni tra i due. Il Manifesto Agile delinea una serie di principi per la creazione di software attraverso lo sviluppo iterativo.
Scrum, d'altra parte, è un insieme di linee guida che devono essere rispettate durante lo sviluppo del software Agile. Agile è un concetto, mentre Scrum è una tecnica per metterlo in pratica.
Scrum è un metodo per implementare Agile, quindi entrambi hanno molte cose in comune. Entrambi gli approcci sono iterativi, danno priorità alla consegna del software precoce e frequente e accettano il cambiamento. Supportano anche l'apertura e lo sviluppo continuo.
Agile Vs Cascata
Rigido vs flessibile descrive meglio le distinzioni tra il processo Waterfall e Agile. Mentre Agile è fluido e in continua evoluzione, Waterfall è una metodologia molto più rigida e rigida.
Queste ulteriori distinzioni tra di loro sono le seguenti:
- Agile non richiede un approccio lineare, mentre Waterfall è sequenziale.
- Sebbene i bisogni siano spesso predefiniti nei progetti Waterfall, si prevede che cambieranno e si adatteranno nelle iniziative Agile.
- A differenza di Agile, i progetti Waterfall non consentono di apportare modifiche a lavori che erano stati completati in una fase precedente.
- La cascata è una procedura organizzata in cui devi completare ogni passaggio prima di passare al successivo. Tuttavia, Agile è una metodologia flessibile che ti consente di procedere con il progetto al tuo ritmo.
Agile Vs Waterfall Vs Scrum
- La cascata aumenta la fiducia in ciò che verrà fornito molto presto dopo la pianificazione. Agile si basa sulle migliori pratiche dell'ambiente di sviluppo. In questo caso, è possibile gestire bene una serie di rischi di progetto poiché i risultati vengono continuamente valutati.
- Waterfall non prevede che il team e il progetto risiedano nella stessa posizione. Mentre Scrum e Agile hanno bisogno della co-locazione dei dipendenti.
- Agile si concentra sulla riduzione della rilavorazione del progetto e incoraggia l'integrazione dei cambiamenti molto prima. A differenza della cascata, che risponde in modo diverso, Scrum consente anche la scoperta precoce dei cambiamenti.
- Un progetto più compatto per il prodotto finale è fornito da agile e Scrum. Questo crea un problema con le promesse fatte all'acquirente. Al contrario, la grafica a cascata offre a clienti e sviluppatori una migliore impressione del risultato finale.
- Ognuna di queste tecniche ha una serie di strumenti per organizzare e simulare i compiti coinvolti nella loro creazione.
Conclusione
Se hai seguito fino ad ora e sei sicuro della tua conoscenza delle distinzioni tra i processi Waterfall, Agile e Scrum, dovresti già sapere quale strategia funzionerà meglio per te e il tuo team.
La tecnica Waterfall, che è per progetti con una portata, un periodo di tempo e un budget definiti, può essere la tua migliore opzione se ti piacciono le regole e le procedure rigide e scopri che portano chiarezza.
D'altra parte, se la libertà e l'adattabilità offerte da Agile ti ispirano, potrebbe essere dove dovresti porre la tua attenzione.
Scrum è la strada da percorrere, tuttavia, se desideri un po' di disciplina all'interno di una struttura flessibile.
Tuttavia, devi considerare questi approcci alla luce del progetto su cui stai lavorando e del tuo risultato finale.
Lascia un Commento