Scrum Sprint significa lavorare al ritmo più veloce possibile?

21

Di recente ho intervistato alcune aziende che fanno Agile, Scrum per essere più precisi e ci sono alcune cose che non mi sembrano proprio Agile. Prenderò un caso che mi interessa particolarmente in questo momento, quello degli sprint Scrum.

Un particolare project manager con cui ho parlato (sì, ho detto project manager) ha dichiarato con orgoglio che le persone del suo team comprendono ("mi è stato detto" è quello che ho raccolto dal contesto) che non vai a casa quando l'orario di lavoro è finito , vai a casa quando il lavoro è finito, non importa quanto ci vuole. Quello che ho letto tra le righe è che racchiudiamo quante più funzionalità possibile in uno sprint e facciamo gli straordinari per farlo accadere.

Ormai non ho ancora fatto Agile (ho lavorato con istituzioni finanziarie e governative che la maggior parte preferiscono ancora a cascata) ma la mia comprensione è che:

sprint in Scrum è il nome dell'iterazione generica in Agile;
il team dovrebbe lavorare a un ritmo sostenibile e cercare di evitare gli straordinari a lungo termine poiché ciò ha effetti solo sul breve periodo e gli effetti sono sminuiti dai problemi che si presentano a lungo termine.

Le mie dichiarazioni sono giuste? E dovrei prendere la presentazione del manager come una bandiera rossa?

agile scrum development-methodologies

— JohnDoDo
fonte

Nessuna esperienza reale con Agile, ma da quello che ho capito, il carico di lavoro dello sprint dovrebbe essere bilanciato con la durata dello sprint, quindi o gli sviluppatori stanno sottovalutando il loro carico di lavoro o il manager sta semplicemente dando loro lavoro senza chiedere il loro feedback sul carico di lavoro . In questo caso probabilmente quest'ultimo. - Correggimi se sbaglio, però

— Andreas,

4

@gnat Penso che le domande siano troppo diverse

— Andreas,

27

"... non vai a casa quando l'orario di lavoro è finito, vai a casa quando il lavoro è finito, non importa quanto ci vuole ...". Corri come il vento. È un'idiota.

— JᴀʏMᴇᴇ,

Ho votato per riaprire questa domanda. La domanda del duplicato proposto è -agile-il-nuovo-microgestione ha in comune con questa domanda, che il manager chiama qualcosa di "mischia" e chi chiede vuole sapere se si tratta davvero di mischia. Questa domanda riguarda "gli straordinari" proposta su "non è permesso parlare con altri sviluppatori".

— k3b,

"... che non vai a casa quando l'orario di lavoro è finito, vai a casa quando il lavoro è finito, non importa quanto ci vuole" sembra un conflitto diretto con il concetto chiave di ritmo sostenibile - io lavora lì se dovessi mettere del cibo sul tavolo. HST, se questo si verifica di volta in volta, non ho alcun problema. A volte, nonostante ogni sforzo, c'è una crisi e il cliente viene prima. Ma lei fa sembrare che questo sia un evento regolare ed è ammirevole. Ciò significa che non stanno facendo la causa principale per capire perché si sta verificando e risolvere il problema sottostante.

— Don Branson,

27

Non devi cercare lontano per vedere che queste pratiche sono contrarie ai principi alla base di Agile. Uno dei principi alla base del Manifesto Agile afferma:

I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.

Alcuni anni fa, Scrum ha fatto un cambiamento sottile ma importante . Invece di impegnarsi nel lavoro che possono essere realizzati, i team prevedono ciò che pensano di poter svolgere.

Il cambiamento arriva a causa dell'abuso, che suona in modo molto simile all'atteggiamento da non andare a casa fino a quando non viene descritto. Nello sviluppo, al di fuori del controllo dei team ci sono molti fattori a cui non possono impegnarsi: per usare l'analogia del tempo, non puoi "impegnarti" che domani pioverà.

Per rispondere direttamente alle tue domande:

sì, Sprint è il nome di un'iterazione in Scrum, vedi questa risposta per la differenza
sì, i team dovrebbero lavorare a un ritmo sostenibile. L'unica certezza del lavoro straordinario è che sarà ridurre il lungo termine le squadre produttività.
si, è una bandiera rossa!

— Dave Hillier
fonte

23

Sì, hai ragione, e se mi dicessero cosa ti è stato detto, scapperei da lì il più velocemente possibile. Stanno solo usando l'agile come una scusa. Sembra la classica marcia della morte.

— Miki Watts
fonte

3

Una marcia della morte in genere non avrebbe fine? Quel progetto sembra un inferno eterno se è così che lavorano sprint dopo lo sprint.

— DXM,

5

No, in una marcia della morte c'è sempre "dobbiamo solo passare alla versione successiva, quindi possiamo riformattare e correggere i bug! Oops, abbiamo promesso al cliente la prossima versione successiva tra due mesi, dobbiamo solo passare alla prossima successiva versione!" e così via, hai avuto l'idea.

— Miki Watts,

2

@DXM ha una fine quando tutti lasciano o vengono licenziati. I progetti di Death March potrebbero durare anni.

— Dogweather,

3

Le marce della morte di @DXM finiscono quando muori.

— Dave Hillier,

hmm, immagino stavo proiettando la mia esperienza lì. In qualche modo nella mia mente i progetti mal gestiti sono una combinazione di marcia della morte seguita da mesi di indecisione su dove andare dopo. Il tempo più lungo in cui la nostra squadra è rimasta seduta con i pollici vuoti è stato di quasi 8 mesi. Quindi ci verrebbero concessi 4-6 mesi per un rilascio con la dichiarazione "siamo su un ciclo di rilascio annuale"

— DXM

11

C'è una cosa chiave che può renderlo accettabile: il team accetta l'ambito dello sprint.

In Scrum, i team non ricevono solo lavoro assegnato. Il proprietario del prodotto negozia con il team per dare priorità al lavoro sul prodotto e al lavoro tecnico (di debito). Il project manager, il product owner e il team quindi negoziano su cosa viene coinvolto in uno sprint e qual è lo scopo di quel lavoro.

In questo mondo, il team sta essenzialmente dicendo "possiamo ottenere X lavoro fatto, testato e spedito questa iterazione". Quindi mi aspetto che una squadra lavori occasionalmente per rispettare questi impegni.

Detto questo, così tanti posti bastardano agili - e così pochi team leader possono negoziare efficacemente con persone che di solito sono i loro capi ... Lo prenderei come un'enorme bandiera rossa.

— Telastyn
fonte

8

"occasionalmente lavoro straordinario per rispettare questi impegni ( erroneamente stimati ) = => fare delle stime sbagliate in un'abitudine

— moscerino

1

@gnat - pssh. Le stime sono talvolta elevate. Le stime sono talvolta basse. Se la sottostima diventa una tendenza, è sicuramente un problema. Ma questo è in gran parte il motivo per cui esistono iterazioni: per affinare la stima.

— Telastyn,

8

In genere i programmatori di frodi non accettano trattative da parte dei lavoratori.

— maple_shaft

1

@gnat: se scopri che, come gruppo, stai sottovalutando abitualmente il lavoro, dovresti impegnarti a ridurre il lavoro nel prossimo sprint.

— Bart van Ingen Schenau,

Quando gli obiettivi di gestione sono svolgere il maggior lavoro possibile, indipendentemente dai limiti sull'orario di lavoro (e l'esperienza indica che ciò è vero nella stragrande maggioranza dei casi), e gli obiettivi dei dipendenti sono di ottenere il massimo del lavoro senza superare il lavoro retribuito ore (ammetto che alcuni manager potrebbero obiettare che ciò è ottimistico), quindi indipendentemente dall'errore inerente alla stima, la pianificazione tenderà sempre a> = ore lavorative. L'estensione logica è che gli obiettivi dei dipendenti devono passare alla sottovalutazione. @BartvanIngenSchenau ecco come si sviluppa naturalmente questa abitudine.

— Steven Evers,

1

Scrum è suddiviso in sprint in cui si stima una serie di attività da completare nella durata di tale sprint (in genere 2 settimane, ma ho visto da 1 giorno a 4 settimane). Penso che ciò crei un incentivo a fraintendere i compiti. Le OP (product owner) vorranno stime basse per ottenere un grande impegno per sprint. Il team farà grandi stime per generare grafici di burndown che i PM possano vedere. Questi sono, ovviamente, indicativi di un'organizzazione scadente. Volete davvero ottenere stime accurate e non aver paura di non essere all'altezza e portare storie allo sprint successivo o finire presto ed estrarre compiti extra dal backlog. Penso che il termine "sprint" crei questa immagine di persone che lavorano più velocemente.

— jiggy
fonte

1

salvo che l'OP non dovrebbe partecipare al processo di stima. Se dovessero essere agili, i team sarebbero gli unici responsabili di elaborare stime e in base a ciò che il team stima L'OP può solo cambiare le priorità di arretrato.

— DXM,

2

"Il team farà grandi stime per generare grafici di burndown che i PM possano vedere.": Questo è uno dei motivi per cui penso che l'intero meccanismo sia difettoso. Penso che un manager possa ottenere prestazioni molto migliori da un team di cui si fida piuttosto che forzare un team a fornire stime da inserire nei grafici.

— Giorgio,

Il team dovrebbe, ma come ho detto, hanno un incentivo a riempire le stime. Se l'OP è quello che paga, possono applicare una pressione per stimare in modo più aggressivo. Per il background, lavoro in consulenza, quindi il team di scrum è mio collaboratore, mentre l'OP è di solito esterna e paga il nostro tasso di fatturazione gonfiato :)

— jiggy

@Giorgio una squadra inaffidabile può sempre tamponare le stime e peggiorare le cose. Ma un team affidabile, anche di esperti, può imparare a stimare meglio. Questo è il motivo per cui le stime vengono fatte, e quindi confrontate con il lavoro effettivo, per cercare di migliorare la loro capacità di stima. Il meccanismo non è difettoso, avere un team che sta sfruttando un sistema è il problema e sarà il problema indipendentemente dal sistema di gestione.

— Chris,

1

No: gli scrum sprint sono un timebox, niente di più, niente di meno. All'inizio dello sprint / iterazione, il team fornisce una stima della quantità di punti della storia che credono di poter raggiungere, sulla base di cose come prestazioni precedenti, disponibilità, eventi imminenti, impedimenti aperti, ecc. Quindi negoziano con il proprietario del prodotto su quali storie utente vengono inserite nello sprint. Questo è (o era? Vedi altra risposta) il impegno che il team dà al proprietario del prodotto.

Durante lo sviluppo, se si scopre che le cose non sono realmente come previsto (è lo sviluppo del software dopo tutto) e c'è un rischio che il team non rispetti l'impegno, informano il proprietario del prodotto che c'è un rischio che una o più storie saranno non essere completato.

E va bene. Certo, mi sento male, dover ammettere alla fine dello sprint che lo sprint ha fallito, ma non è una sconfitta, è un'opportunità di miglioramento. Perché alla fine dello sprint / inizio di quello nuovo, puoi fare una retrospettiva sullo sprint, e la prima cosa che qualcuno chiederà è 'Perché abbiamo fallito questo sprint e cosa dobbiamo fare per non fallire di nuovo ?'. Un'opzione sarebbe quella di dare meno impegno (= prendere meno punti trama).

tl; dr: Pace sostenibile. Scrum riguarda la cadenza, qualcosa che la squadra può tenere indefinitamente su base sprint-to-sprint. Il lavoro straordinario non lo è; il team sarà sovraccarico di lavoro, il lavoro diventerà sciatto, i membri chiameranno malati o lasceranno del tutto, e quindi avrai un problema molto più grande di uno sprint fallito.

— Cthulhu
fonte

0

I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.

Dalla gente Agile Manifesto

Il lavoro straordinario in continuazione non mi sembra sostenibile.

Detto questo, non vedo alcun problema con un impegno di primavera che sia forte (se questo è il modo in cui il team vuole lavorare), e dover fare gli straordinari quando si sovraccaricano o si sbagliano le stime è un buon incentivo per migliorare nella stima o nella comunicazione aspettative verso PO.

— ptyx
fonte

0

Un particolare project manager con cui ho parlato (sì, ho detto project manager) ha dichiarato con orgoglio che le persone del suo team comprendono ("mi è stato detto" è quello che ho raccolto dal contesto) che non vai a casa quando l'orario di lavoro è finito , vai a casa quando il lavoro è finito, non importa quanto ci vuole. Quello che ho letto tra le righe è che racchiudiamo quante più funzionalità possibile in uno sprint e facciamo gli straordinari per farlo accadere.

Questo non è Scrum. Il carico di lavoro proposto per un timebox si basa sulla velocità del team , non sulla lista dei desideri del manager. Stanno semplicemente cercando di indurti a credere che il lavoro straordinario senza fine sia "Agile", cosa che non lo è. Il team diventerà più efficiente mentre lavora indisturbato e concentrato, ma Scrum non è una bacchetta magica per infiniti guadagni di efficienza.

O il manager ha un leggero fraintendimento di Agile o (più probabilmente) pensa che gli sviluppatori siano così stupidi. D'altra parte, quando la squadra accetta lo sprint più e più volte, sapendo che dovranno fare un lavoro straordinario, forse sono davvero stupidi e non lo meritano meglio?

Immagino che tu conosca la risposta ... ;-)

— JensG
fonte