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: Velocidade Aleatória: 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

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

Sign up to vote on this title
UsefulNot useful