SlideShare une entreprise Scribd logo
1  sur  9
Télécharger pour lire hors ligne
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

Contenu connexe

En vedette

Chocolate A price worth paying ?
Chocolate A price worth paying ?Chocolate A price worth paying ?
Chocolate A price worth paying ?gbarker
 
Operacija Frankenstein
Operacija FrankensteinOperacija Frankenstein
Operacija FrankensteinDino dino
 
Artefotografico 1
Artefotografico 1 Artefotografico 1
Artefotografico 1 hanniez
 
Taj Mahalmat A Verdadeira HistóRia
Taj Mahalmat A Verdadeira HistóRiaTaj Mahalmat A Verdadeira HistóRia
Taj Mahalmat A Verdadeira HistóRiaBeatris Lopes
 
Festival Integrarte O Pelouro
Festival Integrarte O PelouroFestival Integrarte O Pelouro
Festival Integrarte O PelouroPelouro
 
Length sumbanganm cikgu wan salwa bt wan salim sk jerantut
Length sumbanganm cikgu wan salwa bt wan salim sk jerantutLength sumbanganm cikgu wan salwa bt wan salim sk jerantut
Length sumbanganm cikgu wan salwa bt wan salim sk jerantutshare with me
 
A OraçãO Que Eu Esqueci
A OraçãO Que Eu EsqueciA OraçãO Que Eu Esqueci
A OraçãO Que Eu EsqueciBeatris Lopes
 
Slideshare Proyecto computacion 3°A
Slideshare Proyecto computacion 3°ASlideshare Proyecto computacion 3°A
Slideshare Proyecto computacion 3°Akevin336
 

En vedette (17)

Floke Ursinho
Floke UrsinhoFloke Ursinho
Floke Ursinho
 
Chocolate A price worth paying ?
Chocolate A price worth paying ?Chocolate A price worth paying ?
Chocolate A price worth paying ?
 
Um Certo Galileu
Um  Certo GalileuUm  Certo Galileu
Um Certo Galileu
 
Que Hora Es
Que Hora EsQue Hora Es
Que Hora Es
 
Lingerie Shoot
Lingerie ShootLingerie Shoot
Lingerie Shoot
 
Pemeriksaan paper 2
Pemeriksaan paper 2Pemeriksaan paper 2
Pemeriksaan paper 2
 
Tv 2.0
Tv 2.0Tv 2.0
Tv 2.0
 
Presentación1
Presentación1Presentación1
Presentación1
 
Operacija Frankenstein
Operacija FrankensteinOperacija Frankenstein
Operacija Frankenstein
 
Varadero - Cuba
Varadero - CubaVaradero - Cuba
Varadero - Cuba
 
Artefotografico 1
Artefotografico 1 Artefotografico 1
Artefotografico 1
 
Taj Mahalmat A Verdadeira HistóRia
Taj Mahalmat A Verdadeira HistóRiaTaj Mahalmat A Verdadeira HistóRia
Taj Mahalmat A Verdadeira HistóRia
 
Festival Integrarte O Pelouro
Festival Integrarte O PelouroFestival Integrarte O Pelouro
Festival Integrarte O Pelouro
 
Length sumbanganm cikgu wan salwa bt wan salim sk jerantut
Length sumbanganm cikgu wan salwa bt wan salim sk jerantutLength sumbanganm cikgu wan salwa bt wan salim sk jerantut
Length sumbanganm cikgu wan salwa bt wan salim sk jerantut
 
A OraçãO Que Eu Esqueci
A OraçãO Que Eu EsqueciA OraçãO Que Eu Esqueci
A OraçãO Que Eu Esqueci
 
Derramando Petalas
Derramando PetalasDerramando Petalas
Derramando Petalas
 
Slideshare Proyecto computacion 3°A
Slideshare Proyecto computacion 3°ASlideshare Proyecto computacion 3°A
Slideshare Proyecto computacion 3°A
 

Similaire à Planejamento Baseado Em Evidencias

Gestão de Projetos (22/09/2014)
Gestão de Projetos (22/09/2014)Gestão de Projetos (22/09/2014)
Gestão de Projetos (22/09/2014)Alessandro Almeida
 
Python bge
Python bgePython bge
Python bgeTiago
 
curso-228532-aula-10-20e2-completo 1..pdf
curso-228532-aula-10-20e2-completo  1..pdfcurso-228532-aula-10-20e2-completo  1..pdf
curso-228532-aula-10-20e2-completo 1..pdfkassiocarlos
 
Porque nosso time parou de estimar
Porque nosso time parou de estimarPorque nosso time parou de estimar
Porque nosso time parou de estimarAndrei Tognolo
 
Softdrops - Planning Meeting & Refinement Session
Softdrops -  Planning Meeting & Refinement SessionSoftdrops -  Planning Meeting & Refinement Session
Softdrops - Planning Meeting & Refinement SessionSheila Kimura
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfromuloswati
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfromuloswati
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfromuloswati
 
21 Idéias de Produtividade Para Obter Mais Resultados.pdf
21 Idéias de Produtividade Para Obter Mais Resultados.pdf21 Idéias de Produtividade Para Obter Mais Resultados.pdf
21 Idéias de Produtividade Para Obter Mais Resultados.pdfxukizintrachuk
 
Curso de logica de programação aula 1com imagens
Curso de logica de programação aula 1com imagensCurso de logica de programação aula 1com imagens
Curso de logica de programação aula 1com imagensAntonio Tadeu Segat
 

Similaire à Planejamento Baseado Em Evidencias (20)

Gestão de Projetos (22/09/2014)
Gestão de Projetos (22/09/2014)Gestão de Projetos (22/09/2014)
Gestão de Projetos (22/09/2014)
 
Planilha ágil
Planilha ágilPlanilha ágil
Planilha ágil
 
Python bge
Python bgePython bge
Python bge
 
Estimar ou #NoEstimates
Estimar ou #NoEstimatesEstimar ou #NoEstimates
Estimar ou #NoEstimates
 
Scrum Sprint Planning
Scrum Sprint PlanningScrum Sprint Planning
Scrum Sprint Planning
 
curso-228532-aula-10-20e2-completo 1..pdf
curso-228532-aula-10-20e2-completo  1..pdfcurso-228532-aula-10-20e2-completo  1..pdf
curso-228532-aula-10-20e2-completo 1..pdf
 
Home
HomeHome
Home
 
Guia de Produtividade e Administração do Tempo
Guia de Produtividade e Administração do TempoGuia de Produtividade e Administração do Tempo
Guia de Produtividade e Administração do Tempo
 
Porque nosso time parou de estimar
Porque nosso time parou de estimarPorque nosso time parou de estimar
Porque nosso time parou de estimar
 
Softdrops - Planning Meeting & Refinement Session
Softdrops -  Planning Meeting & Refinement SessionSoftdrops -  Planning Meeting & Refinement Session
Softdrops - Planning Meeting & Refinement Session
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdf
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdf
 
MAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdfMAPA - DESENHO TÉCNICO.pdf
MAPA - DESENHO TÉCNICO.pdf
 
Curso Scratch 2015
Curso Scratch 2015Curso Scratch 2015
Curso Scratch 2015
 
Lógica da programação
Lógica da programaçãoLógica da programação
Lógica da programação
 
Lógica da programação
Lógica da programaçãoLógica da programação
Lógica da programação
 
Revista programar 18
Revista programar 18Revista programar 18
Revista programar 18
 
21 Idéias de Produtividade Para Obter Mais Resultados.pdf
21 Idéias de Produtividade Para Obter Mais Resultados.pdf21 Idéias de Produtividade Para Obter Mais Resultados.pdf
21 Idéias de Produtividade Para Obter Mais Resultados.pdf
 
Algoritmos com java script
Algoritmos com java scriptAlgoritmos com java script
Algoritmos com java script
 
Curso de logica de programação aula 1com imagens
Curso de logica de programação aula 1com imagensCurso de logica de programação aula 1com imagens
Curso de logica de programação aula 1com imagens
 

Planejamento Baseado Em Evidencias

  • 1. 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.
  • 2. 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.
  • 3. • 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
  • 4. 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
  • 5. 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:
  • 6. 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á
  • 7. 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
  • 8. 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.
  • 9. 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