Stima dei punti di mischia per team non interfunzionali

4

Stiamo lavorando per trasformare il nostro team di sviluppo in modo più agile. Ho una domanda sulla stima del punto della storia e sulla loro relazione con l'abilità di un individuo.

Lo scenario è che i membri del nostro team non hanno competenze interfunzionali. Uno potrebbe focalizzarsi interamente sul front-end, un altro solo sul back-end.

Il problema non riusciamo a pianificare di conseguenza la composizione del nostro team. Calcoliamo, se la nostra velocità media è diciamo 200 punti per sprint, allora quel numero non dovrebbe essere superato. Tuttavia, le attività variano ogni sprint e talvolta ci sono troppe poche attività di back-end o troppo poche attività front-end.

La mia domanda è - dovremmo dividere e pianificare separatamente le attività di back-end e front-end, o c'è un modo migliore?

    
posta Zappateur 15.06.2015 - 14:38
fonte

4 risposte

3

Quando pianifichi in Scrum, la prima cosa da capire è che dovresti non cercare di pianificare il lavoro per tenere tutti occupati, ma piuttosto dovresti provare a pianificare una certa quantità di funzionalità che il tuo team proverò a consegnare alla fine dello sprint.

In Scrum, l'input per la pianificazione è il backlog del prodotto, che dovrebbe contenere le funzionalità desiderate nell'ordine in cui forniscono il massimo valore all'azienda. Durante la pianificazione, prendi gli articoli dalla parte superiore del backlog del prodotto finché non hai abbastanza lavoro per riempire uno sprint.
Se la parte superiore del backlog del prodotto contiene molte caratteristiche che coinvolgono principalmente il lavoro front-end, allora può accadere che lo sprint sia "pieno" prima di raggiungere il punteggio di 200 punti. Completo qui significa che gli sviluppatori front-end sono completamente caricati.

All'interno del framework Scrum ci sono alcune possibilità per affrontare questa situazione:

  • Se prevedi un sacco di back-end nel backlog, che si tradurrebbe nella stessa situazione nel prossimo sprint, puoi negoziare con il Product Owner per scambiare alcune storie pesanti front-end per il back-end storie pesanti per creare un carico di lavoro più uniforme sul team.
  • Se non c'è nulla di adatto allo scambio, o se il Product Owner non è d'accordo con uno swap, allora è bene rendersi conto che ci sono sempre attività che possono essere raccolte da qualsiasi membro del team. Se non ci sono attività correlate al back-end su cui gli sviluppatori back-end possono lavorare, dovrebbero cercare di aiutare gli sviluppatori front-end a sfruttare al massimo le loro capacità in modo che il team possa terminare il lavoro il programmato.
    Esempi di lavoro che gli sviluppatori di back-end potrebbero raccogliere sono:
    • Scrivi le specifiche del test
    • Esegui test manuali
    • Scrivi test unitari
    • Se hanno familiarità con la tecnologia front-end, esegui recensioni
    • ecc.

In Scrum, l'obiettivo non dovrebbe essere quello di lavorare individualmente alla massima capacità / produttività, ma che il team produce ciò che avvantaggia maggiormente il business.

    
risposta data 15.06.2015 - 19:23
fonte
2

Quando il team disegna storie durante la pianificazione dello sprint, deve tenere in considerazione le proprie abilità disponibili. Ciò significa che potrebbero trarre una storia da backend e lasciare sul tavolo una trama pesante, se hanno capacità di back-end gratuite, o viceversa.

Se non altro, alcuni programmatori potrebbero trovare il tempo per il necessario refactoring.

Se lo squilibrio persiste per un lungo periodo, allenati nuovamente o cambia squadra.

    
risposta data 15.06.2015 - 17:22
fonte
1

Se hai zero o pochissimo sviluppo del backend (o viceversa), per tutti gli scopi pratici, tratti quella persona come faresti se andasse in vacanza o lavorasse su un altro progetto. Un particolare scatto consente di regolare i punti totali della storia.

Da un punto di vista gestionale, potresti considerare questa come un'opportunità per addestrare trasversalmente le persone con la programmazione della coppia. Se il cross-training è uno degli obiettivi di questo progetto, allora conta entrambi i tempi / punti dello sviluppatore. Avrai un modo più accurato per pianificare un progetto che prevede un allenamento incrociato.

    
risposta data 15.06.2015 - 15:27
fonte
1

Sì, si dovrebbero suddividere le attività per competenza nell'area di lavoro. Ciò consentirà una pianificazione accurata delle risorse e del progetto / sprint. Diciamo dopo la stima del punto della storia che hai 100 punti front end e 50 punti back end nel corso dei prossimi mesi di interazioni di 2 settimane.

Se così fosse, a un livello molto alto bisognerebbe finire allo stesso modo:

  • 2 sviluppatori front-end e 1 sviluppatore back-end OR
  • 1 sviluppatore front-end e 1 generalista (anteriore / posteriore) O
  • 1 sviluppatore front-end e 1 sviluppatore back-end (part-time - 50%)

La stima del punto storia è il primo passo. Il secondo sta pianificando assegnazioni di risorse, flussi di lavoro + dipendenze.

Ogni progetto è diverso e fornito di persone con diverse abilità. Ci sono pochi sviluppatori "full stack" che sono bravi a fare il front end dell'interfaccia utente fino alla fine del database. Anche all'interno di una tecnologia generale come .Net ci sono specializzazioni come ASP.NET MVC, servizi WCF, Entity Framework, ecc. Quindi, prendi in considerazione le abilità degli sviluppatori quando pianifichi gli sprint dal backlog e ci sarà un utilizzo efficiente di risorse trasversali.

    
risposta data 15.06.2015 - 19:21
fonte

Leggi altre domande sui tag