In ritardo ha qualche significato nelle metodologie Agile?

Ciò è emerso da alcune delle risposte e dai commenti su un'altra domanda ( questa ).

Ho lavorato principalmente con progetti a cascata e mentre ho lavorato a progetti ad hoc che hanno assunto comportamenti agili e hanno letto un bel po 'di agile, direi che non ho mai lavorato a un progetto "corretto" .

La mia domanda è: il concetto di "in ritardo" ha qualche significato in agile, se sì, allora?

Il mio ragionamento è che con Agile non hai un piano iniziale e non hai requisiti dettagliati all'inizio. Potresti avere in mente un obiettivo di alto livello e una data teorica allegata, ma entrambi possono cambiare (potenzialmente in modo massiccio) e nessuno dei due è certo.

Quindi se non sai esattamente cosa consegnerai sostanzialmente fino a quando non lo consegnerai e l'utente lo accetterà, e se non hai un programma oltre lo sprint successivo, come potresti mai arrivare in ritardo in qualche modo ha davvero un significato?

(Ovviamente capisco che uno sprint potrebbe essere invaso ma ne sto parlando oltre.)

Giusto per essere chiari, sono (personalmente) felice dell'ipotesi che i progetti a cascata in tempo (anche quelli relativamente grandi) siano possibili in base al fatto che li ho visti e che sono stati coinvolti in essi - non sono facili o comuni nemmeno ma sono possibili.

Non si tratta di bussare agilmente, ma di capirlo. Ho sempre visto il vantaggio di Agile come nulla a che fare con scadenze o budget (o piuttosto solo indirettamente), ha a che fare con l'ambito: Agile offre più vicino a ciò che è veramente importante piuttosto che a ciò che il team del progetto ritiene importante prima di loro " ho visto qualcosa.

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

La mia esperienza è che gli analisti aziendali hanno trascorso un bel po 'di tempo a lavorare in riunioni di progettazione con clienti e sviluppatori per elaborare un elenco dettagliato di requisiti realizzabili presentati come storie degli utenti. Questi vengono quindi suddivisi in attività con stime adeguate allegate da 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 accadere la storia dell'utente.

Alla fine dell'iterazione tutte le storie utente per quell'iterazione dovrebbero essere complete o sei in ritardo . Allo stesso modo, lo sviluppo dovrebbe essere in grado di arrestarsi alla fine di ogni iterazione e il prodotto rilasciato. Potrebbe non essere completo in termini di tutti gli user story, ma gli user story richiesti nell'iterazione sono completi e il prodotto può funzionare fino a tali limiti.

"in ritardo" in una metodologia agile significa la stessa cosa che significa in una metodologia a cascata: le stime erano sbagliate, la portata era troppo grande per il tempo assegnato, apparivano difficoltà inaspettate, il cliente non era abbastanza reattivo, i programmatori diventavano pigri, le macchine si sono schiantate, il tuo cane ha mangiato il mio bytecode, ecc.

impari da esso e ti adegui alla prossima iterazione

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

Sì, ma ci vorrà solo 1 mese per sapere che non raggiungerai la data di scadenza del progetto finale mitica di 9 mesi anziché 9.

Il tuo ragionamento si basa sul presupposto che sono possibili piani iniziali e requisiti dettagliati per grandi progetti. Non sono sicuro che ci siano molte prove a sostegno di ciò. Forse tutte le storie dell'orrore sono solo aneddotiche? A qualsiasi sviluppatore piacerebbe lavorare con specifiche complete e mai mutevoli che il cliente è pienamente d'accordo e capisce.

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

Ma sappiamo che non puoi prevedere il futuro e sappiamo che il cliente cambierà costantemente idea e siamo d'accordo sul fatto che sia una buona cosa. Se lo accettiamo, dobbiamo anche accettare che tutti gli impegni sono praticamente sempre sbagliati, il che, a sua volta, rende facile rispondere alla domanda sul ritardo: abbiamo sempre torto (all'inizio o alla fine). È tutta una questione di ipotesi, non importa quanto ben rifinito. Lancia una moneta.

Questo è qualcosa che noi 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 quello di fornire il software di lavoro il più presto possibile, con la possibilità di smettere quando il cliente è soddisfatto.

Ed è di questo che agile. Un modo intelligente per gestire questa scomoda nozione secondo cui il ritardo è un dato di fatto e dobbiamo semplicemente affrontarlo nel miglior modo possibile.

Ad esempio, sei in ritardo quando non riesci a mantenere gli impegni presi all'inizio dell'attuale iterazione. 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 gestirlo è mantenere le iterazioni il più piccolo possibile.

Per la pianificazione multi iterazione, nota anche come pianificazione del rilascio, si utilizza la velocità calcolata dalle iterazioni completate e si estrapolano i dati per prevedere una data di rilascio futura. Vi consiglio di James Shores' articolo o il mio proprio (più breve) per maggiori dettagli su questo. Si noti che non è mai un impegno solido e soprattutto "siamo certi all'80% che completeremo le prossime funzionalità entro tale data". Questo può (in un certo senso) farti arrivare in ritardo, ma l'impegno è solo una probabilità, non un dato di fatto.

Ora par questo con la promessa di base di Agile che dovresti sempre essere pronto a rilasciare software funzionante, funzionalità completa o meno. Ciò offre al cliente la libertà di interrompere lo sviluppo quando ritiene che il sistema sia abbastanza buono, il che può avvenire molto prima del previsto. Incoraggia inoltre a portare il progetto in nuove direzioni sulla base di feedback reali dall'ultima iterazione.

I punti di cui sopra dovrebbero essere più che sufficienti per consentire a qualsiasi cliente di avere il pieno controllo dello sviluppo e spero che risponda alla domanda sul ritardo nei metodi agili.

Esistono due tipi di "ritardo" in Agile SCRUM>

1. Riporto: le storie non "completate" 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 l'organizzazione abbia una roadmap e supponendo che abbia date, se mancano i principali risultati finali per quelle date, che possono essere considerati "in ritardo".