Quanto dovrebbe essere rilassato (o no) uno sprint?

Quale dovrebbe essere l'atteggiamento nei confronti del fare storie assegnate a uno sprint? Ovviamente vuoi dare la priorità al loro completamento nello sprint, ma per me il punto di agilità è quello di essere dinamico: non vuoi procrastinare deliberatamente o renderlo "ok" per perdere le storie degli utenti finali in uno sprint, ma a nello stesso momento in cui accadono cose inaspettate, e quelle storie non vengono completate e vengono spinte allo sprint successivo, non vuoi la sensazione di aver fatto qualcosa di sbagliato. Non dovrebbe essere un'esperienza spaventosa o negativa, vero?

Le esperienze negative / spaventose sono accettabili per gli impegni sprint persi? Gli sviluppatori dovrebbero essere ritenuti responsabili degli impegni sprint persi quando si presentano compiti imprevisti che devono essere affrontati (ad es. Supporto alla produzione)?

Dovresti assolutamente mirare a fare gli oggetti in uno sprint.

Uno dei principali vantaggi di SCRUM è che dà al progetto un "battito cardiaco".

Dai la priorità, scegli gli articoli da un elenco, li consegna, li demo, rifletti come sono andati, quindi lo fai di nuovo in cicli prevedibili.

Tutta la pianificazione, le stime e le priorità sono basate su questo concetto. Che possiamo e commetteremo punti X all'interno dello sprint e, nel tempo, possiamo stabilire una velocità che possiamo usare per una migliore pianificazione.

Se sei troppo disinvolto sul contenuto e sugli impegni dei tuoi sprint, SCRUM secondo me si rompe e perdi molto i suoi benefici.

Ovviamente il mondo reale a volte avrà qualcosa da dire al riguardo, ma questa dovrebbe essere l'eccezione piuttosto che la regola ...

La chiave è che ci deve essere responsabilità nel non riuscire a completare le storie.

Ciò significa che dovrebbe esserci una solida ragione per cui una storia non è stata completa e che questa ragione è spiegata nel piano del progetto in futuro, quindi non viene ripetuta.

Questo motivo deve essere qualcosa di più di un vago "inventato".

Ad esempio, se una storia non era completa perché un membro del team doveva lavorare su un problema di produzione, allora questa possibilità deve essere affrontata in iterazioni future, sia pianificando un numero inferiore di ore da questo membro del team, sia organizzando un'altra copertura.

Se il motivo avrebbe potuto essere evitato con maggiore diligenza o duro lavoro in anticipo, allora sì, questa responsabilità potrebbe essere un po 'dolorosa. Spero che il dolore sia della varietà "Questo è ciò che dobbiamo fare meglio la prossima volta" piuttosto che della varietà "Non stai facendo il tuo lavoro".

Non dovrebbe essere un'esperienza spaventosa o negativa, vero?

Se succede una o due volte, no, allora non dovrebbe essere un'esperienza negativa. Se succede regolarmente, hai un problema. La squadra è quindi sempre troppo impegnativa. Migliora la stima e pensa due volte a ciò che commetti per uno sprint, ma non diventare ansioso.

Sprint rilassati significa che hai avuto un sottoimpegno.

Sprint non rilassati significano che hai avuto un impegno eccessivo.

Consegno semplicemente ciò che commetto e cerco di migliorare nel mio impegno. Solo in circostanze speciali passerei una storia al prossimo sprint. Preferisco avere una leggera pressione ogni giorno piuttosto che avere una pressione infernale poco prima di alcune scadenze.

Sulla base della mia esperienza - Come qualsiasi altra cosa agile, ci adattiamo a un sistema di feedback continuo che include la stima.

Va bene perdere una scadenza per il primo sprint (inizio del progetto) ma IMPARARE da ciò che è andato storto (sottovalutazione, non conoscendo i punti di forza del team ecc.). Quindi prendi il feedback e lo invii allo sprint successivo e ottieni una stima migliore.

In base alla mia esperienza, sono trascorsi 11 mesi nel mio nuovo progetto agile che raramente ci manca la scadenza, se non ci manca affatto. Ma abbiamo mancato la scadenza per il primo sprint perché non conoscevamo il ritmo e la forza dei membri del nostro team.

Alcune persone sostengono che "allocare" più tempo per il primo sprint per superare il primo problema di sprint.

È interessante vedere le risposte / i commenti qui. Su ogni agile (tipo) progetto a cui ho lavorato, il vantaggio principale era di diffondere la pressione sulle scadenze su molte mini scadenze piuttosto che una marcia della morte sulle scadenze alla fine di un progetto. IMO, gli sprint dovrebbero essere presi sul serio. Eventuali errori nella scadenza o funzionalità fornite devono essere considerati potenziali problemi nella gestione o nello sviluppo del progetto.

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. - Principi alla base del Manifesto Agile

Se è un'esperienza spaventosa o negativa, e succede sempre, hai un problema. Lo sviluppo del software dovrebbe essere divertente. Non negativo o spaventoso.

Tuttavia, se il team si impegna a terminare alcune storie in uno sprint e continua a non consegnare, hai anche un problema. Quasi certamente questo problema non verrà risolto aggiungendo ulteriore pressione sulla squadra per completare le storie. Se il problema è dovuto a fattori esterni, è necessario gestirli. Se il team si sta impegnando eccessivamente, ScrumMaster può guidare il team a impegnarsi in meno punti trama. Ci possono essere molte ragioni e ognuna potrebbe aver bisogno di essere affrontata diversamente. Un team energico e motivato dovrebbe avere molte motivazioni per andare avanti.

Idealmente, qualunque sia il problema, viene sollevato durante la retrospettiva e risolto.

Non dovrebbe essere così complicato per il team capire cosa possono realizzare durante il periodo relativamente breve dello sprint e poi realizzarlo (una storia occasionale che viene spinta allo sprint successivo è OK, la velocità può fluttuare, le cose cambiano ecc. .). Se dopo qualche sprint non riesci a farlo ragionevolmente senza intoppi, stai facendo qualcosa di sbagliato.

Dipende molto dalla cronologia.

A volte avrai BISOGNO di fare tutte le storie, o la maggior parte comunque. Sebbene Agile offra una certa flessibilità, dovrai anche portare a termine il progetto, possibilmente in tempi stretti .. Quindi, avere la maggior parte delle storie fatte ti permetterà di portare a termine il tuo progetto in tempo.

Detto questo, però, verranno fuori delle cose che ti impediranno di portare a termine ogni storia, ogni sprint.

Se il prodotto si trova su una sequenza temporale e mancano storie chiave, quel prodotto lo rende in ritardo. Il prodotto in ritardo in alcuni casi può danneggiare la posizione competitiva di un'azienda. Quindi, in quel caso, potresti VOGLERE che sia un'esperienza negativa perdere storie - potrebbe farti fare tutto la prossima volta.

Se dosato correttamente, lo stress è buono. Vuoi non togliere tutto lo stress, vuoi solo distribuirlo più uniformemente nel tempo. Anche quando giochi al tuo gioco preferito, avrai una certa quantità di stress e sentimenti negativi. In realtà ne ricavi più energia.

Una squadra dovrebbe davvero sentirsi male per le storie mancate. Darà loro energia per cambiare qualcosa la prossima volta (lavora in modo diverso o pianifica meno storie, entrambe sono buone). Dovrebbero anche sentirsi orgogliosi quando fanno le loro storie, ovviamente.

Si menzionano anche attività impreviste (supporto alla produzione). Ciò solleva una bandiera rossa con me. Ci sarebbe dovuto essere un intervallo di tempo concordato per tutte le questioni estranee alle storie. Altrimenti il ​​gioco non è giusto, la squadra si sente impotente e i sentimenti negativi non vengono utilizzati per migliorare.

Dovresti esaminare i fattori che fanno fallire i tuoi impegni e cercare di risolverli. Grandi quantità di eventi casuali continueranno a incasinare i tuoi sprint rendendo imprevedibile la tua velocità. O risolvi le cause di ciò o introduci un rallentamento nei tuoi sprint. Preferisco riparare.

In ogni caso, la squadra non può essere ritenuta responsabile se il loro lavoro è disturbato da fattori esterni. Usa le retrospettive per esaminare questo.