Transcript
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 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. www.olympya.com
www.fogcreek.com.br
www.futweb.com.br
Como planejar tarefas de desenvolvimento de software 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 www.olympya.com
www.fogcreek.com.br
www.futweb.com.br
Como planejar tarefas de desenvolvimento de software 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 azdoctips: 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 em: http://www.azdoctips.com/doc/29112680/Make-Better-Software-V1 Fora do azdoctips
2 - Gerencia de Projetos e outras Funcionallidades - FogBugz 8.0
O FogBugz é um sistema completo de gerência de projeto e da vida do produto concebido para auxiliar a comunicação nas equipes de software. Este sistema ajuda as equipes a trabalharem juntas controlando, priorizando e coordenando milhares de pequenas tarefas que realizam no dia-a-dia e propicia a produção de softwares melhores. É um produto web e, por isso, toda equipe tem sempre a perspectiva global do projeto. Solicitações de novas funcionalidades, email para clientes e bugs são facilmente registradas e acompanhadas. O FogBugz é uma criação de Joel Spolsky, do famoso blog Joel on Software. Pode ser instalado num servidor web
www.olympya.com
www.fogcreek.com.br
www.futweb.com.br
Como planejar tarefas de desenvolvimento de software dedicado ou pode ser usado sob assinatura diretamente dos servidores da Fog Creek.
O FogBugz é um sistema integrado que inclui:
Um wiki, onde se pode criar e compartilhar documentos e especificações técnicas;
Um sistema de gerenciamento de projetos, em que se pode acompanhar o progresso do trabalho, inclusive os bugs e o desenvolvimento de novas funcionalidades;
O premiado sistema de acompanhamento de bugs, incluindo geração automática de inúmeros relatórios para acompanhamento de projeto.
Planejamento baseado em evidências, um sistema sofisticado para gerar um cronograma e estimar a probabilidade de cumprí-lo no parágrafo XIII incluímos um gráfico de probabilidades da etapa 1 extraído do sistema;
Grupos de discussão e email, para se comunicar com clientes.
Completa integração com o Kiln, cujas funcionalidades serão descritas a seguir.
Estes recursos funcionam de modo a manter toda equipe atualizada e permitir que os projetos sejam, literalmente, autogerenciados.
www.olympya.com
www.fogcreek.com.br
www.futweb.com.br
Como planejar tarefas de desenvolvimento de software A recém-lançada versão 8.0 do FogBugz representa uma revisão completa do produto para melhorar ainda mais Seu desempenho e facilidade de uso. Sugestões de clientes resultaram em centenas de aprimoramentos nesta Última versão. O sistema Kiln (http://fogcreek.com/kiln/) fornece uma solução integrada para controle de versão baseado na tecnologia de código livre Mercurial (http://mercurial.selenic.com/). O Kiln adota o novo paradigma de controle de versão distribuído, permitindo uma colaboração mais flexível e robusta entre os diversos analistas/programadores envolvidos no projeto. A alta integração do Kiln com o FogBugz permite também um processo estruturado (porém simples) de revisão de código — prática essencial para o controle contínuo de qualidade ao longo de todo o processo de desenvolvimento. Joel Spolsky é autor de vários livros sobre desenvolvimento de software, gerência, negócios e Internet. Tem uma reputação internacional de guru na área de usabilidade. Sua empresa Fog Creek Software publica, além do FogBugz, o Fog Creek Copilot e o Kiln. No Brasil e em Portugal, a Olympya Software é a parceira exclusiva da Fog Creek Software (http://www.fogcreek.com.br) e provê suporte aos seus produtos para os clientes brasileiros e portugueses.
Fogbuguz 8.0: Visite www.fogcreek.com.br e aprenda mais sobre este novo release Aprenda mais sobre a Olympya Software, empresa que representa a Fogcreek no Brasil, visitando www.olympya.com . A nossa empresa também desenvolve games e, se você se interessa por esta área visite o site do FutWeb: MMO game de futebol que estamos desenvolvendo – www.futweb.com.br
http://www.azdoctips.com/doc/44456174/FutWeb-MMO-game-online-de-futebol
http://www.azdoctips.com/doc/14226730/Projeto-FutWeb-Game-MMO-de-Futebol
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.
www.olympya.com
www.fogcreek.com.br
www.futweb.com.br
