Pianificazione di poker e sviluppatori wordy [chiuso]

Sembra che le cose siano definite in modo formale, quindi un timer sarebbe una buona idea, dal momento che la pianificazione del poker è definita come un periodo di tempo in cui le persone possono parlare.

Ha un'idea sbagliata anche della stima, tutti stimano contro la storia e non l'implementazione , motivo per cui ottieni tale varianza. Ad esempio, alcune persone potrebbero ignorare un framework o una soluzione standard e iniziare a scrivere le cose da zero.

Il membro del team suona una personalità analista. Gli analisti hanno bisogno di molte informazioni per prendere una decisione. L'idea del timer è la migliore, ma sappi che sta andando a cavillare da tutto ciò che dà. Lavora con lui per spiegare che si tratta solo di una stima iniziale basata sul problema NON sulla soluzione. Se vuole fare domande, chiedigli di tenerlo per il problema, non la soluzione. Potrebbe essere necessario interromperlo o infastidirlo per un po 'quando continua a vagare alle soluzioni.

Assicurati di tenere gli altri membri della squadra alle stesse regole, in modo che non si senta escluso. Gli analisti sono una personalità comune nella programmazione, quindi puoi benissimo incontrare altri come lui.

Sembra che il tuo collega non capisca la differenza tra stima e impegno o non gli sia stata comunicata durante l'allenamento. E, dal momento che hai cercato di collegare il problema alla sua personalità, è possibile che l'intera squadra non lo capisca ancora. (Ma non preoccuparti! La maggior parte del nostro settore non lo capisce. Agile è difficile!)

Quando diciamo che la dimensione di una storia è X punti, in realtà intendiamo una distribuzione di probabilità. Se le nostre stime sono corrette, la storia dovrebbe impiegare più tempo il 50% delle volte (e l'altro 50% richiederà meno tempo). Se il tuo collega crede che, quando sono passate X unità di tempo, gli verrà chiesto di dimostrare la storia, altrimenti cambierà il suo approccio alla stima.

Pianificare il poker introduce un altro errore: invece di provare a bloccare X, lo abbiniamo a una scala discreta, la scala di Fibonacci (1, 2, 3, 5, 8, ecc.) è la più popolare. Sta dicendo che la dimensione non è tanto quanto è. Quando diciamo che la dimensione della storia è di 3 punti, diciamo veramente "è X più-meno la varianza e X è più vicina a 3 che a 2 o 5".

Il tuo team potrebbe trarre beneficio dalla comprensione di quanto sia impreciso questo esercizio e da quanto la stima differisca dall'impegno. Se vuoi / devi studiare questi concetti in modo approfondito, questo libro ha quello.

Posso vedere da dove proviene il tuo membro del team, ma chiaramente non ha compreso completamente il concetto di Agile e Planning Poker. Dovresti iniziare assicurandoti che tutti comprendano i concetti e il ragionamento che stanno dietro di loro, e quindi dovrebbero fare da soli.

Per i team con cui lavoro, all'inizio di ogni sessione di pianificazione ho impostato un timer di sabbia di 3 minuti sul tavolo. Lascio che tutto il team sappia che se in qualsiasi momento sentono che la conversazione sta diventando un'immersione profonda, o irrilevante, o in qualsiasi altro modo andrà oltre ciò che ritengono necessario per stimare la storia nei punti della storia, allora chiunque nel team può capovolgere il timer. Quando la sabbia si esaurisce, il team stima immediatamente.

Questo metodo consente a tutti gli individui del team di limitare la conversazione, quando ritengono che la conversazione non sia più utile per stimare la storia discussa. Allo stesso tempo, non interrompe immediatamente la conversazione, ma fornisce a tutti un'indicazione visiva secondo cui la conversazione deve concludersi nei prossimi minuti, perché voteremo.

Un altro strumento che utilizzo per mantenere le sessioni di pianificazione incentrate, è quello di accertarsi che tutti i membri del team abbiano rivisto le storie nella parte superiore del backlog almeno un paio di giorni prima della pianificazione. L'idea è che se hai una lista di domande immediatamente dopo aver letto le storie, puoi far sapere al proprietario del prodotto le potenziali domande alcuni giorni prima, in modo che possano chiarire la storia o la critica dell'accettazione per limitare eventualmente la discussione successiva. Questo permette anche alle persone di iniziare a pensare al potenziale design della storia, prima di essere in pianificazione (e di provare a progettare durante la pianificazione).