Come posso assicurarmi che il lavoro pianificato non superi la capacità, a persona?

-3

Attualmente gestisco un team di 1 sviluppatori di backend e 2 sviluppatori di frontend. Di solito suddividiamo le attività in sottotitoli backend e frontend.

Prima di impegnarci in un ambito per un'iterazione, assegniamo e stimiamo le attività secondarie. Quindi ci assicuriamo che la somma delle stime di ogni sviluppatore sia inferiore alla durata dell'iterazione (20 giorni). È importante pianificare a persona, non per l'intera squadra, perché altrimenti rischiamo di sovraccaricare il singolo sviluppatore di back-end.

Questo è un processo manuale al momento, dove passiamo attraverso il ticket tracker e sommiamo tutte le stime. Mi piacerebbe trovare una soluzione migliore che renderebbe più facile. Idealmente, mi piacerebbe vedere rapidamente se a uno sviluppatore sono stati assegnati più compiti di quanti possano adattarsi a una iterazione.

Ho provato a cercare in Jira, ma non sembra fornire tali capacità di pianificazione. Permette di pianificare l'intera squadra, ma non a persona. (Il rapporto sul carico di lavoro della versione si avvicina, ma non consente alcun filtraggio, quindi in un gruppo più grande diventerebbe molto affollato).

  1. Come posso stimare rapidamente il lavoro per persona pianificato per un'iterazione?
  2. Mi manca qualcosa e risolvo il problema sbagliato?
posta sbichenko 29.07.2017 - 21:06
fonte

1 risposta

3

How can I quickly estimate work per person planned for an iteration?

Suppongo che la risposta a questa domanda sia ciò che stai facendo ora: stai stimando rapidamente il lavoro a persona. E non funziona come vuoi.

Quello che vuoi veramente è una stima molto precisa che puoi ottenere, e non c'è nessuno strumento per questo perché hai a che fare con umani che possono commettere errori, occuparsi di cose casuali, stancarsi, ammalarsi, lasciare il lavoro , o anche morire.

Anche mettendo da parte il fattore umano, ci sono sempre alcuni compiti casuali che possono apparire durante uno sprint, e ci vorrà più tempo anche se hai stimato le attività conosciute con precisione.

Am I missing something, and solving the wrong problem?

Penso che sia una questione di scelta del paradigma del ciclo di vita del software.

  • Se alcune attività non rientrano in uno sprint, puoi semplicemente rimandarle a uno sprint successivo. Se deve prendere così a lungo , impiegherà quel lungo .

  • Puoi liberarti del tuo arbitrario periodo di tempo di 20 giorni e rilasciare appena tutto ciò che desideri rilasciare è completo. Sono le caratteristiche che sono importanti, non il fatto che si adattino in 20 giorni, giusto?

  • Puoi mettere meno compiti in uno sprint. Ad esempio, pianifica solo il 70% di quello che hai stimato. Puoi trascorrere il tempo libero migliorando la qualità e affrontando il debito tecnico.

  • Anche se sei costretto (dai tuoi clienti) ad avere delle stime, puoi spiegare loro che avviene la merda, ea volte ci vuole più tempo.

Concedersi la possibilità di commettere errori non fatali e prevedibili crea un ambiente di lavoro migliore in cui gli sviluppatori si sentono al sicuro. Come sviluppatore, so quanto sia meglio non avere una scadenza: il lavoro richiede sempre lo stesso tempo (perché lo è, lo sai), ma mi sento meno stressato e produco di conseguenza un codice migliore.

    
risposta data 29.07.2017 - 22:47
fonte

Leggi altre domande sui tag