L'agile è più di una semplice cascata?

Ho usato principalmente la metodologia a cascata nei 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 che si sviluppa su uno o due anni, ci sono piccole cascate che durano settimane o forse pochi mesi al massimo.

La mia comprensione è corretta o c'è di più? Quali sono le filosofie agili?

A un livello semplice, sì. Semplicemente eseguire una cascata ogni due settimane non ti rende agile , ma è iterativo (che è la metà di agile).

Il modello a cascata definisce le fasi: requisiti, architettura, progettazione, implementazione, verifica (test), validazione (test di accettazione) e rilascio. In qualsiasi metodologia iterativa, attraversi ciascuna di queste fasi all'interno di ogni iterazione. Potrebbero esserci sovrapposizioni tra loro, ma si ottengono e si acquisiscono requisiti, si adotta l'architettura e la progettazione del sistema per consentire l'implementazione, sviluppare le nuove funzionalità o correggere i difetti, testare i nuovi moduli e quindi presentarlo al cliente per accettazione test e implementazione.

Tuttavia, c'è molto di più da agile che essere solo iterativi e incrementali. Gli inquilini di Agile vengono catturati nel Manifesto per lo sviluppo di software Agile . Ci sono quattro punti chiave fatti nel Manifesto:

Individui e interazioni su processi e strumenti

Coinvolgi spesso singole persone. Molte implementazioni sono incentrate su team auto-organizzati e auto-diretti. Quasi tutti hanno frequenti interazioni con il cliente o qualcuno che ha la voce del cliente. Anziché disporre di una serie formale di procedure da seguire e di strumenti da utilizzare, 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.

Software funzionante su documentazione completa

In un progetto software, l'obiettivo principale è la consegna del software. Tuttavia, in alcuni progetti, c'è una produzione dispendiosa di documenti che non aggiungono valore. Scott Ambler ha scritto un buon articolo sulla documentazione Agile / Lean . Non si tratta di non produrre documentazione, ma di scegliere la documentazione che aggiunge valore al tuo team, ai futuri sviluppatori, al cliente o all'utente. Invece di produrre documentazione che non aggiunge valore, i tuoi ingegneri software producono invece software e test associati.

Collaborazione con i clienti sulla negoziazione del contratto

Piuttosto che definire i termini e gli orari e i costi in anticipo, diventa uno sforzo continuo con il cliente. Ad esempio, potresti acquisire i tuoi requisiti sotto forma di storie utente e assegnare loro dei punti. Dopo alcune iterazioni, ti accontenti di una velocità (punti / iterazione) e puoi determinare quante funzioni la tua squadra può implementare in un'iterazione. Poiché i tuoi clienti forniscono feedback su quali funzionalità aggiungono il massimo valore, possono decidere quando il progetto viene svolto 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 della vita utile, il cliente scopre che non ha bisogno di tutto ciò che pensava, quindi decide di porre fine al progetto, il progetto non va a buon fine e il cliente lo vede presto e può annullarlo ...

Rispondere al cambiamento seguendo un piano

Non hai un grande progetto o un piano definitivo in anticipo e devi eseguire rilavorazioni ogni volta che quel progetto o piano deve cambiare. Stimate e rivedete continuamente le stime in base alle informazioni in vostro possesso. Scegli attentamente le tue metriche per fornire informazioni sullo stato del progetto e su quando apportare modifiche interne. Spesso aggiungi, rimuovi e ridistribuisci requisiti con il cliente. Alla fine, capisci che il cambiamento è l'unica costante.

Essere agili significa concentrarsi sulle persone e soddisfare le loro esigenze fornendo rapidamente software di alta qualità a valore aggiunto. Man mano che 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, sulla consegna tempestiva di software funzionante e sull'adattamento a un ambiente in rapido cambiamento.

Sì e no: il processo effettivo 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 (sviluppo, qa, attività, ecc.), Nelle retrospettive, che dovrebbe condurre a un'unità molto più stretta che è in grado di reagire ai problemi e pianificare e consegnare con precisione. Sto semplificando enormemente qui, c'è molto di più, ma non penso che questo sia un brutto punto di partenza.

Direi che è un modo semplicistico di dirlo. Sì, quando ci si arriva, sono piccoli flussi d'acqua, ma c'è molto altro dietro che lo fa funzionare. Un'intera metodologia che cambia il modo in cui approcci i progetti ... Per non parlare della mentalità necessaria per questo.

Se sei serio su Agile, ecco una buona (e lunga) serie di webcast che potrebbero interessarti:

http://autumnofagile.net/

Dimentica Agile un minuto, pensa cosa si intende per "cascata".

C'è una fase dei requisiti, in cui tutti cercano di capire quali problemi deve risolvere il prodotto finale. La gente ne discute per un po ', e poi tutti firmano su una serie di requisiti. A questo punto il tuo ambito di applicazione è definito, i contratti sono firmati e il cliente può allontanarsi e attendere che ti venga in mente un prodotto che risolva tali requisiti definiti.

Successivamente c'è una (o forse due) fasi di progettazione. I progettisti (che possono o meno essere gli sviluppatori) discutono su COME il sistema deve andare insieme per soddisfare i requisiti approvati. Possono verificarsi problemi se non comprendono del tutto un requisito, il che può significare che devono tornare dal cliente, riaprire potenzialmente la fase dei requisiti (e ottenere un altro round di approvazioni) o almeno attivare la gestione delle modifiche . Spesso, i progettisti fanno semplicemente la loro ipotesi migliore. Potrebbero trovare un modello logico di dati e un sacco di UML che descrivono un nuovo sistema e come dovrebbe funzionare. Quindi firmano.

Ora gli sviluppatori iniziano effettivamente a programmare, in base al design approvato. Possono verificarsi problemi se non comprendono del tutto il progetto, il che può significare che devono tornare dal progettista, potenzialmente riaprire la fase di progettazione (e ottenere un altro giro di firme) o almeno attivare la gestione delle modifiche . I progettisti possono a loro volta rendersi conto che la confusione risale davvero ai requisiti, il che significa che devono riaprire le discussioni sui requisiti, le approvazioni e l'ulteriore gestione delle modifiche. Spesso, i programmatori (che hanno una scadenza incombente) fanno semplicemente la loro ipotesi migliore. Fanno il possibile per creare un codice funzionale. Quindi lo rilasciano per i test.

Ora inizia la fase di test del sistema. I tester eseguono il test in base alla loro comprensione dei requisiti e della progettazione e registrano ciò che percepiscono come difetti in un sistema di gestione dei bug tracking / change, facendo ricominciare gli sviluppatori a meno che non vedano il problema come un difetto di progettazione, che lo rimanda alla progettazione, ecc ... Alla fine i test di sistema passano e vengono firmati.

Infine, il cliente ritorna ed esegue i test di accettazione dell'utente sul nuovo sistema. È qui che decidono se la soluzione testata dagli sviluppatori, sviluppata dagli sviluppatori e progettata dai progettisti è effettivamente ciò che desiderano. In caso contrario, è necessario ritornare alla fase di progettazione o addirittura rivisitare i requisiti.

L'idea alla base di waterfall è che è difficile (e molto indesiderabile) tornare indietro una volta completata una fase. Persone diverse sono generalmente coinvolte in fasi diverse, quindi ci sono più passaggi, ognuno dei quali comporta un sacco di rischio di interpretazione errata e perdita di informazioni. C'è anche un divario significativo tra quando i clienti dicono ciò che vogliono e quando vedono ciò che è stato costruito, nel quale i requisiti reali potrebbero benissimo essere cambiati.

Le metodologie agili si concentrano su una forte comunicazione e cooperazione tra tutte le parti interessate. Il principio "Collaborazione del cliente sulla negoziazione del contratto" significa che non dovresti dover passare attraverso una serie di approvazioni e dispense, ma invece devi semplicemente collaborare con il cliente, ogni iterazione che determina i requisiti per un pezzo del puzzle e formando immediatamente test, un design e un codice di lavoro - con tutti i giocatori che comunicano il più direttamente possibile (eliminando costi e rischi di consegna). Il codice di lavoro è rapidamente testabile dal cliente, eliminando i rischi di ritardo. Tutte le attività avvengono in un vortice collaborativo, non in un flusso discendente.

Per un'eccellente panoramica di ciò che le metodologie agili cercano di fare, consiglio vivamente lo sviluppo software agile di Allistair Cockburn : il gioco cooperativo .

Sì, è più o meno corretto. C'è stato molto scritto e discusso su come procedere, ma un mucchio di piccole cascate è il punto cruciale.

L'implementazione specifica di come utilizzare un mucchio di piccole cascate non è però banale. Ad esempio, non passerai dalla realizzazione di grandi progetti in un paio d'anni alla realizzazione di numerosi piccoli progetti. C'è ancora il grande progetto con 1-2 anni di lavoro da realizzare. Quindi è necessario dividere il grande progetto in una serie di piccoli progetti. Ciò può sembrare abbastanza ovvio, ma riempie pagine e pagine di libri.

È corretto o c'è di più?

Tutti e due. Sì, questo è un riassunto accurato del concetto, ma ci sono molti dettagli che vengono riassunti. Voglio dire, praticamente ogni aspetto della pianificazione cambia quando stai pianificando solo per la settimana successiva invece dell'anno successivo.

Se osservi la struttura statica (definizione del processo) di un progetto agile, sembra che molte piccole cascate sì. Ma l'obiettivo di un progetto agile è ottenere un feedback più rapido e migliore .

• Esegui uno sviluppo guidato dai test per sapere immediatamente se il tuo software funziona ancora
• Un cliente è sul posto ed esegue test di accettazione per sapere quando hai finito
• Hai delle retrospettive per adattare il tuo processo in base a cosa è andato bene e cosa no.

Il manifesto agile evidenzia alcune differenze tra agile e cascata (come percepito da coloro che hanno firmato).

Davvero "agile" significa spesso cascate di 1-2 giorni, non settimane. Ciò non significa che non segui un piano generale e che i cicli di rilascio reali siano 1-2 giorni. Ma dovresti provare ad avere un prodotto funzionante e testato ogni giorno e potresti rilasciarlo - in teoria - ogni giorno.

Scrum, ad esempio, utilizza sprint di 4 settimane, ma uno sprint non è solo una cascata (almeno, non dovrebbe essere). Puoi cambiare le priorità ogni giorno ogni volta che vedi che qualcosa non va come previsto all'inizio dello sprint.