Planejamento Baseado em Evidncia

Artigo original em ingls publicado pelo Joel da FogCreek

Os desenvolvedores de software no gostam de fazer planos. Geralmente, eles tentam se dar bem sem eles. "Estar pronto quando acabar!" dizem, na expectativa de que uma postura to corajosa e engraada desarmar seu chefe, e por via de conseqncia, o planejamento ser esquecido. A maior parte dos planos so algo assim meia-boca. So guardados num arquivo compartilhado qualquer e completamente esquecidos. Quando, dois anos depois, o trabalho terminado, aquele sujeito em cujo escritrio 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 engraado! Desde que voc no tenha ido falncia. Voc precisa dispender seu tempo em coisas que lhe do o mximo de retorno. E voc no 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 funes financeiras voc, sem dvida, precisa saber quanto tempo cada uma vai levar. Por que os desenvolvedores no planejam? Duas razes. Uma: um saco. Duas: ningum acredita que o plano srio. Por que se desgastar num planejamento que no vai funcionar? Por quase todo ano que passou ns na Fog Creek desenvolvemos um sistema to fcil de usar que mesmo nossos desenvolvedores mais rabugentos o aceitaram. E podemos garantir, ele gera cronogramas extremamente confiveis. o Planejamento Baseado em Evidncia, ou EBS (na sigla em ingls). Voc coleta evidncias, na maior parte dos histricos de horas trabalhadas, e as insere nos seus planos. Com isto voc consegue no apenas uma data, mas uma curva de distribuio de confiana, que mostra a probabilidade de atingir uma dada data de entrega. Tem a seguinte aparncia:

Quanto mais inclinada a curva, maior sua confiana 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 no vai funcionar. preciso que voc divida seu cronograma em pequenos trabalhos que possam ser medidos em horas. Nenhum maior que 16 horas. Isso o fora a pensar no que vai fazer. Escrever a subrotina foo. Criar aquela caixa de dilogo. Analisar sintaticamente o arquivo Fizzbott. Tarefas de desenvolvimento individuais so fceis de estimar pois voc j escreveu subrotinas, criou caixas de dilogo, e analisou arquivos. Se for preguioso, e escolher trabalhos de trs semanas (p.ex., Implementar o editor de fotos em Ajax), voc no pensou no que vai fazer. Em detalhe. Passo a passo. Quando voc no pensa sobre o que vai fazer, no pode estimar sua durao. Estabelecer o mximo de 16 hora fora-o a projetar o raio da funcionalidade. Se propuser uma funcionalidade que vai levar trs semanas como o Editor de fotos em Ajax sem um projeto detalhado, sinto muito em diz-lo mas voc est oficialmente condenado. Como no pensou nos detalhes vai esquecer um monte deles.

2) Acompanhe o cronograma
difcil conseguir estimativas individuais exatas. Como levar em conta as interrupes, bugs imprevisveis, reunies de status, e o dia do Dzimo Semi-anual do Windows quando voc tem que reinstalar tudo na sua mquina? Pro inferno, mesmo sem nada disso, como voc vai dizer exatamente a durao do desenvolvimento de uma subrotina? Realmente, no 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 grfico indica uma tarefa encerrada, com seus tempos estimado e real. Dividindo o tempo estimado pelo real, voc acha a velocidade: quo rapidamente a tarefa foi feita comparada com a estimativa. Com o tempo, voc ter o histrico de velocidades de cada desenvolvedor.

O mito do estimador perfeito, que existe somente na sua imaginao, sempre acerta nas estimativas. Sua velocidade {1; 1; 1; 1; 1; ....} Um mau estimador tem velocidades por todos os cantos do grfico, 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 no levou em conta a soluo de bugs, reunies de comit, intervalos para o cafezinho, e o maluco do gerente a interromper o tempo todo. O estimador normal consegue velocidades consistentes, mas elas esto 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 experincia ganham os estimadores, melhor ficam suas estimativas. Porisso esquea as estimativas mais velhas que, digamos, seis meses.

Se receber na equipe um estimador novo, sem histrico, assuma o pior: atribua-lhe um histrico qualquer com grande variao de velocidades, at que cumpra meia dzia de tarefas reais.

3) Simule o futuro
Ao invs de somar as estimativas para conseguir uma data nica, que parea correta mas que resulte num resultado profundamente errado, voc vai usar o mtodo de Monte Carlo para simular vrios futuros possveis. Numa simulao de Monte Carlo podem ser criados 100 possveis cenrios futuros. Cada destes possveis futuros tem 1% de probabilidade, deste modo voc pode mapear a probabilidade de cumprir qualquer data. Para calcular cada futuro possvel de um desenvolvedor particular, voc divide cada estimativa de tarefa por uma velocidade aleatoriamente selecionada do histrico deste desenvolvedor, que foi coletado no passo 2 acima. Veja uma amostra de futuro: Estimativa: Velocidade Aleatria: E/V: 4 0.6 6.7 8 0.5 16 2 8 16 0.6 0.6 0.5 3.3 13.3 32 Total: 71.3

Faa 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 mtico estimador perfeito, todas velocidades so divididas por 1. Dividir uma velocidade qualquer por 1 no muda nada. Assim, todas rodadas da simulao resultam na mesma data, e esta tem 100% de probabilidade. Assim como nos contos de fada! As velocidades do mau estimador esto por todo mapa 0,1 e 13,0, tm a mesma probabilidade. Cada rodada da simulao vai produzir resultados muito diferentes, pois quando so divididas por velocidades aleatrias resultam em nmeros muito diferentes de cada vez. A distribuio 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 informao til, alis: pois lhe diz que voc no deve confiar nas datas previstas. O estimador normal consegue uma poro de velocidades muito prximas, 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 iterao 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 histrico, provado, real destes desenvolvedores. E, como todas as velocidades histricas esto muito prximas, rondando 0,6, em cada rodada da simulao, voc chega a valores similares, com isso voc acabar num intervalo estreito de possveis datas para o trmino do desenvolvimento. claro que a cada rodada da simulao de Monte Carlo voc ter que converter o resultado em horas para uma data calendrio, isto significa que vai ter que levar em conta o horrio de trabalho

de cada desenvolvedor, suas frias, 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 so clculos meticulosos mas, felizmente, os computadores so bons nisto.

No necessrio um comportamento Obsessivo-compulsivo

O que voc faz com o chefe que o interrompe o tempo todo com estrias sem fim sobre suas pescarias? Ou com as reunies de vendas a que voc forado a ir mesmo sem qualquer boa razo? Coffee breaks? Gastar metade do dia ajudando o funcionrio novo a criar seu ambiente de trabalho? Quando Brett e eu desenvolvamos esta tcnica na Fog Creek, preocupamo-nos com coisas que consomem tempo mas que no podem ser previstas. s vezes, estas coisas consomem mais tempo do que a codificao. Ser que voc deveria ter estimativas para isso tambm, e acompanh-las e registr-las?

Bom, sim, voc pode faz-lo se quiser. E o Planejamento Baseado em Evidncias vai funcionar. Mas voc no precisa disso. O fato que o EBS funciona to bem que tudo que voc precisa manter o relgio contando o tempo do que voc estava fazendo quando ocorreu a interrupo. Desconcertante como possa parecer, o EBS produz melhores resultados quando voc age assim. Vou conduzi-lo num exemplo rpido. Para faz-lo o mais simples possvel, vamos imaginar, John, um programador bastante previsvel, cujo trabalho escrever cdigos de uma linha para as funes de ler e escrever em linguagens de baixo nvel. 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 algum 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 no seria politicamente prudente. Em vez disso, John deixa o relgio correr. Assim, seus registros

aparecem como: {2; 2; 2; 2; 4; 2; 2; 2; 2; 4; 2; } E suas velocidade so: {1; 1; 1; 1; 0,5; 1; 1; 1; 1; 0,5; 1; } Pense agora no que acontece. Na simulao 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 provvel que o EBS resulte numa evidncia exata sobre estas interrupes que o desenvolvedor mais obsessivo por registros. E esta exatamente a razo porque ele funciona to bem. Veja como explico este fato. Quando os desenvolvedores so interrompidos eles podem 1. fazer uma grande confuso sobre registrar a interrupo nas suas estimativas de modo a que a gerncia veja quanto tempo est sendo gasto em conversas sobre pescarias, ou 2. fazer uma grande confuso para no 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 incluso de conversas bobas sobre pescarias para as quais eles nem foram convidados. ... e em ambos os casos, o EBS resulta no mesmo resultado correto, No 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 fcil descobrir quo melhor ficam os prazos se voc cortar as funcionalidades de prioridade mais baixa.

Voc pode tambm observar a distribuio dos prazos por cada desenvolvedor:

Desenvolvedores (como Milton na figura) podem causar problemas com seus prazos to 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!) no esto no caminho crtico, e podem ser deixados em paz.

Crescimento do escopo
Assumindo que voc tenha planejado tudo nos nimos detalhes antes do incio do trabalho, o EBS funciona muito bem. Para ser honesto, porm, voc vai implementar algumas funcionalidades que no planejou. Voc tem novas idias, os vendedores prometem funcionalidades que voc no oferece, e algum diretor aparece com a nova concepo de fazer um aplicativo para que o GPS do carrinho de golfe funcione como um eletrocardigrafo enquanto o golfista se movimenta pelo campo. Tudo gera atrasos no poderiam ser previstos quando voc fez o plano original. Idealmente voc colocou alguma reserva para isso. Deste modo, v em frente e coloque alguma proteo (buffer) no seu plano para: 1. Novas funcionalidades 2. Resposta competio 3. Integrao (fazer com que os cdigos de todos desenvolvedores funcionem quando consolidados) 4. Tempo de depurao 5. Teste de usabilidade (e incorporao do resultado destes testes no produto) 6. Testes Beta E assim, quando novas funcionalidades aparecerem, voc pode usar um pouco da proteo adequada e us-la na implementao da novidade. O que ocorre se ainda existirem funcionalidades para adicionar e voc no tem mais proteo sobrando? Bem, a as datas que o EBS estimou comeam a deslizar para a frente. Voc deve tirar uma foto da distribuio de confiana dos prazos toda noite, para acompanh-los ao longo do tempo: A abcissa indica quando o clculo foi feito; a ordenada a data de entrega. H trs 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 prximas as curvas mais estreito o intervalo de datas possveis para a entrega. Se observar que as datas esto 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 tambm observar se a distribuio de confiana na data da entrega est se apertando (as curvas esto 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 responsvel pela funcionalidade pode determinar os passos que sero necessrios para implement-la. 2) Resolva os bugs assim que encontr-los, e debite o tempo tarefa original. Voc no pode planejar a soluo de qualquer bug antecipadamente, pois no sabe quais vo acontecer. Quando encontrar bugs, debite o tempo tarefa original que voc implementou incorretamente. Isto ajudar ao EBS na predio do tempo que leva para se conseguir um

cdigo totalmente depurado, no apenas um cdigo funcional. 3) No 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 motivao. Quando estou atrasado no cronograma, fico deprimido e me sinto condenado. Quando estou adiantado, fico alegre e produtivo. O cronograma no o local adequado para jogos psicolgicos. Por que os gerentes tentam isto? Quando o projeto comea, os gerentes tcnicos saem, renem-sem com o pessoal de negcio e vm com uma lista de funcionalidades que acham levar cerca de trs meses, mas que na realidade vai demorar doze. Quando se imagina escrever cdigo, 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 negcio fica infeliz. Gerentes ineptos tentam solucionar isto imaginando como conseguir que o pessoal trabalhe mais rpido. Isto no muito realista. Voc pode contratar mais gente, mas eles precisam maturar e trabalharo a 50% de eficincia por vrios meses (e ainda reduziro a eficincia dos outros que tero que trein-los). Voc pode ser capaz de conseguir que a equipe produza, temporariamente, 10% mais de cdigo cru ao custo de desgast-los em 100% num s ano. No um grande ganho, e como se voc estivesse comendo os gros da semeadura. Claro, quando voc carrega muito os desenvolvedores, o tempo de depurao dobra e projetos que esto atrasados atrasam ainda mais. Karma esplndido. Mas voc no pode gerar 4n de n, nunca, e se acha que pode, por favor mande por email o smbolo de sua empresa no mercado de aes para que possa me livrar delas. 4) Um plano uma caixa de blocos de madeira. Se voc tem uma poro de blocos de madeira e no 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 no 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 benefcios de planos realistas que voc forado 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 fcil de implementar e os programadores esto ansiosos para codific-la (Veja! <pisca>!), mas no serve para nada. Se no planejar, os programadores escolhero primeiro a funcionalidade fcil/engraada. Da ficaro sem tempo, e voc no ter escolha a no ser atrasar a entrega para poder implementar a funcionalidade til/importante. Se planejar, mesmo antes de comear a trabalhar, vai perceber que ter que remover alguma coisa, assim voc vai cortar a funcionalidade fcil/engraada e implementar apenas a til/importante. Ao se forar a escolher algumas funcionalidades para cortar, voc termina por desenvolver um produto mais

poderoso e melhor com uma combinao superior de funcionalidades e uma data de entrega antecipada. Tempos atrs, 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! pensvamos. Estas so funcionalidades importantssimas! Como poderemos sobreviver sem um mago de edio de macros? Afinal, sem escolha, tivemos que cortar o que entendamos ser at o osso para atingir o plano. Todos ficaram infelizes com os cortes. Para sentirmo-nos melhor, dissemos para ns mesmos que no estvamos cortando as funcionalidades, mas apenas adiando-as para o Excel 6. Quando o Excel 5 estava quase pronto, comecei a trabalhar na especificao 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. No achei que qualquer delas tivesse algum dia merecido ser pensada. O processo de selecionar funcionalidades para caber num plano foi a melhor coisa que poderamos ter feito. Se no tivssemos 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 verses anteriores, at o fim dos tempos.

Sumrio
Usar o Planejamento Baseado em Evidncias muito simples: produzir estimativas detalhadas vai lhe tomar um dia ou dois no comeo, e alguns segundos todo dia para registrar quando voc comear a trabalhar numa tarefa diferente. Os benefcios, todavia, so imensos: planos realistas. Planos realistas so fundamentais para criar software de qualidade. Eles o foram a desenvolver as melhores funcionalidades primeiro e lhe permitem tomar as decises 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 Evidncias parte do FogBugz. Artigo original em ingls escrito por Joel Spolsky - http://www.fogcreek.com Sobre o Tradutor: Paulo Andr de Andrade Engenheiro Eletrnico e Diretor da OLYMPYA TI, responsvel, no Brasil, pela comercializao dos softwares da Fog Creek - www.fogcreek.com.br Paulo Andr atua em Informtica desde 1971 em setores que vo de Engenharia de Qualificao de Componentes para Hardware, Engenharia de Produtos de Hardware, Desenvolvimento de Hardware e Software, Desenvolvimento de Negcios, Marketing e Vendas de Software e Consultoria em Gerncia de Projetos e em Servios de Informtica. Olympya Software Acesse agora o link e comece a usar gratuitamente o software de gerncia 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 vdeos esto no canal: http://www.youtube.com/user/OlympyaSoftware subscreva e acompanhe a evoluo 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 no relacionada aos produtos da Olympya Software
Ganhe dinheiro na internet sem sair da sua cadeira e sem nenhum gasto inicial ! No perca tempo acesse o link, Faa seu cadastro e comece a ganhar hoje mesmo!