Come gestire il project manager che si arrabbia quando le attività trascorrono più giorni nello sviluppo?

1

Il nostro processo è che gli sviluppatori creano sottotask per le storie degli utenti per tracciare il loro lavoro su quella particolare user story sulla lavagna.

Buono finora.

Tuttavia, abbiamo un project manager de facto che tenta di "fare agile" e assumere il ruolo di scrum master. Durante la situazione quotidiana, diventa visibilmente sconvolto quando una sottotabella si trova nella colonna "In sviluppo" per più di un giorno o due. Afferma che gli sviluppatori dovrebbero creare sottoattività equivalenti a 4-8 ore di sviluppo. In questo modo, ci dovrebbero essere sottotasks che si muovono su tutta la linea ogni volta.

Come sviluppatore, ho voglia di provare a dividere arbitrariamente il mio lavoro in blocchi di 4-8 ore e creare un compito separato per ognuno solo così si sente meglio quando guarda la lavagna:

  1. non ha senso
  2. spreca tempo di sviluppo
  3. crea documenti inutili / lavoro impegnato che impantana il processo

Come sviluppatore, qual è un modo solido per gestirlo?

    
posta Derek 17.06.2017 - 00:27
fonte

3 risposte

5

Quattro punti ....

  1. Per Schwaber e Beedle, un'attività Scrum dovrebbe prendere circa da 4 a 16 ore . Alcuni compiti complicati possono richiedere più tempo se il team non riesce a trovare un modo migliore per scomporlo. Quindi, anche se il tuo collega ha parzialmente ragione, anche lui è in parte in errore. Magari comprargli una copia di questo libro e chiedigli di leggerlo (gentilmente).

  2. La ripartizione dell'attività ( comprese le ore stimate ) dovrebbe essere rivisto durante lo sprint kickoff, e il supervisore della mischia dovrebbe essere presente e consapevole delle ore associate a ciascuna attività. Se ha un problema con la lunghezza di un particolare compito, dovrebbe parlare poi, e non più tardi. Assicurati di richiamare la sua attenzione sulle stime durante il calcio d'inizio.

  3. La percezione del progresso dovrebbe essere gestita da due cose: obiettivamente, tramite il tasso di burndown e soggettivamente tramite demo. Non osservando le attività spostare su tutta la linea. Se i tuoi sprint durano più di 2 settimane, potrebbe aver senso programmare più demo, eventualmente settimanalmente. Se riesce a vedere i progressi con altri mezzi, forse non si ossessionerà così tanto nel contare i compiti.

  4. Anche se l'attività non è completata, le ore completate / rimanenti dovrebbero essere aggiornate quotidianamente. Quindi, se il tuo manager guarda le ore rimanenti totali invece delle attività rimanenti totali, forse sarà soddisfacente.

risposta data 17.06.2017 - 00:59
fonte
4

Chiedigli "qual è il valore del sottotitolare il mio lavoro in 4-8 pezzi di tempo?" seguito da "le nostre storie utente non dovrebbero essere abbastanza piccole da non dover essere sottoposte a sottoprogrammi?"

I project manager che tentano di "fare Agile" tendono a cadere in questa trappola dove si collegano alle parti più meccaniche di Scrum, in genere cose come attività a tempo e impegno sprint, perché sono le parti di Scrum più familiari a ciò che già fanno sai, che è la gestione degli stili di comando e controllo.

Sembra che questo manager de facto abbia bisogno di aiuto per comprendere i valori e i principi di Agile. Forse indirizzandolo al Agile Manifesto .

Senza un cambio di visione del mondo, è improbabile che questo gestore sia in grado di implementare correttamente Scrum.

    
risposta data 17.06.2017 - 00:47
fonte
2

Scrum, più di ogni altra cosa, riguarda la cultura, compresa la cultura dell'organizzazione in generale. Tutti devono comprarlo, dall'alto verso il basso, affinché abbia successo. Dato che, se l'organizzazione è completamente dietro a Scrum, è possibile effettuare alcune mosse per allineare meglio questo "manager" con il ruolo Scrum Master, o per sostituirlo con uno Scrum Master reale. Se l'organizzazione è non dietro Scrum, allora probabilmente sei fregato per cominciare.

In definitiva, il ruolo di Scrum Master è non un ruolo manageriale. Il compito dello Scrum Master è quello di rimuovere gli impedimenti al team di sviluppo nel fare eseguire i PBI e assicurare che il rituale di Scrum sia rispettato. Questo è tutto. In Scrum, il team di sviluppo è responsabile della definizione dei propri obiettivi, dell'assegnazione del lavoro agli sprint e dell'impostazione della cadenza e della velocità. Tutto questo è fondamentalmente disallineato con uno stile di gestione tradizionale dall'alto verso il basso.

Tutto ciò che ho detto, ci sono due cose da guardare qui. Innanzitutto, un'attività che occupa più giorni è probabilmente un segno che dovrebbe essere suddivisa in attività più piccole. L'unica altra ragione per cui occorre tanto tempo è se c'è un impedimento che impedisce di essere completato, che è quindi il compito dello Scrum Master, e quindi del tuo attuale tipo di manager, da risolvere. Se hai una ragione valida per cui non riesci a completare l'attività, è compito tuo far sapere allo Scrum Master, quotidianamente o prima, e poi il suo lavoro, di risolverlo, in modo che tu possa andare avanti con il tuo lavoro. Sinceramente, però, nella maggior parte dei casi un compito abbastanza grande da richiedere più giorni e che non potrebbe essere suddiviso in più attività, segnalerebbe un PBI che in realtà è troppo grande per adattarsi a un singolo sprint . Dovresti gestire queste cose di conseguenza.

In secondo luogo, alla fine potresti non avere molto potere in questa situazione. Se il tuo manager ti sta dicendo di interrompere l'attività, interrompi l'attività. Che sia una cosa da "Scrum", oltre al punto, perché in realtà non stai seguendo lo Scrum anche dal fatto che hai un manager che ti dice cosa devi fare. Puoi educatamente affrontare il problema e tentare di spiegare perché non pensi che questo sia un buon modo per fare le cose, ma alla fine, ciò che dice il tuo manager, va, e dovrai vivere con quello, o cercare un impiego alternativo.

    
risposta data 27.07.2017 - 19:17
fonte

Leggi altre domande sui tag