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.

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

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 (AddisonWesley). Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com Veja também, aqui no scribd: 1 - Make Better Software

Make Better Software é um programa de seis semanas para o treinamento abrangente de equipe software de qualquer tamanho. Você vai aprender alguns conceitos chave de desenvolvimento de software, os mesmos que Joel seu site, Joel on Software, e vê-lo em ação na Fog Creek Software, a empresa que ele criou em N 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 em: http://www.scribd.com/doc/29112680/Make-BetterSoftware-V1

2 - Gerencia de Projetos e outras Funcionallidades - FogBugz 7.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ão 7.0. O FogBugz 7.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 a um marco do projeto ao longo do tempo, fornecendo ao gerente do projeto uma boa noç progresso global. • Tags: permitem que os usuários atribuam palavras-chave pesquisáveis aos casos do FogBugz e Páginas do wiki. • Exportar para o Excel: Veja sua lista de casos off-line usando a funcionalidade Exportar par 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 perso e estendam o FogBugz adicionando-lhe novas funcionalidades, modificando seu comport e permitindo ao FogBugz integrar-se com outros aplicativos.Navegue e procure por Plugin disponíveis na Galeria de Plugins do FogBugz. • Workflow Personalizado: Por padrão, o FogBugz fornece um workflow intencionalmente sim para a solução e o fechamento de casos. Fog Bugz 7.0, Veja mais informações e use o produto gratuítamente por 45 dias visitando: http://www.fogcreek.com.br/Fog Bugz/ Veja este artigo completo e, outros a respeito de desenvolvimento de Software e gerencia de projeto em: http://www.scribd.com/groups/view/10541-desenvolvimento-e-gerencia-de-software

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.

Sign up to vote on this title
UsefulNot useful