La contrattazione e i tentativi di abbattimento delle stime Scrum sono parti legittime del processo?

Ho notato nelle riunioni della mischia che gli sviluppatori spesso danno stime realistiche sulle storie. Tuttavia, anche le storie piuttosto semplici richiedono molti sforzi per la configurazione, l'impostazione di componenti di terze parti, i test e la costruzione finale e il sistema ha accumulato un certo debito tecnico, quindi le stime appaiono spesso troppo alte per il proprietario o la gestione del prodotto.

L'OP cerca spesso di ridurre tali stime, come: "Cosa, vuoi 13 punti storia [4 giorni] per questa storia, questo non può essere! Non posso spiegarlo al management, qualcuno dovrebbe essere in grado di codificare questo con 3 SP [in 4 ore]! ". Di conseguenza, gli sviluppatori si torcono le braccia per impegnarsi in una stima di 5 o 8 punti storia (da 1,5 a 2 giorni) (le stime Scrum sono ancora prese come impegni, non solo previsioni).

Naturalmente, senza alcun piano per ridurre le aspettative (principalmente su test e qualità), questi sprint spesso falliscono. La stima degli sviluppatori è onesta e realistica e battere la stima non abbatte il lavoro effettivo da svolgere.

Si può dire: "Non dovresti prendere un impegno impossibile, solo perché qualcuno ti spinge a farlo!" Ma a mio avviso, il lavoro di uno sviluppatore è la progettazione e la codifica del software, non contrattare o resistere alla pressione! Potrebbero esserci jack di tutti i trade, in genere quelli che trattano direttamente con clienti esterni, ma questa non è la maggior parte degli sviluppatori di ufficio!

Per me, questa pratica fa apparire i programmatori come dei cretini, causa costanti guasti allo sprint e impedisce stime realistiche, oltre a cercare miglioramenti effettivi.

Cosa dicono le linee guida Scrum su questo argomento o dicono qualcosa al riguardo?

EDIT: sostituiti i tempi con punti trama. Mi riferivo alla fase di stima iniziale con Planning Poker e punti trama, non alla pianificazione dei dettagli dell'attività. Ho appena messo i giorni / le ore lì, perché a volte era un tipico dialogo come questo, anche con il tempo invece dei punti. Ci scusiamo per qualsiasi confusione! Gli esempi dei punti della storia rappresentano periodi di tempo più lunghi rispetto agli esempi di tempo.

EDIT 2 Al momento non esiste uno scrum master dedicato e l'OP assume quel ruolo, quando si tratta di riunioni di stima. Quindi è probabilmente il ruolo del conflitto a peggiorare questa contrattazione inappropriata, dal momento che appare come un'autorità, invece di una scrum master neutrale o sviluppatore. Forse, questo può essere risolto assumendolo come un partecipante parziale anziché un "master", purché non sia disponibile.

La situazione che descrivi è tossica. Questo tipo di contrattazione ignora la realtà e l'esperienza del team, nasconde intenzionalmente informazioni al team e all'organizzazione in generale e impedisce al team di migliorare nel tempo.

Se si desidera città http://www.scrumguides.org/scrum-guide.html come autorità, vorrei evidenziare:

Solo il team di sviluppo può valutare ciò che può realizzare nel prossimo Sprint.

e

Scrum si basa sulla trasparenza. Le decisioni per ottimizzare il valore e controllare il rischio vengono prese in base allo stato percepito dei manufatti. Nella misura in cui la trasparenza è completa, queste decisioni hanno una solida base. Nella misura in cui i manufatti sono incompleti trasparenti, queste decisioni possono essere imperfette, il valore può diminuire e il rischio può aumentare.

Il proprietario del prodotto potrebbe desiderare che un'attività sia possibile in sole 4 ore. Potrebbe anche essere un obiettivo ragionevole. Una buona reazione potrebbe essere quella di accettare la stima del team, misurarla se è accurata e chiedere "cosa dovremmo cambiare per essere in grado di completare questo tipo di attività più rapidamente?" Anche negoziare l'ambito del lavoro coinvolto nell'attività potrebbe essere ragionevole ed evidenziare un'importante differenza nel modo in cui gli sviluppatori e il proprietario del prodotto comprendono quel lavoro a portata di mano. Chiedere al team di modificare le proprie stime senza nuove informazioni garantisce solo stime imprecise.

Ci sono molte strategie che il team di sviluppo potrebbe usare per provare a cambiare questo schema, ma quando dai un esempio di risposta "Non riesco a spiegarlo al management" divento molto nervoso. Sembra che il proprietario del prodotto non abbia la fiducia della direzione (le stime imprecise che stanno producendo probabilmente non aiutano) e potrebbero non essere disposti a essere trasparenti sugli attuali fallimenti del processo.

Secondo me, uno dei più grandi successi di SCRUM è lo sviluppo di punti della storia, con l'esplicito intento esplicito di evitare i problemi di contrattazione menzionati qui. Il punto centrale delle storie è quello di evitare una connessione diretta tra un'attività e quanti giorni ci vorranno. Invece, questi due concetti sono collegati dall'idea di velocità.

Se fossi uno sviluppatore e venissi distorto nel chiamare una storia a 13 punti una storia a 8 punti, sarei felicemente obbligato. Sono le loro capacità di stima che stanno influenzando. Scalerò semplicemente tutte le mie difficoltà per abbinarle. Alla fine la velocità della squadra diminuirà in termini di punti trama a settimana per corrispondere alla volontà del management di "distribuire" i punti trama. I numeri consegnati al management dovrebbero corrispondere: "Abbiamo ridotto con successo il numero di punti di lavoro necessari per raggiungere il traguardo del 50%. Tuttavia, abbiamo visto una corrispondente riduzione della velocità del 50%, quindi l'effetto netto è realizzeremo esattamente ciò che avremmo realizzato esattamente nel tempo che ci sarebbe voluto. " Il concetto di velocità esiste per combattere il pio desiderio dell'alta dirigenza.

Ora ci sono due estremi che penso valga la pena guardare. Uno è un completo fallimento della gestione e l'altro è in realtà una preoccupazione molto valida per la gestione di cui preoccuparsi. Il primo caso è una condanna a morte per SCRUM, quando agli sviluppatori viene detto "non sei abbastanza produttivo. Devi produrre più punti narrativi che valgano il lavoro". Se ciò accade, in realtà non stai usando SCRUM, sei un Cookoo, che ha cacciato SCRUM dal nido e sta cercando di essere nutrito dall'uccello madre che torna al successivo.

Ora c'è un caso in cui penso che la gestione dovrebbeessere in grado di impegnarsi a torcere il braccio in questo modo. Dovrebbe essere ragionevole per il cliente dire "Non posso permettermi 50 punti trama per completare questo compito se la tua velocità è di 20 punti / settimana. Ho bisogno che tu lo compia in 30 punti storia", se quel cliente è disposto rinegoziare il contenuto di tali storie per ridurne la portata del 40%. SCRUM non è un buono pasto gratuito per gli sviluppatori di fare ciò che vogliono, è uno strumento di comunicazione per aiutarli e il management a conversare apertamente su ciò che deve essere fatto. È anche valido per un cliente mettere la stretta sullo sviluppatore e dire "svolgere l'attività in 30 punti" se sono disposti ad accettare il rischio intrinseco che il lavoro semplicemente non venga completato in tempo. Quando la scadenza non viene rispettata, se gli sviluppatori possono dire " e poi accetta tutto ciò che è stato effettivamente fatto. Penso che ci siano modi migliori per misurare la produttività di una squadra, ma devo ammettere che è un processo che funziona. e poi accetta tutto ciò che è stato effettivamente fatto. Penso che ci siano modi migliori per misurare la produttività di una squadra, ma devo ammettere che è un processo che funziona.

Per uno, l'OP non dovrebbe fornire informazioni sulla gestione alla direzione. Le stime delle attività sono strettamente a vantaggio del team. L'unica cosa che chiunque al di fuori della squadra deve sapere è su quali storie stanno lavorando, quali sono i loro valori in punti e quale è la velocità media della squadra. T

In secondo luogo, a meno che l'OP non sia uno sviluppatore di livello senior con una profonda conoscenza del software, la sua opinione sulle stime delle attività non dovrebbe avere molto peso. Gli sviluppatori sono quelli con la conoscenza del sistema e quelli che stanno facendo il lavoro. A meno che non siano tutti appena usciti dalla scuola con abilità di stima pari a zero, le loro stime dovrebbero essere escluse.

Questo non vuol dire che le stime a volte non possano essere messe in discussione. In tal caso, ciò deve avvenire in modo positivo. Ad esempio "hai considerato che abbiamo già svolto metà del lavoro per" x "" o "ti sei ricordato di includere il tempo per fare Y?".

In conclusione: gli sviluppatori dovrebbero sentirsi sicuri di fare le stime che desiderano, purché facciano un tentativo in buona fede di essere precisi. Se dicono che qualcosa richiede quattro ore, devi accettarlo.

Cosa dicono le linee guida Scrum su questo argomento o dicono qualcosa al riguardo?

Non dicono niente. La stima dell'attività non fa parte della mischia. Con mischia, la stima si interrompe nei punti della storia. La stima delle attività è semplicemente uno strumento per aiutare i team a fare meglio nella stima dei punti della storia assicurandosi di aver riflettuto su tutto il lavoro necessario per completare una storia.

È compito dello Scum Master assicurarsi che il processo di Scrum sia seguito. Ciò include la garanzia che il team non (costantemente) sovraccarichi la quantità di lavoro che può svolgere in uno sprint.
Da un lato, ciò significa regnare su una squadra eccessivamente entusiasta, ma dall'altra parte anche respingere il Product Owner se sta facendo pressione sulla squadra.

Un buon modo per mantenere realistico l'impegno / previsione è quello di guardare le storie che sono state effettivamente realizzate negli ultimi sprint. Questo è ciò che il team ha dimostrato di poter realizzare, quindi non ha senso trascinare molto più lavoro in uno sprint, poiché non verrà completato.

Come indicano anche altre risposte, la contrattazione sulle stime fornite dal team non fa parte del processo Scrum. Il team è il più familiare con il software, quindi dovrebbe sapere meglio quanto lavoro ha qualcosa.

Ciò che si può contrattare è lo scopo di una storia. Se il Product Owner ritiene che una storia sia stimata come più grande o più piccola di quanto ragionevolmente previsto, allora può chiedere un chiarimento al team per vedere se la visione del lavoro che deve essere fatto corrisponde tra le parti.
Se la storia è davvero così tanto lavoro, il Product Owner può decidere di suddividerla in diverse storie più piccole e distribuendo la funzionalità su quelle storie più piccole.

Il team è responsabile della qualità e non dovrebbe mai aprirsi alla contrattazione.

Sì e no.

Sì, il team di sprint dovrebbe negoziare con il proprietario del prodotto ciò che entra nello sprint.

No, il proprietario del prodotto non ha voce in capitolo su quanto tempo ci vorrà. Siete gli esperti, non loro.

Senti, non dovresti avere a che fare con quel tipo di immondizia: il tuo manager o il capo squadra sono lì per prepararti al successo. Ciò significa avere a che fare con il PM (o il loro capo) in modo da avere successo. Detto questo, non è così difficile.

"No."

Cosa faranno? Scrivi il codice da soli?

Consentire questo comportamento è un fallimento di Scrum Master. Il suo compito, innanzitutto, è proteggere la squadra. L'OP, per i motivi sopra descritti, è miope. Lo Scrum Master dovrebbe intervenire e, in modo positivo, riformulare il contesto della discussione.

Tale pressione, naturalmente, porterà a una pressione al ribasso sulla velocità, qualcosa che l'OP ha già citato. Se i team non riescono costantemente a terminare gli sprint, lo Scrum Master dovrebbe intervenire di nuovo e chiedere perché questo potrebbe essere il caso. In ambienti veramente tossici, i membri del team potrebbero non sentirsi liberi di essere onesti nelle Retrospettive. Ma in quella situazione, lo Scrum Master ha la responsabilità di denunciare comportamenti scorretti e proteggere la squadra.

Se ti trovi in ​​una situazione in cui il tuo Scrum Master non può o non farà queste cose, probabilmente avrai bisogno di un altro Scrum Master. L'OP risponde alle pressioni tipiche. Il team, in speleologia, sta anche rispondendo come spesso fanno gli umani. È compito dello Scrum Master vedere questo per quello che è e metterlo fine. La responsabilità del PO in questo caso è di sollevare la questione nella Retrospettiva e, se necessario, di lead e manager. Se il problema persiste, aggiorna il tuo profilo LinkedIn e trova persone migliori con cui lavorare.

Un team di sviluppo prodotto (che è chiunque, dal proprietario del prodotto, agli sviluppatori, ai tester) può seguire il processo agile e ottenere buoni risultati dati da persone ragionevolmente competenti e aspettative realistiche.

Oppure possono seguire un processo che ricorda superficialmente il processo agile.

Quel PO probabilmente pensa che otterrà risultati migliori cercando di ottenere stime dei tempi inferiori per le attività. Ovviamente non funziona. Se qualcosa richiede tre giorni, mi dai un sacco di soldi e ti darò una stima che posso farlo in un'ora. Ci vorranno ancora tre giorni. Se vieni a gridarmi perché non è finita in un'ora, come promesso, ci vorranno cinque giorni.

Tutto ciò che raggiunge è interrompere il processo agile e rinunciare a tutti i risultati positivi che potrebbe ottenere. Lo scrum master dovrebbe avere l'esperienza, il potere e il coraggio per impedirlo. Se la gestione rende qualcuno che non ha esperienza o che non ha il potere di prevenirlo, è colpa loro che agili interruzioni. Se lo Scrum Master non ha il coraggio, allora condivide la colpa con il Primo Ministro.

Direi che dipende molto dalla motivazione qui. L'obiettivo generale della stima è quello di farsi un'idea di quanto il team può realizzare durante uno specifico sprint, il che consente quindi di prevedere il lavoro futuro in base a tale velocità. Ad esempio, se il team sta completando 30 punti storia ogni sprint e se ci sono circa 60 punti storia davanti all'Articolo X sul backlog, il Product Owner può quindi ragionevolmente dire che l'Articolo X sarà completato in qualcosa come 6 settimane (basato su un sprint standard di due settimane).

Per rendere questa stima il più accurata possibile, non è inaudito avere disaccordi su quanti punti della storia sia un particolare oggetto. Scrum in realtà lo incoraggia. Tale disaccordo a volte può persino essere scaldato. Tuttavia, l'obiettivo finale finale dovrebbe essere la stima accurata della complessità del PBI, non sgonfiando artificialmente lo sforzo in modo da poter provare a stipare più PBI in una data velocità.

Questo è in realtà il modo in cui funziona la pianificazione del poker, in linea di principio. Ognuno espone la propria stima. Lo Scrum Master, quindi prende la stima alta e bassa e chiede perché il membro del team pensa che dovrebbe essere così alto / basso. Ciò offre al team la possibilità di ascoltare prospettive alternative del lavoro coinvolto e di avere un'idea più chiara della complessità del compito. Dopo la discussione, ognuno lancia di nuovo le proprie stime. Questo processo viene risciacquato e ripetuto fino a quando non vi è un consenso generale sulla complessità.

In altre parole, non è sbagliato sfidare la tua stima, dato che lo sfidante ha una logica del perché non sono d'accordo, a parte il fatto che lo vogliono solo più in basso. È tua responsabilità, quindi, convincere la tua squadra che la tua stima è corretta, se ritieni che lo sia ancora.