Dovremmo dedicare tempo alle riparazioni e alle implementazioni UAT come parte di uno sprint?

3

Siamo una squadra relativamente piccola e stiamo cercando di implementare una metodologia di mischia "agile" da queste parti per i nostri progetti.

Tutto il nostro lavoro è basato su progetti (non abbiamo un particolare prodotto su cui lavoriamo continuamente).

Abbiamo pianificato i nostri sprint in base alle storie degli utenti che vogliamo fornire ai nostri clienti, ma stiamo scoprendo che non stiamo pianificando efficacemente la rilavorazione che avviene durante l'UAT (cioè i difetti persi durante i test, minori 'ritocchi' richiesti dal cliente) e per l'implementazione in staging & ambienti di produzione.

Possiamo stimare con precisione le distribuzioni, ma la rielaborazione è per noi una vera incognita. Il tempo per queste attività deve essere preso in considerazione come parte di uno sprint o viene semplicemente trattato come un sovraccarico che si verifica tra gli sprint di sviluppo?

    
posta link64 07.03.2016 - 00:23
fonte

3 risposte

6

In breve, dipende interamente da te.

MISCHIA

Entrambe le opzioni che menzioni sono valide, scegli solo quella più adatta alla tua squadra.

Se trascorri un periodo di tempo abbastanza prevedibile eseguendo lavori di manutenzione , quindi riduci la quantità di tempo disponibile per lo sprint in modo da avere più "overhead".

Se trovi che il tempo non può essere previsto , fallo diventare parte dello sprint backlog.

Per quello che vale, io uso Kanban ora

Non uso più gli sprint fissi perché quando ho iniziato a utilizzare SCRUM ho scoperto rapidamente che non mi stava aiutando. Ora utilizzo Kanban con un flusso di lavoro che ho sviluppato personalmente; le mie ragioni per questo erano triplici:

  1. Ho scoperto che l'organizzazione del lavoro attorno ai casi d'uso tendeva a disorientare l'analisi e la progettazione del dominio (fino al punto di non far parte del flusso di lavoro documentato).
  2. L'organizzazione intorno ai casi d'uso (come ti identifichi) non si adatta alle correzioni di bug, alle revisioni di spec / scope o ad altri lavori di vario genere.
  3. Trovo che sia più in grado di prevedere quando avrò una determinata funzione pronta piuttosto che avere una durata di sprint arbitraria (in genere di due settimane).

Sulle mie schede KanBan, i miei elementi di lavoro principali sono funzioni piuttosto che casi d'uso. Questi sono definiti da un processo di analisi a livello di dominio che identifica i casi d'uso, ne ricava le funzioni e le definisce come componenti.

Ho anche oggetti di lavoro più piccoli che sono collegati alla loro funzione genitore, questi sono: Revisioni (modifica dell'ambito di una funzione), Difetti (ovvero bug o deviazioni dai requisiti delle funzioni indicate), Stranezze (modifiche minori che non sono né delle altre).

Questo mi dà una buona visione di quanto lavoro di manutenzione devo fare nelle prossime settimane o due e quanto nuovo sviluppo.

    
risposta data 07.03.2016 - 01:45
fonte
1

In un unico lavoro, eravamo abituati a stimare approssimativamente la quantità di rilavorazione che ci aspettavamo, in base agli sprint precedenti e agli articoli appena consegnati. Poi faremo il time box: accantonare una quantità fissa di tempo per il lavoro non pianificato relativo all'UDA e ridurre di conseguenza la capacità dello sprint.

Tutti i file UAT risultanti che non erano stati pianificati esplicitamente sono stati tolti dalla finestra temporale. Non rimarrà più tempo nel time box, non più lavoro UAT non pianificato.

Con due sprint settimanali, questo ha funzionato abbastanza bene.

Un avvertimento: devi davvero tenere traccia di quanta parte del time box è stata mangiata e hai davvero bisogno di fermarti (a meno che l'inferno non si congeli) quando è stato speso tutto il tempo nel time box. Ciò richiede disciplina e un buon master SCRUM per gestire le aspettative e le priorità esterne del lavoro UAT in entrata.

    
risposta data 07.03.2016 - 08:13
fonte
1

Una delle cose su cui tutti i metodi Agile, incluso Scrum, puntano è la trasparenza. Questo include anche rendere trasparente la quantità di lavoro che sta andando in cose come distribuzioni e bug fixing.

Per fare / supportare la distribuzione, che deve essere fatta ogni sprint, è possibile ridurre la disponibilità del team con il tempo necessario per eseguire la distribuzione. Potrebbe anche valere la pena di indagare su come ridurre questo carico automatizzando le cose.

Per la correzione dei bug, dovresti riconoscere 3 classi di bug che richiedono un trattamento separato.

  1. Bug trovati nello stesso sprint di cui si sta lavorando sulla storia che li ha introdotti. Questi bug dovrebbero essere risolti immediatamente, perché tecnicamente la storia non viene "fatta" mentre ci sono problemi noti. Questo potrebbe essere rinunciato per problemi che sarebbero atterrati in basso sul backlog se fossero stati trovati più tardi.
  2. Bug rilevati dopo la consegna che sono abbastanza importanti da richiedere un'attenzione immediata. Questi bug devono essere abbastanza seri da consentire al Product Owner di annullare tutti i lavori in corso per risolvere il problema. In base all'esperienza precedente, è necessario ridurre la disponibilità del team per creare un buffer per la gestione di questi bug senza disturbare troppo lo sprint. Se arrivano più bug di quelli consentiti dal buffer, dovresti iniziare a lasciare il lavoro dallo sprint.
  3. Errori rilevati dopo la consegna, la cui risoluzione può attendere almeno fino al prossimo sprint. Questi bug dovrebbero andare al backlog del prodotto e avere la priorità tra gli altri elementi del backlog. Nei prossimi sprint, introdurrai un mix di correzioni di bug e nuovi lavori.
risposta data 07.03.2016 - 09:28
fonte

Leggi altre domande sui tag