Sto lavorando in un negozio simile. Come altri hanno notato, ciò che descrivi potrebbe essere agile ma non miserabile. Vorrei anche aggiungere che il fatto che i log e gli sprint siano o meno sensati dipende dal fatto che si tratti di nuovo lavoro o manutenzione e supporto continuo. Se il primo, un approccio a cascata avrebbe più senso per una squadra di una persona. Altrimenti, dal punto di vista del PM, quello che stanno facendo sembra un buon approccio se hanno più progetti nel loro portafoglio.
Per gli appassionati di Agile, la semplice menzione dell'uso della cascata è il sacrilegio. Ma le persone devono usare il buon senso.
Vorrei fare un esempio da un mio recente progetto. Stavo guidando un team di 3 sviluppatori su una timeline aggressiva di 5 mesi per riprogettare due siti Web principali. Abbiamo avuto riunioni quotidiane di stand-up. Ma era un progetto a cascata perché era un piccolo team, un ciclo di vita limitato e gli sviluppatori erano tutti appaltatori a breve termine impegnati nel progetto solo fino al lancio. Il progetto ha seguito un ciclo di vita a cascata molto tradizionale. Assolutamente niente di sbagliato in questo. Tranne il fatto che abbiamo lavorato in modo "agile", abbiamo tenuto le riunioni di stand-up e abbiamo mantenuto le migliori pratiche di sviluppo agile. Il nostro piccolo team è stato esonerato dalle riunioni di pianificazione dello sprint settimanale del team più grande. Perché? Perché non avevamo distribuzioni settimanali. E il nostro team non ha dipeso o influenzato il lavoro svolto da nessun altro team. In effetti, abbiamo lavorato quasi autonomamente. Dopo il lancio dei siti Web, siamo passati a un processo agile per la manutenzione e il supporto continui. Gli altri sviluppatori ora stanno lavorando altrove. Tutti i miglioramenti sono pianificati in base a distribuzioni periodiche.
Il punto è che è meglio usare i processi che hanno più senso per le dimensioni, la complessità e la maturità di ciascun progetto. Se stai facendo molte ricerche, è difficile fare una stima per i prossimi cinque mesi, quindi l'agile è probabilmente un approccio migliore rispetto alla cascata.
Parte del problema è che alcune persone sembrano pensare di essere in grado di pianificare i prossimi cinque sprint in anticipo. È stato il caso prima di me. Non dovresti pianificare più di due sprint perché se lo fai allora stai sconfiggendo l'intero scopo di avere gli sprint. Uno sprint dovrebbe essere un impegno a fornire una quantità realistica di miglioramenti entro un determinato periodo di tempo. Non dovresti impegnarti in qualcosa di cui non sei sicuro. La pianificazione dello sprint è per sua natura una pianificazione a breve termine, ma questo è un po 'il punto. Se hai un programma a lungo termine, pensa a scomporre le cose in risultati più piccoli. O organizzare riunioni di checkpoint in base a dove ti trovi nell'SDLC.
La pianificazione dello sprint dovrebbe essere un impegno realistico su ciò che è garantito per essere completato entro un determinato periodo di tempo. Se scopri che la pianificazione non tiene conto di variabili sconosciute, forse dovresti iniziare a fornire intervalli o stime pessimistiche. O come altri hanno suggerito, usa i punti della storia. Inoltre, gli sprint non devono essere prenotati completamente per consentire lo slittamento e altre attività importanti che si presentano.