In ritardo ha qualche significato nelle metodologie Agile?

Non sono d'accordo sul fatto che un progetto Agile non abbia un piano iniziale.

La mia esperienza è che gli analisti aziendali hanno trascorso una discreta quantità di tempo lavorando in riunioni di progettazione con clienti e sviluppatori per trovare un elenco dettagliato dei requisiti realizzabili presentati come storie degli utenti. Questi vengono quindi suddivisi in attività con le stime appropriate allegate dagli sviluppatori esperti.

Una volta identificati i compiti più importanti all'inizio dello sprint / iterazione, può iniziare la codifica. Questo processo di selezione determina il significato dell'iterazione nel progetto complessivo ("Stiamo creando il processo di accesso"). Vari membri del team vanno avanti con i vari compiti necessari per far sì che la storia dell'utente avvenga.

Alla fine dell'iterazione, tutte le storie utente per tale iterazione dovrebbero essere completate, o sei in ritardo . Allo stesso modo, lo sviluppo dovrebbe essere in grado di fermarsi alla fine di ogni iterazione e il prodotto rilasciato. Potrebbe non essere completo in termini di tutte le storie degli utenti, ma quelle storie utente che sono state richieste nell'iterazione sono complete e il prodotto può funzionare fino a quei limiti.

"tardi" in una metodologia agile significa la stessa cosa che significa in una metodologia waterfall: le stime erano sbagliate, l'ambito era troppo grande per il tempo assegnato, apparivano difficoltà impreviste, il cliente non era abbastanza reattivo, i programmatori sono diventato pigro, le macchine si sono bloccate, il tuo cane ha mangiato il mio bytecode, ecc.

si impara da esso e si regola per la successiva iterazione

la differenza è che questo può accadere ogni 2-4 settimane, quindi le lezioni vengono apprese e il processo viene regolato rapidamente

Sì, ma ci vorrà solo 1 mese per sapere che non colpirai il tuo mitico-finale-progetto-scadenza a 9 mesi invece di 9.

Il tuo ragionamento si basa sul presupposto che siano possibili piani anticipati e requisiti dettagliati per progetti di grandi dimensioni. Non sono sicuro che ci siano molte prove a sostegno di ciò. Forse tutte le storie dell'orrore sono solo aneddotiche? Qualsiasi sviluppatore vorrebbe lavorare con specifiche complete e mai modificate che il cliente sia pienamente d'accordo e comprenda.

Ogni volta che fai un impegno di qualche tipo, corri il rischio di essere in ritardo. Ciò vale anche per l'agile.

Ma sappiamo che non è possibile prevedere il futuro e sappiamo che il cliente cambierà costantemente idea e siamo d'accordo che è una buona cosa. Se accettiamo ciò, dobbiamo anche accettare che tutti gli impegni sono sempre sbagliati, il che, a sua volta, rende facile rispondere alla domanda sul ritardo: Abbiamo sempre torto (presto o tardi) . È tutta una questione di supposizioni, non importa quanto bene lucido. Lancia una moneta.

Questo è qualcosa che noi, come sviluppatori, dobbiamo semplicemente accettare, e da quel punto di vista cercare di trovare un altro modo di lavorare, un modo in cui il problema del ritardo è reso molto meno importante. Un cambio di prospettiva. Penso che il modo per farlo sia focalizzato sulla fornitura di software di lavoro il più presto possibile, con la possibilità di smettere quando il cliente è soddisfatto.

And that is what agile is all about. A clever way to managing this uncomfortable notion that lateness is a fact and we simply have to deal with it the best we can.

Ad esempio, sei in ritardo quando non riesci a rispettare gli impegni che hai fatto all'inizio dell'iterazione corrente. Questo è previsto e dovresti imparare da questo e adattare il tuo processo in modo da avere meno probabilità di fallire nella prossima iterazione. Il modo migliore per gestire questo è mantenere le iterazioni il più possibile ridotte.

Per la pianificazione della iterazione multipla, ovvero la pianificazione del rilascio, si utilizza la velocità calcolata dalle iterazioni completate e si estrapolano i dati per prevedere una data di rilascio futura. Raccomando il articolo di James Shores o il mio own (più breve) per maggiori dettagli a riguardo. Si noti che non è mai un impegno solido e più di un "siamo sicuri all'80% che completeremo le prossime funzionalità entro quella data". Questo può (in qualche modo) causare il ritardo, ma l'impegno è solo una probabilità, non un dato di fatto.

Ora tutto ciò con la promessa di base di agile che dovresti sempre essere pronto a rilasciare software funzionante, funzionalità completa o meno. Questo dà al cliente la libertà di interrompere lo sviluppo quando pensa che il sistema sia abbastanza buono, cosa che può accadere molto prima del previsto. Incoraggia anche a portare il progetto in nuove direzioni sulla base di un feedback reale dall'ultima iterazione.

I punti precedenti dovrebbero essere più che sufficienti per consentire a qualsiasi cliente di avere il pieno controllo dello sviluppo, e spero che risponda alla domanda sui ritardi nei metodi agili.

Ci sono due tipi di "late" in Agile SCRUM >

1. Carryover - Storie non "Fatto" alla fine di uno sprint, gli sviluppatori "si impegnano" a fare un PBI, quindi quando non è fatto, può essere considerato carry.

2. Roadmap - Supponendo che la tua organizzazione abbia una roadmap e supponendo che abbia delle date, se mancano i risultati principali per quelle date, può essere considerato "tardivo".