Quanto dovrebbe essere rilassato (o meno)?

12

Quale dovrebbe essere l'atteggiamento nei confronti delle storie fatte assegnate a uno sprint? Ovviamente vuoi dare priorità allo scatto fatto nello sprint, ma per me l'intero punto di agilità è essere dinamico: non vuoi deliberatamente procrastinare o rendere "ok" il fatto di non riuscire a terminare le storie degli utenti in uno sprint, ma a allo stesso tempo quando vengono fuori cose inaspettate, e quelle storie non vengono completate e vengono spinte al prossimo sprint, non vuoi la sensazione di aver fatto qualcosa di sbagliato. Non dovrebbe essere un'esperienza spaventosa o negativa, dovrebbe?

Le esperienze negative / spaventose sono accettabili per gli impegni sprint mancati? Gli sviluppatori dovrebbero essere ritenuti responsabili degli impegni sprint mancati quando emergono compiti inaspettati che devono essere affrontati (ad esempio supporto alla produzione)?

    
posta void.pointer 01.05.2012 - 17:31
fonte

9 risposte

7

Devi assolutamente mirare a ottenere gli elementi entro uno sprint.

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

Assumi la priorità, scegli gli elementi da un elenco, li consegni, li dimostri, rifletti su come sono andati, poi lo fai di nuovo in cicli prestabiliti.

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

Se sei troppo informale sul contenuto e sugli impegni dei tuoi sprint, SCRUM si rompe a mio avviso e perdi molto i suoi benefici.

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

    
risposta data 01.05.2012 - 17:43
fonte
5

La chiave è che ci deve essere responsabilità per non aver completato le storie.

Ciò significa che dovrebbe esserci una solida ragione per cui una storia non è stata completata, e che questa motivazione è spiegata nel piano del progetto andando avanti in modo che non venga ripetuta.

Questa ragione deve essere più che una vaga "roba".

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 nelle iterazioni future - o pianificando per meno ore da questo membro del team o disponendo altri la copertura.

Se la ragione avrebbe potuto essere evitata con maggiore diligenza o duro lavoro, allora, sì, questa responsabilità potrebbe essere un po 'dolorosa. Speriamo che il dolore sia nella varietà "Questa è la cosa che dobbiamo fare meglio la prossima volta" piuttosto che nella varietà "Non stai facendo il tuo lavoro".

    
risposta data 01.05.2012 - 17:56
fonte
4

That shouldn't be a scary or negative experience, should it?

Se succede una o due volte, no, allora non dovrebbe essere un'esperienza negativa. Se succede regolarmente, hai un problema. Il team è quindi sempre in fase di overcomitting. Ottieni una stima migliore e pensa due volte a ciò che impegni per uno sprint, ma non diventare ansioso.

Sprint rilassati significa che hai avuto un sottocommittimento.

Gli sprint non rilassati significano un eccesso di impegno.

Consegno solo ciò che commetto e cerco di migliorare nel commettere. Solo in circostanze particolari sposterei una storia per il prossimo sprint. Preferisco avere una leggera pressione ogni giorno che avere una pressione infernale poco prima di alcune scadenze.

    
risposta data 01.05.2012 - 17:42
fonte
4

In base alla mia esperienza - Come qualsiasi altra cosa in 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 impari da ciò che è andato storto (sottovalutazione, non conoscendo i punti di forza della squadra, ecc.). Quindi prendi il feedback e lo trasmetti allo sprint successivo e ottieni una stima migliore.

Dalla mia esperienza, sono passati 11 mesi nel mio nuovo progetto agile raramente ci manca la scadenza se non ci manca. Ma ci mancava la scadenza per il primo sprint perché non conoscevamo il ritmo e la forza dei membri del nostro team.

Alcuni sostengono che "allocare" più tempo per il primo sprint a superare il primo problema di sprint.

    
risposta data 01.05.2012 - 17:47
fonte
2

È interessante vedere qui le risposte / i commenti. Su tutti i progetti agili (di tipo) su cui ho lavorato, il vantaggio principale era quello di diffondere la pressione di scadenza su molte mini-scadenze piuttosto che una marcia della morte a scadenza alla fine di un progetto. IMO, gli sprint dovrebbero essere presi sul serio. Qualsiasi slittamento nella scadenza o nella funzionalità fornita dovrebbe essere considerato come un potenziale problema nella gestione o nello sviluppo del progetto.

    
risposta data 01.05.2012 - 17:57
fonte
2

I processi Agile promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado mantenere un ritmo costante indefinitamente. - I principi dietro al Manifesto Agile

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

Tuttavia, se la squadra si sta impegnando a finire alcune storie in uno sprint e continua a non consegnare, hai anche un problema. Quasi certamente questo problema non verrà risolto aggiungendo ulteriore pressione alla squadra per completare le storie. Se il problema è dovuto a fattori esterni, è necessario gestirli. Se la squadra è in over-committing, ScrumMaster può guidare la squadra verso il commit di meno punti storia. Ci possono essere molte ragioni e ciascuna potrebbe dover essere affrontata in modo diverso. Una squadra energica e motivata dovrebbe avere molte motivazioni per andare avanti.

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

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

    
risposta data 02.05.2012 - 08:51
fonte
1

Dipende molto dalla tua cronologia.

A volte hai bisogno di fare tutte le storie fatte, o la maggior parte di loro comunque. Sebbene Agile offra una certa flessibilità, dovrai anche portare a termine il progetto, possibilmente su una tempistica ristretta. Quindi, avere la maggior parte delle storie fatte ti consentirà di portare a termine il tuo progetto.

Detto questo, però, arriveranno cose che ti impediranno di completare ogni storia, ogni sprint.

Se il prodotto si trova in una sequenza temporale e le storie chiave non vengono rispettate, il coudl rende il prodotto in ritardo. Il ritardo del prodotto in alcuni casi può compromettere la posizione competitiva di un'azienda. In tal caso, potresti VOGLIONO essere un'esperienza negativa per la mancanza di storie: potrebbe farti fare tutto alla prossima volta.

    
risposta data 01.05.2012 - 17:39
fonte
1

Se dosato correttamente, lo stress è buono. Vuoi non voler togliere tutto lo stress, vuoi solo estenderlo in modo più uniforme nel tempo. Anche quando giochi al tuo gioco preferito, avrai una certa quantità di stress e sentimenti negativi. In realtà ottieni più energia da esso.

Una squadra dovrebbe sinceramente sentirsi in colpa per le storie perse. Darà loro l'energia per cambiare qualcosa la prossima volta (lavorare diversamente o pianificare meno storie, entrambi sono buoni). Dovrebbero anche sentirsi orgogliosi quando fanno le loro storie, ovviamente.

Hai anche menzionato compiti inaspettati (supporto alla produzione). Questo alza una bandiera rossa con me. Dovrebbe esserci stato un intervallo di tempo concordato per tutte le questioni non correlate alle storie. Altrimenti il gioco non è giusto, la squadra si sente impotente e i sentimenti negativi non sono usati per migliorare.

    
risposta data 02.05.2012 - 08:22
fonte
1

Dovresti esaminare i fattori che fanno fallire i tuoi impegni e cercare di risolverli. Grandi quantità di eventi casuali continueranno a rovinare i tuoi sprint rendendo la tua velocità imprevedibile. O risolvere le cause di questo o introdurre slack nei tuoi sprint. Preferisco il fissaggio.

In ogni caso, la squadra non può essere ritenuta responsabile se il suo lavoro è disturbato da fattori esterni. Utilizza le retrospettive per esaminarlo.

    
risposta data 02.05.2012 - 09:31
fonte

Leggi altre domande sui tag