Alcuni team agili li usano per comunicare con il cliente quando può aspettarsi di avere una nuova versione del software (anche se quella versione è incompleta). Ciò consente al cliente di pianificare la migrazione alla nuova versione, prima che venga rilasciata.

Ad esempio, per un software sviluppato in modo agile e rilasciato ogni 6 mesi , le seguenti potrebbero essere le pietre miliari.

Alfa 1 - 19 dicembre

Arriva il primo set di funzionalità, solitamente con errori. Questo è utile per provarli e dare un feedback

Alpha 2 - January 23rd

Prossimo set di funzionalità, oltre ad alcune correzioni per il feedback in Alpha

Beta 1 - 27 febbraio

Ci sono tutte le funzionalità per la versione corrente e nessuno verrà aggiunto fino alla versione finale. Il nuovo sviluppo sarà nella prossima versione. Puoi comunque suggerire qualche piccola modifica a quella esistente.

Beta finale - 27 marzo

Il comportamento della funzione è completamente bloccato, a meno che non venga rilevato un difetto critico. Verrà risolto solo un bug.

Release Candidate - 10 aprile

La versione finale da rilasciare. Nessun bug dovrebbe essere trovato qui. Se alcuni vengono trovati, viene creato un nuovo candidato alla versione.

Versione finale - 17 aprile

La versione supportata è rilasciata al pubblico in generale, poiché non è stato trovato alcun errore nel rilascio del candidato

(Nota: non ho seguito esattamente la semantica di ubuntu qui)

Con questo piano di rilascio in mano, un cliente può pianificare in anticipo. Se una nuova funzionalità è realmente prevista, può verificarla durante la fase alpha per assicurarsi che si adatti a ciò che è richiesto. I programmatori possono iniziare a sperimentare con la nuova funzione durante la fase beta. Il test di regressione può iniziare durante la fase di rilascio del candidato.

Sapere quando il software verrà rilasciato e cosa conterrà è di enorme importanza per molti utenti. Usando la milestone, puoi sapere cosa sta per succedere e quando . La mentalità agile è ancora lì, manifestata dal fatto che prima di una certa data il set di funzioni è variabile . Diversamente dalla modalità cascata , dove hai pianificato entrambe le funzioni e la data di rilascio . E ovviamente la prossima versione non è impostata, a differenza del metodo waterfall.

Quindi, per rispondere alla tua domanda: In agile, vengono utilizzate pietre miliari per indicare quando saranno prese importanti decisioni e azioni , anche se tali azioni e decisioni possono cambiare.

Penso che lo scopo della pietra miliare sia di vedere una grande immagine del rilascio / del programma candidato / dell'app (o di qualsiasi altra cosa che sviluppi il team).

Potrebbe essere utile per sviluppatori / lavoratori:

Posso immaginare un sistema di tracciamento dei problemi con molte attività, bugfix, funzionalità ecc. Ha un campo milestone. Penso che se il tuo team ha due punti cardine e solo uno preferisce il tuo cliente, che il tuo team inizi a svolgere queste attività, o corregge questi bug o sviluppa queste funzionalità contrassegnate con questo traguardo.

Potrebbe essere utile per i gestori:

Questa è una cosa molto importante che sarà rilasciata nell'ambiente di produzione del cliente. In questo caso la pietra miliare è rilasciata nell'ambiente di produzione. Ma la pietra miliare potrebbe essere un pacchetto di caratteristiche.

Potrebbe essere utile per il cliente:

Può essere, il cliente desidera mostrare questo programma, o programma la versione con bug corretti, o nuove funzionalità del programma per un'altra persona / organizzazione. Quindi, il cliente ha bisogno di una versione stabile del programma. Penso che quando il programma raggiungerà questo traguardo sarebbe stabile e rilasciabile.

Se il cliente, i manager e i lavoratori verificano bug, taks e funzionalità nel tracker dei problemi, penso che i migliori ne conoscano una pietra miliare.

Quando avvii un progetto di sviluppo - indipendentemente dalla metodologia - dovresti avere sempre un piano approssimativo che stai seguendo, sulle funzionalità "indispensabili", funzionalità di base, funzionalità "veramente importanti" che si desidera sviluppare e in quale ordine. Idealmente hai anche una visione sul tempo di realizzazione. Annotare questo piano sotto forma di pietre miliari rende questo trasparente per chiunque sia coinvolto nel progetto.

In qualsiasi tipo di progetto reale, questo piano deve essere adattato alla realtà di volta in volta. Forse è necessario riassegnare le caratteristiche a diverse tappe, a volte si identificano le cose come meno importanti di quanto si pensasse in anticipo, a volte si devono aggiungere alcuni requisiti / caratteristiche mancanti al piano di sviluppo e talvolta si può dover modificare l'elenco delle tappe fondamentali . IMHO la differenza principale tra un progetto "a cascata" e un progetto "agile" è che in un progetto agile sei onesto con il cliente sulla necessità di adattamento dal giorno 1. Nei progetti a cascata, non hai meccanismi integrati per modificare il pianificare prima che il prodotto sia "pronto" (e probabilmente difettoso). Nei progetti agili, è un dovere esplicito del cliente aiutare il team di sviluppo ad adattare il piano alla realtà, continuamente durante l'intero progetto, ogni settimana o anche più spesso.

C'è anche una differenza nel momento in cui si analizzano i dettagli cruenti dei requisiti per qualsiasi traguardo. I progetti sulle cascate tendono ad analizzare in anticipo ogni caratteristica di ogni traguardo, in progetti agili si analizzerà tipicamente solo una caratteristica del prossimo traguardo approfondito.

Quindi direi soprattutto nei progetti agili un piano milestone che aiuta gli stakeholder a capire che lo sviluppo non è del tutto arbitrario o casuale e che si continua a seguire un piano generale.

Una domanda diversa è se hai bisogno della funzione "milestones" dal tuo tracker di problemi. Un piano milestone è in genere solo un documento nel tuo formato di documento preferito, quindi puoi facilmente mostrarlo a qualsiasi stakeholder del tuo progetto. Devi decidere da solo se ti porta qualche vantaggio nel mettere le pietre miliari nel tuo sistema di tracciamento dei problemi, o se preferisci mantenerlo in un modo completamente diverso.

Hai già risposto alla tua domanda. "... utile quando fai grosse pressioni programmate ..."

Dato che lavori solo manutenzione e aggiornamento, le pietre miliari non hanno molto senso. Tranne : anche quando si scelgono le funzionalità da iterare è bello avere una panoramica di dove si stanno dirigendo tutte le funzionalità per mantenere lo sviluppo agile da spirale fuori controllo e per il progetto di coesione.

Le pietre miliari forniscono un punto per misurare il modo in cui vengono raggiunti gli obiettivi a lungo termine e un punto da fermarsi e valutare quale direzione dovrebbe seguire l'iterazione futura.

Le milestone sono utili per il coinvolgimento del cliente, ad esempio: quando si sviluppa un prototipo, una pietra miliare consentirà al team di sapere quali elementi di lavoro devono essere completati per avere un prototipo pronto per la presentazione.

È anche utile per implementazioni evolutive oltre a fornire una pista di audit di sviluppo. In una squadra in cui avevo lavorato in precedenza, il capogruppo si sarebbe sbilanciato dal repository principale per mantenere una versione del prodotto in quella pietra miliare specifica. Questo ci ha permesso di mostrare al top management l'evoluzione del prodotto e di giustificare il budget.

Ogni caratteristica è una pietra miliare, per definizione

an action or event marking a significant change or stage in development

L'utilità di tracciare singoli o gruppi di pietre miliari per il tuo progetto e tuo team e tuo cliente è principalmente una questione di gusto / stile

Alcuni team / clienti preferiscono controllare le pietre miliari ogni giorno o giù di lì, altri si accontentano di farlo meno frequentemente

ADDENDUM: la parola chiave è "significativa", che è soggettiva. Le tue pietre miliari possono variare. :)