La nostra versione di Agile non funziona. Suggerimenti?

Lavoro a un piccolo team di 4 sviluppatori. Stiamo implementando una versione di Agile che sembra fornirci continuamente le stesse difficoltà, settimana dopo settimana, e sto cercando suggerimenti che possano aiutarci a migliorare il nostro processo.

Lo sfondo:

Generalmente facciamo sprint di 2 settimane e ogni sprint tendiamo a sottovalutare il nostro lavoro e ci mettiamo nei guai con il nostro manager perché siamo in ritardo.

Iniziamo ogni sprint assegnando le storie che il nostro manager crea per noi. A volte lancia anche i compiti e li stimiamo. Non usiamo i punti della storia. Usiamo il software Urban Turtle per "gestire i nostri sprint", che essenzialmente sono solo storie e compiti, e il relativo esaurimento. Non prevediamo un rilascio al termine di uno sprint.

Il problema più comune che si verifica è che pianifichiamo un'attività all'inizio di uno sprint solo per scoprire che ha una portata molto più ampia, ma comunque alta nella priorità, quindi dobbiamo lavorarci su ore aggiuntive. Il secondo problema più comune è che uno di noi incontra un problema tecnico che rallenta le ore bruciate, causando un blocco stradale.

L'unico suggerimento che ci viene fornito è di essere più proattivi nell'adeguare le nostre stime e nel fornire aggiornamenti durante gli stand-up al mattino, in modo che possiamo adeguarci per il tempo extra necessario.

Tuttavia, sembra esserci qualcosa di fondamentalmente sbagliato nel modo in cui stiamo facendo le cose. Forse c'è una disconnessione tra le aspettative del manager a livello di progetto e le aspettative a livello di sprint. Perché stiamo effettuando queste iterazioni di sprint secondo un piano di progetto, e quindi l'estensione di uno sprint o il rinvio di elementi rovina il piano di progetto. Quindi, come sviluppatori, siamo incoraggiati a eseguire Agile estendendo le stime quando necessario, ma completando anche lo sprint in tempo, il che è fonte di confusione.

Questo non può essere un problema insolito, quindi spero che quelli più saggi di me là fuori abbiano un suggerimento o due su come possiamo smettere di imbatterci in questo stesso problema ogni sprint. È frustrante.

perché siamo in ritardo

Questo tipo di pensiero è il tuo problema. Non sei dietro il programma, il programma è troppo stretto. Dovresti iniziare a stimare storie in punti astratti anziché ore e poi, nel corso di 2-3 iterazioni, capire la tua velocità. La tua velocità è quanti punti fai di solito ogni iterazione, non quanti punti il ​​tuo manager vuole inserire.

Dopodiché non importa se sottovaluti costantemente i compiti: la tua velocità lo spiega già.

Ovviamente, questo è impossibile se usi ore anziché punti.

Sembra che i problemi siano l'incapacità del tuo team di fare stime accurate e l'impossibilità di prevedere i problemi che sorgono inevitabilità.

Le piccole attività sono molto più facili da stimare in modo accurato rispetto alle attività di grandi dimensioni, quindi prova a suddividere le attività in blocchi molto più piccoli.

Non permettere a nessuno di fare una stima per qualsiasi attività, a meno che non sappiano ESATTAMENTE come lo faranno. Per qualsiasi attività che lo sviluppatore non sappia cosa completare, dedica un po 'di tempo al programma di QUESTO sprint affinché lo sviluppatore faccia qualche indagine e progettazione e fornisca una stima accurata. Mai meno di mezza giornata. Ma sposta l'attività su NEXT sprint. Quindi, quando arriverai alla pianificazione per il prossimo sprint, avrai una buona stima. Nota che questo tempo extra non è sprecato, perché è tempo che lo sviluppatore finisca per spendere in ogni caso.

E non aver paura di tornare dal project manager e dirgli che avrai bisogno di più sprint per passare attraverso l'elenco delle attività. È meglio farlo, piuttosto che impegnarsi per obiettivi impossibili.

Stai cercando di allocare il 100% del tuo tempo? Se è così, smetti di farlo. Inizia sommando tutte le ore che la tua squadra deve contribuire durante lo sprint. Fallo supponendo che ogni lavoratore impiegherà nella migliore delle ipotesi 6 ore al giorno per il progetto. Questo è considerato un "giorno ideale". Quelle altre due ore? Risucchiato da riunioni, interruzioni, attività amministrative, quella mattina che stai leggendo e-mail e pianificando la tua giornata, ecc. Questo non è "proteggere le tue scommesse" o "sandbagging", è realistico.

In secondo luogo, moltiplicare tale 6 ore / giorno per l' 80% . Perché? Perché come esseri umani facciamo schifo nel prevedere quanto tempo impiegherà un compito. Questo spiega errori nel nostro giudizio. Ancora una volta, non sandbagging, è realistico.

Ora hai un numero che rappresenta un numero realistico di ore che prevedi di applicare direttamente alle tue attività. Quando effettui una stima, smetti di aggiungere storie quando la storia successiva ti metterà sopra.

Infine, non lasciare che il proprietario del prodotto aggiunga attività. La pianificazione della mischia è per il team , l'OP non fa parte del team che svolge il lavoro. Certo, nel mondo reale se l'OP è più ben informato di chiunque nel team il suo contributo può essere molto utile. Tuttavia, se il team si prende il caldo per essere dietro, il team deve assumersi la responsabilità di esattamente quali compiti faranno. Il tuo obiettivo è essere in grado di soddisfare i criteri di accettazione; se un'attività non porta direttamente a quello, non farlo.

Ricorda, Scrum non significa essere più produttivi. Si tratta di essere più aperti e comunicativi. Il lavoro richiederà tutto il necessario per essere completato. Scrum è lì per rendere più semplice la stima, la comunicazione più semplice con le parti interessate e un impegno più facile per il tuo team.

Criteri di accettazione mal definiti all'inizio dello sprint?

Le stime iniziali sono spesso troppo basse perché le carte trama hanno scarsi criteri di accettazione (se presenti) quando vengono stimate. Che ne dici di passare allo sviluppo del collaudo basato sull'accettazione -test (ATDD), noto anche come storytest per aiutare il team a chiarire meglio qual è la carta?

Storie troppo grandi?

Un altro motivo per cui scopri che a metà scatto le tue storie impiegano più tempo del previsto potrebbe essere che sono troppo grandi. Hai visto l' Agile in un mazzo di flashcard Flash ? Hanno una flashcard chiamata "Riduci storie XL per adattarsi". Fornisce strategie per dividere storie come il differimento di casi limite, effetti collaterali, aspetti non funzionali o gestione degli errori nelle storie successive.

Non riesci a stimare perché non hai informazioni sufficienti?

@sleske dà un buon suggerimento sui picchi . Prova a identificare incognite tecniche al momento della stima. Se ci sono, vedere se è possibile posticipare la storia in uno sprint più tardi e invece fare un time-boxed indagine (picco) questo sprint per cercare di imparare ciò che ci vuole per essere in grado di valutare. Non lasciarti trasportare e risolvi la storia originale: il picco si fa quando ne sai abbastanza per stimare la storia.

Fallire più velocemente

E sono d'accordo con @Patrick Hughes - considera di passare agli sprint di 1 settimana in modo da poter vedere i problemi più velocemente.

Oltre ai buoni suggerimenti di @Kevin e @Patrick ...

Gli approcci agili non sono "taglia unica" ma questo commento ha attirato la mia attenzione:

Stiamo implementando una versione di Agile che sembra fornirci continuamente le stesse difficoltà

Stai meglio iniziando con una metodologia "dal libro" (Scrum è dominante in questi giorni a quanto pare) - e fai ESATTAMENTE quello che ha fatto qualche altra squadra di successo ... Fallo per alcuni sprint ... E solo allora inizi a considerare cambiamenti necessari per ottimizzare le condizioni locali.

Noleggiare un esperto Scrum coach (per alcune iterazioni) può essere una vera differenza. C'è sottigliezza nel diventare agili nel modo giusto.

Per prima cosa consiglio di seguire il libro scrum-xp-from-the-trenches . Guarda a pagina 26 il punto sui calcoli della velocità. L'idea è di definire un fattore di messa a fuoco e di dirlo per il prossimo Sprint:

giorni lavorativi disponibili * fattore di messa a fuoco = velocità stimata

la velocità stimata è la somma delle stime delle storie che prevedi di implementare durante il prossimo Sprint.

E dopo uno Sprint si calcola l'ultimo fattore di messa a fuoco Sprint come:

fattore di messa a fuoco = velocità effettiva / giorni lavorativi disponibili

dove la velocità effettiva è la somma delle stime delle storie che hai implementato durante lo sprint.

Quindi riutilizzi questo fattore di messa a fuoco effettivo per il prossimo Sprint e dopo alcuni Sprint sarai in grado di essere più preciso con quanto puoi davvero ottenere durante uno Sprint ...

Fino a quando non ottieni le tue stime per accorciare i tuoi sprint a una settimana, in questo modo riconoscerai più rapidamente l'eccesso e sarai in grado di reagire con incrementi più piccoli.

Trascorri più tempo in anticipo durante la progettazione di attività per ottenere un po 'di respiro per riconoscere gli effetti collaterali che probabilmente stanno causando il sanguinamento dell'oscilloscopio dappertutto. Potrebbe anche essere che i compiti stessi siano troppo lunghi per una corretta valutazione agile, vedere se i compiti possono essere suddivisi in passaggi più brevi che saranno più facili da ingoiare.

Metti tutti a proprio agio con l'invio di una bandiera rossa non appena colpiscono un problema invece di rimanere bloccati su un problema per alcune ore. Prova a staccare l'ego e la colpa da questo processo, è più facile per alcuni rispetto ad altri =)

E come @Kevin allevato, non pianifichi mai direttamente al 100% direttamente alle attività perché ci sono sempre riunioni generali e così via che potresti non riconoscere come mangiatori di tempo.

Quando tutto va bene per quanto riguarda la programmazione, poi torni indietro di due settimane, ti riprenderai magicamente un po 'di tempo dal minor numero di riunioni.