Ho usato principalmente la metodologia waterfall sui miei progetti, ma ora sto espandendo i miei orizzonti in metodologie agili. Da quello che ho letto finora, e forse ho letto le cose sbagliate, agile significa piccole cascate. Invece di una grande cascata si sviluppa per uno o due anni, hai piccole cascate che durano settimane o forse un paio di mesi al massimo.
La mia comprensione è corretta o c'è dell'altro? Quali sono le filosofie agili?
A un livello semplice, sì. Semplicemente eseguire una cascata ogni due settimane non fa sei agile , ma è iterativo (che è metà di agile).
Il modello a cascata definisce le fasi: requisiti, architettura, progettazione, implementazione, verifica (test), convalida (test di accettazione) e rilascio. In qualsiasi metodologia iterativa, si passa attraverso ciascuna di queste fasi all'interno di ogni iterazione. Potrebbe esserci una sovrapposizione tra loro, ma si ottengono e si acquisiscono i requisiti, si adottano l'architettura e il design del sistema per consentire l'implementazione, sviluppare le nuove funzionalità o correggere i difetti, testare i nuovi moduli e quindi presentarli al cliente per l'accettazione test e implementazione.
Tuttavia, è molto più agile del semplice iterativo e incrementale. Gli inquilini di agile vengono catturati nel Manifesto per lo sviluppo di software agile . Ci sono quattro punti chiave fatti nel Manifesto:
Individuals and interactions over processes and tools
Coinvolgi frequentemente persone individuali. Molte implementazioni sono incentrate su team auto-organizzanti e autodiretti. Quasi tutti hanno frequenti interazioni con il cliente o qualcuno che ha la voce del cliente. Piuttosto che avere un insieme formale di procedure da seguire e strumenti da usare, lasci che le persone che lavorano al progetto guidino il modo in cui il progetto viene eseguito per consentirgli di farlo nel miglior modo possibile.
Working software over comprehensive documentation
In un progetto software, l'obiettivo principale è la consegna del software. Tuttavia, in alcuni progetti, c'è una produzione sprecata di documenti che non aggiunge valore. Scott Ambler ha scritto un buon articolo su Agile / Lean Documentation . Non si tratta di produrre documentazione, ma di scegliere la documentazione che aggiunge valore al tuo team, ai futuri sviluppatori, al cliente o all'utente. Piuttosto che produrre documentazione che non aggiunge valore, i tuoi ingegneri del software stanno invece producendo software e test associati.
Customer collaboration over contract negotiation
Piuttosto che definire termini, orari e costi in anticipo, diventa un impegno continuo con il cliente. Ad esempio, potresti acquisire le tue esigenze sotto forma di storie di utenti e assegnarle dei punti. Dopo alcune iterazioni, stabilisci una velocità (punti / iterazione) e puoi determinare quante funzioni il tuo team può implementare in una iterazione. Poiché il cliente fornisce un feedback su quali funzionalità aggiungono il maggior valore, può decidere quando il progetto viene eseguito in qualsiasi momento. Qualsiasi numero di cose può accadere con consegne frequenti e interazione con il cliente - i requisiti sono stati soddisfatti e il progetto si conclude con la manutenzione e alla fine del ciclo di vita, il cliente scopre che non hanno bisogno di tutto ciò che pensavano così decide di terminare progetto, il progetto sta fallendo e il cliente lo vede presto e può cancellarlo ... la lista continua.
Responding to change over following a plan
Non hai un grande progetto o un piano definitivo in anticipo e devi eseguire una rilettura ogni volta che il progetto o il piano deve cambiare. Continui a stimare e revisionare le stime in base alle informazioni che hai. Scegli attentamente le tue metriche per fornire informazioni sulla salute del progetto e quando apportare modifiche interne. Spesso aggiungi, rimuovi e riorganizzi i requisiti con il cliente. In definitiva, comprendi che il cambiamento è l'unica costante.
Essere agili significa concentrarsi sulle persone e soddisfare i loro bisogni offrendo rapidamente software di alta qualità e valore aggiunto. Quando le esigenze del cliente cambiano, ti adegui a quelle esigenze per concentrarti sull'aggiunta di valore. Esistono implementazioni specifiche di metodologie agili, ma sono tutte incentrate sulle persone, la consegna tempestiva del software funzionante e l'adattamento a un ambiente in rapida evoluzione.
Sì e no - il processo attuale può essere visto come una serie di piccole cascate, ma la differenza è che il processo si evolve e viene migliorato dall'input dell'intero team (dev, qa, business ecc.), in retrospettive, che dovrebbe portare a un'unità molto più rigida, in grado di reagire ai problemi e pianificare e consegnare accuratamente. Sto grossolanamente per semplificarlo qui, c'è molto di più, ma non penso che questo sia un brutto punto di partenza.
Direi che è un modo semplicistico di metterlo. Sì, quando ci si abbassa, si tratta di piccoli flussi d'acqua, ma c'è molto di più dietro che lo fa funzionare. Un'intera metodologia che cambia il modo in cui ti avvicini ai progetti ... Per non parlare della mentalità necessaria per questo.
Se sei serio su Agile, ecco una buona (e lunga) serie di webcast a cui potresti essere interessato:
Dimentica Agile un minuto, pensa a cosa si intende per "cascata".
Esiste una fase dei requisiti, in cui tutti cercano di capire quali sono i problemi che il prodotto finale deve risolvere. La gente ne discute per un po 'e poi tutti firmano una serie di requisiti. A questo punto, il tuo ambito è definito, i contratti sono firmati e il cliente può allontanarsi e aspettare che arrivi un prodotto che risolva quei requisiti definiti.
Poi c'è una (o forse due) fasi progettuali. I progettisti (che possono o meno essere sviluppatori), discutono su COME il sistema deve andare insieme per soddisfare i requisiti firmati. Potrebbero verificarsi dei problemi se non capiscono un requisito, il che potrebbe significare che devono tornare al cliente, potenzialmente riaprire la fase dei requisiti (e ottenere un altro giro di assunzioni) o almeno impostare la gestione del cambiamento in azione . Spesso, i progettisti fanno semplicemente la loro ipotesi migliore. Possono venire con un modello di dati logici e un sacco di UML che descrive un nuovo sistema e come dovrebbe funzionare. Quindi si disconnettono.
Ora gli sviluppatori iniziano effettivamente a programmare, in base al design firmato. Potrebbero verificarsi dei problemi se non capiscono il progetto, il che potrebbe significare che devono tornare al progettista, potenzialmente riaprire la fase di progettazione (e ottenere un altro giro di approvazioni) o almeno impostare la gestione del cambiamento in azione . A loro volta, i progettisti possono rendersi conto che la confusione risponde davvero ai requisiti, il che significa che devono riaprire le discussioni sui requisiti, i firmamenti e ulteriori cambiamenti di gestione. Spesso i programmatori (che hanno una scadenza incombente) fanno semplicemente la loro ipotesi migliore. Fanno quello che possono per fare codice funzionale. Quindi lo rilasciano per il test.
Ora inizia la fase di test del sistema. I test dei tester si basano sulla loro comprensione dei requisiti e del design e registrano quelli che percepiscono come difetti in un sistema di tracciamento bug / gestione dei cambiamenti, facendo in modo che gli sviluppatori si riavviano, a meno che non vedano il problema come difetto di progettazione, che lo rimanda al design, ecc ... Alla fine i test di sistema passano e vengono firmati.
Infine, il cliente torna e fa test di accettazione utente sul nuovo sistema. È qui che decidono se la soluzione testata dai tester, gli sviluppatori sviluppati e i progettisti progettati è in realtà ciò che vogliono. Se non lo è, è potenzialmente necessario tornare alla fase di progettazione o addirittura rivedere i requisiti.
L'idea alla base della cascata è che è difficile (e molto indesiderabile) tornare una volta completata una fase. Diverse persone sono generalmente coinvolte in diverse fasi, quindi ci sono più hand-off - ognuno dei quali introduce un sacco di rischi per l'interpretazione errata e la perdita di informazioni. C'è anche un divario significativo tra quando i clienti dicono quello che vogliono e quando vedono cosa è stato costruito, in quale momento le reali esigenze potrebbero essere cambiate molto bene.
Le metodologie agili si concentrano su una strong comunicazione e cooperazione tra tutte le parti interessate. Il principio "Collaborazione del cliente per la negoziazione del contratto" significa che non dovresti dover passare attraverso una serie di accordi e di licenziamenti, ma invece dovresti semplicemente lavorare insieme al cliente, ogni iterazione che determina i requisiti per un pezzo del puzzle e formando immediatamente test, un design e un codice funzionante - con tutti i giocatori che comunicano il più direttamente possibile (eliminando costi e rischi di hand-off). Il codice di lavoro è rapidamente testabile dal cliente, eliminando i rischi di ritardi. Tutte le attività avvengono in un turbinio collaborativo, non in un flusso verso il basso.
Per un'eccellente panoramica di ciò che le metodologie agili cercano di fare, consiglio vivamente l' Agile Software Development: The Cooperative di Allistair Cockburn Gioco .
Is that correct or is there more to it than that
Entrambi. Sì, questo è un sommario accurato del concetto, ma c'è un molto di dettagli riassunti. Voglio dire, praticamente ogni aspetto dei cambiamenti di pianificazione quando si pianifica solo per la prossima settimana invece del prossimo anno.
Se si osserva la struttura statica (definizione del processo) di un progetto agile, sembra che si tratti di molte piccole cascate sì. Ma l'obiettivo di un progetto agile è ottenere feedback più rapidi e migliori .
Il manifesto agile evidenzia alcune differenze tra agile e cascata (come percepito da chi ha firmato).
Realmente "agile" spesso significa cascate di 1-2 giorni, non di settimane. Ciò non significa che non segui un piano generale e che i cicli di rilascio reale siano 1-2 giorni. Ma dovresti provare ad avere un prodotto funzionante e testato ogni giorno, e potresti rilasciarlo - in teoria - tutti i giorni.
Scrum, ad esempio, usa sprint di 4 settimane, ma uno sprint non è solo una cascata (almeno, non dovrebbe essere). Puoi cambiare le priorità ogni giorno quando vedi che qualcosa non va come era stato pianificato all'inizio dello sprint.
Sì, è più o meno corretto. C'è stato molto scritto e discusso su come affrontarlo, ma un mucchio di piccole cascate è il punto cruciale.
L'implementazione specifica di come utilizzare un gruppo di piccole cascate non è tuttavia banale. Ad esempio, non passerai dal realizzare grandi progetti in un paio d'anni a realizzare una serie di piccoli progetti. C'è ancora il grande progetto con 1-2 anni di lavoro da mettere dentro. Quindi è necessario suddividere il grande progetto in una serie di piccoli progetti. Può sembrare abbastanza ovvio, ma riempie pagine e pagine di libri.
Leggi altre domande sui tag development-process agile