BT

Medir Hiper-Produtividade é Perda de Tempo?

por Vikas Hazrati , traduzido por Fábio Rehm em 12 Jun 2009 |

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.

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 menssagens dessa discussão

Medir Hiper-Produtividade é Perda de Tempo? by Ubiratan Padilha

Concordo 100% com o que disse Roy Morien ("...é muito difícil medir a produtividade pessoal ou de um time matematicamente. Por isso, times devem focar em entregar software que tenha alguma utilidade...")

Ubiratan Padilha
Project Manager, CSM, Especialista em Usabilidade
www.linkedin.com/in/ubiratanpadilha
twitter.com/ubiratanpadilha

Medir porque? by Felipe Rodrigues

Medir a produtividade da equipe para que? Essa é a verdadeira pergunta. Se for apenas para saber se o time está realmente sendo produtivo, me lembra muito a gestão comando-controle.

Processos ágeis são baseados em confiança. Isso inclui a confiança de que todos estão dando o máximo de si no projeto. Ou seja, todos sempre são tão produtivos quanto possível. Essa deve ser a idéia original.

Então, o que deve ser mensurado? Qual q quantidade de obstáculos a equipe teve. Isso é mais fácil de mensurar, através dos impedimentos. A equipe produzirá menos, quando tiver mais impedimentos. Isso sim seria ágil.

Re: Medir porque? by Ubiratan Padilha

Olá, Felipe.

Vou fazer a vez do "advogado do diabo": não precisamos conhecer a produtividade da equipe para definir o que entra na Sprint?

Re: Medir porque? by Felipe Rodrigues

Não precisa conhecer a produtividade, mas sim a velocidade do time. Essa velocidade pode ser baseada em dados históricos e não precisa ser medida individualmente.

A diferença é que a velocidade não diz se o time está sendo tão produtivo o quanto poderia ser, apenas diz qual é a quantidade média de unidades de medida (pontos ou qq outra) que o time entrega por sprint.

Ex: Um time de velocidade média de 100 pontos, talvez ainda não esteja no máximo de sua produtividade, pois é possível que, so impedimentos consomem 50 pontos em média por sprint. Se essa equipe focar nos impedimentos, aí sim, saberão que podem aumentar sua produtividade em 50%.

Re: Medir porque? by Ubiratan Padilha

Seguindo seu exemplo, Felipe, se a velocidade do time são 100 pontos e os impedimentos estão consumindo 40 pontos, logo a produtividade neste caso é de 60 pontos. E a velocidade, por conta desta produtividade, será também de 60 pontos.

Ou seja, ok que a velocidade do time é de 100 pontos. Mas se a produtividade é 60, a velocidade naquele momento também será de 60. Então, vejo que a produtividade é um fator importante para conhecer a velocidade do time num determinado momento.

Re: Medir porque? by Felipe Rodrigues

A velocidade não conta com os impedimentos. O tempo perdido com impedimentos é irrecuperável. A velocidade é igual à quantidade de pontos entregues. Se são 10 pontos, significa que mesmo com o tempo perdido com os impedimentos, foram entregues 100 pontos. Se não fossem perdidos 40 pontos com impeidmentos, a entrega seria de 140 pontos e nào de 100 pontos.

Isso nào quer dizer que a produtividade é de 60 pontos. Na verdade, talvez para entregar esses 100 pontos a equipe não se esforçou. Ou talvez a equipe tenha se esforçado além do limite. Pois a velocidade não mede esforço.

Um exemplo:
Um time que entregou 100 pontos em uma semana, porém trabalhando 9 horas por dia é menos produtivo que um time que entregou 100 pontos em uma semana trabalhando 8 horas por dia.

Produtividade != velocidade - impedimentos

Re: Medir porque? by Ubiratan Padilha

Felipe, seguindo a fórmula que você utilizou (Produtividade = velocidade -impedimentos), os números que utilizei no meu comentário anterior estão corretos: Produtividade (x) = velocidade (100) - impedimento (40). Logo, Produtividade = 60. Sendo assim, fiquei na dúvida com relação ao que você questionou (..."isso não quer dizer que a produtividade é de 60 pontos..."). Seguindo seu raciocínio, penso que na fórmula deveríamos incluir também o fator "esforço".

Re: Medir porque? by Felipe Rodrigues

Eu disse que Produtividade é diferente (!=) e não igual (=). É um operador comum em linguages de programação. Deveria ter usado <> no lugar de !=.
=)<>

Re: Medir porque? by Ubiratan Padilha

Ok, Felipe, rsrs... Desculpe, eu não prestei atenção no sinal...

Bom, vamos lá. Qual é a fórmula da Produtividade?

Re: Medir porque? by Felipe Rodrigues

Tudo bem... =)

Bom, não sei qual seria a fórmula mais apropriada. Também acredito que seja impossível medir corretamente a produtividade.

Meu ponto de vista é similar ao (e influenciado pelo) proposto pela TOC. Não adianta medir a produtividade individual e local, visto que são números enganosos. O ideal é identificar o gargalo e tentar alinhar o sistema ao gargalo e finalmente elevar o sistema como um todo.

No meu ponto de vista, o gargalo são os impedimentos. Identificando quanto tempo se gasta com os impedimentos, alinhando o sistema para que se consiga medir o quanto é feito mesmo com estes impedimentos e finalmente, removendo os impedimentos para elevar o sistema é o caminho mais apropriado. Por isso falei que o mais interessante é medir a velocidade e não a produtividade.

Não consigo imaginar quais seriam as bases, ou unidade, para se medir a produtividade. Horas ativas? Pontos realizados por hora?

Acho que teria que incluir várias variáveis para criar uma fórmula que serviria somente para uma situação, não sendo aplicável a todos os ambientes e equipes, devido ao grande número de fatores que influenciam. Exemplos do que deveria ser levado em consideração é o esforço, a complexidade de cada ponto, os pares, a velocidade da rede, o momento do projeto, etc...

Mas esse é só meu ponto de vista. =)

Re: Medir porque? by Ubiratan Padilha

E a fórmula da velocidade, qual seria e como é obtido o resultado?

Re: Medir porque? by Felipe Rodrigues

A velocidade é a média de pontos entregues por sprint. Pode-se fazer ae por dia, mas acho que é uma unidade muito pequena e, por isso, está sujeita a muita interferência.



A velocidade pode ser medida também, levando em conideração a complexidade entregue. Por exemplo:



São entregues em média 100 pontos por sprint. Para isso basta somar os pontos reais de cada user story de um sprint.



Dos 100 pontos entregues, a complexidade média é de 60. Complexidade é um número abstrato, por isso, depende muito de como esse número é usado em sua equipe e se ele é usado.



Se em um sprint você entregou 100 pontos de complexidade 60 e em outro entregou 90 pontos de complexidade 80, significa que você foi mais rápido no segundo sprint.



Como identificar o gargalo? Rastreando quantos pontos foram gastos para remover impedimentos. Por exemplo:



Se 1 ponto = 1 hora, uma equipe de 10 pessoas pode entregar 80 pontos por dia, 400 pontos por semana. Se essa equipe entregar apenas 200 pontos, significa que, ou estimou errado (comum nos primeiros sprints) ou gastou os pontos em outras atividades, como remoção de impedimentos por exemplo. Nesse caso, identificar onde foram gastos esses pontos é identificar o gargalo. Se não houver gargalo, significa que a entrega por iteração seria infinita.




Lições da TOC.

Re: Medir porque? by Ubiratan Padilha

Se produtividade é a qualidade de produtivo e produtivo é o adjetivo que indica que alguém ou algo produz, enxergo ainda que a fórmula é: Produtividade = velocidade - impedimento. Exemplo: Velocidade 100 - 40 de impedimento. Produtividade = 60. Considero impedimento neste caso tudo que pode retardar a velocidade (política e cultura organizacional, infra-estrutura...)

Produtividade: é a relação entre a quantidade final produzida e a quantidade de trabalho necessária para gerá-la.

Velocidade: é o quanto eu posso produzir, desconsiderando os impedimentos.

Normalmente quando as pessoas querem saber qual a taxa de produtividade de um time, no fundo elas querem saber qual a velocidade de entrega daquele time. Pra muitos inclusive, estes 2 termos são sinônimos. No final, na visão do cliente, o que vale é o quanto eu consigo entregar num determinado cenário. O que adianta dizer pra ele que a minha velocidade é de 100, mas no cenário dele a minha produtividade é de 40. Pra ele, 40 será a velocidade (de entrega).

Estou tentando aqui exercitar o pensamento da aplicabilidade destes conceitos junto às empresas. :)

Re: Medir porque? by Felipe Rodrigues

Você pensou nesta fórmula porque não entendeu a relação entre velocidade e impedimentos. Velocidade é o que a equipe entregou realmente, já descontados os impedimentos. Dessa forma, não há razão ou lógica em subtrair os impedimentos da velocidade, já que eles impediram que o time fosse mais veloz.

Re: Medir porque? by Ubiratan Padilha

Felipe, discordo do seu conceito de velocidade. Pra mim velocidade = capacidade de produzir algo medido numa determinada escala de tempo. Esta capacidade - impedimentos = produtividade.

Se considerarmos, como você disse acima, que velocidade é o que a equipe entregou, já descontados os impedimentos, qual o significado, então, do termo produtividade?

Re: Medir porque? by Felipe Rodrigues

Exatamente o que tenho tentado explicar. Por considerar como eu descrevi acima, não vejo qual o valor de medir "produtividade".

PS: Capacidade de produzir algo medido num determinado espaço de tempo = velocidade máxima possível.

Aquilo que a equipe conseguiu entregar de fato = velocidade real da equipe.

Não se mede nada pela velocidade máxima possível, apenas pela velocidade real. Baseado na velocidade real você pode projetar os próximos sprints com uma idéia de quanto poderá entregar. Mesmo assim, muito vagamente, pois não podemos esquecer dos cisnes negros. =)

Re: Medir Hiper-Produtividade é Perda de Tempo? by Ricardo Mitrano

Concordo 100% com o que disse Roy Morien ("...é muito difícil medir a produtividade pessoal ou de um time matematicamente. Por isso, times devem focar em entregar software que tenha alguma utilidade...")

Ubiratan Padilha
Project Manager, CSM, Especialista em Usabilidade
www.linkedin.com/in/ubiratanpadilha
twitter.com/ubiratanpadilha


Concordo.

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

Receber menssagens dessa discussão

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

Receber menssagens dessa discussão

17 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