Come usare Velocity in un team non interfunzionale?

Sembra un Scrum-ma

Come indicato nei commenti, non hai uno Scrum team se non è cross-funzionale.

Scrum Teams are self-organizing and cross-functional

La combinazione di sviluppatori front-end e back-end rende effettivamente il cross-functional del team. Gli sviluppatori non sono robot; nessuna squadra è composta da membri completamente identici. Sembra che il problema che stai mettendo in evidenza è che puoi vedere che non avrai un utilizzo perfetto attraverso questo sprint.

La velocità non è un predittore perfetto del lavoro, solo uno strumento. Se occasionalmente non ottieni pieno utilizzo, questo avrà un impatto sulla tua velocità. Se la squadra non crede di poter realizzare questa storia a 9 punti nello sprint, allora dovrebbe scomporla in una storia realizzabile e portare qualcos'altro in modo che possano rimanere produttivi.

Forse il team si è auto-organizzato in una divisione back e front-end perché risolve il problema per la maggior parte degli sprint. È un ovvio compromesso a causa di scenari come te descritti, ma nonostante ciò, potrebbe ancora essere il modo più efficiente per organizzarsi.

In termini di divenire più cross-funzionali, la tua squadra dovrebbe cercare di condividere le competenze. Tecniche come la programmazione della coppia sono spesso raccomandate per questo. Dato che hai già due coppie, sembra ideale associare uno sviluppatore back-end e front-end.

Qualsiasi membro del team dovrebbe essere in grado di svolgere qualsiasi compito. Non devi essere un esperto per contribuire. Guarda l'open source come un esempio di modifiche che vengono trattate in base ai loro meriti. È possibile utilizzare le revisioni del codice per garantire che la qualità rimanga elevata nell'intero codebase.

Sono stato in molti diversi tipi di team e mi considero uno specialista generalista .

O creare due team / progetti separati o semplicemente sapere che alcuni sprint saranno spenti sulle stime quando le attività sono pesanti in un'area rispetto all'altra.

Sembra che tu abbia davvero due squadre diverse. Fai tutto separatamente quando si tratta di pianificare sprint. Dove disegna la linea per separare un progetto o trattarlo come lo stesso progetto? È solo una questione di prospettiva. Un gruppo potrebbe creare un'app di front-end e un'altra una sorta di back-end o servizio. Solo perché entrambi stanno costruendo quello che potrebbe essere chiamato il sistema di fatturazione non significa che devono fare tutto insieme. Raccogli storie, mantieni sincronizzati entrambi i progetti e poi parti da solo per costruire ciò che hanno in programma durante lo sprint e tracciare la propria velocità.

Se vuoi tenere unita la squadra, ti limiti a farlo. Dovrai adeguare la quantità di lavoro svolto per lo sprint. Non aspettarti di averlo esattamente. Non è diverso quindi avere uno sviluppatore non disponibile durante una parte importante dello sprint. È necessario identificare questi sprint con scarsa produttività, in modo da poter prendere decisioni future in termini di personale e formazione. Se ciò accade una volta ogni tanto, nessuno prenderà misure drastiche per risolverlo. È un'occasione per allenarsi trasversalmente se la squadra è incline. Molti non lo sono.

Una chiave per tentare di stimare non è guardare troppo stretta di un compito o una porzione di tempo. Stai cercando di stimare in media ciò che l'intera squadra può realizzare durante uno sprint. Non tutti gli sprint sono uguali e chi lo fa sempre in modo perfetto probabilmente è barare. Quando il lavoro è bilanciato su tutti i set di abilità, il team sarà più produttivo. Molte squadre non hanno un equilibrio di talento. In una squadra di 4 persone, quando lo sviluppatore principale non è disponibile, non contare su ottenere il 75% del lavoro svolto. Non puoi nemmeno ottenere il 50%.

Supponendo che la storia a nove punti sia fatta, hai due possibilità:

1. tira la storia e fai del tuo meglio. Forse le persone di back-end possono aiutare facendo le parti di test o di documentazione della storia
2. dividi la storia in storie più piccole in modo da poter realizzare una storia in questo sprint e una o più nei seguenti sprint.

Ricorda: i punti storia e la velocità sono semplici strumenti per aiutarti a pianificare. Alla fine della giornata, la tua squadra deve decidere come eseguire il lavoro usando i punti come guida piuttosto che una legge immutabile.