Cosa significa essere agili?

Ciò che stai descrivendo non è Agile per definizione (Agile Manifesto) è Cascata con incontri di stato giornalieri . Agile significa adattarsi facilmente ai cambiamenti, se non c'è un ciclo di feedback interattivo con il proprietario del prodotto e quindi i clienti, allora quale cambiamento si sta verificando?

Agile riguarda i guasti rapidi, attraverso una comunicazione costante con il proprietario del prodotto / i clienti. È meglio fallire prima possibile, meno lavoro è fatto e meno è "perso". E non rimarrai bloccato dall'argomento, che "non abbiamo il tempo di farlo correttamente, dato che abbiamo passato così tanto tempo a sbagliare, abbiamo solo bisogno di continuare su questo stesso percorso, anche se porta a un fallimento ".

Sembra che la tua gestione stia facendo "SCRUM, ma ..." dove "ma" è dove buttano fuori tutto SCRUM cose che non capiscono o non sono d'accordo e fanno le stesse cose come sempre, ma con nuovi e brillanti nomi di parole d'ordine.

In SCRUM lo standby giornaliero è NON sull'erogazione dello stato alla gestione, è per forzare l'interazione dello sviluppatore, così sai cosa stanno facendo i tuoi colleghi e puoi aiutarsi a vicenda e non duplicare il lavoro. Se ci vogliono più di 45 secondi a persona, stai sbagliando. Riguarda la trasparenza per il team, se una persona sta dando lo stesso status di più giorni a qualcosa che dovrebbe essere un singolo giorno di lavoro, il team può risolvere il problema delle persone prima possibile.

Se non si sta testando il codice dell'altro come è scritto, non lo si sta facendo correttamente. I test dovrebbero essere incorporati nel processo, non in un secondo momento. Il QA dovrebbe essere incluso nelle sessioni di pianificazione e fornire stime su quanto tempo ci vorrà per testare.

Se non incontri gli impegni di Sprint e non riesci a capovolgerli, non lo stai facendo correttamente. Gli sprint riguardano circa impegni se ti impegni a lavorare troppo, smetti di farlo, non è possibile introdurre alcuna prevedibilità o ripetibilità se non puoi impegnare accuratamente i deliverable.

Jarrod ha fornito una buona risposta (+1 a questo) e mi piacerebbe approfondire un po '.

Agile non riguarda solo i guasti rapidi e il feedback tra il proprietario del prodotto (cliente) e il team; si tratta di un rapido riscontro tra tutte le parti interessate coinvolte. Essere veramente agili (e questo è direttamente da il manifesto ) è riconoscere che il processo esiste solo per aiutare gli sviluppatori a fornire un prodotto migliore. Le persone sopra il processo indicano che non appena il team riconosce che il processo esistente non funziona, lo modifichi e lo attivi.

"Mischia ma ..." è anche un problema, ma ci sono entrambi i lati di questa moneta. Se osservi il manifesto, vedrai che riguarda il team e che gli strumenti / processi funzionano 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 seguirlo alla lettera e vedere se funziona per la tua squadra.

Un'altra alternativa è quella di spingere un altro processo nel team e far seguire a tutti quello che Scrum ti dice di fare, provare l'approccio agile : comunicare con il team e vedere se insieme puoi identificare le aree problematiche e soluzioni per ciascuno. Quindi, introduci gradualmente le modifiche nel modo in cui lavori in modo che i problemi vengano risolti.

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

1. Prima risolvi i problemi più importanti che avranno il maggiore impatto sulla capacità del tuo team di fornire prodotti
2. Identificando i problemi immediati e partecipando alla creazione di soluzioni, i membri del tuo team capiranno perché certe pratiche sono importanti e non le faranno semplicemente perché gli viene detto di farle.

Se tracciamo un'analogia tra Scrum e uno schema di progettazione, il modo in cui ho proposto sarebbe stato simile alla codifica in uno schema, in cui si mantiene il codice il più semplice possibile e convergono solo su un modello di progettazione quando necessario. Al contrario di scegliere un modello di design e rotolare con esso (cioè selezionare ciecamente Scrum e tutti i suoi processi come un set), il che a volte rende il codice più complesso e difficile da mantenere di quanto avrebbe potuto essere altrimenti.

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

se il team (e il suo management) vogliono veramente "essere agili", devono scegliere una delle metodologie agili ( Scrum , ad esempio), allenarsi su di esso e seguirlo completamente. Dovrebbero anche esaminare approfonditamente le Pratiche di ingegneria utilizzate per supportare il particolare progetto agile metodologia scelta