Joel on Software

Joel on Software   Joel sobre Software

 

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Cronogramas de software sem sofrimento


Por Joel Spolsky
Traduzido por Nadia Karasawa
Editado por Adriana Burgos
29 de Março de 2000

Em outubro do ano passado, o nordeste dos Estados Unidos foi lotado de propagandas sobre um tal de Acela, um novo trem expresso de Boston a Washington. Com tantos comerciais na TV, outdoors e cartazes em todos os lugares, supõe-se que a campanha tenha criado uma demanda considerável para o novo serviço oferecido pela Amtrak.

Talvez. A Amtrak nuca teve a chance de saber. O Acela atrasou, atrasou de novo e enquanto isso sua campanha de marketing estava a pleno vapor sem que o Acela estivesse funcionando. Isso me lembra algo que ouvi de um gerente de marketing quando seu produto recebeu ótimas críticas um mês antes de ser lançado: “Ótima propaganda! Pena que não consigo achar o produto para comprá-lo!”

As loucas empresas de games gostam de dizer em seus websites que o próximo jogo vai ser lançado “quando estiver pronto”. Cronograma? Quem disse que a gente precisa de cronograma? A gente faz games! A maioria das empresas não tem esse luxo. Pergunte para a Lotus. Quando eles lançaram o Lotus 123 v3.0, era necessário ter um 80286 para rodá-lo, o que não era muito comum na época. Eles então atrasaram o lançamento por 16 meses, enquanto tentavam adaptar o produto para os 640K de memória de que o 8086 dispunha. Quando finalmente terminaram o trabalho, a Microsoft estava 16 meses na frente no desenvolvimento do Excel e, que ironia!, o 8086 já estava obsoleto de qualquer maneira.

Enquanto escrevo este artigo, o Netscape 5.0 já está com um atraso de dois anos. Em parte por causa da decisão suicida de jogar fora todo o código e começar tudo do zero: o mesmo erro que mandou o Ashton-Tate, o Lotus e o MacOS da Apple para a lixeira da história do software. A Netscape tem visto sua participação no mercado cair de 80% para 20% durante esse tempo, e nada pode fazer para reverter esse quadro, já que seu principal produto foi desmontado em mais de 1000 peças e não se encontra em mínimas condições de ser lançado. Esta única decisão, mais do que qualquer outra coisa, foi a bomba nuclear da Netscape que acabou com ela própria (a mundialmente famosa explosão de raiva de Jamie Zawinski tem mais detalhes sobre isso).

Portanto, você tem que ter um cronograma. Isto é algo que praticamente nenhum programador gosta de fazer. Segundo minha própria experiência, a grande maioria tenta escapar disto simplesmente não fazendo um cronograma. E dos poucos que o fazem, geralmente só o fazem porque foram obrigados por seus chefes. Ninguém acredita realmente em cronogramas, exceto pela alta gerência, que também acredita que “nenhum projeto nunca está em dia” e na existência de OVNIs.

Então por que ninguém faz cronogramas? Há duas razões principais. Primeiro, é porque é realmente um saco. Segundo, ninguém acredita que vale a pena. Para que ter tanto trabalho elaborando um cronograma se ele não vai estar atualizado? Existe uma percepção geral de que os cronogramas estão sempre errados, e só pioram à medida que o tempo passa; então para que sofrer por nada?

Eis uma maneira simples e sem sofrimentos de fazer cronogramas que realmente dão certo.

1) Use o Microsoft Excel. Não use nada muito pomposo como o Microsoft Project. O problema do Project é que ele assume que você queira gastar tempo se preocupando com dependências. Uma dependência acontece quando você tem duas tarefas e uma delas precisa estar completa para que a outra possa começar. Na minha opinião, no caso de desenvolvimento de software, as dependências são tão óbvias que não vale a pena o esforço de ficar constantemente atualizando-as tão formalmente.

Outro problema com o Project é que ele assume que em determinado momento você vai querer apertar um botãozinho e reorganizar todo o cronograma. Isso implica que inevitavelmente ele vai ter que rearranjar tudo e redesignar tudo para diferentes pessoas. Em projetos de software, isso não faz sentido algum. Os programadores não são facilmente trocados. O John leva sete vezes mais tempo para corrigir um bug da Rita do que a Rita levaria para corrigir seu próprio bug. E se você tentar colocar seu programador de UI para resolver um problema do WinSock, ele vai empacar e levar pelo menos uma semana se adaptando à programação do WinSock. Concluindo, o Project foi desenhado para a construção de prédios comerciais, não de software.

2) Mantenha-o simples. O formato padrão que uso para cronogramas é tão simples que você pode até decorar. Comece com apenas sete colunas:

Se você tem vários desenvolvedores, você pode tanto separar uma planilha para cada um quanto criar uma coluna para o nome do desenvolvedor que está trabalhando na tarefa.

3) Cada funcionalidade deve conter várias tarefas. Um exemplo de funcionalidade seria adicionar um verificador de ortografia no seu programa. Esta funcionalidade consiste em diversas tarefas menores que o programador precisa fazer. A parte mais importante de se fazer um cronograma é criar a lista de tarefas. Por isto, segue a regra básica:

4) Apenas o programador que vai escrever o código pode fazer a estimativa de tempo que será necessário. Qualquer sistema no qual a gerência determina os tempos e simplesmente comunica-os aos programadores está condenado a falhar.  Apenas o programador que realmente vai fazer o trabalho pode pensar exatamente nos passos que precisarão ser implementados. E somente este programador pode dizer quanto tempo cada um dos passos vai levar para ser concluído.

5) Escreva tarefas pequenas e precisas. Esta é a parte mais importante neste trabalho. Suas tarefas devem ser medidas em horas, não em dias. (Quando vejo um cronograma medido em dias, ou mesmo semanas, eu tenho certeza de que ele não é real). Você deve estar pensando que um cronograma com tarefas pequenas é vantajoso simplesmente porque é mais preciso. Errado! Erradíssimo! Quando você começa um cronograma com tarefas grandes e começa a quebrá-las em tarefas menores e mais precisas, você obtém um resultado final diferente, não apenas mais preciso. Trata-se de um número totalmente diferente. Por que isto ocorre?

Quando você pensa em tarefas menores, você se força a pensar em todos os passos que terão que ser tomados. Escrever a subrotina X. Escrever uma mensagem assim e assado. Ler o arquivo Y. É fácil de estimar quanto tempo você leva para implementar cada um desses passos, porque você já criou subrotinas, escreveu mensagens e abriu arquivos para leitura em algum trabalho anterior.

Se você for preguiçoso e escrever tarefas grandes demais (“implementar um corretor de gramática”), você não vai estar pensando no que você realmente terá que fazer. E se você não pensar no que terá que fazer, você simplesmente não saberá quanto tempo vai precisar.

Como regra geral, cada tarefa deve ter duração estimada de 2 a 16 horas. Se você tem uma tarefa de 40 horas (uma semana), você não está quebrando-a em tarefas menores suficientemente.

Eis uma outra razão para escrever tarefas precisas: isto te força a pensar no design da funcionalidade. Se você tem uma funcionalidade chamada “integração com a Internet” e você estimou 3 semanas para concluí-la, você está em apuros, amigo. Se você tiver que pensar quais rotinas terá que escrever, você é forçado a quebrar a feature em pedaços menores.  Sendo obrigado a planejar neste nível, você elimina muita da instabilidade de um projeto de software.

6) Fique de olho nas estimativas originais e atuais. Quando adicionar uma tarefa ao cronograma, estime quanto tempo ela levará para ser feita e coloque este valor tanto na coluna Estimativa Original quanto Estimativa Atual. Com o tempo, se a tarefa levar menos ou mais tempo do que você tinha previsto, vá alterando a coluna Estimativa Atual quantas vezes precisar. Esta é a melhor maneira de aprender com os erros e de se ensinar a estimar tempos mais precisos. A maioria dos programadores não tem idéia de como estimar tempos. Tudo bem. Contanto que você esteja sempre aprendendo e alterando a planilha à medida que aprende, o cronograma vai funcionar. (Talvez você tenha que cortar algumas funcionalidades, mas o cronograma vai continuar funcionando, já que ele te dirá quando você terá que cortá-las). Minha experiência é que a maioria dos programadores começa a estimar tempos mais precisos com mais ou menos um ano de experiência.

Quando a tarefa for concluída, a Estimativa Atual e o Tempo Corrido devem ter o mesmo valor, e o Tempo Restante deve ser 0.

7) Altere o Tempo Corrido diariamente. Você não precisa ficar de olho no cronômetro enquanto codifica. Um pouco antes de ir para casa, ou dormir debaixo da mesa (se você for um daqueles viciados), ou fingir que trabalhou nas últimas  8 horas (há!), dê uma pensada nas tarefas nas quais trabalhou e divida cerca de 8 horas nas colunas de tempo corrido correspondentes. O último campo é calculado automaticamente pelo Excel.

Aproveite também e altere a Estimativa Atual para essas tarefas, para que reflitam a realidade. A manutenção diária da planilha não deve levar mais do que dois minutos. É por isso que este é um método sem sofrimento – é rápido e fácil.

8) Adicione linhas para férias, feriados etc. Se seu cronograma levar mais ou menos um ano, cada programador provavelmente tirará de 10 a 15 dias de férias. Você deve ter uma funcionalidade chamada férias, feriados e qualquer outra coisa que demande tempo das pessoas. A idéia é que a data de entrega possa ser calculada somando-se a coluna Tempo Restante e dividindo por 40 – o resultado é o número de semanas restantes, com tudo incluído.

9) Coloque a fase de debug no seu cronograma! Esta fase é a mais difícil de estimar. Pense no último projeto em que trabalhou. Provavelmente o tempo de debug foi de 100% a 200% vezes o tempo que o código levou para ser escrito. Esta fase tem que estar no seu cronograma e provavelmente será o mais longo item da lista de funcionalidades.

Funciona assim. Digamos que um desenvolvedor está trabalhando em X. A Estimativa Original era 16 horas, mas até agora ele já demorou 20 e tudo indica que ainda precisará de mais 10 para ser concluída. Então, o desenvolvedor muda a Estimativa Atual para 30 e o Tempo Corrido para 20.

Ao final de um “milestone”, todas essas pequenas “falhas” provavelmente somaram um bom tanto. Teoricamente, algumas funcionalidades teriam que ser cortadas para não comprometer a entrega. Felizmente a primeira que podemos cortar é esta enorme funcionalidade chamada Buffer, que tem inúmeras horas já alocadas para ela.

A princípio, os desenvolvedores deveriam debugar à medida que forem codificando. Um programador nunca deveria trabalhar em um código novo se há bugs a serem corrigidos. O contador de bugs deveria estar sempre o mais baixo possível, por duas razões:

1) É mais fácil corrigir bugs no mesmo dia que você escreveu o código. Leva-se muito mais tempo e trabalho para corrigir bugs um mês depois, quando você já esqueceu como o código funciona.

2) Corrigir bugs é como fazer pesquisa científica. É impossível saber quando você descobrirá e corrigirá o bug. Se há apenas um ou dois grandes bugs em um determinado momento, é fácil estimar quando o produto será entregue porque não há tanto tempo “inestimável”. Por outro lado, se há centenas ou milhares de bugs, é impossível saber quando todos eles serão corrigidos.

Se os desenvolvedores estiverem sempre corrigindo bugs a medida que criam o código, qual o motivo de ter uma linha para a fase de debug no cronograma? Bom, mesmo que você tente corrigir todos os bugs na hora, no final haverá um bom trabalho pela frente quando os testadores (internos e betas) encontrarem bugs realmente difíceis de serem resolvidos.

10) Coloque a uma linha de integração no cronograma. Se você tem mais de um programador, inevitavelmente haverá coisas que dois programadores fazem que são inconsistentes e precisam ser conciliadas. Eles podem, por exemplo, implementar caixas de diálogo para coisas parecidas que são desnecessárias e inconsistentes. Alguém terá que navegar por todos os menus, atalhos, ferramentas etc., limpando e organizando os novos itens do menu que  todo mundo foi adicionado aqui e ali. Haverá erros de compilação quando duas pessoas fizerem o check in do código que estão escrevendo. Tudo isso precisa ser corrigido e portanto precisa estar no cronograma.

11) Coloque uma folga no cronograma.  As coisas tendem a se atropelar. Há dois tipos de folga que você pode considerar. Primeiro: uma para as tarefas que levaram mais tempo que o previsto. Segundo: uma para as tarefas que você não sabia que teria que fazer, geralmente porque a gerência decidiu que implementar X é SUPER IMPORTANTE e tem que estar na próxima versão.

O tempo para férias, feriados, debug, integração e buffer pode te surpreender ao ser maior que o tempo para as tarefas em si. Mas se você se surpreendeu mesmo, não faz muito tempo que você programa, faz? Bom, ignore este tempo a seu próprio risco.

12) Nunca permita que os gerentes peçam aos programadores para que reduzam uma estimativa. Muitos gerentes de projeto inexperientes acham que eles podem “motivar” seus programadores fazendo-os trabalhar mais rápido ao dar-lhes cronogramas “apertados” (leia-se irrealmente curtos). Acho que este tipo de motivação é péssimo. Quando estou atrasado com relação ao cronograma, sinto-me perdido, deprimido e desmotivado. Quando estou adiantado, sinto-me animado e produtivo. O cronograma não é o lugar certo para jogos psicológicos.

Se seu gerente te obrigar a reduzir uma estimativa de tempo, eis o que fazer. Crie uma nova coluna na planilha chamada Estimativa do Rick (supondo que seu nome seja Rick, claro.) Coloque sua estimativa lá. Deixe seu gerente fazer o que quiser com o Tempo Estimado.  Ignore as estimativas dele. Quando o projeto acabar, veja quem chegou mais perto da realidade. Tenho visto que só a ameaça de fazer isso já faz maravilhas, especialmente quando seu gerente se dá conta de que ele só entrou num concurso para ver o quão devagar você pode trabalhar!

Por que gerentes incapacitados tentam fazer com que os programadores reduzam estimativas?

Quando o projeto começa, o gerente técnico encontra-se com a alta gerência e criam uma lista de funcionalidades que eles acham que pode estar completa em 3 meses, mas na verdade levaria 9. Quando você pensa em escrever código sem pensar em todos os passos necessários, sempre parece que vai levar um tempo n, quando na verdade levaria um tempo 3n. Quando um cronograma real é escrito, você lista todas as tarefas e se dá conta de que o projeto vai levar muito mais tempo do que se pensava. É aí que a  realidade vem à tona.

Gerentes incapacitados tentam resolver isso pensando como fazer para que as pessoas trabalhem mais rápido, o que não é muito realista. Você pode até contratar mais pessoas, mas elas precisam se adaptar e provavelmente renderão apenas 50% do potencial durante vários meses (além de diminuir o potencial das pessoas que terão que orientá-las). De qualquer maneira, neste mercado, contratar bons programadores levaria uns 6 meses.

Você pode até conseguir, temporariamente, 10% a mais de código das pessoas, ao risco de queimá-las 100% ao final de um ano. Não é uma grande vantagem; é como dar um tiro no próprio pé.

Você pode até conseguir 20% a mais de código das pessoas implorando para que todos trabalhem prá caramba, independentemente do quão cansados estejam. Bum! O tempo da fase de debug dobra. Uma tola decisão que sai magnificamente pela culatra.

É impossível reduzir 3n para n, simplesmente impossível. E se você não concorda com isso, por favor me mande um e-mail com o código da sua empresa na bolsa de valores para que eu possa tirá-la da minha carteira de ações.

13) Um cronograma é como blocos de madeira. Se você tem um monte de blocos de madeira e não consegue colocá-los dentro de uma caixa, você tem duas opções: arranjar uma caixa maior ou tirar alguns dos blocos. Se você achava que poderia lançar o software em 6 meses mas há 12 meses no seu cronograma, você tem que ou atrasar a entrega ou excluir algumas funcionalidades. Não dá para diminuir o tamanho dos blocos e, se você fingir que dá, você só estará se privando da oportunidade de ver o futuro, mentindo para você mesmo sobre o que está vendo.

E sabe o que mais? Um outro grande subproduto de fazer bons cronogramas é que você é obrigado a descartar funcionalidades. E por que isso é bom? Suponha que você tem duas funcionalidades: uma delas é realmente útil e torna seu produto muito bom (ex.: tabelas no Netscape 2.0) e a outra é fácil de ser implementada e os programadores adorariam codificá-la (ex: a tag BLINK), mas não tem tanta utilidade nem vantagens competitivas.

Se você não fizer um cronograma, os programadores começarão pela funcionalidade mais fácil e divertida de ser implementada. Quando então o tempo se esgotar, você não terá outra escolha a não ser aumentar o prazo para fazer a funcionalidade mais importante e útil.

Mas se você fizer o cronograma, mesmo antes de começar o desenvolvimento, você saberá que alguma coisa terá que ser cortada e poderá descartar a funcionalidade fácil e fazer somente a mais importante. Sendo forçado a escolher funcionalidades para descartar, você concluirá um produto melhor, mais conciso, com funcionalidades melhores e com prazo menor.

Lembro de quando estava desenvolvendo o Excel 5. Nossa lista inicial de funcionalidades era enorme e requeria um prazo muito maior do que tínhamos. Meu Deus!, pensamos. Todas as funcionalidades são super importantes! Como é que a gente pode ficar sem o assistente de edição de macro?

Não tínhamos outra escolha se não cortar o máximo que podíamos para fazer o cronograma. Todo mundo estava infeliz com os cortes. Para acalmar os ânimos, dizíamos a nós mesmo que não estávamos cortando funcionalidades, simplesmente estávamos adiando-as para o Excel 6, já que não eram tão importantes.

Quando o Excel estava quase concluído, comecei a trabalhar na especificação do Excel 6 com um colega, Eric Michelman. Começamos repassando a lista das funcionalidades que tinham sido cortadas do Excel 5. Ficamos chocados ao ver que era a lista mais fajuta que se pode imaginar. Nenhum item valia o esforço de fazê-lo. E não acho que nenhuma das funcionalidades foi implementada, nem mesmo nas três versões seguintes. O processo de descarte de funcionalidades para ajustar o desenvolvimento ao cronograma foi a melhor coisa que poderíamos ter feito. Se não o tivéssemos feito, o Excel 5 teria levado o dobro do tempo para ficar pronto e teria 50% de funcionalidades inúteis. (Não tenho dúvida alguma de que é exatamente isso que acontece com o Netscape 5/Mozilla: eles não têm um cronograma, não tem uma lista definitiva de funcionalidades, ninguém quer cortar nada e assim nada é lançado. E quando algo realmente for lançado, eles terão um monte de funcionalidades inúteis como um cliente IRC, nas quais eles não deveriam ter gasto tempo algum desenvolvendo.)

Apêndice: Coisas que você deveria saber sobre o Excel

Uma das razões pelas quais o Excel é tão bom para se trabalhar com cronogramas de software é que a única coisa que os programadores fazem no Excel é manter seus cronogramas!  (Poucos fazem análise de cenários de possibilidades...nós estamos falando de programadores!)

Pasta de trabalho compartilhadas O uso das pastas compartilhadas (no menu Ferramentas) permite que várias pessoas abram o arquivo e editem campos ao mesmo tempo. Já que a equipe toda deve atualizar o cronograma constantemente, é uma mão na roda.

Auto Filtro Essa é uma ótima maneira de filtrar o cronograma de forma que, por exemplo, você só veja as funcionalidades designadas a você. Usando com a Classificação, você pode ver todas as funcionalidades que você deve fazer ordenas por prioridade, ou seja, sua lista de coisas “to do” . Legal!!!

Relatório de tabela dinâmica Essa é uma ótima maneira de ver resumos e referências cruzadas. Por exemplo, você pode criar um gráfico mostrando as horas restantes para cada desenvolvedor para cada prioridade. É como pão de forma e milkshake de chocolate. Você precisa aprender como usá-los porque eles tornam o Excel um milhão de vezes mais poderoso.

A função WORKDAY das Ferramentas de Análise do Excel é uma ótima maneira de elaborar calendários a partir de cronogramas.



Esse artigo apareceu originalmente em Inglês com o título Painless Software Schedules  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky