Your SlideShare is downloading. ×
Como Planejar Tarefas De Desenvolvimento De Software[1]
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Como Planejar Tarefas De Desenvolvimento De Software[1]

1,026
views

Published on

Planejando o desenvolvimento de software …

Planejando o desenvolvimento de software
Atividade necessária, ardua e dificil, veja o que o Joel Spolsky da http://www.fogcreek.com escreveu sobre este assunto
A construção de cronogramas de desenvolvimento de software é um conhecimento profissional, não uma arte. 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.
A Olympya Software - www.olympya.com.br - é também a representante exclusiva no Brasil e Portugal da FogCreek, http://www.fogcreek.com.br empresa fundada pelo Joel Spolsky.

Você pode usar gratuitamente por 45 dias o produto FogBugz 7.0, totalmente web, para gerencia de projetos e outras funcionalidades, visitando o link http://try.fogbugz.com

A Olympya também é representante de um novo produto da FogCreek, para treinamento em engenharia de software. Este novo produto foi lançado desde o inicio em Português veja mais detalhes em:

http://training.fogcreek.com.br – venda sem instrutor.

Para ver a nossa oferta que inclui assistência com nossos instrutores na Avenida Paulista, em Copacabana ou na sua empresa, veja:

http://www.scribd.com/doc/29112680/Make-Better-Software-V1

Se você é fã de futebol e ou de games, visite: www.futweb.com.br

Published in: Education

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,026
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Como planejar tarefas de desenvolvimento desoftwareA construção de cronogramas de desenvolvimento de software é um conhecimento profissional, nãouma arte. Seguem algumas dicas para se conseguir melhores cronogramas.Deixe os desenvolvedores planejarem seu próprio trabalhoQualquer 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 passosnecessários para implementar aquela funcionalidade específica. E só o programador é capaz deestimar o tempo que cada tarefa vai levar.Conceba antes e com detalhesTentar planejar o desenvolvimento de uma função antes de entender, detalhadamente, como ela vaifuncionar 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 desenvolvimentode software é que o que parece simples é, freqüentemente, muito complicado quando analisado emdetalhe. Por exemplo: se pensar em criar um sistema de registro e logon, você pode esquecer quevai ser necessário um processo que evite que as senhas sejam as mesmas que o nome do usuário, eum processo para lidar com senhas esquecidas, e uma forma para as pessoas se desregistrarem eassim por diante. Até que se entenda o efeito, na concepção do projeto, de cada uma dessaspossibilidades, não existirá qualquer fundamento para um bom plano.Decomponha tudo nos seus mínimos detalhesEsta é a coisa mais importante para que um plano realmente funcione. O trabalho precisa sermedido em horas, não em dias. (Qualquer cronograma que utilize dias ou semanas, não deve serválido). Pode-se pensar que um cronograma com tarefas planejadas em termos de tempo muitocurtos é apenas mais preciso. Errado! Muito errado! Quando se começa um plano com tarefas muitoabrangentes e depois as divide em tarefas menores, o resultado é muito diferente, não é apenas umcronograma 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 temde realizar. Escrever a subrotina foo. Criar o diálogo tal e tal. Ler o arquivo wawa. Estes são passossimples 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 aindanã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 40horas (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. Aoescolher uma funcionalidade como “Integração com a Internet” e planejá-la em três semanas, seuplanejamento provavelmente vai falhar. Se você tiver que determinar quais subrotinas serãodesenvolvidas, você se força a definir com precisão a funcionalidade. Ser forçado a planejar nestenível elimina muitas instabilidades de um projeto de software.
  • 2. Acompanhe a execução do cronograma e aprenda com seuserrosA maioria dos programadores não sabem como estimar a duração das tarefas. Sem problema. Desdeque eles estejam continuamente aprendendo e continuamente atualizando suas estimativas enquantoaprendem, 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 constantementequando funcionalidades devem ser reduzidas ou adiadas). A maioria dos programadores tornam-sebons 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. NoFogBugz, é possível estabelecer feriados comuns e cada desenvolvedor pode, também, informar seupró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 paracada desenvolvedor. Uma equipe com cinco desenvolvedores deve ter cinco itens de planejamentode 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 atrabalhar mais rápido estabelecendo cronogramas legais e apertados (irrealisticamente curtos). Estaé uma forma retardada de motivação. Grande parte dos desenvolvedores, quando atrasados nocronograma, sentem-se condenados, deprimidos e desmotivados. Quando estão adiantados nocronograma, ficam animados e produtivos. Portanto, o cronograma não é o lugar para para se metermedo 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 voltamcom uma lista de funcionalidades que pensam que levarão cerca de três meses, mas que na realidadevão demorar nove. Quando se pensa em desenvolver software sem pensar sobre os passos quedeverão ser seguidos, sempre se acha que vai levar um tempo n quando na realidade demorará 3n oumais. 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 trabalhemmais rapidamente. Isso nunca funciona. É possível extrair 10% a mais de código dosprogramadores, temporariamente, ao custo de tê-los 100% exauridos em um ano. Não é uma grandevantagem, 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 seinteressar se estão ou não cansados. Isso resulta na duplicação do tempo de depuração. Uma táticaidiota 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 oplanejamento deve-se ignorar completamente os pensamentos fantasiosos do cliente e focar no querealmente vai acontecer.Aprenda maisNão é verdadeira a noção de que as estimativas de software são “um problema sem solução”. Naverdade muitas organizações de desenvolvimento de software continuam na ignorância de tudo quese aprendeu nos últimos 40 anos sobre como planejar o desenvolvimento de software e entregá-lono prazo, por outro lado há também muitos desenvolvedores que produzem cronogramas precisos eos cumprem dentro de 5% a 10% de desvio.O livro Software Estimation: Demystifying the Black Art, de Steve McConnell, publicado pelaMicrosoft 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.comVeja também:1 - Make Better SoftwareMake Better Software é um programa de seis semanas para o treinamento abrangente de equipes desoftware de qualquer tamanho.Você vai aprender alguns conceitos chave de desenvolvimento de software, os mesmos que Joel prega emseu 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.0O FogBugz, ferramenta WEB para gerencia de projetos, administração de bugs, planejamento porevidencias 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 definitivapara 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 FogBugzUse gratuitamente por 45 dias clicando aquiSobre o Tradutor:Paulo André de Andrade é Engenheiro Eletrônico e Diretor da OLYMPYA TI, responsável, noBrasil, 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 deComponentes para Hardware, Engenharia de Produtos de Hardware, Desenvolvimento de Hardwaree Software, Desenvolvimento de Negócios, Marketing e Vendas de Software e Consultoria emGerência de Projetos e em Serviços de Informática.