A arte da Estimativa versus o medo de estimar

O verbete estimativa é um substantivo feminino que identifica um cálculo aproximado, avaliação ou conjectura. Ampliando este entendimento inicial, estimação é uma aproximação, pressuposto, hipótese ou suposição.

O verbete medo retrata um substantivo masculino sobre o estado emocional provocado pela consciência que se tem diante do perigo, grande inquietação em relação a algo desagradável ou possibilidade de insucesso, algo que tememos.

O que vem antes? O que é mais importante? Não estimar e dizer que só se preocupa com o valor entregue? Estimar e correr o risco de ser cobrado pela estimativa? Aprender com o debate e exercício de planejamento? Equipes podem blindar estas informações do PO e empresa? Será que Tuckman pode nos ajudar?

Eu sempre proponho a analogia de uma pirâmide de abstração, iniciamos pelo topo durante o exercício da Scrum Vision onde discutimos apenas estratégia, no Release Plan descemos um pouco para entender quais são as histórias e qual o nível de complexidade estimando pontos por comparação, no Sprint Planning já temos protótipos de tela e entendimento para quebrar em tarefas, mas somente ao desenvolver teremos o domínio, fato consumado.

Quem acompanha meu blog está acostumado a ver exemplos destes momentos em posts onde detalho estas técnicas e justifico, vendo isso como oportunidade e não como risco. O valor da estimativa e a ciência do previsto x realizado agrega muito aprendizado, mas tem que perder o medo   \o/

Paradigmas

Em projetos tradicionais de software temos enraizada a pretensão de prever e acertar com meses de antecedência cada movimento, ação, tarefa, resultados e principalmente prazos. Anos trabalhando neste modelo acabou por gerar um modelo de gestão baseado em controle, disputa de contratos, change requests, pouca transparência, jogo de cintura e saídas pela tangente.

Métodos ágeis se propuseram a valorizar mais a transparência na interação entre as pessoas em um trabalho mais sinérgico, onde que cada ator trabalhará para colaborar com os demais com o objetivo de conhecer-se cada vez mais para poder entender, construir e entregar um pedacinho de software de cada vez, o pedaço de maior valor a cada momento, dentro do potencial e características do time.

Parece simples, mas não é, o maior desafio é não usar a retórica de time quando convém e de comando-controle e poder quando for conveniente, ou acreditamos em auto-conhecimento, melhoria contínua, confiança mútua e coletivo, ou em pouco tempo cada um voltará a se preocupar com cláusulas, datas e entregas com alta opacidade em meio a bônus e penalidades.

Uma faca de dois gumes, 8 ou 80

Muitos agilistas e times que tentam trabalhar de forma ágil negam a necessidade de estimativas e o valor de termos previstos x realizados. Com medo de voltar a serem cobrados de forma reducionista, por escopo e prazo, negam a si mesmos a oportunidade de tentar estimar, acompanhar e comparar para aprender cada vez mais sobre o que fazem, como fazem e o que entregam a cada sprint.

Ron Jeffries em seu artigo “Estimativas são do mal” acaba por dizer que equipes maduras em agile e experientes na tecnologia se beneficiam de suas estimativas, pois com frequência as superam, produzindo um sentimento de entrega além do previsto. Neste mesmo artigo ele diz que equipes com menor maturidade e experiência podem vir a se enrolar com suas estimativas, errando, tratando-as como promessas e comprometendo seu foco na entrega de valor, qualidade e aprendizado, gerando um vórtice de angústias e falta de transparência.

Em um de seus artigos Ron diz “Há uma série de ideias sobre estimativas usando Pontos, Gummi Bears, Fibonacci ou tamanhos de camiseta, meios inventados para obscurecer o aspecto tempo de modo que a administração não seja tentada a abusar das exigências e cobranças sobre as estimativas” e mais, complementa afirmando “Eu sei, eu estava lá quando elas foram inventadas”.

Dissonância Cognitiva

Cachorro picado por cobra tem medo de linguiça! Eu não concordo em satanizar as estimativas só porque há o risco de serem mal utilizadas, o segredo não está em eliminar as estimativas ou usar estimativas enigmáticas, pois estas soluções apenas confirmam a Teoria da Dissonância Cognitiva … a solução é aprender a usar as estimativas da forma correta, esse é o caminho mais instigante.

Dissonância cognitiva é uma teoria da psicologia social que demonstra que quando temos um conflito aparentemente insolúvel entre dois pressupostos, quando temos uma angústia ou conflitos em nossas crenças, inconscientemente criamos elementos de consonância para solucionar estes impasses. Por exemplo, se estimar é um risco, então vamos nos convencer que estimar é ruim!

A meu ver, é nestas horas que precisamos de alguém experiente para nos alertar, orientar e provocar a dar novos passos em direção a novos aprendizados, evitarmos criar novas zonas de conforto. Na prática, abandonar o uso de boas e adequadas técnicas de estimativa, de forma clara e construtiva gera mais riscos que oportunidades de aprendizado, é postergar um maior auto-conhecimento e bons argumentos para planos de ação voltados ao nosso crescimento.

Martin Fowler

Um dos ícones das metodologias ágeis debate mitos e realidades no tema estimativas, dizendo haver um tanto de agilistas que negam a necessidade de estimar ou o quanto é prejudicial estimar o que será feito. Fowler diz que estimar depende do quanto isso gera valor para o projeto e participantes, ao estilo XP: “Se vale a pena fazer, então por que você não está fazendo isso em tudo”.

Ele inicia alertando que bons desenvolvedores tendem a ser otimistas em suas estimativas, que conscientemente ou inconscientemente são vistas como compromisso pelo cliente, gestão e por eles mesmos. Ao dar errado, frustra, podendo gerar um comportamento menos transparente nos desenvolvedores, que podem construir software de menor qualidade para cumprir os prazos.

Por outro lado, segundo Fowler, estimar pode ser um instrumento útil para tomada de decisão, alocação de pessoas, custos e dimensionamento. Em projetos com dependências, quer com outros projetos, comerciais, com outras equipes, etc, é preciso manter um constante alinhamento na medida que o projeto evolui, quer atingindo metas estimadas ou não. É importante saber porque necessitamos de estimativas, mas mais que isso, entender o que É uma estimativa.

Segundo esta abordagem, “estimativas podem nos ajudar a compreender alguns trade-offs e, assim, decidir como responder à mudança. Em uma escala maior, de re-estimação de um lançamento, pode nos ajudar a entender se o projeto como um todo ainda é o melhor uso da nossa energia”. Ele cita como exemplo um projeto que ao perceber-se muito maior que o inicialmente estimado acabou por ser cancelado.

Ele cita a frase de um gerente de um de seus projetos que afirmava que “planos e estimativas eram como alfaces, boas para um alguns dias, inúteis após semanas e irreconhecível após alguns meses”, e cita integrantes que percebem estimativas como oportunidade de melhor compreensão das formas de implementação e GC.

Conclusões

Me parece que quanto maior a maturidade ágil e experiência (domínio técnico) de uma equipe de desenvolvimento, menor o impacto e riscos, independente do modelo ou técnicas utilizadas, usando de maior ou menor abstração. Este patamar é resultado de uma construção, demanda tempo, convívio, erros e acertos, mas se evitarmos os debates, erros e aprendizados, demora mais e talvez abandonemos antes de chegar lá.

Por outro lado, equipes novas no método ou equipes não tão seniores na tecnologia podem se beneficiar do debate proveniente da prática de estimativas e com o aprendizado proveniente desta dinâmica. Uma história quebrada em X tarefas e estimada de alguma forma sempre gerará um bom aprendizado, insights para colaboração, instrução, reciclagem, auto-diagnósticos, etc …

É um assunto polêmico, mas o exercício da estimativas, quer sejam em T-Shirt size ou user story points no release plan incentivam e estabelecem o debate, convergência e entendimento além da conta. Um mecanismo que privilegia os 3C’s – cartão, conversação e critérios.