Planejamento Baseado em Evidência

Este artigo apareceu na página Joel on Software na sexta -

feira, 26 de outubro de 2007
Os desenvolvedores de software não gostam de fazer planos. Geralmente, eles tentam se dar bem
sem eles. "Estará pronto quando acabar!" dizem, na expectativa de que uma postura tão corajosa e
engraçada desarmará seu chefe, e por via de conseqüência, o planejamento será esquecido.
A maior parte dos planos são algo assim meia-boca. São guardados num arquivo compartilhado
qualquer e completamente esquecidos. Quando, dois anos depois, o trabalho é terminado, aquele
sujeito em cujo escritório se encontra o arquivo, leva o documento para o arquivo morto, e o pessoal
todo ri. “Olhaí! Planejamos duas semanas para reescrever tudo em Ruby!”
Muito engraçado! Desde que você não tenha ido à falência.
Você precisa dispender seu tempo em coisas que lhe dão o
máximo de retorno. E você não consegue descobrir quanto
vai lhe custar sem saber quanto tempo vai levar. Quando tem
que decidir entre implementar o “clip de papel animado” e
“mais funções financeiras” você, sem dúvida, precisa saber
quanto tempo cada uma vai levar.
Por que os desenvolvedores não planejam? Duas razões.
Uma: é um saco. Duas: ninguém acredita que o plano é sério.
Por que se desgastar num planejamento que não vai funcionar?
Por quase todo ano que passou nós na Fog Creek desenvolvemos um sistema tão fácil de usar que
mesmo nossos desenvolvedores mais rabugentos o aceitaram. E podemos garantir, ele gera
cronogramas extremamente confiáveis. É o Planejamento Baseado em Evidência, ou EBS (na sigla
em inglês). Você coleta evidências, na maior parte dos históricos de horas trabalhadas, e as insere
nos seus planos. Com isto você consegue não apenas uma data, mas uma curva de distribuição de
confiança, que mostra a probabilidade de atingir uma dada data de entrega. Tem a seguinte
aparência:

Quanto mais inclinada a curva, maior sua confiança na data de embarque.

Veja como você usa o EBS.
1) Divida-o
Quando vejo um plano medido em dias, ou mesmo semanas, sei que não vai funcionar. É preciso
que você divida seu cronograma em pequenos trabalhos que possam ser medidos em horas.
Nenhum maior que 16 horas.
Isso o força a pensar no que vai fazer. Escrever a subrotina foo. Criar aquela caixa de diálogo.
Analisar sintaticamente o arquivo Fizzbott. Tarefas de desenvolvimento individuais são fáceis de
estimar pois você já escreveu subrotinas, criou caixas de diálogo, e analisou arquivos.
Se for preguiçoso, e escolher trabalhos de três semanas (p.ex., “Implementar o editor de fotos em
Ajax”), você não pensou no que vai fazer. Em detalhe. Passo a passo. Quando você não pensa sobre
o que vai fazer, não pode estimar sua duração.
Estabelecer o máximo de 16 hora força-o a projetar o raio da funcionalidade. Se propuser uma
funcionalidade que vai levar três semanas como o “Editor de fotos em Ajax” sem um projeto
detalhado, sinto muito em dizê-lo mas você está oficialmente condenado. Como não pensou nos
detalhes vai esquecer um monte deles.

2) Acompanhe o cronograma
É difícil conseguir estimativas individuais exatas. Como levar em conta as interrupções, bugs
imprevisíveis, reuniões de status, e o dia do Dízimo Semi-anual do Windows quando você tem que
reinstalar tudo na sua máquina? Pro inferno, mesmo sem nada disso, como você vai dizer
exatamente a duração do desenvolvimento de uma subrotina?
Realmente, não dá.
Porisso, marque o tempo gasto. Registre quanto tempo gastou em cada tarefa. Assim você pode em
retrospecto verificar o quanto se desviou da estimativa. Você vai coletar dados como estes para cada
desenvolvedor:

Cada ponto no gráfico indica uma tarefa encerrada, com seus tempos estimado e real. Dividindo o
tempo estimado pelo real, você acha a velocidade: quão rapidamente a tarefa foi feita comparada
com a estimativa. Com o tempo, você terá o histórico de velocidades de cada desenvolvedor.
 • O mito do estimador perfeito, que existe somente na sua imaginação, sempre acerta nas
estimativas. Sua velocidade é {1; 1; 1; 1; 1; ....}
• Um mau estimador tem velocidades por todos os cantos do gráfico, por exemplo {0,1; 0,5;
1,7; 0,2; 1,2; 0,9; 13,0}
• A maioria dos estimadores erram na escala mas acertam na estimativa. Tudo demora mais do
que o esperado, pois a estimativa não levou em conta a solução de bugs, reuniões de comitê,
intervalos para o cafezinho, e o maluco do gerente a interromper o tempo todo. O estimador
normal consegue velocidades consistentes, mas elas estão sempre abaixo de 1,0. Por
exemplo: {0,6; 0,5; 0.6; 0,6; 0,5; 0,6; 0,7; 0,6}
Quanto mais experiência ganham os estimadores, melhor ficam suas estimativas. Porisso esqueça as
estimativas mais velhas que, digamos, seis meses.
Se receber na equipe um estimador novo, sem histórico, assuma o pior: atribua-lhe um histórico
qualquer com grande variação de velocidades, até que cumpra meia dúzia de tarefas reais.

3) Simule o futuro
Ao invés de somar as estimativas para conseguir uma data única, que pareça correta mas que resulte
num resultado profundamente errado, você vai usar o método de Monte Carlo para simular vários
futuros possíveis. Numa simulação de Monte Carlo podem ser criados 100 possíveis cenários
futuros. Cada destes possíveis futuros tem 1% de probabilidade, deste modo você pode mapear a
probabilidade de cumprir qualquer data.
Para calcular cada futuro possível de um desenvolvedor particular, você divide cada estimativa de
tarefa por uma velocidade aleatoriamente selecionada do histórico deste desenvolvedor, que foi
coletado no passo 2 acima. Veja uma amostra de futuro:
Estimativa: 4 8 2 8 16
Velocidade Aleatória: 0.6 0.5 0.6 0.6 0.5 Total:
E/V: 6.7 16 3.3 13.3 32 71.3
Faça isto 100 vezes; cada total tem 1% de probabilidade, e aí você pode deduzir a probabilidade de
cumprir uma dada data.
Agora observe o que acontece:
• No caso do mítico estimador perfeito, todas velocidades são divididas por 1. Dividir uma
velocidade qualquer por 1 não muda nada. Assim, todas rodadas da simulação resultam na
mesma data, e esta tem 100% de probabilidade. Assim como nos contos de fada!
• As velocidades do mau estimador estão por todo mapa 0,1 e 13,0, têm a mesma
probabilidade. Cada rodada da simulação vai produzir resultados muito diferentes, pois
quando são divididas por velocidades aleatórias resultam em números muito diferentes de
cada vez. A distribuição de probabilidade resultante será bem achatada, o que mostra que a
chance de terminar amanhã ou em qualquer data no futuro distante é a mesma. Esta é uma
informação útil, aliás: pois lhe diz que você não deve confiar nas datas previstas.
• O estimador normal consegue uma porção de velocidades muito próximas, por exemplo
{0,6; 0,5; 0,6; 0,6; 0,5; 0,6; 0,7; 0,6}. Ao usar estas velocidades você aumenta o tempo que
que leva para fazer qualquer coisa, assim em uma iteração um trabalho de 8 horas vai levar
13; em outra pode levar 15 horas. Isto compensa o otimismo constante destes estimadores. E
compensa precisamente, baseado exatamente no otimismo histórico, provado, real destes
desenvolvedores. E, como todas as velocidades históricas estão muito próximas, rondando
0,6, em cada rodada da simulação, você chega a valores similares, com isso você acabará
num intervalo estreito de possíveis datas para o término do desenvolvimento.
É claro que a cada rodada da simulação de Monte Carlo você terá que converter o resultado em
horas para uma data calendário, isto significa que vai ter que levar em conta o horário de trabalho
de cada desenvolvedor, suas férias, feriados, etc. E, a cada rodada, você terá que notar qual
desenvolvedor termina mais tarde, pois ele determina quando o trabalho estará pronto. Estes estes
são cálculos meticulosos mas, felizmente, os computadores são bons nisto.

Não é necessário um comportamento Obsessivo-compulsivo

O que você faz com o chefe que o interrompe o tempo todo com estórias sem fim sobre suas
pescarias? Ou com as reuniões de vendas a que você é forçado a ir mesmo sem qualquer boa
razão?Coffee breaks? Gastar metade do dia ajudando o funcionário novo a criar seu ambiente de
trabalho?
Quando Brett e eu desenvolvíamos esta técnica na Fog Creek, preocupamo-nos com coisas que
consomem tempo mas que não podem ser previstas. Às vezes, estas coisas consomem mais tempo
do que a codificação. Será que você deveria ter estimativas para isso também, e acompanhá-las e
registrá-las?

Bom, sim, você pode fazê-lo se quiser. E o Planejamento Baseado em Evidências vai funcionar.
Mas você não precisa disso.
O fato é que o EBS funciona tão bem que tudo que você precisa é manter o relógio contando o
tempo do que você estava fazendo quando ocorreu a interrupção. Desconcertante como possa
parecer, o EBS produz melhores resultados quando você age assim.
Vou conduzi-lo num exemplo rápido. Para fazê-lo o mais simples possível, vamos imaginar, John,
um programador bastante previsível, cujo trabalho é escrever códigos de uma linha para as funções
de ler e escrever em linguagens de baixo nível. O dia todo é isto que ele faz:
private int width;
public int getWidth () { return width; }
public void setWidth (int _width} { width = _width; }
Eu sei, eu sei... este é um exemplo deliberadamente bobo, mas você sabe você já encontrou alguém
assim.
De qualquer maneira, cada leitura e escrita lhe toma 2 horas. Assim suas estimativas para o trabalho
parece-se com isto:
{2; 2; 2; 2; 2; 2; 2; 2; 2; 2; 2; … }
Agora, este infeliz tem um gerente que o interrompe o tempo
todo com uma conversa mole de duas horas sobre pescaria de
merlin. Ora, é certo que John poderia ter uma tarefa no seu
elenco chamada “Papos chatos sobre merlins”, e registrar o
tempo gasto, mas isto não seria politicamente prudente. Em
vez disso, John deixa o relógio correr. Assim, seus registros aparecem como:
{2; 2; 2; 2; 4; 2; 2; 2; 2; 4; 2; … }
E suas velocidade são:
{1; 1; 1; 1; 0,5; 1; 1; 1; 1; 0,5; 1; … }
Pense agora no que acontece. Na simulação de Monte Carlo, a probabilidade de cada estimativa ser
dividida por 0,5 é exatamente a mesma que a probabilidade de o chefe de John interrompê-lo. E
assim o EBS produz um plano correto!
Na realidade, é muito mais provável que o EBS resulte numa evidência exata sobre estas
interrupções que o desenvolvedor mais obsessivo por registros. E esta é exatamente a razão porque
ele funciona tão bem. Veja como explico este fato. Quando os desenvolvedores são interrompidos
eles podem
1. fazer uma grande confusão sobre registrar a interrupção nas suas estimativas de modo a que
a gerência veja quanto tempo está sendo gasto em conversas sobre pescarias, ou
2. fazer uma grande confusão para não registrá-la, e deixar que a funcionalidade em que
estejam trabalhando atrase, pois eles se recusam a calibrar suas estimativas, que eram
totalmente corretas, com a inclusão de conversas bobas sobre pescarias para as quais eles
nem foram convidados.
... e em ambos os casos, o EBS resulta no mesmo resultado correto, Não interessa se você é um
desenvolvedor do tipo passivo ou agressivo.

4) Gerencie ativamente seus projetos

Quando você entender isso, você poderá

gerenciar ativamente seus projetos para que
terminem no prazo. Por exemplo, se você
classificar as funcionalidades por prioridade,
fica fácil descobrir quão melhor ficam os
prazos se você cortar as funcionalidades de
prioridade mais baixa.

Você pode também observar a distribuição dos prazos por cada desenvolvedor:
Desenvolvedores (como Milton na figura) podem causar problemas com seus prazos tão incertos:
eles precisam aprender a fazer melhores estimativas. Outros desenvolvedores (como Jane) fornecem
prazos bem precisos mas que ocorrem muito tarde: eles precisam que algum trabalho seja removido
da sua lista. Outros desenvolvedores (eu! sim!) não estão no caminho crítico, e podem ser deixados
em paz.

Crescimento do escopo
Assumindo que você tenha planejado tudo nos ínimos detalhes antes do início do trabalho, o EBS
funciona muito bem. Para ser honesto, porém, você vai implementar algumas funcionalidades que
não planejou. Você tem novas idéias, os vendedores prometem funcionalidades que você não
oferece, e algum diretor aparece com a nova concepção de fazer um aplicativo para que o GPS do
carrinho de golfe funcione como um eletrocardiógrafo enquanto o golfista se movimenta pelo
campo. Tudo gera atrasos não poderiam ser previstos quando você fez o plano original.
Idealmente você colocou alguma reserva para isso. Deste modo, vá em frente e coloque alguma
proteção (buffer) no seu plano para:
1. Novas funcionalidades
2. Resposta à competição
3. Integração (fazer com que os códigos de todos desenvolvedores funcionem quando
consolidados)
4. Tempo de depuração
5. Teste de usabilidade (e incorporação do resultado destes testes no produto)
6. Testes Beta
E assim, quando novas funcionalidades aparecerem, você pode usar um pouco da proteção
adequada e usá-la na implementação da novidade.
O que ocorre se ainda existirem funcionalidades para adicionar e você não tem mais proteção
sobrando? Bem, aí as datas que o EBS estimou começam a deslizar para a frente. Você deve tirar
uma foto da distribuição de confiança dos prazos toda noite, para acompanhá-los ao longo do
tempo:

A abcissa indica quando o cálculo foi feito; a ordenada é a data de entrega. Há três curvas aqui: a de
cima é a data com 95% de probabilidade, a do meio a com 50% e a inferior é a de 5%. Quanto mais
próximas as curvas mais estreito o intervalo de datas possíveis para a entrega.
Se observar que as datas estão atrasando cada vez mais (a curva está subindo), você está em perigo.
Se estiverem atrasando mais de um dia a cada dia, significa que o trabalho está crescendo mais
depressa do que sua capacidade de realizá-lo, e você nunca vai terminá-lo. Você pode também
observar se a distribuição de confiança na data da entrega está se apertando (as curvas estão se
aproximando), que é o que deve ocorrer se você estiver convergindo para uma data.

Enquanto estamos no assunto

Eis aqui outras coisas que aprendi ao longo dos anos sobre planos.
1) Só o programador que realiza o trabalho pode criar a estimativa. Qualquer sistema em que o
gerente planeja e entrega aos programadores está condenado a falhar. Só o programador responsável
pela funcionalidade pode determinar os passos que serão necessários para implementá-la.
2) Resolva os bugs assim que encontrá-los, e debite o tempo à tarefa original. Você não pode
planejar a solução de qualquer bug antecipadamente, pois não sabe quais vão acontecer. Quando
encontrar bugs, debite o tempo à tarefa original que você implementou incorretamente. Isto ajudará
ao EBS na predição do tempo que leva para se conseguir um código totalmente depurado, não
apenas um código funcional.
3) Não permita que gerentes atormentem os
desenvolvedores para que produzam estimativas com
prazos mais curtos. Muitos gerentes de software iniciantes
acham que podem “motivar” seus programadores a
trabalhar mais rapidamente passando-lhes cronogramas
lindos e “apertados” (irrealisticamente curtos). Acho que
este é um tipo idiota de motivação. Quando estou atrasado
no cronograma, fico deprimido e me sinto condenado.
Quando estou adiantado, fico alegre e produtivo. O
cronograma não é o local adequado para jogos psicológicos.
Por que os gerentes tentam isto?
Quando o projeto começa, os gerentes técnicos saem, reúnem-sem com o pessoal de negócio e vêm
com uma lista de funcionalidades que acham levará cerca de três meses, mas que na realidade vai
demorar doze. Quando se imagina escrever código, sem pensar em todos os passos, sempre parece
que vai demorar um tempo n quando na realidade provavelmente demorará algo como 4n. Quando
faz um plano realista, você soma todas as tarefas e entende que o projeto vai durar muito mais que
originalmente pensou. O pessoal de negócio fica infeliz.
Gerentes ineptos tentam solucionar isto imaginando como conseguir que o pessoal trabalhe mais
rápido. Isto não é muito realista. Você pode contratar mais gente, mas eles precisam maturar e
trabalharão a 50% de eficiência por vários meses (e ainda reduzirão a eficiência dos outros que
terão que treiná-los).
Você pode ser capaz de conseguir que a equipe produza, temporariamente, 10% mais de código cru
ao custo de desgastá-los em 100% num só ano. Não é um grande ganho, e é como se você estivesse
comendo os grãos da semeadura. Claro, quando você carrega muito os desenvolvedores, o tempo de
depuração dobra e projetos que estão atrasados atrasam ainda mais. Karma esplêndido.
Mas você não pode gerar 4n de n, nunca, e se acha que pode, por favor mande por email o símbolo
de sua empresa no mercado de ações para que possa me livrar delas.
4) Um plano é uma caixa de blocos de madeira. Se você tem uma porção de blocos de madeira e
não consegue arranjá-los numa caixa tem duas escolhas: pegar uma caixa maior, ou remover alguns
blocos. Se quiser entregar em seis meses, mas tiver doze no seu plano, vai ter que atrasar ou achar
algumas funcionalidades para remover. Você não pode encolher os blocos, e, se quiser fazer de
conta que consegue, está somente se privando de uma oportunidade de perceber o futuro por estar
se enganando sobre o que vê lá.
Agora que o mencionei, um dos grandes benefícios de planos realistas é que você é forçado a
remover funcionalidades. Por que isto é bom?
Suponha que você pensou em duas funcionalidades. Uma é realmente útil e vai tornar seu produto
excelente. A outra é fácil de implementar e os
programadores estão ansiosos para codificá-la (“Veja!
<pisca>!”), mas não serve para nada.
Se não planejar, os programadores escolherão primeiro a
funcionalidade fácil/engraçada. Daí ficarão sem tempo, e
você não terá escolha a não ser atrasar a entrega para poder
implementar a funcionalidade útil/importante.
Se planejar, mesmo antes de começar a trabalhar, vai
perceber que terá que remover alguma coisa, assim você vai
cortar a funcionalidade fácil/engraçada e implementar apenas a útil/importante. Ao se forçar a
escolher algumas funcionalidades para cortar, você termina por desenvolver um produto mais
poderoso e melhor com uma combinação superior de funcionalidades e uma data de entrega
antecipada.
Tempos atrás, quando trabalhei no desenvolvimento do Excel 5, nossa lista de funcionalidades era
enorme que nos teria levado a estourar em muito o cronograma. “Pô meu!” pensávamos. “Estas são
funcionalidades importantíssimas! Como poderemos sobreviver sem um mago de edição de
macros?”
Afinal, sem escolha, tivemos que cortar o que entendíamos ser “até o osso” para atingir o plano.
Todos ficaram infelizes com os cortes. Para sentirmo-nos melhor, dissemos para nós mesmos que
não estávamos cortando as funcionalidades, mas apenas adiando-as para o Excel 6.
Quando o Excel 5 estava quase pronto, comecei a trabalhar na especificação do Excel 6 com Eric
Michelman, um colega. Sentamo-nos para repassar a lista de funcionalidades do “Excel 6” que
tinham sido chutadas do plano do Excel 5. Adivinhe só? Era a lista mais fajuta que se podia
imaginar. Nenhuma daquelas funcionalidades merecia ser implementada. Não achei que qualquer
delas tivesse algum dia merecido ser pensada. O processo de selecionar funcionalidades para caber
num plano foi a melhor coisa que poderíamos ter feito. Se não tivéssemos feito isso, o Excel 5 teria
demorado duas vezes mais e incluiria 50% mais de funcionalidades idiotas que teriam que receber
suporte, para compatibilidade com versões anteriores, até o fim dos tempos.

Sumário
Usar o Planejamento Baseado em Evidências é muito simples: produzir estimativas detalhadas vai
lhe tomar um dia ou dois no começo, e alguns segundos todo dia para registrar quando você
começar a trabalhar numa tarefa diferente. Os benefícios, todavia, são imensos: planos realistas.
Planos realistas são fundamentais para criar software de qualidade. Eles o forçam a desenvolver as
melhores funcionalidades primeiro e lhe permitem tomar as decisões corretas sobre o que deve ser
feito. Isto torna seus produtos melhores, seu chefe mais feliz, delicia seus clientes, e – melhor de
tudo – deixa você ir para casa as 17 horas.
P.S.
Planejamento Baseado em Evidências é parte do FogBugz 7.0.

Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com

Sobre o Tradutor: Paulo André de Andrade é Engenheiro Eletrônico e Diretor da OLYMPYA TI,
responsável, no Brasil, pela comercialização dos softwares da Fog Creek - www.fogcreek.com.br -
Paulo André atua em Informática desde 1971 em setores que vão de Engenharia de Qualificação de
Componentes para Hardware, Engenharia de Produtos de Hardware, Desenvolvimento de Hardware
e Software, Desenvolvimento de Negócios, Marketing e Vendas de Software e Consultoria em
Gerência de Projetos e em Serviços de Informática.

A Olympya Software - www.olympya.com.br é também a representante exclusiva no Brasil

e Portugal da FogCreek, http://www.fogcreek.com.br empresa fundada pelo Joel Spolsky.

Você pode usar gratuitamente por 45 dias o produto FogBugz, totalmente web, para
gerencia de projetos e outras funcionalidades, visitando o link

http://try.fogbugz.com

Para treinamento em como fazer melhores softwares você pode aprender mais sobre outro
produto da FogCreek, já em Português:

http://www.scribd.com/doc/29112680/Make-Better-Software-V1