Come coordinare gli sviluppatori tra due diversi progetti in Scrum?

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

• Inserisci nuove attività nel backlog.
• Non interrompere gli sviluppatori.
• Attendi lo sprint successivo.

Mettendo i tuoi sviluppatori in più di una mischia, avendo due backlog separati o assegnando solo una percentuale del loro tempo allo sprint, tutto funziona contro quello che sta cercando di ottenere, cioè un flusso consistente di compiti completati.

Se provi questo tipo di cose, in sostanza, torni alle metodologie di sviluppo "caos" o "JFDI" con tutti i relativi problemi, ad es.

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

Ovviamente la solita risposta a questo consiglio è "Ma non posso farlo! Il business ha bisogno che quegli errori di produzione siano risolti al più presto!"

Ma non è proprio vero.

Se hai davvero tanti bug reali che stanno interessando il business in questa misura, allora devi diventare un professionista e migliorare i tuoi test. Basta lavorare su bug e test automatici fino a quando non li hai risolti tutti. Assumi una squadra di QA e prova a morte tutte le nuove uscite.

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

• Gli errori sono problemi operativi, esaurimento spazio su disco, 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 forma i tuoi utenti, scrivi documentazione.

• Paura del rollback. Hai lanciato una nuova funzionalità e si è rotto qualcosa, non provare ad affrettare una correzione. Tornare alla versione precedente e inserire gli errori nel backlog.

Sto solo provando a pensare fuori dagli schemi qui.

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

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

Avrai bisogno di un team di 5+ perché sia realistico, forse.

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

Poiché molto probabilmente non ci sono errori sufficienti per utilizzare uno sviluppatore completo per le correzioni, ci sono altri problemi o attività che è possibile eseguire.

• Esecuzione di test per identificare colli di bottiglia delle prestazioni o problemi di scalabilità
• Manutenzione del sistema di build
• Riunioni con i clienti
• Ricerca di nuovi framework / librerie
• Esplorare le funzionalità del linguaggio che desideri utilizzare
• Informazioni su problemi di sicurezza
• Manutenzione del database
• Manutenzione del server

La velocità del team potrebbe aumentare, lo stress potrebbe scendere, i conflitti con la gestione potrebbero andare giù, in realtà avrai tempo per migliorare le tue conoscenze.

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

Il costoso aspetto 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 passa in rassegna il ciclo, in modo che ogni giorno una nuova persona venga dichiarata "Batman" durante lo stand up meeting e risponda 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 di sofferenza per il supporto. Con un team di 5, è un giorno alla settimana in cui uno sviluppatore può essere interrotto e 4 giorni di tempo di sviluppo prevedibile e ininterrotto.

Questo ha il vantaggio di condividere la conoscenza / esperienza tra i membri del team, in modo da non avere una persona responsabile per la risoluzione di problemi particolari e diventare un unico punto di errore e un'equa divisione dei problemi di supporto.