Quanto spesso ti rilascia durante uno sprint. Solo alla fine dello sprint o ogni volta che una funzione è pronta. E come gestire le versioni di bugfix?
Quanto spesso ti rilascia durante uno sprint. Solo alla fine dello sprint o ogni volta che una funzione è pronta. E come gestire le versioni di bugfix?
TL; DR: Rilascia ogni volta che è opportuno
Realizziamo rilasci ogni volta che c'è un valore nel fare un rilascio. A volte questo significa fare un rilascio dopo che una singola funzione o un bugfix sono stati completati. A volte questo significa rilasciare una raccolta di funzionalità e / o correzioni di errori.
Questo non significa che spesso abbiamo "emergenze" che richiedono rilasci veloci. Significa che abbiamo lavorato duramente per rendere le pubblicazioni facili. Il nostro codice è testato, taggato e confezionato con ogni build. Usiamo test di accettazione automatici e di conseguenza abbiamo sviluppato una grande quantità di fiducia nel codice che passa i suoi test. Poiché i nostri pacchetti sono immediatamente disponibili tramite un repository locale yum, la distribuzione di una release è banale.
Mai durante. Ciò viola la premessa di base di uno "sprint". Corri finché non finisci ciò che hai impegnato a finire. Dopo aver finito, è davvero fatto e funziona davvero. Puoi quindi 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 una pianificazione regolare degli sprint della stessa lunghezza è considerato da molti una cattiva idea. Pertanto, la regola normale è che le correzioni dei bug sono semplicemente lavori ad alta priorità che si verificano durante lo next sprint.
Se si tratta di un'emergenza, hai troppe cose in corso - supporto e sviluppo - e dovresti prendere in considerazione la possibilità di cambiare l'organizzazione per avere meno cose da fare.
Se il lavoro a cui il team si sta impegnando è propizio a fare più uscite all'interno dello sprint, rilascialo tutte le volte che vuoi.
Lo stesso vale per i rilasci di correzioni di errori - se ha senso rilasciarli, fallo.
L'ultimo lavoro Agile a cui ho lavorato ha rilasciato ogni sprint; il codice è stato congelato ogni due giovedì (sprint di due settimane), quindi il prodotto è stato confezionato e pubblicato su un server UAT con cui i nostri clienti possono lavorare. Questo era durante lo sviluppo iniziale del prodotto; per un prodotto maturo, in particolare un programma distribuibile e non un'app Web, probabilmente non vorrai sovraccaricare gli utenti con aggiornamenti ogni due o tre settimane.
Praticamente tutte le nostre pubblicazioni includevano un misto di punti storia e difetti (bug). Difetti contati come "ore non ideali"; ci sono 5 ore ideali in un giorno lavorativo, che significa codifica head-down del nuovo lavoro a punti. Le altre tre o quattro ore al giorno sono incontri, discussioni, progetti, a volte "picchi" (ricerca focalizzata / sviluppo di proof-of-concept) e lavoro sui difetti; roba che contribuisce a un prodotto migliore ed è una parte necessaria del processo, ma semplicemente non può occupare l'intero sprint dell'intero team. L'unica volta in cui abbiamo realizzato rilasci di difetti era quando non c'era nessun lavoro di story-point disponibile nel backlog come in un IPM; poi abbiamo semplicemente programmato uno sprint QA in cui siamo stati incaricati di "uccidere quanti più difetti possibile". Perché non avendo i requisiti pronti a partire è SEMPRE l'errore dell'OP (e l'OP ha funzionato per i clienti), potremmo semplicemente emettere un avviso di modifica del contratto e lavorare con ciò che avevamo. Ovviamente, una volta terminato il lavoro della storia reale e lo sviluppo della "garanzia", i difetti erano tutti presenti.
In un progetto Agile ben gestito, l'esaurimento dei requisiti non dovrebbe mai accadere; il backlog dovrebbe sempre avere uno sprint di valore di lavoro pronto da raccogliere. Ma a volte il PO viene sommerso dai requisiti di produzione; a volte i BA / tester tengono il rilascio di storie per lo sviluppo arretrato, per ragioni relative alla qualità dei requisiti o ai conflitti tra storie; a volte una squadra decide di dover "punt" su una storia che non era ben definita o ben stimata, e non c'è qualcosa che possa facilmente occupare i cicli rimanenti. In breve, anche in Agile, avviene la merda.
Che cosa intendi per rilascio? Se intendi PSP, probabilmente un prodotto che può essere spedito, hai due opzioni:
La principale differenza tra il livello 2 e il livello 3 è che nel livello 2 devi fare un po 'di sforzo per rendere definitiva la PSP alla fine dello sprint, ma nel livello 3 hai inizialmente messo da parte soldi e sforzi per i tuoi strumenti e configurazioni e tu PSP ha preparato automaticamente tutto il tempo = non è necessario alcuno sforzo manuale. Raggiungere completamente il livello 3 è raro.
Non ci sono assolutamente regole in Scrum su quando possono essere implementate nuove funzionalità. Ogni squadra deve avere una "definizione di fatto", che dovrebbe sempre includere alcuni criteri di test. Una volta che una funzionalità è "completata", è 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 attendere la fine dello Sprint per distribuirlo.
Nessuno dei due significa che non è presentato alla riunione di Sprint Review / Planning. Il concetto è che tutto ciò che il Team ha completato viene mostrato all'OP (e alle altre PMI del cliente) in modo che possano incorporarlo nella crescente comprensione del sistema man mano che evolve.
Dopo un paio di settimane abbiamo trovato una buona soluzione che si adatta alle nostre esigenze. Decidiamo di rilasciare quando vogliamo. Come lo facciamo:
Ecco. Usiamo git e maven come sistema di CI e abbiamo una buona copertura di test. Qual è uno dei motivi per cui possiamo fare così.
Rispondere a una domanda che ha quasi 2 anni può essere un po 'ridondante, ma sperare di aggiungere valore per gli altri che vengono a questa domanda vorrei aggiungere un 2cento o giù di lì. :)
Per rispondere alla domanda: dovresti preferibilmente rilasciare ciò che è stato impegnato nello sprint, alla fine di quello sprint. Farlo è in linea con tutte le altre parti / processi / linee guida di scrum che sono orientate a ottenere il miglior valore aziendale al momento giusto.
MA le emergenze, i bug, gli eventi imprevisti ecc. possono forzare la mano, che è il luogo in cui il concetto se "Pianificazione della versione" potrebbe tornare utile. Con "Release Planning" non intendo pianificazione a cascata, ma piuttosto pianificazione di aspettative che potrebbero aiutare a gestire il backlog di prodotto e la priorità delle storie negli sprint ect.
Ma forse il commento di David sulla questione è qualcosa da considerare meglio. Scrum non è sempre la risposta giusta.
Leggi altre domande sui tag release-management scrum