Transcript
Planejamento Baseado em Evidência
1 Artigo original em inglês publicado pelo Joel da FogCreek
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 "Tota"
" " " " " " "l: "
"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!
!"), 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.
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.
Olympya Software
Acesse agora o link e comece a usar gratuitamente o software de gerência
de projetos fogbugz 8.0 : http://goo.gl/7tklj
Para treinamento do seu time - Make Better Software : http://goo.gl/Bc8zU
Veja os produtos e games da Olympya visitando:
http://www.linkedin.com/company/olympya-
software/products?trk=top_nav_products
Nossos vídeos estão no canal: http://www.youtube.com/user/OlympyaSoftware
subscreva e acompanhe a evolução dos games e produtos
Se você é fã de games e ou de futebol visite: www.futweb.com.br e
http://futweb.com.br/ole
Dica não relacionada aos produtos da Olympya Software
Ganhe dinheiro na internet sem sair da sua cadeira e sem nenhum gasto
inicial ! Não perca tempo acesse o link, Faça seu cadastro e comece a
ganhar hoje mesmo!
