Come coordinare il tempo degli sviluppatori tra due diversi progetti in Scrum?

Sono diventato il mastro scrum di un team di nuova costituzione, che è responsabile della creazione di un software e della manutenzione di altre applicazioni distribuite. Quindi praticamente ogni membro del team ha compiti di sviluppo e operazioni.

Ho osservato come funzionano nelle ultime due settimane e ho notato che il team sta avendo problemi nel coordinare questi compiti. quando uno sviluppatore si sta concentrando sulla programmazione, viene interrotto per risolvere un problema sollevato durante la produzione, ed è difficile per lui concentrarsi nuovamente sulle attività precedenti.

Ho provato ad allocare% del tempo di sviluppo per operazioni funzionanti, ma a quanto pare questo non sta risolvendo il problema. Sono interessato a ricevere notizie da scrum master che si sono già imbattuti in questa situazione, come l'hai gestita e quali sono i tuoi consigli?

Questo problema è vecchio quanto la mischia. C'è una soluzione, ma non ti piacerà.

• Inserisci nuove attività nel backlog.
• Non interrompere gli sviluppatori.
• Aspetta il prossimo sprint.

Mettendo i tuoi sviluppatori in più di una mischia, avendo due arretrati separati o assegnando solo una percentuale del loro tempo allo sprint tutto funziona contro ciò che la mischia sta cercando di raggiungere, cioè un flusso coerente di attività completate.

Se provi quel tipo di cose, fondamentalmente torni alle metodologie di sviluppo "caos" o "JFDI" con tutti i suoi problemi ad es.

• Lo sviluppatore ha dieci attività in movimento alla volta. Nessuno sa a cosa stanno lavorando o quando sarà finito.
• Tempo sconosciuto per terminare il progetto, perché dipende da quali altri progetti stanno accadendo contemporaneamente.
• Nessuna visione coerente della priorità del progetto. Altri gestori indirizzano gli sviluppatori verso i loro progetti di animali domestici.

Naturalmente la solita risposta a questo consiglio è "Ma non posso farlo! Il business ha bisogno di correggere quei bug di produzione al più presto!"

Ma questo non è proprio vero.

Se hai davvero tanti bug reali che stanno interessando il business fino a questo punto, devi diventare professionale e migliorare i tuoi test. Lavora solo su bug e test automatici fino a quando non li avrai risolti tutti. Assumi un team addetto al controllo qualità e prova tutte le nuove versioni.

Ciò che è più probabile è uno dei seguenti:

• I bug sono problemi operativi, spazio su disco insufficiente, nessun DR, nessun backup, nessun failover ecc. Ottieni un team OPS.

• I bug sono gli utenti che non capiscono come dovrebbe funzionare il sistema "Questo è successo! È un bug?". Ottieni un helpdesk e addestra i tuoi utenti, scrivi documentazione.

• Paura del rollback. Hai lanciato una nuova funzionalità e si è rotto qualcosa, non cercare di affrettarti a risolvere il problema. Ripristina la versione precedente e inserisce i bug nel backlog.

Sto solo cercando di pensare fuori dagli schemi qui.

Poiché potrebbe non essere possibile convincere il proprietario del prodotto a vedere le cose a modo tuo. Potrebbero esserci ancora errori critici che semplicemente non possono aspettare, incontrare i clienti dove è necessaria l'assistenza degli sviluppatori, ecc. Dove è necessario eliminare uno sviluppatore dallo sprint per un po '.

Perché non provare ad anticiparlo e usarlo a tuo vantaggio?

Avrai bisogno di una squadra di 5+ perché sia ​​realistica forse.

Ma perché non eliminare uno sviluppatore ogni sprint (ruotando tra gli sviluppatori, ognuno ottiene il proprio turno).

Poiché molto probabilmente non ci sono abbastanza errori per utilizzare uno sviluppatore completo per le correzioni, ci sono altri problemi o attività che possono essere eseguiti.

• Esecuzione di test per identificare colli di bottiglia delle prestazioni o problemi di scalabilità
• Manutenzione del sistema di compilazione
• Incontri con i clienti
• Ricerca di nuovi framework / librerie
• Esplorazione delle funzionalità linguistiche che desideri utilizzare
• Leggere su problemi di sicurezza
• Manutenzione del database
• Manutenzione del server

La velocità della squadra potrebbe aumentare, lo stress potrebbe diminuire, i conflitti con la gestione potrebbero diminuire, in realtà hai tempo per migliorare le tue conoscenze.

Una soluzione efficace per la gestione degli sforzi degli sviluppatori per problemi di produzione veramente essenziali che ho usato è "l'approccio di Batman".

L'aspetto costoso della responsabilità di supporto alla produzione durante lo sviluppo di nuove funzionalità è il cambio di contesto, quindi dovresti mirare a limitarlo.

Con il buy-in del team, crea un elenco dei membri del team e scorrilo ciclicamente, in modo che ogni giorno una nuova persona venga dichiarata "Batman" durante lo stand up meeting e risponderà ai problemi di produzione essenziali in quel giorno. Il resto del team può rimanere concentrato sullo sviluppo senza dover cambiare contesto e tutti hanno una buona dose del dolore del supporto. Con un team di 5, è un giorno alla settimana in cui uno sviluppatore può essere interrotto e 4 giorni di tempo di sviluppo ininterrotto e prevedibile.

Questo ha il vantaggio della conoscenza / esperienza condivisa tra il team, quindi non hai una persona responsabile per risolvere problemi particolari e diventare un unico punto di fallimento e un'equa divisione dei problemi di supporto.