Planejando Poker e desenvolvedores prolíficos [fechado]

Minha equipe é composta por 4 desenvolvedores; tudo experiente e qualificado. Um deles é um sujeito prolixo e bem-intencionado, que insiste em definir a solução técnica para nossas histórias antes de colocarmos nossas estimativas no Planning Poker. Ele se recusa a estimar se não tem uma idéia aproximada da solução técnica acordada (o que parece razoável, certo?).

O problema é que nossas sessões de estimativa demoram uma eternidade para terminar !! Na sua experiência, como você lida com esse tipo de personalidade ao jogar o poker de planejamento?

Ele parece gostar de que as coisas sejam definidas formalmente, então um cronômetro seria uma boa idéia, já que o planejamento do poker é definido como um período de tempo definido para as pessoas falarem.

Ele também tem a ideia errada sobre estimativa, todo mundo avalia contra a história e não a implementação , e é por isso que você obtém essa variação. Por exemplo, algumas pessoas podem desconhecer uma estrutura ou uma solução pronta para uso e começar a escrever as coisas do zero.

Seu membro da equipe parece uma personalidade de analista. Os analistas precisam de muitas informações para tomar uma decisão. A idéia do cronômetro é a melhor, mas lembre-se de que ele vai se esquivar de tudo o que der. Trabalhe com ele para explicar que é apenas uma estimativa inicial baseada no problema, NÃO na solução. Se ele quiser fazer perguntas, peça a ele que mantenha o problema e não a solução. Você pode ter que cortá-lo ou incomodá-lo por algum tempo, quando ele fica à deriva para soluções.

Certifique-se de manter os outros membros da equipe nas mesmas regras, para que ele não se sinta destacado. Os analistas são uma personalidade comum na programação, então você pode muito bem encontrar outros como ele.

Parece que seu colega não entende a diferença entre estimativa e comprometimento ou não foi comunicado a ele durante o treinamento. E, como você tentou anexar o problema à personalidade dele, é possível que toda a sua equipe ainda não o entenda. (Mas não se preocupe! A maior parte do nosso setor não entende. Agile é difícil!)

Quando dizemos que o tamanho de uma história é X pontos, na verdade queremos dizer uma distribuição de probabilidade. Se nossas estimativas estiverem corretas, a história deve demorar mais de 50% do tempo (e os outros 50% levarão menos tempo). Se o seu colega acreditar que, depois de decorridas X unidades de tempo, ele será solicitado a demonstrar a história ou isso mudará sua abordagem de estimativa.

O planejamento do pôquer introduz outro erro: em vez de tentar determinar o X, nós o igualamos em uma escala discreta, sendo a escala de Fibonacci (1, 2, 3, 5, 8, etc.) a mais popular. Está dizendo que o tamanho não é tanto quanto o que é. Quando dizemos que o tamanho da história é 3 pontos, realmente dizemos "é X mais-menos alguma variação e X está mais próximo de 3 do que de 2 ou 5".

Sua equipe pode se beneficiar ao entender quão impreciso é este exercício e como a estimativa difere do comprometimento. Se você deseja / precisa estudar esses conceitos em profundidade, este livro possui isso.

Eu posso ver de onde vem o membro da sua equipe, mas ele claramente não entendeu completamente o conceito de Agile and Planning Poker. Você deve começar se certificando de que todos entendam os conceitos e o raciocínio por trás deles e, em seguida, eles devem fazer o que querem por si mesmos.

Para as equipes com as quais trabalho, no início de cada sessão de planejamento, defino um cronômetro de areia de 3 minutos sobre a mesa. Informei a equipe inteira que, a qualquer momento, eles sentem que a conversa está se tornando um mergulho profundo, ou irrelevante, ou de qualquer outra forma, está indo além do que eles acham necessário para estimar a história em pontos da história, então qualquer pessoa da equipe pode virar o cronômetro. Quando a areia acabar, a equipe estima imediatamente.

Esse método permite que todos os indivíduos da equipe limitem a conversa, quando sentem que a conversa não é mais útil para estimar a história que está sendo discutida. Ao mesmo tempo, ele não interrompe imediatamente a conversa, mas fornece a todos uma indicação visual de que a conversa precisa ser encerrada nos próximos minutos, porque vamos votar.

Outra ferramenta que eu uso para ajudar a manter as sessões de planejamento focadas é garantir que todos na equipe revisem as histórias no topo da lista de pendências pelo menos alguns dias antes do planejamento. A idéia é que, se você tiver uma lista de perguntas imediatamente após a leitura das histórias, poderá informar o proprietário do produto sobre as possíveis questões vários dias antes, para que eles possam esclarecer a história ou a crítica de aceitação para, com sorte, limitar a discussão posterior. Isso também permite que as pessoas comecem a pensar no design potencial da história, antes de estarem planejando (e tentando projetar durante o planejamento).