BT

Devemos contabilizar a correção de bugs na velocidade do time?

por Vikas Hazrati , traduzido por Eder Ignatowicz em 21 Set 2011 |

Tem ocorrido diversos debates recentes sobre a decisão de contabilizar a correção de bugs na medição de velocidade de uma equipe ágil. A questão parece não possuir uma única resposta correta, contudo alguns agilistas discorrem sobre em quais casos a correção de bugs deve ser adicionada a contagem de velocidade e quando deve ser desconsiderada.

Syed Rahan, criador da ferramenta Scrumpad, sugere que a decisão de inclusão da contagem de bugs depende da forma que é caracterizada a velocidade. Se a velocidade é baseada em "perspectiva de valor", a correção de bugs não deve ser considerada, pois não adiciona valor ao cliente. Contudo, se a velocidade é baseada na "perspectiva de custo", então as correções de bugs devem ser contabilizadas pois tomam tempo e esforço (e portanto custo) para serem realizadas.

Mike Cohn recomenda que pontos de história (story points) sejam atribuídos a correções de bugs:

Esta solução une o melhor de dois mundos. É possível visualizar a quantidade de trabalho que a equipe está apta a realizar, e se pode observar os dados históricos além de visualizar quantos pontos foram gastos em correções de bugs no sprint

Jason Yip, consultor da Thoughtworks, faz uma analogia interessante quando compara a velocidade a um indicador da maneira que se avança em direção a uma meta. Yip, através de desenhos e fórmulas, enfatiza que a parte mais importante é a meta:

Imagine um cenário em que um atleta corre em direção a uma linha de chegada (meta). Se a referência temporal é um minuto, então a velocidade do atleta é a distância percorrida em direção à meta, dividida pelo tempo decorrido (veja a figura abaixo, extraída do post de Yip). A parte importante da analogia de Jason Yip é em "em direção à meta".

Jason Yip, segue seu exemplo propondo um cenário em que foram percorridos 10 metros, mas em que, por alguma razão o atleta retrocedeu 5 m. Logo após, o atleta se recupera e percorre mais 5 m. A distância total percorrida foi de 15 metros, mas o atleta está na marca de 10:

Desta forma, o autor verifica que o progresso total foi de 10 m, pois a medida é relativa ao progresso em direção a uma meta e não ao esforço despendido. Sendo assim, Yip conclui que a velocidade é um vetor e não um escalar.

Na seção de comentários do post de Jason Yip, é sugerida uma avaliação conjunta para determinar velocidade:

Eu incluiria a contagem da correção de bugs na velocidade mas gostaria de descontar esta velocidade das iterações anteriores onde o bug foi criado. Desta forma aplicaria um valor negativo nesta iteração.

Em outros comentários, é levantado que é perigoso não contabilizar a correção de bugs na medição de velocidade, pois há vários contextos em que isso não faz sentido.

Jack Milunsky, no blog Agile Software Development menciona que independentemente de ser levada em conta ou não a correção de bugs para a velocidade do time, esse trabalho deve ser considerado pois consome tempo de desenvolvimento da sua equipe.

A correção de bugs deve ser agendada em um sprint ou iteração durante o planejamento do sprint. Desta forma o tempo total para implementar as tarefas de conserto de bugs não deve exceder a capacidade de trabalho do seu time. Sei que muitos consultores argumentam que correções de bugs devem ser medidas separadamente e que bugs devem ser corrigidos durante o sprint. Mas isso nem sempre funciona na prática. Agende a correção de bugs no planejamento do sprint e você irá melhorar a estimativa do seu time significativamente.

Existe, portanto, um consenso na importância da contabilização de correções de bugs no processo de desenvolvimento. Mas considerar - ou não - essa atividade ao calcular a velocidade do time é uma questão controversa, pois a decisão depende muito do contexto no qual a equipe está inserida e da forma como a velocidade é caracterizada.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Não existe uma única resposta absoluta para esse dilema. by Guilherme Motta

A relacao de velocidade com corrida colabora para as pessoas não entenderem do que se trata velocity (NÃO é velocidade de um time!).

Na minha perspectiva, velocidade é para medir coisas que já aconteceram, independentemente se a velocidade é baseada em valor ou em custo. Na minha experiência com times e projetos ágeis, os bugs tendem a ser corrigidos em um curto espaco de tempo (são encontrados, corrigidos e re-verificados enquanto a story está "in-play"), então esta estimativa faz parte da própria story.

E bugs em producao? Bom.. daí é outra história.. tem que se considerar o tempo que o time perde para resolver este problema (que provavelmente vai consumir mais tempo do que corrigir algo que vem sendo trabalhado pelo time).

Eu acredito que pode ser interessante manter um histório de bugs (quantitativo?) para verificar eventuais impactos na velocidade (na iteracao X verificamos 9823749823 bugs e por isso não entregamos tantos pontos quanto entregamos no passado). Por outro lado, a tendência dos times ágeis é não acontecer picos altos/grandes de bugs, é mais constante e em menor número. Caso aconteca esses picos de bugs, provavelmente o processo em si possui algum bug.

Todo bug deve ser contabilizado neste histórico? Não.. apenas bugs que tiverem um valor de negócio para aplicacao (se não tem valor, não quero contabilizar nem perder meu tempo armazendo em ferramentas de bug tracking, nem poluindo relatórios, nem adicionando nos meus ciclos de regressao, nem..).

Na minha opnião, não deve ser contabilizado by Julio Faerman

Se for, quanto mais bugs mais velocidade?
Velocidade é valor, custo deve ser medido também, mas de outra forma.

Se contabilizar, volta pro cascata! :P by Elias Nogueira

Na minha visão isso depende muito do que o time quer mostrar como progresso e custo, e quanto o cliente cobra o PO em relação a isso.
Eu vejo que o ideal é contabilizar isso dentro do proprio sprint enquanto ele ainda está rodando, compatilhando da mesma visão do Guilherme.

Controlar a correção de bugs na velocidade do time, pra mim, é voltar a modelos tradicionais de desenvolvimento. :)

Se influencia a capacidade, deveria contabilizar by Vinicius Assef

Prefiro pensar em capacidade de entrega, do que em velocidade, já que não estimamos em horas, mas em story points.

Fazendo uma analogia direta, não me interessa saber quanto eu gastei mês passado, se meu orçamento continuar bagunçado esse mês. Da mesma forma, saber a capacidade de sua equipe no sprint anterior só terá utilidade se você usar essa informação para planejar o próximo sprint.

É isso que vai dizer se é possível entregar o sprint backlog. Faz com que as estimativas de capacidade passem do "eu acho que dá" para o "historicamente, temos conseguido fazer esse tanto".

Se as pessoas corrigem bugs durante o expediente (o que é recomendável), certamente afeta a capacidade de entrega do time. Entenda por time a seguinte composição: product owner, scrum master, desenvolvedor, designer, testador, infra, suporte, etc.

Um bug gera um novo cartão, certo? Um cartão deve ser estimado, certo? Se deve ser estimado, terá um esforço de trabalho para ele, certo? Se alguma coisa foi modificada, precisa ser testada, certo? Se aprovado, vai pra deploy, certo? Se rejeitada, volta o ciclo. Portanto, vai consumir tempo e esforço de uma ou mais pessoas da equipe. E isso afeta a capacidade de entrega.

A prioridade do conserto dos problemas é outra história. Sistema em produção não pode parar. Aí o product owner e o scrum master devem negociar.

Depende do que chamar de "bug" by Sergio Taborda

Não existe essa de "depende de como definir velocidade". Velocidade só tem uma definição Story Points / Sprint. O que está em causa é a definição de "bug".

Existem dois conceitos aqui, o conceito do problema que foi detectado e corrigido durante o Sprint e o conceito do problema que foi detectado ( não importa quando) e corrigido em um sprint. Ou posto de outra forma, os problemas que são corrigidos dentro do sprint em que são criados, e os que são corrigidos em um sprint diferente.

Os problemas que são identificados e corrigidos no mesmo spring são chamados bugs (sem aspas) e os que são identificados a qualquer outro momento são chamados Defeitos.
Defeitos são tipos de historias e sofrem o processo normal das historias , cotação de SP, priorização, etc... bugs não são Histórias, são tarefas, do sprint.

A velocidade será afetada por bugs. Dadas 3 historias que valem 20 pontos num sprint de 20 pontos, quanto mais bugs menos chance de terminar todas as historias. Isto vai afetar a velocidade no sentido que mais bugs impedem as historias de serem terminadas. Por consequencia isso vai afetar o fator de foco e será um issue a discutir em reunião : porque geramos tantos bugs durante o sprint ?

Mas de-se por contente se vc detectar e corrigir o problema no mesmo sprint. O pior é quando o problema é detectado depois como sendo um defeito.

Aqui a dicussão fica mais complexa, porque melhorias tabmém são caracterizadas como defeitos. Contudo, a quantidade de defeitos mostra o quanto o projeto está fora de alinhamento com a intenção do PO e por consequencia o quando de valor não está sendo colocado à piori. A quandidade de defeitos de melhoria mostra o quando o PO não é previdente e não estabelece o melhor beneficio em cada historia implementada. A quantidade de defeitos por erro de implementação mostra o quando a equipe erra ao implementar o que o PO pediu. A quantidade de defeitos não influenciam a velocidade, influencia o numero de sprints necessários para terminar o backlog.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT