A habilidade individual deve ser considerada nos pontos da história?

Meu entendimento da estimativa de histórias é que se deve estimar o tamanho de uma história como seria para um desenvolvedor imaginário e médio - um pouco como o conceito de "espectador razoável" na lei. Ou seja, você não deve estimar o tamanho da história, supondo que você precise fazer isso .

Para dar um exemplo: no meu trabalho anterior, eu fazia parte de uma equipe onde eu era, de longe, o desenvolvedor Ruby mais confiante. Meus colegas de equipe costumavam estimar histórias relacionadas ao Ruby muito maiores do que eu, com argumentos como "Bem, eu não sei como o X funciona no Ruby, então isso levaria muito tempo para ser feito".

Meu argumento contra isso vem do fato de que o planejamento do sprint é onde a capacidade da equipe entra em jogo. Esse é o fórum correto para dizer: "Nossa capacidade neste sprint será um pouco menor que o normal, porque a maioria das tarefas é baseada em Ruby e temos apenas um desenvolvedor Ruby forte". Considerar isso durante a estimativa duplicaria esse aspecto.

Eu apreciaria qualquer referência autorizada nas respostas, mas opiniões simples também seriam ótimas.

Os pontos da história são uma estimativa relativa. Então, o dobro dos pontos significa o dobro do nível de esforço. As estimativas relativas estão menos sujeitas a variações no nível de habilidade. A questão não é quanto tempo você levaria para 1 ponto, mas que 2 pontos requerem um esforço potencial duas vezes maior. O nível de habilidade pode importar mais se você levar dias ideais em vez de contar histórias, porque você assume um nível de produtividade individual.

As estimativas relativas são mais robustas. Além disso, a avaliação do ponto da história não deve ser realizada por um indivíduo, mas resultar de um esforço coletivo da equipe . Para histórias menos complexas, geralmente há um acordo rápido. Para histórias mais desafiadoras, a equipe apresentará um resultado com o qual a maioria dos membros concordará e, portanto, levará em consideração implicitamente o nível de habilidade coletiva da equipe.

Por fim, a avaliação da história é realizada no momento em que as tarefas dentro da equipe ainda não estão necessariamente decididas. Este é mais um argumento para não levar em consideração o nível de habilidade individual. Para o planejamento do sprint, você terá a capacidade de ponto da história da equipe, que é uma figura que evoluirá com base nos números reais de desempenho, para que ela se ajuste automaticamente ao nível de habilidade global da sua equipe.

Em conclusão, a capacidade individual não deve ser levada em consideração para a estimativa. Mas mesmo que isso fosse feito, devido às estimativas coletivas e à robustez da abordagem relativa, isso não importaria tanto.

A resposta canônica é que você não deve alterar as estimativas por desenvolvedor. Isso significaria que você obtém muito mais pontos por sprint do que seus colegas, e isso é bom porque os pontos medem a velocidade da equipe , não os desenvolvedores. Os negócios podem estimar quanto a equipe produzirá para obter expectativas aproximadas de entrega, e tudo está ótimo.

No entanto, isso causa todos os tipos de problemas na prática. O que acontece se você estiver de férias nessa semana? O que acontece quando o tempo de revisão chega e você percebe que está produzindo 200% dos pontos médios da história e 110% do salário médio? O que acontece quando os negócios começam a pensar que a velocidade da equipe dividida por pessoas é realmente uma aproximação precisa? O que acontece quando os negócios percebem que você está produzindo muito mais bugs do que seus pares (enquanto ignora você produz muito mais funcionalidades)? O que constitui histórias de "tamanho pequeno" quando as pessoas têm mordidas tão variadas?

O que descobri ao longo da minha carreira é que isso não importa muito. O processo existe para atendê-lo, não vice-versa. Se sua organização precisar avaliar se os desenvolvedores estão sobrecarregados, os pontos de história por desenvolvedor são uma boa solução. Se sua organização precisar avaliar a velocidade da equipe, os pontos da história do desenvolvedor independente fornecerão uma imagem mais clara. No entanto, eles sempre são uma aproximação e sempre serão abusados ​​e mal interpretados.

No final, eles são pontos compensados ​​para um processo inventado que você precisa adaptar ao seu ambiente.

TL; DR
Devemos sempre assumir que apenas desenvolvedores competentes serão atribuídos a uma história específica.

Competência (ou falta dela) não é um insulto. É simplesmente uma medida razoável das habilidades de um desenvolvedor que não está atrasado nem é excepcionalmente experiente.

Isso pode ser uma questão de abordagem de uma empresa específica. Vi empresas adaptarem estimativas para desenvolvedores específicos. Também vi empresas que aplicaram um sistema em que três desenvolvedores selecionados aleatoriamente fazem estimativas de histórias antes de designar quase aleatoriamente um desenvolvedor (não um dos três iniciais) para a tarefa.

Todo sistema pode funcionar, todo sistema pode falhar. A questão não é tanto qual sistema é melhor, mas com quais falhas a empresa é capaz / disposta a lidar .

Em princípio, o tempo de estudo para dominar o idioma / estrutura não deve ser incluído. Tangente menor: embora não devam existir em um mundo ideal, deve-se incluir o tempo de estudo para obstáculos específicos do projeto ou da história.

Há muitas justificativas para fazer isso, mas acredito que essa abordagem geralmente é uma escolha melhor, porque permanece fiel à intenção de estimar uma carga de trabalho. Isso pode ser apenas uma questão de minha opinião, e não objetividade. Eu não posso dizer com certeza.

O tempo de estudo é pessoal . Está no escopo de um desenvolvedor em particular que precisa trabalhar em uma tecnologia específica. Não é relevante ao avaliar a carga de trabalho de uma história de usuário, pois ela só está no escopo do aplicativo (e na tecnologia que ele usa).

O tempo de estudo geralmente não se compara. Digamos que nosso novato saiba pouco sobre C # e estimamos que ele precise de três dias extras para descobrir o ambiente antes de poder fazer o trabalho. Como é comum em muitas empresas em que trabalhei, agora estamos em uma reunião em que devemos estimar várias histórias de usuários (individualmente). Por uma questão de exemplo, digamos que temos três histórias para enfrentar.

• Adicionamos três dias a cada história? Se todas as três histórias tiverem um foco técnico semelhante, isso significa que o novato não precisará de tempo extra na segunda e na terceira história. Superestimamos o trabalho em seis dias.
• Adicionamos um dia a cada história? Isso também não está correto. Se acabarmos atribuindo o novato a uma de três histórias, então o enganamos dois dias necessários para estudar; e concedemos dois dias desnecessários de tempo de estudo a outros desenvolvedores.
• Adicionamos três dias a uma história? Como podemos garantir que essa história será tratada antes das outras duas? O objetivo de criar histórias de usuário separadas é que as histórias geralmente podem ser abordadas independentemente uma da outra. A correção de nossa estimativa agora depende da suposição de que nosso novato fará o trabalho, além da ordem em que ele recebe essas tarefas (se isso importa, por exemplo, se a carga de trabalho combinada ultrapassar um único sprint).

Nota :
Há outros casos em que o tempo de estudo se acumula, por exemplo, se as três histórias estiverem sobre tópicos muito diferentes e exigirem habilidades diferentes.
Mas, para descobrir se é esse o caso ou não, precisaríamos examinar as três histórias ao mesmo tempo, o que lentamente começa a violar o princípio de ter histórias de usuários independentes . Se tivéssemos abordado essas estimativas em reuniões separadas, possivelmente com diferentes desenvolvedores presentes; não poderíamos avaliar com precisão a sobreposição entre as histórias.

Como não podemos garantir quais histórias realmente serão exibidas (o cliente pode recusar uma estimativa grande) e quem será atribuído a elas, é inútil tentar explicar que um desenvolvedor específico seja atribuído a uma história específica. Só acaba confundindo a água.

Em vez disso, devemos fazer uma estimativa da carga de trabalho, assumindo que o novato já foi atualizado (e, portanto, é um desenvolvedor igual aos colegas de trabalho).
Essa estimativa é independente do desenvolvedor e, portanto, a exatidão da estimativa não varia, dependendo de qual desenvolvedor acaba sendo atribuído à história.

Nota
Ainda é relevante reconhecer que um desenvolvedor em particular pode precisar de mais tempo para estudar antes de poder abordar uma história específica. Essa ainda é uma consideração muito relevante. Mas essa consideração não deve ser anexada à história , mas sim à atribuição desse desenvolvedor em particular a essa história em particular.

Mas, como comecei, isso pode variar de empresa para empresa. Algumas empresas podem não ser tão preocupadas com o tempo de estudo (por exemplo, se o desenvolvedor inevitavelmente precisar aprender a usar a tecnologia). Outros podem confiar fortemente na precisão dessas estimativas, pois influencia o faturamento para um cliente.

No final, é uma questão de escolher seu veneno. Não é garantido que nenhuma dessas abordagens seja mais precisa que as outras.

Este é um tópico complexo e há debates frequentes sobre o assunto. Não gosto do conceito de opinião "canônica" sobre isso: existem várias opiniões com valor. Mas existem valores, princípios e práticas de apoio que devem orientar a abordagem.

O seguinte é baseado em minhas próprias opiniões, trabalhando com equipes de scrum por mais de 10 anos. Mas é apenas a minha opinião.

1. Pontos da história como um método de previsão O objetivo original dos pontos da história era encontrar um método rápido para estimar o esforço com o objetivo de prever o que uma equipe pode concluir durante um período de tempo. Alguns dos "luminares" afirmam que os pontos são usados ​​apenas para prever o escopo de longo prazo (em uma liberação, por exemplo), e não para determinar a capacidade no nível do sprint. Além disso, o conceito é que as equipes estão aplicando o "dimensionamento relativo" com base em valores históricos (o esforço X é semelhante ao esforço B, que foi de 3 pontos). Isso acelera o processo de estimativa, para que as equipes não precisem dividir o trabalho futuro em pacotes de trabalho detalhados e aplicar horas a todas as tarefas. As equipes de alto desempenho se esforçam para transformar todos os trabalhadores técnicos em membros muito competentes de níveis de habilidade semelhantes. (Este conceito será explorado mais no ponto 4). Quando isso for alcançado, o nível de habilidade individual não será realmente uma variável no dimensionamento. MAS: Geralmente, leva muito tempo e esforço conjunto para atingir esse objetivo. Então ... o que fazemos antes de chegarmos lá?

2. As horas de tarefa determinam a capacidade de sprint: de acordo com os mesmos "luminares" que afirmam que os pontos são usados ​​para previsões de longo prazo, eles também propõem que as horas de tarefa sejam usadas para determinar a capacidade de sprint, em vez de pontos. Na minha opinião, tudo bem, mas direi que, quando ajudei a treinar equipes para "Alto Desempenho", suas habilidades niveladas atingiram uma média de onde eles poderiam determinar com precisão o que poderiam concluir em um sprint usando apenas Story Points . Novamente, esse pode ser um objetivo pelo qual nos esforçamos, mas as equipes mais novas não estão prontas para isso. Portanto, você pode encontrar em uma única corrida uma história com 2 pontos com 12 horas de trabalho e outra com 25 horas de esforço. Então, o que você faz? Algumas pessoas que chamo de "ágeis-puristas" afirmam que o tamanho da história (em pontos) deve ser agnóstico em relação à duração. Outros discordam. Leia a lógica do item 3 e veja o que você pensa.

3. Apontar histórias por consenso: aplicar volume, incógnitas, complexidade e conhecimento

Portanto, as equipes analisam um trabalho e precisam concordar com os pontos que servirão de proxy para o Nível de Esforço. Certo? Supondo que todas as habilidades sejam iguais, é fácil chegar a um consenso. Mas muitas vezes as equipes têm um cara que é um guru de Java, outro que não é tão bom em Java (talvez ela fosse uma pessoa em C # ou .Net ou Cobol e esteja aprendendo Java). Portanto, a tarefa X para Bob é muito simples. Para Jane, é mais difícil.

As equipes ágeis tentam promover a propriedade coletiva do código e o crescente / crescente conhecimento. Portanto, geralmente não atribuímos histórias às pessoas com base em seus conhecimentos: preferimos que as equipes trabalhem coletivamente nas histórias e aprendam juntas. Isso está alinhado com o conceito de "desacelerar para acelerar": se dedicarmos um tempo para dar a Jane experiência com Java, enquanto isso pode nos atrasar a princípio, mais tarde teremos desenvolvedores Java mais competentes. De fato, se tivermos apenas UM especialista em Java e todos trabalharem em suas próprias áreas de especialização, estamos criando uma situação com vários "pontos de falha" potenciais. O que acontece no sprint quando 90% do trabalho é Java, mas Bob (nosso especialista em Java) está doente ou de férias? Ao expandir as habilidades, eliminamos possíveis gargalos e reduzimos os riscos. Com aquilo em mente: Quando a equipe examina uma história, eles devem ter vários conceitos em mente ao dimensionar. Você pode pensar no acrônimo VUCK para lembrar disso.

Volume: alguns esforços são bastante simples, mas exigem um grande volume de tarefas repetidas. (Eu tinha um cara que tinha que copiar e reformatar mais de 50 tabelas e disse que era 1 ponto porque era simples. Mas, após a reflexão, a equipe percebeu que, embora fosse fácil, consumia tempo e havia um grande volume de tabelas para otimizados, tivemos que reajustar os pontos devido ao volume de trabalho)

Desconhecidos: Às vezes, pensamos que sabemos o que fazer, mas também identificamos alguns desconhecidos - eles representam RISCOS . E isso implica que podemos encontrar problemas inesperados que precisamos resolver, reprojetar ou tentar uma solução diferente.

Complexidade: Este é bastante óbvio. Algumas soluções são tecnicamente complexas. Sabemos exatamente o que fazer, mas isso requer conhecimento técnico. Complexidade também implica algum risco, não é? Portanto, mesmo se todos tivermos habilidades iguais, a complexidade técnica implica que podemos enfrentar desafios imprevistos. Então, podemos tornar essa história maior.

Conhecimento: REALMENTE sabemos o que estamos resolvendo? Às vezes, os clientes não são totalmente claros sobre a solução que desejam, e estamos experimentando um pouco. Ou talvez ninguém nunca tenha implementado essa solução (nova tecnologia nunca usada antes) e, portanto, não sabemos o que não sabemos.

Na minha opinião, cada uma dessas considerações é na verdade um proxy por um período prolongado. História fácil, muito volume? Vai levar mais tempo, ou precisamos dividir a história. Desconhecidos? Adicionado risco, pesquisa, experimentação, pode levar mais tempo ou precisamos dividir a história. Complexo? Risco adicional, necessidade de corrigir bugs, reprojetar etc., para que possa levar mais tempo. Não sei se temos o conhecimento necessário? Temos riscos adicionais, talvez seja necessário experimentar etc., por isso pode levar mais tempo ...

Veja onde isso está indo? Portanto, embora o conceito de pontos da história nos desencoraje a pensar em duração ao estimar, por outro lado, seria ilógico ter uma história de 1 ponto que possamos concluir em 4 horas e outra história de 1 ponto que seja simples, mas exigirá 2 semanas.

4. As equipes de alto desempenho eliminam os silos e os gargalos: como as equipes tentam aumentar o nível de todos os membros, às vezes eles têm menos experiência em enfrentar novos desafios ou emparelham códigos para compartilhar conhecimentos para melhorar como equipe. Como mencionado anteriormente, este é um requisito para que a equipe atinja níveis reais de alto desempenho.

Portanto, se Jane se voluntaria para assumir esse esforço de Java e isso faria o esforço 2x ou 3x a duração do mesmo esforço se Bob fizesse isso, o que você faz? Com o tempo, minhas equipes decidiram dimensionar histórias com base no nível de esforço (LOE) / VUCK para as pessoas que trabalham no esforço. Não faz sentido para Bob, o time Guru, dizer "esse é um 1", quando para Jane não será fácil e levará uma semana para ser concluído, além de exigir um pouco do tempo de Bob para codificação e revisão de código em pares. Portanto, aumentamos esses pontos para refletir o verdadeiro LOE. Na próxima vez que uma história semelhante veio, o que era 8 para Jane se tornou um 5. Eventualmente, todos concordaram que era um 3. Fácil. Nesse ponto, sabíamos que estávamos crescendo como uma equipe.

TLDR

Não, mas talvez não pelo motivo que você pensa.

Versão longa

Muitas das outras respostas explicaram que os Story Points devem ser calculados puramente em relação a outros trabalhos. Isto é absolutamente verdade. Como os Story Points estimam a quantidade de trabalho e não o tempo necessário para concluí-lo, faz pouco sentido atribuir Story Points com base em um indivíduo.

Por exemplo (um dos meus favoritos), considere sua tarefa "Cavar um buraco". Você pode estimar isso com base na quantidade de terra a ser removida ou no tempo que levará para remover a terra. Meu amigo escava um todo a uma taxa de 3 metros por hora, eu tenho uma escavadeira mecânica grande para poder gerenciar 100! A única constante é a quantidade de terra - portanto, é isso que usamos como nossa unidade de estimativa.

No entanto, uma segunda (e na minha opinião mais importante) razão para descontar a capacidade do desenvolvedor de estimar histórias de usuários é o fato de que quase todas as histórias de usuários provavelmente serão trabalhadas por várias pessoas.

Você pode ter um arquiteto, um desenvolvedor, um testador, talvez um segundo desenvolvedor para fazer a interface do usuário. Antes de sua história de usuário ser marcada como Concluída (idealmente implantada e concluída), muitas pessoas diferentes terão trabalhado nela. De repente, a ideia de estimar com base no desenvolvedor em questão faz muito pouco sentido, a única maneira de estimar com precisão quanto esforço será envolvido pela equipe é medir a velocidade das equipes e estimar o trabalho a ser concluído.

Não existe um "eu" na equipe e absolutamente nenhum eu no planejamento ágil!