Come dovrebbero supportare / bugfix funzionare in un'organizzazione più grande?

Sono un altro sostenitore di "Total Ownership".

Penso che aiuti a guidare la qualità. Ho lavorato in un'organizzazione in cui c'erano "team di caratteristiche" e "team di bug". Sembra che le squadre di bug stiano bruciando e perdendo terreno sul loro backlog. Alla fine hanno capito che forse c'era bisogno di essere solo squadre e ogni squadra era responsabile sia delle caratteristiche che degli errori nella sua area.

L'ultima cosa che vuoi sono gli sviluppatori "su chiamata". Non c'è modo la risposta giusta è un cambio di codice / ruolo nel mezzo della notte senza controllo di qualità o controllo degli adulti. Non finirà bene.

Come altre persone hanno suggerito, ci dovrebbe essere una sorta di DevOps o staff di supporto che ha un piccolo set di pulsanti che possono spingere per riavere il cliente online. Esattamente cosa e come dipende dalla natura del tuo software / servizio. Possono scrivere l'incidente e inoltrarlo alla squadra di mischia appropriata.

Nella mia organizzazione supportiamo più prodotti e ogni team ha un bug bug settimanale che incontra il responsabile dell'assistenza, il proprietario del prodotto e il lead tecnologico dove è possibile effettuare una disposizione iniziale.

Pianifichiamo anche i nostri sprint solo per l'80% della capacità, quindi abbiamo un buffer per le escalation impreviste del servizio clienti (e altre sorprese). Ciò significa che non stai influenzando il lavoro pianificato dal momento in cui succede qualcosa. E, se hai un tranquillo sprint in termini di supporto, puoi sempre inserire una trama o due per riempire la capacità in eccesso.

Nella mia esperienza, i bug sono disponibili in due varianti:

• Deve essere risolto come ... ieri. Luci rosse lampeggianti. Sirene. Boss che richiedono uno stato.
• Oh. Si. Lo sistemeremo. Ad un certo punto. Può essere.

Nel primo caso, è quello che è. Questo non interessa per "Sprint" o pianificazione o velocità o punti. Deve essere fatto al più presto e rovinerà il tuo piano. Non c'è niente che tu possa fare. Non vuoi che chi è in una sorta di rotazione per questo, vuoi la persona che può fare il lavoro meglio su questo. E tu lo vuoi ora. Non c'è niente che tu possa fare. Molto probabilmente sono proprio i PO / PM che si lamentano della velocità che lo desidera. Lascia che scoprano come recuperare il loro piano dopo un incidente del genere.

Nel secondo caso, vuoi stabilità per la pianificazione. Ma ovviamente non sai cosa sarà scoperto se gli sviluppatori si immergono davvero nel bug report. Quindi utilizza uno strumento Scrum testato: Timeboxing . Assegna un timebox per il tuo primo sprint per scoprire cosa deve essere corretto. Ad esempio: una persona impiega un giorno lavorativo per capire cosa c'è che non va. Se si risolve anche l'errore, ottimo. Fallo e basta. Altrimenti, la tua storia è "finita" nella misura in cui l'hai capito e ora puoi scrivere una storia per il prossimo sprint che può essere correttamente stimato. Se quel timebox è finito e non hai ancora capito il bug, allora quella storia non è completata alla fine dello sprint e forse deve essere discussa. Qualunque cosa accada, hai stabilità per questo sprint attraverso il timebox e hai una stima migliore per il prossimo sprint perché hai dati complessi e non solo una segnalazione di bug.

Penso che sia ovvio che Scrum ha bisogno della proprietà del prodotto. Non puoi avere Scrum corretto se un'altra squadra può apportare modifiche arbitrarie al tuo prodotto dietro la schiena.

L'approccio migliore che ho visto è un mix di "proprietà totale" e "team di supporto dedicato"

Il team di sviluppo per l'app possiede tutti i bug e deve dare la priorità e scrivere le correzioni nei loro sprint.

Il team di assistenza distribuisce l'app e reagisce ai problemi in tempo reale. Ma solo ripristinando i rilasci, riavviando server e sollevando bug ecc. Non cambiando codice.

Quindi nel caso di un bug di "smantellamento del treno" in diretta hai una risposta predeterminata. Tornare alla versione precedente per riportare i clienti online, inserire il bug nel registro di back-up del team in modo da assegnare la priorità allo sprint successivo.

Ora la pressione sul team di sviluppo non è più "il sito è inattivo !!" ma meno preoccupante 'l'ultima versione è stata ritirata! abbiamo bisogno di quelle caratteristiche! '. Dare al project manager una maggiore flessibilità su come reagire al problema.

Smashing una correzione di codice e metterlo su server live nel bel mezzo della notte non è davvero ciò che qualcuno vuole fare. Distribuzioni pianificate e graduali, separate dal processo di sviluppo, uniformare questi problemi limitando gli utenti interessati e dando una risposta immediata provata