Come gestire attività di manutenzione a breve preavviso (ma ad alta priorità) in SCRUM

Se ottieni più di queste attività, forse KANBAN sarebbe un'alternativa migliore, ma sembri impostato per SCRUM, quindi vediamo cosa puoi fare all'interno di SCRUM:

SCRUM ha una cosiddetta lista di impedimenti . Questa è una lista di tutte le cose che impediscono alle persone di essere produttive. Tale compito non è stato pianificato nello sprint e farlo invece di lavorare sull'obiettivo sprint è un impedimento.

D'altra parte, sembra che questo sia un compito pianificato. Potresti avere un elemento del backlog che dice "gestire le richieste da parte dell'analitica" che pianifichi in ogni sprint.

Abbiamo una modalità operativa di sviluppo e supporto. Seguiamo SCRUM. Abbiamo un ambiente simile in cui potremmo non essere in grado di prevedere quali casi / biglietti arriveranno durante uno sprint, quindi abbiamo stanziato l'80% del nostro tempo in uno sprint per il lavoro di sviluppo e il 20% per il lavoro di supporto durante la pianificazione dello sprint.

Quando ci impegniamo durante uno sprint, abbiamo alcune storie utente estese che potremmo fare nel caso in cui non abbiamo abbastanza lavoro di supporto durante quel particolare sprint e abbiamo finito con le nostre user story impegnate. Credo che allo stesso modo sia possibile avere una user story per lo script nel backlog sprint e prenderla se viene altrimenti continuare con il lavoro di sviluppo.

Spero che questo approccio ti aiuti.

L'ho sicuramente sperimentato in diverse impostazioni agili.

Suggerirei di considerare le "regole" come linee guida che consentono eccezioni e modifiche rispetto al normale processo.

Se questi biglietti sono già di dimensioni adeguate, sai esattamente qual è il lavoro E conosci la loro priorità - apparentemente più importante di quanto avrei consentito che questi biglietti fossero stimolati direttamente nella colonna pronta.

Per completare le attività è necessario tenerne conto quando si pianifica lo sprint: si prevede di avere attività che occupano solo il 75% del tempo disponibile (non è facile da fare!) o di tenere conto del fatto che alcune attività non essere completato quando arrivano queste richieste 'asap'.

Suggerisco anche di esaminare l'uso del kanban incentrato su un flusso continuo di ticket e di lavoro piuttosto che su scrum focalizzato su sprint di lunghezza fissa.

• Se tali attività di manutenzione si verificano senza una pianificazione prevedibile, perché non classificarle come incidenti? Se tutto ciò che hai è un martello, il tuo compito diventa un chiodo.
• In alternativa, inserisci diverse attività nel backlog con l'etichetta "esamina gli script e aggiorna come richiesto". Tira uno per ogni settimana dello sprint, chiudili quando hai cambiato lo script o hai stabilito che non è necessario apportare modifiche.

Ma questo sta cercando di inserire i pioli quadrati nei fori rotondi. Gli aggiornamenti di script sono così tanto utili da renderli tracciati alla lavagna? Ogni programmatore dovrebbe avere un po 'di tempo libero per le cose che hanno bisogno di fare, senza biglietto.