Ron Jeffries é um dos 17 signatários originais do Manifesto Ágil, um dos 3 fundadores do Extreme Programming. Ele publica artigos na e-revista da Pragmatic Programmers e na edição 46 de abril de 2013 ele publicou o artigo "Estimation". Pedi permissão ao editor Michael Swaine para traduzir o artigo para português porque é um assunto que eu já ia dissertar a respeito e o Ron, obviamente, já fez um trabalho melhor. Ainda há muito que quero dizer a respeito mas por agora vamos direto à tradução do artigo:

Dois meses atrás nestas páginas, Ron Jeffries nos falou que estimativas são do mal. Agora ele está de volta para nos dizer que é um mal necessário e, feito da forma correta, não é nem mesmo mal.

Sim, existem muitos abusos perpetrados por organizações em volta da noção de estimativa. Muitos desenvolvedores sofreram injúrias sobre esses abusos mais de uma vez em suas carreiras.

Infelizmente, isso nos leva à visão comum ingênua entre pretensos praticantes agilistas que ainda estão no início do aprendizado: eles querem abolir estimativas completamente. Isso provavelmente não é possível e certamente não é ideal. Nós temos a habilidade de estimar quão rapidamente conseguimos fazer as coisas, e as empresas podem tomar decisões melhores se nós compartilharmos o que sabemos.

Desenvolvimento de software não é uma máquina perfeita que cospe funcionalidades rapidamente. Eu sei que é confortável pensar que não temos responsabilidades nas preocupações de negócios como dinheiro, tempo ou datas. Mas isso não é verdade. O que construímos não é isoladamente somente influenciado por algum Lorde dos Produtos que decide o que vamos fazer e assume todos os riscos. Os executivos são os que tem a decisão final, mas muitas das decisões são melhor tomadas pela equipe - e não somente em como fazer as coisas, mas o que fazer. Nós temos a responsabilidade e ajudar a guiar os projetos, usando nossa criatividade e nosso conhecimento especial.

O Manifesto Ágil diz, "as melhores arquiteturas, requerimentos e designs emergem de equipes auto-organizadas" e é isso que queríamos dizer (ênfase minha). Desenvolvedores ágeis normalmente tem um bom senso de quanto tempo as coisas vão levar, e isso é um componente valioso de selecionar e refinar requerimentos. Desenvolvedores precisam ter a atitude de falar sobre possíveis custos do que lhes é pedido para fazer.

Preocupações com Estimativas

Realmente existem inúmeros problemas sérios relacionados a estimar um trabalho de software. Em um artigo anterior "Estimativa é do Mal", eu descrevi alguns deles. Vamos revisá-los:

  • Backlogs pré-definidos de trabalho reduzem a criatividade e inibem ajustar o projeto para o sucesso.
  • Demandar entrega de "tudo" em alguma data fixa é um truque que nunca funciona.
  • Tratar estimativas como promessas levam a equipes conservadoras e resultados frustrantes.
  • Tentar melhorar a "qualidade" das estimativas é uma atenção que poderia dar melhores resultados se voltados para melhorar a qualidade do produto.
  • E assim por diante.

Naquele artigo, eu argumentei que o resultado desse foco é "Agile fraco". Em essência, equipes focadas em estimativas estão geralmente no lado fraco da balança entre custo e valor. Equipes melhores focam mais em valor e menos em custo. Eles ainda consideram custo, porque custo é um componente importante na entrega de valor. Mas valor é seu interesse primário.

É verdade que muitas equipes de primeira não estimam no real senso do termo. Eles trabalham em pequenas histórias, pequenas o suficiente que para conseguir um senso de progresso você pode apenas contabilizá-las. Eles trabalham nas coisas de maior valor primeiro - usando qualquer noção de valor que eles tem. Eles ajustam sua visão frequentemente, e ajustam no que vão trabalhar em seguida de acordo com o que está acontecendo. Eles trabalham para produzir um fluxo contínuo de software de valor, e eles entregam o mais frequentemente possível, normalmente diariamente.

Já que estimativa está frequentemente associado a equipes fracas e disfuncionais, e já que grandes equipes parecem trabalhar sem estimativas, muitos praticamentes de Agile fortemente resistem qualquer estimativa de qualquer tipo. E é uma coisa boa montar uma equipe - e uma organização - que é forte o suficiente para trabalhar sem estimativas. Mas isso é uma forma avançada de trabalho, nunca a forma para começar. Não é bom recusar a estimar, ou mesmo se sentir ressentido disso, em uma organização onde isso é necessário. Do contrário, nós precisamos aprender a fazer isso direito, de uma forma que influencie a organização positivamente.

Orçando Novos Projetos

Agora, vamos olhar a uma necessidade legítima, ajudando a organização a decidir se deve prosseguir ou não com um projeto.

Quando alguma coisa dá errado com nossa casa ou carro, e nós não temos todo o dinheiro do mundo, nós provavelmente recebemos estimativas para consertar essas coisas. Provavelmente consideramos alternativas: se o tampo do maleiro está riscado, devemos pintar novamente o carro inteiro para acertar a cor perfeitamente, apenas passar um spray no tampo, tentar polir os riscos, ou apenas viver com os riscos? Nós escolhemos a opção que parece ser o melhor uso do nosso dinheiro.

Pessoas de negócios orçando projetos tem o mesmo problema de alocar fundos. Eles precisam considerar como entregar o maior valor possível dentro do orçamento. Em uma pequena organização tentando criar maravilhosos produtos novos, a preocupação é ainda maior. Precisamos começar a gerar fluxo de caixa positivo antes do dinheiro acabar!

Em situações como essa, nós realmente precisamos ter estimativas. Precisamos saber se é uma decisão sábia ir em frente com o novo projeto. Pessoas de negócios já tem algumas estimativas em mente: quantas pessoas vão se interessar? Qual a porcentagem de prospects se tornarão compradores? Quanto os compradores vão pagar pelo produto?

Mas eles precisam decidir: podemos começar a trazer dinheiro suficiente para permanecer vivo antes do nosso dinheiro acabar?

O tomador de decisão sabe que todas essas estimativas são estimativas, e usa o melhor julgamento para colocar valor neles. Mas existe uma área chave que ele não conhece muito sobre: quanto desse produto pode ser feito, em qual data, por quanto dinheiro? Essa é uma questão técnica e isso precisa ser respondido por pessoas técnicas.

Sim, claro que nós também não sabemos. Nós realmente não sabemos quanto vai levar. Mas vamos encarar os fatos, nós temos uma idéia melhor de quanto tempo as coisas vão levar comparado ao pobre empreendedor, e ele precisa de nossa ajuda.

Eu acredito que nós conseguimos dar um chute melhor se vai levar uma semana, um mês, um trimestre ou um ano antes de começarmos a ter uma boa idéia de quão rápido conseguimos progredir. E esse chute, por mais abrangente que seja, é um chute melhor do que uma pessoa de negócios pode dar.

Não podemos somente dizer "Vamos tentar?" Parece que podemos dizer alguma coisa assim:

"Nosso equipe custa $10 mil por semana. Vamos começar a trabalhar nas partes mais importantes, mais arriscadas, mais informativas do seu produto, e criar um senso de quão difícil será e quão longo as coisas serão. Você nos verá construindo o que nos pediu. Você nos verá trabalhando. Você será capaz de decidir se quer continuar investindo ou parar."

Parece fazer sentido dizer que - a menos que seja os seus $10 mil do seu bolso saindo toda semana. Aí você tem mais perguntas. "Eu vou saber depois de uma semana? Eu vou ter que esperar um mês inteiro pra saber? Vou saber por Junho? Caraca pessoal, são uns $100 mil daqui até Junho. É dinheiro pra caramba! Me dêem um tempo aqui! Quanto que isso vai custar?"

Precisamos tomar as rédeas desse tipo de desafio. Devemos dar a resposta mais sólida que conseguirmos, mesmo quando não temos uma resposta absolutamente concreta.

Estamos pisando em areia. Como ficamos concretos?

A pergunta é, "Quanto tempo vai levar, e quanto dinheiro vai custar, para chegar num produto que as pessoas possam comprar?"

Gostaríamos de dizer, "Bem, comece a gastar algum dinheiro conosco, e se você se entediar, pare," mas isso não ajuda em nada. Podemos mudar essa idéia um pouco? Vamos começar com uma estimativa bem abrangente apenas para ter uma noção de onde estamos.

Nós provavelmente já temos alguma noção se vai levar uma semana, um mês, ou seis meses para fazer alguma coisa usável. Se é assim, vamos falar sobre isso. Nosso investidor já tem um valor em mente que ele pode gastar. Vamos descobrir quanto é isso, ou ter uma noção disso na conversa.

Suponha que nós imaginamos que talvez consigamos ter uma versão rudimentar mas usável do produto em seis meses, e o investidor está disposto a investir até $1 milhão até conseguir um fluxo de caixa positivo. $1 milhão é aproximadamente um ano do nosso tempo, e se levarmos 9 meses em vez de 6, precisaremos trazer $1 milhão em três meses para chegar a positivo. Vamos falar sobre isso. Quão rápido ele espera que o faturamento cresça com a primeira versão? Suponha que ele ache que o faturamento vá crescer rapidamente, de forma que ele se levarmos 9 meses, estamos bem. Isso soa arriscado para mim, mas parece que o projeto pelo menos parece bom o suficiente para explorar.

Lembre-se de como Agile funciona. Queremos que as pessoas de negócios estejam totalmente engajadas nas tomadas de decisão sobre gastar dinheiro baseado no que ele vê. Então vamos começar a pensar em selecionar funcionalidades, não apenas datas.

Estimativas que não vão te fazer se arrepender

"Ok, intuitivamente, nós achamos que podemos entregar uma versão inicial em seis meses, e achamos que se levarmos nove meses, o projeto seria viável. Isso parece bom, mas ainda soa arriscado. Odiaríamos ver você gastar tudo isso e chegar a lugar nenhum, e o que temos ainda são chutes grosseiros."

"Então vamos fazer o seguinte: vamos gastar duas semanas para produzir uma resposta mais concreta. Duas semanas vai lhe custar somente $20 mil, que é muito menos que $1 milhão. Nessas duas semanas, você vai trabalhar ativamente conosco nos aspectos mais importantes do produto. Algumas serão coisas de interface, algumas serão guiadas por riscos de negócio ou técnico que podemos prever agora. No final dessas duas semanas, nós decidimos se queremos continuar. Nosso trabalho será lhe mostrar, concretamente, o que podemos construir que nos convença se devemos prosseguir ou não. Seu trabalho será nos guiar descrevendo o que você quer, e trabalhar conosco para identificar riscos e preocupações."

"Se depois dessas duas semanas, as coisas parecerem ruins, nós saberemos disso e vamos recomendar que você pare. Se as coisas parecerem boas até então, vamos decidir juntos qual será o próximo ponto de decisão. Pode ser daqui a um mês, ou daqui a três meses. Francamente, estamos perfeitamente felizes de fazer isso a cada duas semanas."

"Sim, isso mesmo. A cada duas semanas vamos falar com você sobre o que fazer a seguir. Vamos fazer isso e mostrar para você. Se estiver bom o suficiente, continuarmos. Se não, paramos."

"Dessa forma, seu risco nunca será maior do que mis $20 mil. Você pode decidir se vai usar esse dinheiro para conseguir mais informação, para redirecionar seus esforços, ou ver se deveria gastar esse dinheiro de alguma outra forma."

"Podemos trabalhar dessa forma?"

Se ele disser sim, vamos começar. Se ele disser não, precisamos descobrir porque, e mesmo se esse projeto é para nós.

Isso é definitivamente estimativa, e é um tipo de estimativa que podemos fazer em conjunto com nossas pessoas de negócios em vez de em conflito com eles.

Nós estimamos, com alguma certeza, que podemos produzir informações úteis em duas semanas. Se acharmos que não conseguimos isso, melhor sugerir quatro ou seis ou oito semanas.

Mais do que isso, nós estimamos que um produto viável é provavelmente possível em seis ou nove meses. Se não tivéssemos nenhuma idéia, ou pior ainda, se sinceramente tivéssemos dúvidas disso, então não podemos legitimamente convidá-lo a descobrir - pelo menos não nos termos acima. Nós devemos a ele de dizer "Francamente, isso parece um projeto de dois, três anos para nós. Podemos estar errados: aqui está o que precisamos aprender para descobrir. Aqui está o que custaria para descobrirmos, e nossos melhores chutes agora é que a resposta será má notícia."

Algumas vezes temos uma boa idéia do que podemos fazer. Algumas vezes sabemos menos. De qualquer jeito, estimando o que sabemos, podemos desenhar experimentos - investimentos - que melhore nossa capacidade de decidir o que fazer.

Quando estamos falando de gastar o dinheiro dos outros, eu acho que devemos a eles pensar e agir dessa forma.

Isso é Estimativa, não Negociação!

Uma estimativa não precisa ser "Este projeto estará terminado na Terça, 14 de Maio, às 14:35h." Supõe-se que uma estimativa seja expressa com um intervalo de possibilidades. Seria perfeitamente OK dizer alguma coisa como, "Não vemos possibilidade de isso feito até Abril. Se tudo sair perfeito, podemos estar prontos até meio de Maio. Baseado na nossa experiência, estamos pensando em Junho, talvez Julho."

Se dizemos isso ou não, as chances são que sabemos disso, ou pelo menos suspeitamos. E se é isso que pensamos, o projeto precisa dessa informação. Entretanto, se colocamos dessa forma, seremos empurrados pra trás. Alguém vai nos desafiar para provar, sem sombra de dúvidas, que não conseguimos entregar até 30 de Abril, e se provarmos isso, eles dirão "Que tal 5 de Maio?" Bah, odiamos quando eles fazem isso. Então como podemos entregar informações que o projeto necessita sem jogar esse jogo?

Mova de Data Estimada para Velocidade Estimada

Vamos usar o método das Cinco Cartas de artigos anteriores, não para estimar uma data, mas para quebrar o projeto todo em sub-histórias pequenas o suficiente que nossa equipe faça, digamos, cinco delas em duas semanas. Claro que podemos acabar tendo apenas três prontas. Podemos ter seis mas duvidamos disso. Então chegamos numa estimativa em termos de velocidade:

"Quebramos o projeto em histórias menores. Acreditamos que com histórias deste tamanho, seremos capazes de fazer entre três a cinco a cada duas semanas. E ao fim de um período de duas semanas, tudo que fizermos estará visível, testado, integrado e funcionando. Então se forem cinco ou seis ou dois por semana, saberemos, e você saberá"

"Se você puder remover ou deferir algumas dessas histórias e ainda ter um produto viável, você terá o produto antes. Se puder simplificar, poderá ter o produto antes. Se adicionar histórias, ou tornar as coisas mais difíceis, você vai atrasar o produto pra depois."

"Depende de você. Podemos quebrar as coisas neste tamanho, podemos chutar nossa velocidade agora como sendo três itens a cada duas semanas, e você saberá a cada duas semanas o que está realmente acontecendo. Você pode usar essa informação para decidir o que fazer, o que deferir, a fim de você receber o melhor produto para quaisquer datas que escolher."

Ajude a Gerência a Aprender sobre Velocidade

Agora a gerência pode ainda querer negociar sobre isso conosco. Se eles tentarem adicionar os números para conseguir datas, e então começar a ajustar as datas, não negocie: devolva a conversa de volta à taxa de progresso. "A data depende de você. Se escolher fazer mais, será mais tarde. Se escolher fazer menos, será antes. Nós achamos que faremos entre três a cinco ítens a cada dusa semana. Podemos estar errados: se estivermos, você saberá tão cedo quanto nós."

Alguém pode tentar pressionar a velocidade. "Vocês não conseguem fazer sete a cada duas semanas? Assim poderiam terminar a tempo."

Lembre-se de como Agile funciona: desenvolvedores trabalham em um ritmo ótimo sustentável; os desenvolvedores não são responsáveis pelas datas; o lado de negócios é dona das datas, e é dona da responsabilidade de chegar nessas datas.

O trabalho dos desenvolvedores é entregar no melhor ritmo possível: "Nós achamos que conseguimos fazer três a cinco. Se conseguirmos por acaso ir mais rápido, você vai saber. Se formos mais devagar, você vai saber também. QUando vamos acabar depende disso, mas depende mais ainda, em quão pouco você nos dê para fazer. O que será colocado nessas datas depende de você. Você deve planejar em três a cinco itens a cada duas semanas, e checar o que está acontecendo de verdade."

Isso pode pressionar mais de uma vez para ir mais rápido. Mas temos os fatos à nossa disposição, da forma como estão. "Baseado na nossa experiência, teremos de três a cinco feitas. Não seria sábio assumir nada maior do que isso, porque provavelmente não vai acontecer. Se alguma coisa acontecer que nos faça ir mais rápido, todos nós saberemos e você poderá selecionar mais itens na versão."

Tudo isso, claro, tem muito mais a ver com comunicação, não sobre estimativa, e enfaticamente não sobre negociação. A estimativa foi trivial: fizemos logo no começo quando separamos os cartões. Agora estamos comunicando o que sabemos, o que chutamos, o que acreditamos.

Demos à gerência nossas melhores estimativas e taxas de produçõa, e nos comprometemos com elas, melhorando à medida que vamos evoluindo. Continuamos a deixar claro que o pessoal de negócios controla as datas escolhendo quanto trabalhos pedem.

Otimizando o Produto

Seja você a favor ou não de estimativas, você deve saber que Agile é sobre construir produtos incrementalmente, em boas condições, a partir do primeiro dia até o último dia, e tirar valor disso o mais cedo possível. Isso requer grandes capacidades técnicas, mas capacidades técnicas não são suficientes. As pessoas pagando por nosso trabalho precisam alocar seus recursos. Eles precisam gerenciar seu dinheiro, e eles precisam coordenar nosso trabalho com atividades e partes interessadas de fora da nossa equipe.

Para fazer isso de forma eficiente, eles precisa de informações de quanto tempo as coisas vão levar, que se traduz em quanto as coisas vão custar, e quanto tempo vai levar para começarmos a receber nosso dinheiro de volta. Eles precisam de informação que temos para realizar esse trabalho bem. O fato da nossa informação ser vaga, falha e incerta não é uma razão para não expô-la. Precisamos colocar nossa informação nas mãos deles, e fazer isso de forma que lhes dê a melhor oportunidade de usá-la da melhor forma possível.

Recusar a estimar não é a coisa certa de se fazer isso. Estimar é necessário, e comunicação efetiva da estimativa é necessária também.

A melhor coisa a fazer é desenvolver funcionalidades pequenas no melhor ritmo sustentável possível, e usar a informação gerada para ajudar as pessoas de negócios decidir o que pedir, e o que deferir. Para fazer isso, precisamos estimar. Nós dividimos história a tamanhos pequenos estimáveis, e estimamos nossa taxa de entregá-las. Esse tipo de estimativa não é mal de forma nenhuma: é incrivelmente útil e é o que as melhores equipes ágeis fazem.

Ron Jeffries desenvolve software há mais tempo do que qualquer pessoa viva. Ele possui graduações avançadas em matemática e ciências da computação, ambas ganhas antes de inteiros negativos terem sido inventados. Suas equipes construíram sistemas operacionais, compiladores, sistemas de bancos de dados relacionais, e diversas aplicações grandes. Os produtos de software de Ron produziram faturamento de mais de meio bilhão de dólares, e ele se pergunta porque não ganhou nada disso.

Envie feedback ao autor ou discuta o artigo no fórum da revista.

comentários deste blog disponibilizados por Disqus