jump to navigation

Dicas / Truques #2 para criação de cronograma de desenvolvimento de software (tradução) 01/06/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

O Jean-Baptiste Queru soltou a segunda dica dele, segue a tradução.

Link para o original: https://plus.google.com/u/0/112218872649456413744/posts/hGfwXrURjZD

Em desenvolvimento de software, os detalhes são os grandes vilões. Tarefas que parecem simples em alto nível, geralmente revelam complexidades inesperadas quando investigados os detalhes.

Esse é o motivo de ser impossível estimar o tempo de uma tarefa olhando apenas no alto nível. A única maneira de estimar o tempo é quebrar as tarefas, pequenas o suficiente para serem colocadas na cabeça de uma pessoa.

Além disso, como todo analista é diferente, cada tarefa deve ser estimada pelo analista que irá efetivamente fazer o trabalho. Estimar o tempo de cada tarefa individualmente é parte do design do projeto. *

Outra dica importante é que estimativa de tempo não pode ser feita por apenas uma pessoa, é sempre melhor feita em dupla. Por ter que explicar a tarefa para outra pessoa, o analista que está estimando o tempo diminui a velocidade da tarefa o suficiente para permitir que possa ver detalhes relevantes.

Minha regra de outro é que tarefas precisam ser quebradas até prazos que demorem entre meio dia e dois dias, com granularidade de meio dia. Tarefas com mais de dois dias são complexas demais para serem estimadas. Tarefas também não podem durar menos de meio dia, por conta do tempo que será necessário para compilar o código, instalar, executar os testes e fazer uma revisão do código.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

* Aqui coloco um comentário meu, muitos analistas tem o costume de estimar para baixo o tempo de conclusão de uma tarefa, achando que assim irão agradar o gerente, o problema é que isso pode gerar diversos problemas como não entrega da tarefa no prazo estimado, o que pode comprometer todo o cronograma do projeto e o trabalho de outros analistas. Nesse caso acho que é interessante sempre ter um analista sênior acompanhando os mais novos.

Veja também a parte #1 da série sobre quanto tempo de um analista pode realmente ser considerado no cronograma
https://rzaratin.wordpress.com/2012/05/31/dicas-truques-1-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Dicas / Truques #1 para criação de cronograma de desenvolvimento de software (tradução) 31/05/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

Semana passada recebi um link de um artigo do Jean-Baptiste Queru (Software Engineer do Google) com dicas sobre estimativa de tempo de tarefas, ele fez algo focado em desenvolvimento de software, mas eu acredito que possa ser utilizado para diversos outros fins. Vou deixar aqui uma tradução do artigo.

Parte #1

Quem quiser ler o orginal, segue o link https://plus.google.com/u/0/112218872649456413744/posts/YZZrAbJeqdb

Criar cronogramas para desenvolvimento de software é difícil. Alguns consideram uma arte obscura. Aprendi alguns truques quem tornam o processo um pouco mais preciso. Aqui vai o primeiro truque.

Analistas vão para reuniões. Eles lidam com papelada. Eles fazem entrevistas. Eles treinam novos analistas. Eles preparam apresentaçãoes e demos. Eles participam de apresentação e demos. Eles vão à conferências. Eles apresentam palestras. Eles lidam com fornecedores. Eles lidam com clientes. Eles lidam com usuários. Eles tiram folgas. Eles perdem tempo com builds quebrados. Eles contribuem com alterações de código. Eles configuram suas estações de trabalho e outras ferramentas. Eles fazem manutenção de código de outras versões/tarefas.

Todas essas tarefas são comuns à Analistas . E elas precisam ser levadas em consideração quando o cronograma está sendo preparado. No entendo, elas não devem ser parte da estimativa de nenhum projeto.

Minha dica para criação de cronogramas é considerar que analistas tem cerca de 50% do tempo deles disponvíel para a tarefa que foi programada. A outra metade vai para as tarefas indiretas mencionadas acima. Se uma tarefa para uma pessoas está estimada em 20 man-days, existe uma boa chance dessa tarefa levar cerca de 2 meses para ser finalizada em condições normais de trabalho.

O valor 50% é apenas uma estimativa. Esse valor fica provavelmente entre 40% e 60% na maioria dos casos. Em casos extremos esse valor pode ser acima ou abaixo. No entando, não existe a menor chance de um analista conseguir produzir 1 man-day por dia de trabalho sem que sejam feitas significantes e insustentáveis horas extras.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0