É correto avaliar os membros do Scrum de acordo com o número de histórias de usuários concluídas?

Quando meu gerente disse à equipe que " agora em diante as histórias de usuários bem-sucedidas serão consideradas para avaliação! "

Ficamos ali por um tempo chocados e esse foi um dos vários momentos de queixo caído que ele nos deu :-)

Achamos que era uma idéia estúpida, pois isso arruinaria todo conceito e objetivo da metodologia de desenvolvimento ágil.

Deixe-me saber o que vocês acham? e como podemos convencê-lo?

Sandy, infelizmente, a afirmação do seu gerente é um equívoco clássico do scrum em particular e ágil em geral.

A abordagem proposta mata a colaboração e contraria o princípio da propriedade coletiva do código . As histórias de usuário no ágil (se é realmente um ágil) raramente são concluídas antes de serem tocadas por várias pessoas. Além disso, você terá histórias de usuário de tempos em tempos que precisam de enxame para serem concluídas na iteração. Como vocês conseguirão isso quando os incentivos individuais estiverem alinhados 180 graus na direção oposta?

Os instintos de sua equipe estão corretos. Que fontes eu sugeriria a curto prazo para você ler ao refletir a resposta ao seu gerente? Veja blogs de renomados especialistas em agile como Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby e vários outros e procure artigos sobre organização de equipes ágeis.

Minha principal objeção a esse método de avaliação é que ele pode ser um obstáculo à cooperação entre desenvolvedores. Eu acho que uma parte importante da produtividade de uma equipe de desenvolvimento é a disposição dos membros da equipe em se ajudarem. Pelo que entendi, o esquema sugerido pode levar os desenvolvedores a manter suas próprias tarefas atribuídas e a ignorar outros membros da equipe que estão presos e que podem facilmente ser desatados por uma pequena assistência.

Estamos sempre buscando a contribuição do programador para a equipe e os negócios.

Isso equivale a medir linhas de código ou número de bugs - mas um pouco mais sofisticado.

À primeira vista, não há nada errado com a medição, mas quando você pensa sobre isso, começa a levantar objeções:

• e as histórias mais complicadas?

é o mais óbvio que vem à mente - tenho certeza de que existem outros.

Seu gerente obviamente pensa que é uma boa ideia, portanto, você deve tomar cuidado para que, quando levantar objeções, também possa apresentar soluções. Essa solução pode ter que ser uma modificação no esquema dele, e não um novo esquema.

Assim, por exemplo, você pode apontar que alguém que trabalha apenas em histórias "fáceis" completará mais do que alguém que trabalha em uma história mais "difícil" e isso pode levar a uma concentração nos aspectos menos importantes do desenvolvimento. Portanto, uma solução pode ser considerar o número de pontos da história em vez de apenas o número de histórias.

Concordo com ChrisF que isso remonta ao mesmo problema com qualquer medida. O que você elogia é o que recebe. Sempre haverá pessoas que jogam no sistema, qualquer que seja o sistema.

O único método realmente eficaz que encontrei para recompensar os programadores vem com três etapas.

1. Os líderes conhecem e compreendem as habilidades das pessoas em sua equipe.
2. Os gerentes ouvem as recomendações dos leads para os membros da equipe que não estão se esforçando.
3. A equipe é elogiada como um todo por sprints de sucesso.

O segredo é que os programadores não são engrenagens de uma máquina que pode ser "ajustada" observando as estatísticas. As pessoas reais precisam ser examinadas e aprimoradas como um todo e a equipe precisa poder confiar umas nas outras de maneira cooperativa e não competitiva.

Os fracos artistas da equipe têm todas as oportunidades de aprimoramento e enriquecimento antes de serem considerados desapontados. Por fim, bons programadores prosperarão nesse ambiente e os pobres, que se recusam a melhorar, serão deixados de lado.

Na maioria das vezes, as histórias de usuários são concluídas em um esforço coletivo. Isso torna praticamente impossível basear a avaliação individual nessa métrica.

A métrica em si pode ser facilmente manipulada, pois o processo de planejamento também é um esforço de equipe e, mais cedo ou mais tarde, todo o sistema é manipulado. Definitivamente, é isso que você não quer em um processo focado nas pessoas.

Acho que o bom desempenho deve ser reconhecido por algum tipo de sistema de bônus com base no sucesso da equipe, mas as Histórias de usuários não são um bom indicador de sucesso.