Desde que começamos a usar a metodologia Scrum, tenho sentido que ainda sofremos com os maus costumes do passado.
O que eu tenho visto é que ao longo do tempo fomos criando uma métrica que não deveria ser usada de forma alguma. Vou explicar….
No primeiro sprint tínhamos, por exemplo, 5 pessoas e conseguimos entregar 100 pontos de esforço num sprint de 3 semanas. A conta que foi feita inicialmente foi: (5 pessoas * 15 dias * 8 horas) / 100 pontos e chegamos a uma média de 6 homem hora por ponto de esforço.
Com essa média em mãos, planejamos nosso próximo sprint selecionando as histórias de acordo com a quantidade de pessoas que teríamos disponíveis.
No segundo sprint, conseguimos produzir bem mais que o planejado e a média caiu pra 5 homem hora por ponto de esforço, melhorando a produtividade.
Aos poucos, fomos apertando a corda no pescoço! O pior é que fizemos isso com apoio do PO e SM.
O problema é que automatizamos o Planning I, fase na qual escolhemos as histórias que deveríamos desenvolver, sem se importar com MÉDIAS anteriores. O Planning I é praticamente inútil atualmente pois o próprio PO poderia fazer esse trabalho, escolhendo as histórias que se encaixam no próximo sprint de acordo com o número de pessoas disponíveis!
Pesquisei um pouco sobre o assunto e me identifiquei muito com o que o Rodrigo Yoshima escreve nos posts Estimativa não é ciência exata e Besteirol Agile.
“As práticas do Scrum e das estimativas ágeis (Planning Poker, literatura do Mike Cohn) são muito humanistas. Não são fatores deterministas que darão a produtividade da equipe. Se alguém na equipe teve que se ausentar, está com problemas na família, está doente ou está grávida, tudo isso é levado em conta na sua velocidade e ninguém é melhor que a própria equipe para fornecer parâmetros sob essa ótica tão empírica. Não é um gerente ditador que faz a equipe engolir a métrica. A EQUIPE É RESPONSÁVEL PELA ESTIMATIVA, sob todos os aspectos. É isso que faz a métrica funcionar.”
“A resposta para a velocidade sempre é dada pela Equipe… pense na velocidade como uma tendência e não como uma certeza. Pense na velocidade como uma aplicação financeira com riscos: “rentabilidade passada não garante rentabilidade futura”.”
Recomendo a leitura dos dois posts por completo, pois ele fala exatamente desse assunto de uma forma bem divertida e objetiva!
Resolvi falar desse assunto pois já faz algum tempo que não acertamos a mão no Planning I, óbvio!
Por várias vezes percebemos que não vamos conseguir entregar tudo o que foi “estimado” e MESMO ASSIM SEGUIMOS EM FRENTE ACEITANDO A MÉTRICA CRIADA ERRONEAMENTE. Lógico que ao final do Sprint temos o desprazer de ter que empurrar várias estórias pro próximo sprint.
Fica uma sensação de que não fizemos o nosso trabalho bem feito pois não entregamos tudo e fica também uma sensação de que deveríamos trabalhar dobrado para entregar o que, na tese, a gente botou a cara a tapa pra fazer.
No sprint atual já é claro que não vamos conseguir entregar boa parte do que foi escolhido no Planning I. Eu já imaginava isso pois estamos desenvolvendo a nova Central de Relacionamento (Tomcat6/ Java6/ Struts2/ JQuery/ Ajax) com várias definições/questões ainda a serem discutidas.
Outro fator que me levou a crer que não entregaríamos tudo é o fato de termos escolhido desenvolver um CMA em Pythn/Django (o que achei uma excelente idéia).
O problema é que não é só o desenvolver (na minha opinião é a parte mais fácil!), e sim o startup de um novo projeto que costuma dar umas engasgadas por termos que configurar vários ambientes (local, desenvolvimento, QAs e produção), configuração de deploy para os ambientes e por ninguém na equipe ter experiência anterior com a linguagem.
Não preciso dizer que está tudo errado né? Nem precisava pesquisar sobre o assunto para ter a certeza de que não estamos trabalhando da forma correta. Não estamos usando o Scrum da forma correta. Mas como resolver essa questão? Acho que só na base do diálogo mesmo!
Já estou tentando fazer com que essa questão seja discutida entre a gente (time) e o PO, para que ele veja que a banda esta desafinando.
A responsabilidade é nossa de fazer o processo funcionar!
Nelson Hochman 