Planning Poker e sviluppatori prolissi [chiuso]

Il mio team è composto da 4 sviluppatori; tutto condito e specializzato. Uno di questi è un tipo prolisso e ben intenzionato che insiste nel definire la soluzione tecnica per le nostre storie prima di scrivere le nostre stime con Planning Poker. Rifiuta di stimare se non ha un'idea approssimativa della soluzione tecnica concordata (che suona ragionevole, giusto?).

Il problema è che le nostre sessioni di stima stanno impiegando un'eternità a finire !! Nella tua esperienza, come gestisci questo tipo di personalità quando giochi a poker di pianificazione?

Sembra che le cose vengano definite formalmente, 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 anche un'idea sbagliata della stima, tutti stimano rispetto alla storia e non all'implementazione , motivo per cui si ottiene tale varianza. Ad esempio, alcune persone potrebbero ignorare un framework o una soluzione standard e iniziare a scrivere cose da zero.

Il tuo membro del team suona una personalità analista. Gli analisti hanno bisogno di molte informazioni per prendere una decisione. L'idea del timer è la cosa migliore, ma attenzione, sta per mettere a soqquadro tutto ciò che dà. Lavora con lui per spiegare che è solo una stima anticipata basata sul problema, NON sulla soluzione. Se vuole porre domande, chiedigli di tenerlo al problema, non alla soluzione. Potrebbe essere necessario interromperlo o infastidirlo per un po 'quando continua a cercare soluzioni.

Assicurati di tenere gli altri membri della squadra a queste stesse regole in modo che non si senta individuato. Gli analisti sono una personalità comune nella programmazione, quindi potresti benissimo imbatterti in altri come lui.

Sembra che il tuo collega non capisca la differenza tra stima e impegno o che non gli sia stato comunicato durante l'allenamento. E, dal momento che hai cercato di collegare il problema alla sua personalità, è possibile che tutto il tuo team 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, intendiamo effettivamente una distribuzione di probabilità. Se le nostre stime sono corrette, la storia dovrebbe richiedere più tempo il 50% del tempo (e l'altro 50% richiederà meno tempo). Se il tuo collega ritiene che, quando saranno trascorse X unità di tempo, gli verrà chiesto di provare la storia o altro, ciò cambierà il suo approccio alla stima.

Pianificare il poker introduce un altro errore: invece di provare a fissare 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 quella che è. Quando diciamo che la dimensione della trama è di 3 punti, diciamo davvero "è X più-meno una certa varianza e X è più vicino a 3 che a 2 o 5."

Il tuo team potrebbe trarre vantaggio dalla comprensione di quanto sia impreciso questo esercizio e di come la stima differisca dall'impegno. Se vuoi / hai bisogno di studiare questi concetti in profondità, questo libro ha questo.

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

Per i team con cui lavoro, all'inizio di ogni sessione di pianificazione ho impostato un timer della sabbia di 3 minuti sul tavolo. Faccio sapere all'intero team che se in qualsiasi momento sentono che la conversazione sta diventando un'immersione profonda, o irrilevante, o in qualsiasi altro modo va oltre ciò che ritengono necessario per stimare la storia nei punti della storia, allora chiunque nel team può capovolgere il timer. Una volta che 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 in discussione. Allo stesso tempo, non interrompe immediatamente la conversazione, ma fornisce a tutti un'indicazione visiva della necessità di concludere la conversazione nei prossimi minuti, perché voteremo.

Un altro strumento che utilizzo per aiutare a mantenere concentrate le sessioni di pianificazione è quello di accertarmi che tutti i membri del team abbiano esaminato le storie in cima all'arretrato almeno un paio di giorni prima della pianificazione. L'idea è che se si ha un elenco di domande immediatamente dopo aver letto le storie, è possibile far conoscere al proprietario del prodotto le potenziali domande alcuni giorni prima, in modo che possano chiarire la storia o la critica di accettazione per sperare di limitare la discussione successiva. Ciò consente anche alle persone di iniziare a pensare al potenziale progetto della storia, prima di essere in pianificazione (e provare a progettare durante la pianificazione).