Quanto spesso rilasci durante uno sprint. Solo alla fine dello sprint o ogni volta che una funzione è pronta. E come gestire le versioni bugfix?
Risposte:
TL; DR: rilasciare quando appropriato
Facciamo rilasci ogni volta che c'è valore nel fare un rilascio. A volte ciò significa eseguire una versione dopo il completamento di una singola funzionalità o correzione di bug. A volte ciò significa rilasciare una raccolta di funzionalità e / o correzioni di bug.
Questo non significa che spesso abbiamo "emergenze" che richiedono rilasci rapidi. Significa che abbiamo lavorato duramente per rendere le versioni facili. Il nostro codice è testato, etichettato e impacchettato con ogni build. Utilizziamo test di accettazione automatizzati e di conseguenza abbiamo sviluppato un'elevata fiducia nel codice che supera i test. Poiché i nostri pacchetti sono immediatamente disponibili tramite un repository yum locale, la distribuzione di una versione è banale.
Mai durante. Ciò viola la premessa di base di uno "sprint". Corri fino a quando non finisci ciò che hai commesso. Dopo aver finito, è davvero fatto e funziona davvero. È quindi possibile rilasciarlo.
Il rilascio può essere un tipo separato di sprint in cui le cose sono impacchettate per il rilascio.
Le versioni di Bugfix possono essere solo brevi sprint. Non avere un programma regolare di sprint della stessa lunghezza è considerato da molti una cattiva idea. Pertanto, la regola abituale è che le correzioni di errori sono semplicemente lavori ad alta priorità che si verificano durante lo sprint successivo .
Se si tratta di un'emergenza, hai troppe cose in corso - supporto e sviluppo - e dovresti considerare di cambiare l'organizzazione per avere meno cose in corso.
Se il lavoro che il team si sta impegnando è favorevole a fare più rilasci all'interno dello sprint, rilascialo tutte le volte che vuoi.
Lo stesso vale per le versioni con correzione dei difetti: se ha senso rilasciarle, fallo.
L'ultimo lavoro Agile a cui ho lavorato ha rilasciato ogni sprint; il codice veniva bloccato ogni due giovedì (sprint di due settimane), quindi il prodotto veniva impacchettato e pubblicato su un server UAT per consentire ai nostri clienti di lavorare. Ciò avveniva durante lo sviluppo iniziale del prodotto; per un prodotto maturo, in particolare un programma distribuibile e non un'app Web, probabilmente non vorrai caricare i tuoi utenti con l'aggiornamento ogni due o tre settimane.
Praticamente tutte le nostre versioni includevano un mix di punti della storia e difetti (bug). Difetti contati come "ore non ideali"; ci sono 5 ore ideali in una giornata lavorativa, che significa codifica a testa in giù di nuovi punti di lavoro. Le altre tre o quattro ore al giorno sono incontri, discussioni, progettazione, a volte "picchi" (ricerca focalizzata / sviluppo di prove concettuali) e lavoro sui difetti; cose che contribuiscono a un prodotto migliore ed è una parte necessaria del processo, ma semplicemente non possono occupare l'intero sprint dell'intero team. L'unica volta che abbiamo fatto rilasci di soli difetti è stato quando non vi era alcun lavoro story-point disponibile nel backlog come di un IPM; poi abbiamo semplicemente programmato uno sprint di QA in cui ci è stato chiesto di "uccidere quanti più difetti possibile". Poiché non avere i requisiti pronti all'uso è SEMPRE colpa dell'OP (e l'OP ha funzionato per i clienti), potremmo semplicemente emettere un avviso di modifica del contratto e lavorare con quello che avevamo. Naturalmente, una volta terminato il vero lavoro della storia e siamo entrati nello sviluppo della "garanzia", i difetti erano tutti lì.
In un progetto Agile ben gestito, l'esaurimento dei requisiti non dovrebbe mai avvenire; l'arretrato dovrebbe sempre avere uno sprint di lavoro pronto a raccogliere. Ma a volte l'OP viene sommersa producendo requisiti; a volte i BA / tester sostengono il rilascio di storie nel backlog di sviluppo, per motivi relativi alla qualità dei requisiti o conflitti di storie; a volte una squadra decide di dover "puntare" su una storia che non è stata ben definita o stimata, e non c'è qualcosa che possa facilmente riprendere i cicli rimanenti. Insomma, anche in Agile, succede merda.
Cosa intendi per rilascio? Se intendi PSP - probabilmente prodotto spedibile, hai due opzioni:
La differenza principale tra il livello 2 e il livello 3 è che nel livello 2 devi fare uno sforzo per fare PSP finale alla fine dello sprint ma nel livello 3 metti un po 'di soldi e sforzi inizialmente per i tuoi strumenti e configurazioni e hai preparato la PSP automaticamente tutto il tempo = non è necessario alcuno sforzo manuale. Raggiungere pienamente il livello 3 è raro.
In Scrum non ci sono assolutamente regole su quando implementare nuove funzionalità. Ogni squadra deve avere una "definizione di fatto", che dovrebbe sempre includere alcuni criteri relativi ai test. Una volta che una funzione è "fatta", è pronta per il mondo reale e se non ci sono altre dipendenze o condizioni che devono essere soddisfatte prima di poter essere distribuite, non c'è motivo di aspettare che la fine dello Sprint schieralo.
Nessuno di questi significa che non è stato presentato durante la riunione Sprint Review / Planning. Il concetto è che tutto ciò che il Team ha completato viene mostrato all'OP (e alle altre PMI dei clienti) in modo che possano integrarlo nella loro crescente comprensione del sistema mentre si evolve.
Dopo un paio di settimane abbiamo trovato una buona soluzione adatta alle nostre esigenze. Decidiamo di rilasciare quando vogliamo. Come lo facciamo:
Questo è tutto. Usiamo git e maven come sistema CI e abbiamo una buona copertura dei test. Questo è uno dei motivi per cui possiamo farlo in questo modo.
Rispondere a una domanda che ha quasi 2 anni può essere un po 'ridondante, ma spero di aggiungere valore per gli altri che arrivano a questa domanda vorrei aggiungere un 2cent o giù di lì. :)
Per rispondere alla domanda: è preferibile rilasciare ciò che è stato impegnato nello sprint, al termine di quello sprint. In questo modo si collega a tutte le altre parti / processi / linee guida della mischia che è orientata a ottenere il miglior valore aziendale al momento giusto.
MA emergenze, bug, eventi imprevisti, ecc. Possono forzare la tua mano, ed è qui che potrebbe tornare utile l'idea di "Release Release". Con "Pianificazione del rilascio" non intendo la pianificazione a cascata, ma piuttosto la pianificazione delle aspettative che potrebbero aiutare a gestire l'arretrato di prodotti e la priorità delle storie negli sprint ect.
Ma forse il commento di David sulla domanda è qualcosa da considerare meglio. Scrum non è sempre la risposta giusta.