jump to navigation

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

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

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

Link para o original:

https://plus.google.com/112218872649456413744/posts/9oYqAoSRaR4

Com um pouco de cuidado é possível criar cronogramas razoavelmente precisos para desenvolvimento de softwar. No entando, desenvolvimento não é a única parte/tarefa de
engenharia de software. Debugging (me recuso a traduzir) é um aspecto que toma um tempo significante. Por conta disso, Debugging não pode ser ignorado no cronograma.

O problema é que o tempo de debugging não pode previsto: Se fosse possível saber quais bugs seriam feitos durante o desenvolvimento, esses bugs não seriam feitos.

A única maneira de prever é fazer estimativas brutas, que podem ser lapidadas por uma equipe. Como uma regra, quando estiver planejando o tempo utilizado, o ponto de
inicial é assumir que o tempo de debugging será o mesmo de desenvolvimento. Essa não é uma regra, e a realidade irá variar de acordo com a equipe e produto/projeto,
mas é melhor do que nada.

Quando todo o desenvolvimento for finalizado e o único trabalho restante for o debugging, é possível olhar com mais precisão. Nesse ponto, minha regra de ouro para
ponto de partida é que cada bug leva cerca de meio dia ser resolvido. É importante lembrar do primeiro artigo da série onde analistas não tem 100% do tempo deles
disponível, então não é provável um analista resolver 10 bug em uma semana, e a realidade será próxima de 5 bugs corrigidos por semana.

Para finalizar, bugs são imprevisíveis e diferentes. Se analistas tendem a corrigir os bugs fáceis primeiro, os únicos bugs que irá restar são os difíceis. Para evitar situações onde os bugs mais críticos e sem previsão são deixados por último, é importante fazer a correção de forma balanceada. Hoje, minha tática preferida é gerar um hash com o número do bug e priorizar a ordem ordenando as hashkeys.

Não importa o método, planejar qualquer faze de debugging é imprevisível e imprecisa. A única maneira de melhorar nesse ponto é coletar informação dos ciclos de desenvolvimento anteriores e aplicar nos ciclos futuros com o mesmo time e/ou produto.

Posts futuros nessa série irão falar sobre alocações incertas em grandes equipes e estouros de cronograma.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

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/

Veja também a parte #2 da série sobre construição de cronogramas quebrando as tarefas em tarefas menores
https://rzaratin.wordpress.com/2012/06/01/dicas-truques-2-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/