BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Medir Hiper-Produtividade é Perda de Tempo?

Medir Hiper-Produtividade é Perda de Tempo?

Favoritos

Numa apresentação sobre Hiper-produtividade e Terapia de Choque, Jeff Sutherland menciona que hiper-produtividade é no mínimo o nível de desempenho da Toyota que é quatro vezes maior do que a média. De acordo com ele, times que desenvolvem software com agilidade de maneira correta notam um aumento de 300% em 3 sprints de duas semanas. Em um debate recente no Scrum Development group, membros discutiram se é proveitoso e possível medir de forma precisa produtividade entre sprints. Além disso, se é possível identificar se um time chegou ao nível de hiper-produtividade.

Adam Sroka sugeriu que é difícil, se não impossível medir produtividade entre sprints. Na maioria das vezes times avaliam o ganho de produtividade baseado em story points que não permanecem constantes entre sprints. De acordo com ele,

Story points não são necessáriamente comparáveis, embora eles pareçam convergir ao longo do tempo (por exemplo, cinco story points na iteração um provavelmente não pode ser comparado a cinco story points da iteração cinco. No entanto, cinco story points na iteração cinco provavelmente pode ser comparado a cinco story points da iteração seis.) Dessa forma, o ganho de produtividade que vemos durante um projeto ágil é falso. Percebemos ele, sabemos que ele existe, mas não temos uma forma definitiva de avaliar.

Tobias Mayer concordou com Adam quando ele disse que,

Essa "hiper-produtividade" medida é em grande parte uma perda de tempo -- e uma forma de vender uma solução para todos os problemas.. Estimativa de estórias não é algo constante; times mudam a forma de fazer isso ao longo do tempo tanto quanto melhoram a capacidade de entrega. Como foi dito por Adam, estórias complexas que aparentemente requerem o mesmo esforço na verdade vão ter sua complexidade reduzida ao longo do tempo a medida que nós melhoramos.
Eu acho que essa necessidade de mensurar a produtividade prejudica o Scrum, e como foi dito na primeira mensagem, se você define seu patamar baixo o suficiente, tudo pode parecer hiper-produtivo. E se um time não finalizar nada no sprint um? Dessa forma, finalizar o sprint dois com um story point concluído representaria um aumento de produtividade "infinito". Tudo isso é um absurdo.

Joseph Little sugeriu que apesar de ser um exagero muito do que se fala sobre hiper-produtividade, hiper-produtividade por si só faz sentido. Ele sugere que para realizar melhorias o time deve saber sua velocidade. Ele concorda que a velocidade pode mudar com as iterações e por isso devemos atribuir story points diferentes para estórias de tamanhos semelhantes no decorrer dos sprints. Para gerenciar isso devemos considerar a velocidade média em 3 sprints ao invés de apenas um. O próximo desafio deve ser dobrar essa velocidade realizando pequenas e grandes mudanças no processo de desenvolvimento de forma que os impedimentos sejam reduzidos consideravelmente. De acordo com Joseph,

Em poucas palavras: O desenvolvimento de software está tão desgastado que dobrar a produtividade de um time não seria tão difícil.

Roy Morien acrescenta que é difícil medir a produtividade pessoal ou de um time matematicamente. Por isso, ao invés de tentar medir precisamente, times devem focar em entregar software funcionando, que tenha alguma utilidade e tentar melhorar o que fizeram no último sprint.

De maneira semelhante, Adam Sroka mencionou que ao invés de perder tempo medindo a produtividade e analisando se os times alcançaram o estado de hiper-produtividade, os times deveriam focar em

  1. Será que estamos entregando software funcionando (de forma contínua) que possui algum valor para o cliente, toda as iterações?
  2. Será que estamos trabalhando de forma sustentável? Podemos continuar entregando nesse ritmo indefinidamente? Podemos melhorar?
  3. Estamos perdendo tempo com coisas que não agregam valor para o cliente? Como podemos eliminar essa perda?

 

Durante toda a discussão, a maioria dos membros do grupo sugerem que existem considerações mais importantes no desenvolvimento de software ágil do que comparar números de sprints para verificar se o estado de hiper-produtividade foi alcançado. Além disso, uma vez que não existe um padrão para a coleta de números dos sprints, compará-los é perda de tempo.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT