Velocidade, Capacidade e Produtividade
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Este texto examina como a produtividade deveria ser medida em projetos ágeis de desenvolvimento de software e sua relação com a capacidade do time.
Concordo com a perspectiva de que velocidade não é produtividade. Devemos ser cautelosos ao aplicar métricas de desempenho, particularmente medidas de produtividade e avaliações de capacidade.
O Problema da Correção de Bugs
Se capacidade é igual a produtividade, como os times devem contabilizar o trabalho de correção de bugs? Essas tarefas não adicionam novo valor de negócio — elas restauram funcionalidades que foram prometidas anteriormente. No entanto, os times despendem esforço real nelas, tornando essas estimativas cruciais tanto para cálculos de velocidade quanto para planejamento de capacidade.
Medidas Alternativas de Produtividade
A abordagem de Simon sugere medir a produtividade através de resultados de negócio em vez de saída: receita gerada por iteração por unidade de estimativa de história. Martin Fowler contrapõe que uma avaliação significativa de produtividade pode levar anos após o lançamento.
O Framework de Definição de Metas
Se um time não tem uma meta, como poderia perseguir seus objetivos?
Times precisam de metas claramente definidas para guiar decisões de desenvolvimento e possibilitar retrospectivas significativas. Embora o pensamento sistêmico mais amplo seja importante, times precisam de alvos específicos que possam controlar e influenciar.
O Limite da Medição
Times devem medir o sucesso no ponto de aceitação da história — quando o trabalho que entrega valor de negócio é concluído. Além desse ponto, fatores externos de negócio fora do controle do time determinam o impacto real na receita. Times só podem otimizar e adaptar seu desempenho até esse limite.