Atividade necessária, ardua e dificil, veja o que o Joel Spolsky da http://www.fogcreek.com escreveu sobre este assunto sistema de gerência - use gratuitamente por 45 dias http://try.fogbugz.com Para treinar sua equipe http://training.fogcreek.com/index.php?lang=pt Se gosta de games: www.futweb.com.br e http://futweb.com.br/ole FutWeb: http://www.youtube.com/watch?v=eGhyXUtEISE Ole: http://www.youtube.com/watch?v=cxn2LlWSt-o Para usuários do Unity e do FogBugz http://www.youtube.com/watch?v=h23XvVOk4cA

1. Como planejar tarefas de desenvolvimento de
software
A construção de cronogramas de desenvolvimento de software é um conhecimento profissional, não
uma arte. Seguem algumas dicas para se conseguir melhores cronogramas.
Deixe os desenvolvedores planejarem seu próprio trabalho
Qualquer sistema onde a gerência estabelece um cronograma e o entrega aos programadores está
condenado a falhar. Só o programador que vai fazer o trabalho pode determinar os passos
necessários para implementar aquela funcionalidade específica. E só o programador é capaz de
estimar o tempo que cada tarefa vai levar.
Conceba antes e com detalhes
Tentar planejar o desenvolvimento de uma função antes de entender, detalhadamente, como ela vai
funcionar não pode resultar em boa coisa, mesmo se “multiplicar por três sua melhor estimativa”,
pois sua “melhor estimativa” tem pouco fundamento em fatos reais. A natureza do desenvolvimento
de software é que o que parece simples é, freqüentemente, muito complicado quando analisado em
detalhe. Por exemplo: se pensar em criar um sistema de registro e logon, você pode esquecer que
vai ser necessário um processo que evite que as senhas sejam as mesmas que o nome do usuário, e
um processo para lidar com senhas esquecidas, e uma forma para as pessoas se desregistrarem e
assim por diante. Até que se entenda o efeito, na concepção do projeto, de cada uma dessas
possibilidades, não existirá qualquer fundamento para um bom plano.
Decomponha tudo nos seus mínimos detalhes
Esta é a coisa mais importante para que um plano realmente funcione. O trabalho precisa ser
medido em horas, não em dias. (Qualquer cronograma que utilize dias ou semanas, não deve ser
válido). Pode-se pensar que um cronograma com tarefas planejadas em termos de tempo muito
curtos é apenas mais preciso. Errado! Muito errado! Quando se começa um plano com tarefas muito
abrangentes e depois as divide em tarefas menores, o resultado é muito diferente, não é apenas um
cronograma mais detalhado. É um cronograma totalmente diferente. Por que isso ocorre?
Quando é preciso determinar tarefas detalhadas, você se força a entender quais os passos que se tem
de realizar. Escrever a subrotina foo. Criar o diálogo tal e tal. Ler o arquivo wawa. Estes são passos
simples de estimar, pois já se escreveu subrotinas, criou diálogos e leu arquivos wawa antes.
Se você é preguiçoso, e escolhe tarefas macro (“implementar correções gramaticais”), então ainda
não pensou realmente sobre o que vai fazer. E quando não se pensou sobre o que vai fazer, não é
possível saber quanto tempo vai levar.
Como uma regra geral, cada tarefa deve levar de 1 a 16 horas. Se alguma tarefa está durando 40
horas (uma semana), o cronograma não foi decomposto no nível de detalhe necessário.
Outra razão para detalhar profundamente as tarefas: ser forçado a projetar a funcionalidade. Ao
escolher uma funcionalidade como “Integração com a Internet” e planejá-la em três semanas, seu
planejamento provavelmente vai falhar. Se você tiver que determinar quais subrotinas serão
desenvolvidas, você se força a definir com precisão a funcionalidade. Ser forçado a planejar neste
nível elimina muitas instabilidades de um projeto de software.

2. Acompanhe a execução do cronograma e aprenda com seus
erros
A maioria dos programadores não sabem como estimar a duração das tarefas. Sem problema. Desde
que eles estejam continuamente aprendendo e continuamente atualizando suas estimativas enquanto
aprendem, o cronograma vai ser cumprido. (Talvez seja necessário reduzir funcionalidades ou adiá-
las, mas o cronograma ainda assim vai funcionar, no sentido de que vai informar constantemente
quando funcionalidades devem ser reduzidas ou adiadas). A maioria dos programadores tornam-se
bons estimadores depois de um ano de experiência.
Leve em conta férias, feriados, reuniões, etc.
Se o cronograma abrange cerca de uma ano, cada programador vai tirar alguns dias de férias. No
FogBugz, é possível estabelecer feriados comuns e cada desenvolvedor pode, também, informar seu
próprio plano de férias.
Adicione itens de planejamento
É necessário adicionar itens de planejamento como:
1. Período de integração, isto é: o tempo gasto para fazer com que códigos escritos por
programadores diversos funcionem juntos.
2. Tempo de contingência: o tempo que os desenvolvedores reservam para funcionalidades e
tarefas não planejadas. A contingência pode ser qualquer coisa entre 50% e 100% do tempo
normal dependendo de quanta confiança se tenha na exatidão do projeto.
3. Tempo de contingência competitiva: tempo planejado para permitir a adição, no último
minuto, de novas funcionalidades para igualar as funcionalidades do competidor.
4. Tempo de depuração: o tempo gasto na solução de bugs descobertos no teste.
5. Testes Alfa e Beta: tempo gasto na distribuição de versões de teste do software, na coleta e
resposta a opiniões e relatórios de bugs, na incorporação das opiniões ao produto e na
solução de bugs descobertos pelos testadores Beta.
No FogBugz, um item de planejamento é um tipo especial de caso. É preciso criar um item para
cada desenvolvedor. Uma equipe com cinco desenvolvedores deve ter cinco itens de planejamento
de depuração, um item para cada desenvolvedor, de modo que as datas geradas pelo “PBE”
(Planejamento Baseado em Evidência) estejam corretas.
Ignore as necessidades de negócio (e o seu gerente)
Muitos gerentes de software iniciantes pensam que podem “motivar” seus programadores a
trabalhar mais rápido estabelecendo cronogramas legais e apertados (irrealisticamente curtos). Esta
é uma forma retardada de motivação. Grande parte dos desenvolvedores, quando atrasados no
cronograma, sentem-se condenados, deprimidos e desmotivados. Quando estão adiantados no
cronograma, ficam animados e produtivos. Portanto, o cronograma não é o lugar para para se meter
medo nos programadores.
Por que gerentes ineptos tentam fazer com que os programadores acelerem o cronograma?
Quando o projeto começa, os gerentes técnicos saem, reúnem-se com o pessoal de negócio e voltam
com uma lista de funcionalidades que pensam que levarão cerca de três meses, mas que na realidade
vão demorar nove. Quando se pensa em desenvolver software sem pensar sobre os passos que
deverão ser seguidos, sempre se acha que vai levar um tempo n quando na realidade demorará 3n ou
mais. Quando se traça o cronograma real, adicionam-se todas tarefas e vê-se que o projeto vai se

3. estender por muito mais tempo do que se estimou originalmente. A realidade afunda.
Gerentes ineptos tentam solucionar isto procurando formas de fazer com que as pessoas trabalhem
mais rapidamente. Isso nunca funciona. É possível extrair 10% a mais de código dos
programadores, temporariamente, ao custo de tê-los 100% exauridos em um ano. Não é uma grande
vantagem, e é como se estivessem comendo os grãos destinados à semeadura.
Pode-se extrair 20% a mais de código dos programadores pedindo-lhe que trabalhem duro, sem se
interessar se estão ou não cansados. Isso resulta na duplicação do tempo de depuração. Uma tática
idiota que é na realidade um esplêndido tiro pela culatra.
O negócio é melhor servido se as estimativas forem tão realistas quanto possível. Durante o
planejamento deve-se ignorar completamente os pensamentos fantasiosos do cliente e focar no que
realmente vai acontecer.
Aprenda mais
Não é verdadeira a noção de que as estimativas de software são “um problema sem solução”. Na
verdade muitas organizações de desenvolvimento de software continuam na ignorância de tudo que
se aprendeu nos últimos 40 anos sobre como planejar o desenvolvimento de software e entregá-lo
no prazo, por outro lado há também muitos desenvolvedores que produzem cronogramas precisos e
os cumprem dentro de 5% a 10% de desvio.
O livro Software Estimation: Demystifying the Black Art, de Steve McConnell, publicado pela
Microsoft Press, ensina como estimar cronogramas de software.
Não se deve deixar de ler o livro: The Mythical Man-Month, de Frederick P. Brooks (Addison-
Wesley).
Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com
Veja também:
1 - Make Better Software
Make Better Software é um programa de seis semanas para o treinamento abrangente de equipes de
software de qualquer tamanho.
Você vai aprender alguns conceitos chave de desenvolvimento de software, os mesmos que Joel prega em
seu site, Joel on Software, e vê-lo em ação na Fog Creek Software, a empresa que ele criou em New York.
O curso é dividido em seis módulos e, cada módulo inclui:
• material impresso que deve ser lido com antecedência
• um DVD de uma hora para toda assistir junta (com legendas em Português)
• material de leitura adicional para as áreas em que se deseje um maior aprofundamento
• sugestões de tópicos para discussão com a equipe
É uma excelente forma para equipes de desenvolvimento dominarem as técnicas que fizeram a
Fog Creek obter sucesso
Veja mais detalhes clicando aqui

4. 2 - Gerencia de Projetos e outras Funcionallidades - FogBugz 8.0
O FogBugz, ferramenta WEB para gerencia de projetos, administração de bugs, planejamento por
evidencias e outras funcionalidades acaba de lançar a versão8.0.
O FogBugz 8.0 é uma nova versão que é o resultado de dois anos de desenvolvimento.
Este documento descreve a multiplicidade de melhorias que fazem do FogBugz a ferramenta definitiva
para o acompanhamento de projetos.
Novas Funcionalidades
• Subcasos: A implementação de subcasos no FogBugz lhe permite decompor seu trabalho em
frações gerenciáveis.
• Planejamento Baseado em Evidências v2.0: O PBE 2.0 está baseado nos poderosos algoritmos
de predição do PBE
• Gráficos de Consumo: O Gráfico de Consumo exibe a previsão de horas restantes para se atingir
um marco do projeto ao longo do tempo, fornecendo ao gerente do projeto uma boa noção do
progresso global.
• Tags: permitem que os usuários atribuam palavras-chave pesquisáveis aos casos do FogBugz e
• Exportar para o Excel: Veja sua lista de casos off-line usando a funcionalidade Exportar para o
Excel, que se encontra sob o menu Mais na barra de ferramentas de filtro.
• Plugins do FogBugz: Os Plugins do FogBugz permitem que os administradores do site personalizem
e estendam o FogBugz adicionando-lhe novas funcionalidades, modificando seu comportamento,
e permitindo ao FogBugz integrar-se com outros aplicativos.Navegue e procure por Plugins
disponíveis na Galeria de Plugins do FogBugz
Use gratuitamente por 45 dias clicando aqui
Dica adicional: Ganhe dinheiro na internet sem sair da sua cadeira! Não perca tempo
acesse o link do meu convite, Faça seu cadastro e comece a ganhar hoje mesmo!
http://www.e-mail.net/prcm29
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 -
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.