Domanda:
Il capo vuole che la mia squadra lavori nei fine settimana
bobo2000
2016-05-08 05:53:59 UTC
view on stackexchange narkive permalink

Attualmente sto gestendo un team interno di sviluppatori, alla fine di uno sprint il mio capo ha richiesto che il team finisse un po 'di lavoro entro lunedì. Ha detto che se il lavoro non può essere svolto il venerdì, il team dovrebbe lavorare sabato.

Il team è rimasto scontento, poiché:

  • vuole che il lavoro sia risolto ore (40 ore a settimana) e fare straordinari durante i fine settimana se assolutamente necessario
  • desidera staccare la spina durante i fine settimana.
  • non sono pagati per i fine settimana di lavoro.

Voglio parlarne al mio capo, come posso farlo in modo non conflittuale? Il mio capo ha il diritto di chiedere al mio team di lavorare nei fine settimana?

La squadra è pagata ogni ora o è esente?
Forse non dovresti provare ad aderire religiosamente a uno "sprint" e fare il lavoro lunedì?
A seconda del tuo contratto, il capo potrebbe effettivamente ordinarti di fare questo - fare gli straordinari - come parte del tuo lavoro. La domanda è perché è così importante?
@Raystafarian sono pagati uno stipendio che è di 40 ore settimanali.
se non ti pagano gli extra, trova semplicemente una compagnia migliore
Ovviamente alla tua seconda domanda non è possibile rispondere senza conoscere il tuo paese, e / o stato, ed eventualmente i contratti di lavoro. Eppure non parli nemmeno del tuo paese.
@pipe - Regno Unito, il contratto di lavoro è di 40 ore settimanali.
Se non vieni pagato nel fine settimana, non lavorare nel fine settimana. Stai complicando eccessivamente la tua situazione.
Chiedi al tuo capo se vuole aumentare o diminuire la produttività. Perché lavorare troppo e demotivare il team costringendolo a lavorare nei fine settimana rovinerà assolutamente la produttività.
Perché stai chiedendo un "modo non conflittuale"? Non ti sto suggerendo di iniziare a chiamare il tuo capo, ma deve esserci una sorta di confronto, giusto? È tuo obbligo nei confronti della tua squadra andare a confrontare il tuo capo con le conseguenze della sua richiesta.
"Certo, capo, sarei felice di chiedere alla mia squadra se qualcuno di loro si offrirà volontario per lavorare questo fine settimana".
non ho altra vita. quindi lavorare nei fine settimana non mi disturberà
Come funziona il lavoro salariato nel Regno Unito? È un massimo di 40 ore impostato? Il capo può richiederti di lavorare senza compenso extra?
@Graham per quanto ne so, il pagamento per gli straordinari non è obbligatorio nel Regno Unito.
"Alla fine di uno sprint il mio capo ha richiesto che la squadra facesse un po 'di lavoro entro lunedì" - se cambi l'ambito a metà, allora non è uno sprint. Il che non impedisce al tuo capo di chiederlo, ma quello che ha chiesto è di sospendere lo sprint e di fare invece qualcos'altro. Quindi non penso che faccia molta differenza se è presto o tardi nello sprint - in entrambi i casi lo sprint è rovinato. Quindi fai il lavoro venerdì e riprogramma la data di fine dello sprint.
[Riferimento Canonical Dilbert] (http://dilbert.com/strip/2001-03-01)
@Mast se ti rifiuti di fare straordinari non retribuiti, questo non dà all'azienda un motivo per sbarazzarti di te?
@bobo2000 Quindi, cosa succede se lo fa? Aspettarsi che le persone facciano straordinari non retribuiti offre anche a queste persone un motivo per trovare lavoro altrove. È un ottimo modo per assicurarti di finire con una squadra piena di persone con scarso rendimento che non possono trovare un lavoro da nessun'altra parte. Vale anche la pena considerare che esiste [una relazione inversa tra produttività e orari di lavoro lunghi] (https://hbr.org/2015/08/the-research-is-clear-long-hours-backfire-for-people-and-for -aziende). Più ore li fai lavorare, meno produttivi saranno. E quelli buoni se ne andranno.
C'è una differenza tra l'ora occasionale di straordinario e un intero fine settimana. Alcuni confini non dovrebbero essere superati.
Cinque risposte:
Jane S
2016-05-08 07:35:18 UTC
view on stackexchange narkive permalink

Leggendo la tua domanda e pur essendo completamente d'accordo con la risposta di keshlam, penso che la domanda giusta da porre sia, come manager, "come puoi ottenere il tuo capo a dare la priorità al nuovo lavoro piuttosto che imporre un aumento del carico di lavoro senza considerare l'impatto sul team? "

Se sei:

  • In ritardo in uno sprint (e potenzialmente in tempo); e
  • Ti è stato chiesto di aggiungere qualcosa allo sprint

quindi devi gestire le aspettative del capo. Ogni volta che è successo a me, dico qualcosa del genere al capo:

Se vuoi che sia fatto prima di lunedì, allora dobbiamo interrompere altri lavori per riprenderlo. Quale altra priorità di questo sprint è ora più bassa che dovrà essere inserita nello sprint successivo?

Fai che il tuo capo scelga se questo lavoro è così urgente da deve essere fatto entro lunedì in modo che altri lavori vengano ritardati o se può attendere il prossimo sprint ed essere programmato di conseguenza.

Ricorda, tu sono il manager di questa squadra. Una delle funzioni più importanti di un buon manager è gestire le aspettative del tuo capo per assicurarti che il tuo team non sia schiacciato da un pensiero arbitrario nella mente del senior management. Ho resistito in molte occasioni quando un capo mi dice che qualcosa è urgente. Invariabilmente, ottengo le mie priorità e pianifico o riprogramma di conseguenza.

Se il tuo capo sta tentando di aumentare il carico di lavoro in modo tale che il tuo team DEVE lavorare più di 40 ore a settimana per rispettare gli impegni, allora devi parlare con hai il compito di assumere risorse aggiuntive per aumentare la capacità del tuo team di mantenere il carico di lavoro dei membri del team a un livello ragionevole.

Aspetti positivi, Jane.
Grazie! È semplicemente che ho affrontato questa situazione troppe volte nella mia carriera, e andrà fuori controllo se non inizi a gestire verso l'alto.
Convincere le persone a fare una vera agilità, piuttosto che una cascata in una resistenza agile, è _estremamente_ difficile a meno che non ci sia un but-in e la volontà di dire di no e di difendere quella risposta, fino in fondo alla catena. Molti di noi stanno combattendo quella battaglia in questi giorni, e sì, richiede una gestione abile verso l'alto.
Ogni volta che ho provato a convincere qualcuno sopra di me a precisare effettivamente un cambiamento di priorità in modi simili ai suggerimenti in questa risposta, la persona si è leggermente infastidita e ha usato il doppio linguaggio senza senso per evitare di prendere una decisione (ad esempio, "prendi semplicemente questi entrambe le tue priorità "). Per quanto questo sia probabilmente l'approccio migliore, è ancora probabile che fallisca, secondo la mia esperienza. Forse sono pessimo nel gestire le aspettative del capo, ma penso che la maggior parte dei capi si rifiuti di far gestire le proprie aspettative, al punto da rifiutare completamente la realtà.
@ToddWilcox Trovo che documentare quando si riceve una decisione stupida (per iscritto!) È il modo migliore per restituire loro la responsabilità. "Volevi che fosse fatto, ti avevo avvertito che avrebbe avuto un impatto su X e Y (mostra la traccia dell'email), cosa che è successo. Come vuoi procedere la prossima volta?"
@ToddWilcox e keshlam questo è esattamente il problema che sto avendo in questo momento, felice di vedere che non sono l'UNICO PM alle prese con questo. Trovo che l'implementazione dell'agile puro sia un problema qui, spesso ricevo risposte, 'sono tutte importanti'
Per aggiungere, trovo anche che il debito tecnologico aumenta quando metto ulteriore pressione sul team: il lavoro è affrettato, mi viene chiesto perché ci sono bug. È una cattura totale 22.
@bobo2000 Questo è esattamente il tipo di impatto di cui sto parlando. Qualità, funzionalità, velocità. Scegli due. Ora presenta quei dati ai tuoi capi quando chiedono che il lavoro venga bloccato per adattarsi ai tempi già specificati.
@JaneS ringrazia Jane. Gli parlerò di questo domani.
@bobo2000 Quando ti dicono "è tutto importante" dovresti controbattere con "naturalmente è tutto importante o non sarebbe nel backlog, ma sicuramente una cosa è più importante dell'altra?" In un negozio online, ad esempio, vuoi davvero delle belle pagine di prodotto e vuoi davvero un sistema di pagamento, ma senza un sistema di pagamento le persone non possono pagarti soldi così chiaramente che è più importante. Trova un esempio simile per il tuo prodotto.
@ToddWilcox, in ultima analisi, deve essere presa una decisione sul lavoro svolto dal team. Qualcosa accadrà che il capo decida o meno, quindi prova a inquadrarlo per forzare una decisione. Poni le alternative e lascia che sia il capo a sceglierne una. per esempio. "Per dare la priorità alla tua nuova richiesta B, dovremo ritardare A di una settimana. Sei felice che procediamo su questa base? Oppure possiamo seguire il piano originale e presentare B più tardi." Se * ancora * non ottieni una risposta chiara, dì al capo cosa intendi fare.
Il capo di @JaneS sembra essere d'accordo. Durante la riunione del mio team oggi a lui e al resto del team ho detto che il lavoro dovrebbe essere suggerito prima dell'inizio degli sprint, una volta che iniziano, qualsiasi nuovo lavoro dovrebbe essere svolto nel ciclo di sprint successivo o se lo sprint finisce presto. Ho avuto una chiamata con un cliente questa mattina, il capo ha detto loro che il miglioramento potrebbe essere fatto questa settimana o nel prossimo ciclo di sprint. La parte difficile ora sarà mantenere questa struttura, facile tornare ai vecchi modi.
Se "è tutto importante" dì al tuo capo che può portare a termine tutto l'80% (o qualche altro numero casuale che immagini) entro la fine dello sprint o alcune attività completate al 100% e circa allo 0%. Digli, se non ottieni priorità cosa completare per primo presto, tutte le attività saranno non completate entro la fine dello sprint. Fallo per iscritto. Ho ottenuto ottimi risultati con quello. Continua a insistere sul fatto che è impossibile finire tutto. Se nessuna decisione viene presa ** dal tuo capo ** su cosa completare per primo, ** niente ** sarà completo al 100% e sarà ** sua ** responsabilità.
@Josef sempre per iscritto. E se ti chiamano in risposta a un'e-mail, rispondi alla telefonata: "Secondo la nostra telefonata / conversazione in sala relax / durante il pranzo, ho capito che ritieni che X sia più importante di Y. Se non lo faccio ricevere un'e-mail che mi dice che non è corretto e che Y è più importante di X entro le 8 di venerdì, opererò partendo dal presupposto che questa comprensione sia corretta. Grazie! "
@bobo2000 Fantastico! A volte ci vuole un po 'di coraggio e convinzione, ma finora ho scoperto che la maggior parte delle organizzazioni si piega alla logica. Infine ;)
@JaneS Non avrei mai pensato che la gestione del progetto sarebbe stata così politica. Ero uno sviluppatore, la vita era molto più semplice. Diventa sempre paranoico che finirò per pestare le dita dei piedi di qualcuno e fargli incazzare.
@bobo2000 Se la vita era semplice allora, probabilmente avevi un buon manager che è andato a battere per la sua squadra :)
@JaneS il mio ultimo manager di linea è stato assolutamente terribile, ma era più semplice nel senso che non ero al centro di tutto
gnasher729
2016-05-08 15:25:02 UTC
view on stackexchange narkive permalink

Cosa significa "scadenza"? C'è il tipo di scadenza in cui la tua azienda ha firmato un contratto e perderà un pagamento di un milione di dollari se non consegni il lunedì, e se non finisci il lavoro prima di lunedì, potresti anche non preoccuparti di venire a lavorare perché lì non ci sono soldi per pagarti.

E c'è il tipo di "scadenza" in cui il tuo capo ha promesso al suo capo che il software sarebbe stato fatto lunedì, senza alcun reale bisogno di farlo, e non vuole sembrare stupido ai suoi capo. È una scadenza per il tuo capo, ma non ha alcuna importanza per l'azienda.

In questo caso non è una scadenza. È uno sprint. Non è assolutamente necessario fare gli straordinari per uno sprint.

Ecco alcune cose da mettere al tuo capo:

  1. Terminare uno sprint venerdì è stupido. Se lo finisci mercoledì o giovedì, puoi aggiungere del lavoro extra senza pestare nessuno - SE pensi che sia necessario. Puoi anche rilasciare cose al pubblico perché qualcuno sarà in ufficio i prossimi giorni se qualcosa va storto.

  2. Uno sprint richiede tutto il tempo pianificato. Se non fai tutto quello che volevi fare, non hai fatto tutto quello che volevi fare. Non allunghi lo sprint. Il tuo capo ha bisogno di apprendere migliori stime di sprint.

  3. Non aggiungi a uno sprint dopo che lo sprint è iniziato. Se qualcuno esaurisce le cose da fare durante lo sprint, potrebbe iniziare con qualcosa dallo sprint successivo, ma in nessun modo aggiungi allo sprint.

Stai usando la terminologia Scrum per la pianificazione / conversazione / recupero. Sfortunatamente sembra che queste persone siano ancora in modalità cascata ...
@keshlam Stiamo lavorando su Scrum - abbiamo sprint settimanali e sto facendo del mio meglio per convincere la direzione a rispettarlo, di tanto in tanto, uno dei problemi che sto avendo in questo momento è dove il mio capo oi miei clienti non rispettano i miei sprint, o si aspettano troppo o nel mezzo dello sprint lui si aspetta che io aggiunga cose nuove. Il cliente direbbe, posso fare x cosa, il capo sarà d'accordo, devo poi mantenerlo da quando inizia il mio capo per impazzire che perderà l'affare se non lo fa. Fare il vero agile è più facile a dirsi che a farsi.
"Il cliente direbbe, posso fare x cosa, il capo sarà d'accordo, devo poi tenerlo presente poiché il mio capo inizia a dare di matto che perderà l'affare se non lo fa." L'intero punto di Agile è per _ consentire_ la modifica delle priorità. Tuttavia, per aggiungere qualcosa al tuo programma, devi prendere qualcos'altro.
@JaneS Ho pensato che una volta che il team si è impegnato nello sprint backlog all'inizio dello sprint, lo sprint è impostato. Quindi, cambiarlo a metà è una cattiva pratica e un segno di scarsa pianificazione?
Terminare lo sprint mercoledì o giovedì: buona idea.
@bobo2000: Il tuo capo sembra essere molto nervoso. Non perderà un affare per questo. Se il tuo "capo" è quello che gestisce l'attività, molto probabilmente renderà la sua attività molto più redditizia se impara a resistere ai suoi clienti.
@BobJarvis Eseguo i miei sprint settimanalmente, se ci capita di finire giovedì, cioè completare tutti gli elementi per allora, allora lavoreremo ad hoc nel giorno rimanente - venerdì. Questo tende ad accadere in una settimana molto buona, abbiamo alcune settimane in cui lo sviluppatore rimane letteralmente bloccato e ha bisogno dell'intera settimana per capire come risolvere il problema.
@bobo2000 È esattamente corretto. Quindi ho detto di cambiare il tuo _schedule_, non il tuo _sprint_. In puro Agile, finisci _questo_ sprint, quindi riaggiusta le tue priorità nello sprint planning meeting per lo _print_ successivo.
@JaneS ha detto oggi al team ciò che l'OP ha menzionato su come organizzare lo sprint. Erano d'accordo. Le cattive abitudini sono dure a morire, quindi mi aspetto che le persone (il capo e altri membri del team di vendita) ricadano nei loro vecchi modi. Agile è fantastico, lo adoro davvero, ma è molto difficile convincere un'intera organizzazione a pensare in modo agile.
@bobo2000: vale la pena ricordare che ci sono alcune organizzazioni per le quali uno sprint di due settimane è semplicemente ridicolmente lungo ed è * essenziale * essere in grado di fare un nuovo lavoro con un preavviso più breve di questo. Se il capo ha bisogno di vendere le cose con un preavviso più breve rispetto alla durata dello sprint e non hai abbastanza persone da dividere in una squadra di sprint e una squadra non di sprint disponibile per nuovi incarichi, allora il tuo processo è sbagliato :-)
@SteveJessop per i progetti dei clienti Faccio kanban, per il prodotto interno che stiamo sviluppando trovo che Scrum funzioni bene quando è fatto correttamente. La sfida sta nel mio capo (responsabile delle vendite) che promette cose da consegnare senza pensare agli sprint. È lì che deve avvenire il cambiamento. Non mi sono preoccupato di uno sprint di 2 settimane, perché come dici tu, è troppo lungo.
@bobo2000: quindi in effetti quello che sta succedendo è che hai definito uno sprint, ma poi lo sprint non può essere finanziato se soddisfi la richiesta del capo di trascinare i giorni dello sviluppatore sul lato kanban consegnabile dal cliente dell'operazione. Sicuramente nessuno si aspetta che uno sprint soddisfi le sue previsioni se non dispone di risorse?
@SteveJessop avrebbe dovuto essere più chiaro: quando lavoro con i freelance su progetti dei clienti faccio kanban, in casa abbiamo il nostro team di sviluppo e loro fanno scrum poiché è più facile farlo quando tutti sono sul posto e lavorano su un prodotto. A volte, però, sì, dobbiamo passare alla modalità kanban se un requisito viene fuori dal nulla per il prodotto che deve essere fatto con urgenza.
@JaneS è già uscito dalla finestra, il capo mi ha appena dato una scadenza aggressiva non tenendo conto della velocità. Il suo atteggiamento è che la squadra abbia lo sprint per completare tutto il lavoro anche se questo significa fare gli straordinari.
@bobo2000 Quindi, senza una stima dello sforzo, tenendo conto del carico di lavoro corrente, il tuo capo ha aggiunto un sacco di lavoro alla tua pianificazione e si aspetta che tutto venga fatto? Chiedi al tuo capo come ha stimato lo sforzo per rispettare quella scadenza, da dove provengono la suddivisione dei compiti e le risorse. Quando dice che non ne ha uno, chiedigli su quali basi ha stabilito la scadenza e come si aspetta che tu abbia preso in considerazione il lavoro se non l'ha fatto.
@JaneS in pratica mi ha detto che ho fissato questa scadenza perché il cliente finale sta andando in vacanza e vuole che tutto sia fatto per allora. In altre parole, i clienti stabiliscono le scadenze e noi dobbiamo consegnare qualunque cosa, indipendentemente dallo sforzo e dalle risorse. Adesso sto diventando davvero frustrato.
@bobo2000 Gli hai chiesto cosa avrebbe tolto dal programma allora? O voleva che tu scegliessi cosa rimuovere? Mi sono imbattuto in capi come questo, ea volte ci vuole un po 'di sforzo per affrontare le loro aspettative impossibili prima che finalmente vedano il senso in quello che stai dicendo loro. Un atteggiamento come il suo non farà altro che allontanare le brave persone.
@JaneS, abbiamo deciso che la prossima settimana faremo uno sprint e proveremo a consegnare tutto il lavoro, e gli ho detto che non potevo promettergli che la qualità ne sarebbe stata influenzata poiché il debito tecnologico si accumulerà quindi probabilmente non lo sarò in grado di fornire tutto. L'altro problema è che il carico di lavoro per la prossima settimana è molto maggiore dell'impegno del team. La mia squadra dovrà probabilmente fare molti straordinari e nel frattempo si arrabbierà.
@bobo2000 Non puoi sapere cosa puoi offrire (indipendentemente dalla qualità) se non hai avuto l'opportunità di stimarlo e di risorse. Ti suggerirei di farlo il prima possibile, quindi presentare al tuo capo ciò che _puoi_ consegnare. Ma devi assicurarti di _lo_ consegnarlo.
@JaneS quando vieni messo sul posto dallo stakeholder e ti viene chiesto di fornire una stima come lo fai in modo accurato, trovo difficile a volte farlo poiché non ho un quadro completo di ciò che è necessario per soddisfare x requisito
Ehi ragazzi, cosa ne pensate di fare uno sprint di 4 giorni e terminarlo giovedì e fare ciò che l'OP ha suggerito? Passa alla modalità kanban il giovedì e il venerdì.
Lo sprint di 5 giorni di @gnasher729 non funzionava per noi, poiché 1 settimana è un lungo periodo di tempo in questa organizzazione. Quindi il mio capo e io abbiamo deciso di fare quello che hai suggerito terminando lo sprint giovedì. Anche il tuo punto di vista sulla spinta alla produzione è positivo. Grazie.
Aggiornamento da quando questa domanda è stata pubblicata. L'approccio di @gnasher729 all'integrazione di Scrum in un'organizzazione è ciò che ha finito per funzionare per noi. Terminiamo i nostri sprint giovedì e poi passiamo a Kanban venerdì. Questo ha reso felice il mio capo, dal momento che tutto è meno rigido, lasciando il team a fare le ui ux fix alla fine della settimana su basi ad hoc. L'implementazione che avverrà giovedì è importante per noi, dal momento che nessuno è in attesa. Il team è anche molto produttivo poiché lo sprint di 4 giorni significa che hanno 4 giorni per portare avanti il ​​lavoro ad alta priorità, senza essere interrotti.
keshlam
2016-05-08 07:05:14 UTC
view on stackexchange narkive permalink

Il tuo capo ha il diritto di chiedere.

Hai il diritto di rifiutare.

Il tuo capo ha il diritto di prendere in considerazione la tua risposta quando arriva il momento della revisione dei dipendenti.

Scegli le tue battaglie e considera che le aziende tendono a ricordare chi è e chi non è disposto a fare uno sforzo in più quando l'azienda ha difficoltà a rispettare una scadenza.

Guarda anche _perché_ sei stanco alla fine di uno sprint. In qualità di manager, è _ tua_ responsabilità garantire che i tempi siano realistici e che le aspettative siano gestite.
"La disponibilità a fare uno sforzo in più quando l'azienda è in difficoltà con una scadenza" è una cosa, la disponibilità a fare un giorno di straordinario non retribuito è un'altra.
@Jcm: non è sempre diverso. E non è necessariamente uno straordinario non pagato, se la società è disposta a restituirlo come orario flessibile / mdto dopo che il crunch è passato o emette un bonus per andare oltre il richiamo della sanità mentale, entrambi i quali a volte ho ottenuto. Alla fine, ognuno ha bisogno di stabilire le proprie priorità, con la consapevolezza che piaccia o no qualsiasi decisione ha delle conseguenze. Ovviamente idealmente questa situazione non dovrebbe presentarsi, ma questo e un dollaro e cinquanta ti daranno una brutta tazza di caffè con una sirena sopra.
@JaneS Trovo generalmente difficile stimare gli sprint. Non tutte le attività sono uguali e variano in complessità, spesso lo scopri quando il lavoro è iniziato. Nella migliore delle ipotesi i punti della storia sono un'approssimazione, NON una stima accurata di quanto tempo impiegherà qualcosa. A volte facciamo bene e la squadra è in anticipo sul programma per la settimana, altre volte la squadra sbaglia e sono in ritardo. Scrum non è un framework basato su stime ma approssimative.
@bobo2000 Questo è il motivo per cui monitori l'accuratezza della stima nel tempo. Inoltre, se le attività sono troppo difficili da stimare, non sono sufficientemente granulari. Prova a scomporli ulteriormente se puoi, potrebbe aiutare la tua precisione.
@JaneS Faccio entrambe le cose. Ma ancora una volta, nella migliore delle ipotesi è sempre un'approssimazione, non puoi mai essere accurato al 100% a meno che l'attività non sia simile a un'attività precedente negli sprint precedenti, quindi in base a ciò sai che possono risolverla poiché l'hanno risolta una volta in precedenza.
@bobo2000 In realtà non penso che la stima sia il tuo problema qui. È la scomposizione del lavoro _additional_ in un'unità di lavoro già pianificata che sta causando il tuo problema.
@JaneS cosa intendi? Le storie non sono abbastanza piccole?
Nella mia esperienza a tutti viene chiesto "tempo extra" di tanto in tanto, e fintanto che è "una volta ogni tanto" non è un problema. Tuttavia, quando "extra" diventa la norma, si supera il limite, il rapporto è diventato abusivo, ed è "tempo di elezioni": le persone possono votare con i piedi.
-1 Commento esteso. Quando viene fatto, questo non risponde alla domanda. La risposta dei team dell'OP è no, ma qual è il modo migliore per realizzarlo in modo costruttivo? E se la risposta è nei fine settimana di lavoro, proponi al team la questione dell'OP?
@bobo2000 No, voglio dire che il problema nella tua domanda non ha nulla a che fare con la stima, è perché il tuo capo sta cercando di incastrare più _in_ uno sprint. Se questa sarà una cosa comune, potresti dover ridurre il numero complessivo di story point che intendi completare in uno sprint in modo da poter lasciare spazio per aggiungere lavori "non programmati". Non è puro Agile e può significare che il tuo team sta spesso prendendo più cose dal backlog per riempire lo sprint, ma se il tuo capo insiste a interrompere i tuoi sprint potrebbe non esserci scelta se vuoi comunque finire le attività _scheduled_.
"No" non è una risposta utile. "Possiamo fare un esame a tutto campo su questo, ma qui ci sono le conseguenze: altre cose saranno ritardate. Non può essere tutto prioritario. E se chiediamo alla gente di fare gli straordinari non pagati su più thgan a base molto occasionale, dobbiamo _dobbiamo_ consentire loro di recuperare quelle ore come tempo flessibile per lo meno, altrimenti si esauriranno e avremo ancora più problemi a rispettare scadenze strette. Se ti va bene posso provare a venderlo alla squadra ... Ma dovremo anche lavorare per evitare che thius accada di nuovo. Stiamo facendo mischia o no? "
"Il tuo capo ha il diritto di prendere in considerazione la tua risposta quando arriva il momento della revisione dei dipendenti.". - questo sembra essere un presupposto, basato sul diritto del lavoro negli Stati Uniti. Ma i commenti hanno chiarito che questo è nel Regno Unito. Sebbene il Regno Unito abbia un'esenzione dalle norme dell'UE sugli straordinari, capisco che ciò significa principalmente che i contratti del Regno Unito possono avere più di 48 ore di ore non straordinarie.
"Le aziende tendono a ricordare chi è e chi non è disposto a fare uno sforzo in più quando l'azienda è in difficoltà rispetto a una scadenza.", Ho fatto l'esperienza esattamente opposta. Ho sprecato tempo e nervi per niente.
@traubenfuchs: Ricordano. Non tutti, sfortunatamente, lo ricompensano se non essendo meno propensi a scegliere te come colui che viene licenziato. Potrebbe comunque valere la pena lavorare, a seconda di quanto vuoi mantenere questo lavoro.
(A proposito, mi scuso di nuovo per gli errori di battitura della tastiera touch. Sto ancora imparando che devo correggere questa bestia.)
njzk2
2016-05-08 19:26:06 UTC
view on stackexchange narkive permalink

Ci sono 2 punti qui. Il tuo capo vuole:

  • Aggiungere cose in uno sprint (e soprattutto verso la fine)
  • Fare lavorare il team di sabato quando non dovrebbero

Uno sprint definisce un insieme di caratteristiche che il team si impegna a fornire alla fine di esso. Aggiungere cose nuove durante lo sprint è per definizione un problema.

In qualità di loro manager, è tuo ruolo proteggere il tuo team da tali problemi.

Avere persone che lavorano in un giorno di riposo di solito indica che la pianificazione è stata eseguita male e che sia il carico di lavoro non è stato ben stimato sia le priorità non sono state ben valutate.

Entrambi questi punti indicano problemi nell'organizzazione e nella pianificazione.

Quando uno sprint viene avviato, non dovrebbe essere modificato fino al completamento, in modo che il team possa essere comodo ed efficiente.

Ora, ovviamente, questo è teorico e accadono cose che richiedono priorità in movimento. In tal caso, consiglierei di sostituire le funzionalità dallo sprint punto per punto .

Cioè, ecco cosa ti suggerirei di fare:

  • Valuta la priorità di ciò che viene chiesto
  • Se (e solo se) la priorità è veramente alta:
  • Valuta il valore in punti cosa lo stackholder ( richiesta del capo)
  • Valuta lo stato di salute dello sprint corrente
  • Crea un piano di sostituzione in cui rimuovi le funzionalità dallo sprint per integrare ciò che viene richiesto.
    • Fai questo pianificare con il team per assicurarsi che non vi siano conflitti nella pianificazione e non abbia senso (ad esempio: non rimuovere un'attività se qualcun altro dipende da essa, non rimuovere l'attività finale che dà significato a 3 mesi di lavoro ...)
    • Suggeriscilo al capo.

Non menzionare il sabato, né al capo, né alla squadra *. Se il capo insiste, sii fermo e fai affidamento sul tuo piano per dimostrare che puoi fornire ciò che il capo chiede, ma anche che il capo non può semplicemente chiedere tutto e ottenerlo.

* Ci sono alcuni casi in cui lavorare in più può avere senso, ma non si tratta mai di aggiungere nuove funzionalità e certamente non di aggiungere cose oltre a ciò che è già promesso. Se, ad esempio, scopri un problema che minaccia i tuoi clienti e deve essere risolto ora , ha senso in pratica abbandonare tutto il resto e risolverlo immediatamente.

"In qualità di loro manager, è tuo ruolo proteggere la tua squadra da tali problemi" - tuttavia, il _tuo_ manager probabilmente ritiene che sia parte del tuo ruolo ottenere uno sforzo extra (es. Straordinari non retribuiti) dal team quando necessario. In caso contrario, rischia di essere una mossa che limita la carriera.
Dalla mia lettura della domanda dell'OP, non sembra essere il caso qui.
Per chiunque legga questo e non sappia cosa sia "planification" (cioè qualcuno che non ha molta familiarità con l'inglese), significa approssimativamente l'esecuzione di un piano.
@QPaysTaxes Di solito si concentra maggiormente sulla preparazione del piano, però
A lungo termine, quando il _tuo_ manager ha tutti i ragazzi che possono trovare un lavoro altrove in fuga e viene lasciato con quelli che non riescono a trovare un altro lavoro, quella sarà una mossa che limita la carriera per lui.
@njzk2 Quindi "approssimativamente". Se si sostituisce "pianificazione" con "esecuzione del piano", è comunque accurato, anche se leggermente meno preciso.
@gnasher729 Non sono in disaccordo. :-) Ma penso che, soprattutto se sei abbastanza nuovo nella gestione di una squadra, devi ricordare che devi mantenere felici sia quelli sopra che quelli sotto di te. Non solo dire che il tuo ruolo è proteggere la tua squadra, fine della storia.
coteyr
2016-05-09 12:37:45 UTC
view on stackexchange narkive permalink

Molte di queste risposte si concentrano sulla gestione del capo, adotterò un approccio diverso.

La risposta, direttamente

Prima di rispondere alla tua domanda, la tua risposta dovrebbe essere: "Ovviamente accetto di lavorare nei fine settimana se significa incontrare uno sprint Scadenza." La ragione di ciò è chiara (per me).

Dal punto di vista dei programmatori

Uno sprint, se usato correttamente, è un "accordo" tra (in questo caso) programmatori e non programmatori, su quando una serie di lavori sarà completata. È uno strumento meraviglioso, perché mentre nel mondo reale devi essere flessibile, una volta che lo sprint inizia il traguardo non si muove . In aggiunta a ciò, affinché uno sprint possa essere utilizzato correttamente, i "programmatori" (individualmente o come team tramite un lead) possono avere un impatto importante, quasi esclusivo, su ciò che entra in uno sprint. Ora l'azienda (o il cliente, o qualsiasi altra cosa) potrebbe desiderare che tu faccia di più in uno sprint, e questo può essere un obiettivo su cui lavorare, ma non importa. Se tutto ciò che puoi fare è un'attività in uno sprint, allora è tutto ciò su cui sei d'accordo.

Ecco il layout che uso. Ho uno sprint settimanale (in questo esempio) con lavoro previsto lunedì. Guardo il backlog (o cosa mai) e metto abbastanza lavoro nello sprint per riempire 4 giorni. Ciò significa che dal lunedì al giovedì ho un carico di lavoro completo. Non troppo pieno, solo pieno. Il lunedì, mi metto un po 'perché abbiamo la configurazione dello sprint e le riunioni di demolizione, e il venerdì, non programma affatto alcun lavoro. Questo mi lascia con 1 giorno intero, con tecnicamente niente da fare.

Nel mondo reale, quell'imbottitura extra significa che non devo lavorare nei fine settimana e che i venerdì di solito sono giorni "leggeri", dove mi occupo solo di cose che sono state ritardate per il resto della settimana. Il resto della giornata posso dedicare compiti amministrativi, come guardare avanti alla prossima settimana e prepararmi per il prossimo sprint. Ovviamente, se succede qualcosa e ho bisogno di un "giorno in più di lavoro" per finire le mie attività di sprint, non è un grosso problema. Sì, significa che il mio normale "venerdì amministrativo" diventa una "corsa per portarlo a termine venerdì", ma queste cose accadono di tanto in tanto.

Dal punto di vista dell'azienda

Quindi, come manager dell'azienda, ciò che ti interessa veramente sono i "costi" e le "scadenze". Gli sprint sono un ottimo modo per capire quale sia una scadenza da un processo che è ancora in gran parte "magico" per chiunque non scriva codice. Quello che vedono è che le cose vanno sulla lista, ho un appuntamento, le cose funzionano magicamente perché queste persone lo fanno funzionare. Il punto è che alla maggior parte delle aziende non interessa quale sia la data di scadenza, a patto che tu la raggiunga, e sembra ragionevole.

I costi d'altra parte sono un fattore importante. Se l'azienda deve pagare gli straordinari (negli Stati Uniti anche un dipendente stipendiato ha diritto a un risarcimento nel tempo se è costante), allora diventa rapidamente meglio assumere un nuovo dipendente, piuttosto che pagare nel tempo, o avere a che fare con il incertezza del "tempo flessibile".

L'azienda, nel suo insieme, dovrebbe trarre vantaggio dall'avere una base di costi più stabile e una migliore "percentuale di completamento" degli sprint, anche se ciò significa che vengono svolte meno attività per sprint.

Considerazioni finali

Se hai molti problemi per cui non riesci a portare a termine i tuoi sprint in tempo, allora tu (o la tua azienda) non lo stai facendo sprint correttamente. Dovresti essere in grado di completare sempre uno sprint, anche se significa una "distanza più breve". Ci sono altre metriche (cioè velocità) per ottenere di più per sprint.

Ricorda che uno sprint è "entrambe le parti". Accetti di fare X entro la fine dello sprint. O non essere d'accordo (spezza X in pezzi più piccoli) o fai quello che hai detto che avresti fatto, anche se questo significa perdere il tuo weekend. Allo stesso tempo, il "lavoro extra" non fa parte di quello sprint. Assicurati di farlo notare.

A volte fallirai uno sprint. Sono cose che capitano. Secondo me, dovresti essere pronto a lavorare il fine settimana in questi casi. Allo stesso tempo, l'azienda dovrebbe essere in grado di rispondere a poche scadenze mancate. Si tratta davvero di credibilità. Stai "lavorando le ore" o stai "lavorando al progetto"?

"Lavoro extra" è abbastanza comune, di solito può rovinare un buon piano, ma è per questo che suggerisco il "giorno in più" di imbottitura. A volte non avrai molta codifica da fare e puoi concentrarti sulla qualità dei ticket e della documentazione o sul lavoro di preparazione. Alcune volte, puoi spenderlo per gestire problemi come questo (nella tua domanda).

Se questo lavoro extra accade spesso, puoi affrontarlo sottolineando che lo sprint è il modo in cui imposti i tuoi giorni di scadenza e che non dovresti spostare il traguardo. Se succede spesso hai un fallimento nella gestione e dovresti chiedere qualcosa del tipo "Cosa possiamo fare per pianificare meglio i nostri sprint in modo da non avere questo Jack-in-the-box così spesso?"

La programmazione è un lavoro in cui dovrai solo succhiarlo alcune volte (ce ne sono altre). Le cose accadono e dovrai lavorare più delle tue 40 ore. Dovresti essere pronto e disposto a farlo. Il tuo capo / azienda ha tutto il diritto di chiedere e tu hai tutto il diritto di dire di no, ma dire di no sembrerà davvero brutto. La chiave è assicurarsi di mitigare e insegnare i tempi in cui ciò deve accadere. Ci saranno sempre momenti critici, ma di solito puoi ridurre il numero di volte a qualcosa di più gestibile. Se ritieni che stia succedendo troppo, affrontalo cercando di inserire quel lavoro "extra" nel tuo normale flusso di lavoro di sprint. Se è solo una o due volte all'anno, allora affrontalo, può essere uno strumento potente (lavori il fine settimana a volte) quando hai bisogno di quel paio di giorni in più per la tua fantastica vacanza.

Sono d'accordo con la maggior parte della tua risposta, ma succhiarlo in realtà non è la cosa giusta da fare imho. Invece, la mentalità agile dovrebbe essere vissuta anche dal management. Se lo sprint è stato troppo pieno, beh, succede. La prossima volta pianifichi di meno. Lezione imparata. Ma se non esiste una consegna continua in cui le cose possono essere spedite oggi, domani o quando è finito, allora è un fallimento della gestione aspettarsi tutto il giorno in cui lo sprint finisce. Contratto sprint o meno, tutti devono essere agili (cioè _flessibili_) in un ambiente come questo.
Sono d'accordo, ma "succedono cose". OMG la nostra app sta inviando informazioni sulla carta di credito .... "Affronterò il prossimo sprint", non una risposta valida. Quindi succedono cose, che non sono prevedibili, e devi "succhiarlo". Ma quelle cose dovrebbero essere poche e lontane tra loro. Diciamo 1-2 volte l'anno. Non tutte le settimane, o spesso, ma occasionalmente.
Capisco cosa stai dicendo. "Suck it up" si riferisce a "cose ​​che accadono", non la tua promessa. Con la tua promessa, a volte l'azienda deve mangiare quella scadenza non riuscita, ma a volte lo fai. Tutto dipende dalla situazione e dalla frequenza con cui si verificano questi fallimenti. Idealmente questi errori di scadenza dovrebbero essere molto rari. Se stanno accadendo molto, hai un fallimento nella pianificazione / gestione.
Se molte di queste cose accadono con breve preavviso, possono essere classificate come "giorno per giorno" e nello sprint può essere pianificato un ticket di blocco che può essere utilizzato per farlo. Gli vengono assegnati story points (o qualsiasi altro metodo di valutazione utilizzato). Se nessuno si è presentato, il ticket ha avuto successo e ha avuto solo un impatto positivo sulla performance complessiva durante lo sprint. Se c'è qualcosa, qualcuno lo fa. Era previsto che potesse succedere qualcosa, va tutto bene. È un po 'come non pianificare una cosa per un giorno, ma penso che vende meglio ai dirigenti difficili da convincere.
Vorrei vedere una discussione su come il fine settimana lavorativo per rispettare gli impegni di sprint sia effettivamente _baro_. Se li stai monitorando, distorcerà le tue metriche di sprint dicendo _ "Abbiamo fatto X in 5 giorni" _ quando in realtà ti ci sono voluti 7. Ti ci è voluto il 40% in più di tempo rispetto a quanto stimato e lo nasconderai! Quando pianifichi il tuo prossimo sprint, metriche accurate ti aiuteranno a pianificare meglio.
Sbagliato nella prima frase: non esiste una cosa come una "scadenza sprint". Uno sprint ha una data di inizio e una data di fine, e ciò che viene fatto viene fatto e ciò che non viene fatto non viene fatto. Se non viene fatto, è una cattiva pianificazione.
@coteyr: "La nostra app invia informazioni sulla carta di credito" non dovrebbe accadere una volta all'anno, non dovrebbe accadere una volta nella vita. Se succede, potresti passare quel fine settimana meglio a scrivere un nuovo CV.
@gnasher729, Il punto è che ci sono eventi che sono così importanti che devi solo risolverli e non preoccuparti del "quando".
@Gusdor, Mi piace l'argomento delle metriche accurate. Tuttavia, se gli sprint sono dal lunedì al lunedì, hai 7 giorni e non 5. Solo due di quei giorni non sono produttivi. Suppongo sia importante se non tutti lavorano nello stesso turno. Ma poi di nuovo le metriche sono ciò che le persone che le realizzano vogliono che siano. Immaginavo che potessi fare attività all'ora e mostrare il problema.
"Tuttavia, se gli sprint sono dal lunedì al lunedì, hai 7 giorni e non 5. Solo due di quei giorni non sono produttivi." Non improduttivo. Non pagato. Il team dell'OP è pagato per lavorare 40 ore. Quindi uno sprint di una settimana è di 40 ore, non di 7 giorni. Factoring in più di quanto può essere (realisticamente) raggiunto in 40 ore è una pianificazione scadente. Inoltre, la situazione qui è che il capo sta apportando ulteriore lavoro allo sprint dopo che è iniziato. Quindi è necessario pianificare riducendo la quantità di lavoro pianificato o respingere il capo per programmarlo correttamente. Questo è gestire.
@JaneS Sono d'accordo, può essere molto difficile quando hai a che fare con clienti finali che non si preoccupano del rispetto degli sprint o dell'agile e vogliono che tutto venga fatto il prima possibile. Questo è l'effetto a catena del team di vendita in questo momento che fa sì che alcuni sprint non valgano 40 ore di lavoro ma di più. Poi di nuovo, al mio capo non importa se la squadra fa gli straordinari ad essere onesti, lo incoraggia.
@bobo2000 Sì, può essere, non esiste una soluzione facile. Per quanto riguarda le modifiche allo sprint, a meno che tu non possa convincere il tuo capo a onorare i tuoi sprint, è come mescolare le sedie a sdraio sul Titanic. Devi prima risolvere il problema sottostante.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...