Como - Planejar - Tarefas - de - Desenvolvimento - de - Software, Notas de estudo de Engenharia Elétrica

Baixe Como - Planejar - Tarefas - de - Desenvolvimento - de - Software e outras Notas de estudo em PDF para Engenharia Elétrica, somente na Docsity! Como planejar tarefas de desenvolvimento de software www.olympya.com www.fogcreek.com.br www.futweb.com.br 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 sabe 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 torna-se bons estimadores depois de um ano de experiência. Leve em conta férias, feriados, reuniões, etc. Como planejar tarefas de desenvolvimento de software www.olympya.com www.fogcreek.com.br www.futweb.com.br 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