Cosa significa essere agili?

Abbiamo un progetto che tutti dicono che faremo in modo agile, ma dubito che abbiamo chiaramente capito cosa sia agile.

In progetti precedenti avevamo programmato riunioni, quindi definito il registro di prodotto e assegnato il lavoro agli sviluppatori in sprint da 2 a 3 settimane. Ogni mattina abbiamo avuto riunioni di mischia (che sembravano andare avanti per mezz'ora ogni volta) e ogni sviluppatore ha continuato con quello. Quasi nessuno ha scritto alcun test fino alla fine dello sprint e il lavoro non completato è stato aggiunto allo sprint successivo.

Gli sviluppatori si sono appena parlati e nello sviluppo non sono stati coinvolti TDD. In effetti, la maggior parte degli sviluppatori aveva una specifica all'inizio e ha continuato a seguirla per le 2 o 3 settimane per le quali è stato organizzato lo sprint. Non c'era quasi alcuna comunicazione con il cliente / detentore del palo.

Il controllo qualità è stato coinvolto di solito pochi mesi dopo e da allora abbiamo trovato i requisiti mancanti che hanno ulteriormente aumentato la quantità di lavoro che dovevamo fare. Chiaramente non c'era un ciclo di feedback.

Quindi la mia domanda è: dove abbiamo sbagliato e come posso impedire alla squadra di fare gli stessi errori.

Quello che stai descrivendo non è Agile per definizione (Manifesto Agile) è Cascata con incontri di stato giornalieri. Agile significa adattarsi facilmente al cambiamento, se non esiste un circuito di feedback interattivo con il proprietario del prodotto e quindi i clienti, quale cambiamento si sta verificando?

Agile riguarda guasti rapidi, attraverso una comunicazione costante con il proprietario / i clienti del prodotto. È meglio fallire prima che dopo, meno lavoro viene fatto e meno viene "perso". E non rimani bloccato con l'argomento, secondo cui "non abbiamo tempo per farlo correttamente, dal momento che abbiamo trascorso così tanto tempo a farlo in modo sbagliato, dobbiamo solo continuare su questa stessa strada, anche se porta al fallimento ".

Sembra che la tua gestione stia facendo "SCRUM, ma ..." dove il "ma" è dove buttano via tutte le cose di SCRUM che non capiscono o sono d'accordo e fanno le cose allo stesso modo casuale come sempre, ma con nuovi nomi di parole d'ordine luccicanti.

In SCRUM lo stand up quotidiano NON riguarda la consegna dello status al management, ma è quello di forzare l'interazione degli sviluppatori, quindi sai cosa stanno facendo i tuoi colleghi e puoi aiutarvi a vicenda e non duplicare il lavoro. Se ci vogliono più di 45 secondi a persona, lo stai facendo male. Si tratta di trasparenza per il team, se una persona sta assegnando lo stesso stato più giorni per qualcosa che dovrebbe essere un singolo giorno di lavoro, il team può risolvere il problema delle persone prima o poi.

Se non stai testando il codice a vicenda mentre è scritto, non lo stai facendo neanche correttamente. I test dovrebbero essere integrati nel processo e non dopo una riflessione. Il QA dovrebbe essere incluso nelle sessioni di pianificazione e fornire stime su quanto tempo ci vorrà per testare.

Se non stai rispettando gli impegni di Sprint e non riesci a farlo, non lo stai facendo correttamente. Gli sprint riguardano impegni se ti impegni a lavorare troppo, smetti di farlo, non puoi in alcun modo introdurre prevedibilità o ripetibilità se non riesci a impegnarti con precisione nei risultati.

Jarrod ha fornito una buona risposta (+1 a quello) e vorrei estenderlo un po '.

Agile non è solo una questione di rapidi guasti e feedback tra il proprietario del prodotto (cliente) e il team; si tratta di un rapido feedback tra tutte le parti interessate. Essere veramente agili (e questo direttamente dal manifesto ) significa riconoscere che il processo esiste solo per aiutare gli sviluppatori a fornire prodotti migliori. Le persone sopra il processo significano che non appena il team riconosce che il processo esistente non funziona, lo cambi e lo fai funzionare.

"Scrum ma ..." è anche un problema, ma ci sono entrambe le facce di questa moneta. Se guardi il manifesto, vedrai che si tratta del team e di far funzionare strumenti / processi per te. Non ci sono due squadre uguali e quindi ognuna funzionerà in modo leggermente diverso e va bene. Potresti certamente prendere l'intera metodologia Scrum e provare a seguirla alla lettera e vedere se funziona per la tua squadra.

Un'altra alternativa è invece di spingere un altro processo nel team e far sì che tutti seguano ciò che Scrum ti dice di fare, provare un approccio agile : comunicare con il team e vedere se insieme è possibile identificare aree problematiche e soluzioni per ognuno. Quindi introdurre gradualmente cambiamenti nel modo in cui si lavora in modo che i problemi vengano affrontati.

Potrebbe volerci un po 'di tempo, ma ...

1. Per prima cosa risolverai i problemi più grandi che avranno il maggiore impatto sulla capacità dei tuoi team di consegnare il prodotto
2. Identificando i problemi immediati e partecipando alla ricerca di soluzioni, i membri del team comprenderanno perché alcune pratiche sono importanti e non le faranno semplicemente perché viene loro chiesto di farlo.

Se tracciamo un'analogia tra Scrum e un modello di progettazione, lavorare nel modo che ho proposto sarebbe simile alla codifica in un modello, in cui mantieni il codice il più semplice possibile e convergere su un modello di progettazione solo quando necessario. Al contrario di scegliere semplicemente un modello di progettazione e rotolare con esso (cioè selezionare ciecamente Scrum e tutti i suoi processi come un unico insieme), che a volte rende il codice più complesso e più difficile da mantenere di quanto non avrebbe potuto essere altrimenti.

La chiave per capire è che l'agile non ha a che fare con un nuovo processo per fare le cose; riguarda il cambiamento continuo e l'adeguamento costante ai processi / pratiche esistenti.

se la squadra (e il suo management) vogliono veramente "essere agili", dovrebbero iniziare leggendo e discutendo come una squadra il Manifesto Agile e i suoi direttori. Quindi scegli una delle metodologie agili che sono state create ( Scrum , ad esempio), prendi un po 'di addestramento su di esso e inizia a seguirlo. Consiglierei di seguirlo da vicino per un po 'prima di modificarlo, ma sono solo io.

Dovrebbero inoltre approfondire le pratiche di ingegneria utilizzate per supportare la particolare metodologia di progetto agile scelta.