Comentários em: planejamento ágil de projeto

Por: Algemiro T Maia

Algemiro T Maia — Mon, 24 Oct 2011 12:29:12 +0000

Cheguei a esse post através de busca sobre iniciar um planejamento de atividades na criação de projetos de software. Muito interessante, gostei muito do nível dos participantes, e da forma como os assuntos são tratados e esclarecidos.

Por: Clavius Tales

Clavius Tales — Wed, 08 Jul 2009 13:15:43 +0000

Oi, Milfont.

a hora ideal de programação que considero tem que se levar em conta se a empresa já passou pelo knowhow de ter desenvolvido um sistema com características semelhantes

Imagino que as estimativas já absorvam esse tipo de questão. Ou seja, as pessoas vão naturalmente estimar “tempos” maiores se o domínio não é tão conhecido.

Por: Clavius Tales

Clavius Tales — Wed, 08 Jul 2009 13:06:07 +0000

Oi, André.
Estimamos no começo sim, o projeto todo. Mas como disse, em geral os agilistas têm uma percepção diferente em relação a essa estimativa. Está mais para uma noção de grandeza do que para um dado preciso. Ou então encara-se como um orçamento, do tipo: “Faça o melhor possível com esse orçamento.” Além disso, quanto maior o projeto, maior o grau de incerteza. Isso tudo precisa ser levado em conta. Outra coisa que os agilistas costumam fazer é um ajuste constante do planejamento (aqui na Fortes por exemplo monitoramos semanalmente). Assim, se a estimativa original estiver fugindo demais da realidade, podemos renegociar e reestimar.

Por: André

André — Wed, 08 Jul 2009 02:13:49 +0000

Olá Tales,

Cheguei a este post através da lista scrum-brasil. Muito legal a tua explicação sobre o assunto.
Pelo que eu entendi, da mesma forma que a maneira tradicional, tu estimas o projeto todo de uma vez, provavelmente no começo do projeto. É isso?

Por: CMilfont

CMilfont — Sun, 05 Jul 2009 22:52:09 +0000

Tales, a hora ideal de programação que considero tem que se levar em conta se a empresa já passou pelo knowhow de ter desenvolvido um sistema com características semelhantes entre outros aspectos.
Agora o principal, complexidade de um algoritmo nem sempre é a complexidade do que é necessário para dominar esse algoritmo e sim knowhow das pessoas envolvidas no processo, exemplifico:
Imagine um algoritmo que necessite calcular a rotação de uma matriz, tome um programador que saiba algebra linear e é muito bom em matemática, essa operação que é trivial para ele vai ser calculada com um esforço grande por todo o time [provavelmente] e uma atividade que foi calculada como um esforço pequeno como por exemplo um CRUD com muitos relacionamentos que precisava de um bom conhecimento em ORM se mostrou levar mais tempo do que o necessário.
Claro que em um processo ágil que haja realmente boa comunicação, isso pode e vai ser minimizado porque o desenvolvedor deverá convencer a todos que a tarefa não é tão cabulosa como todos imaginam.
Isso já aconteceu muito comigo, lembro de uma tarefa que era fazer busca textual e foi considerada de alta complexidade pelo time mas como eu já tinha feito isso antes e sabia o caminho das pedras eu calculei um tempo muito pequeno e foi cumprida no prazo acordado.
Então, esses pontos modificam a ordem de grandeza da velocidade do time e deve ser ajustada de projeto a projeto de acordo com o KnowHow dos envolvidos, eu acredito muito no conselho do Kent Beck para contratar consultores especialistas para facilitar esse andamento.
Aproveitando esse parágrafo e já mudando de assunto:
Eu estou vendo isso na prática hoje em um cliente [que até já falei para você], como um especialista inserido no time conseguiu dar uma agilidade e fazer ultrapassar a concorrência com menor esforço e menos recursos.

Por: Clavius Tales

Clavius Tales — Sun, 05 Jul 2009 22:01:13 +0000

Oi, Milfont.

Sobre as métricas, Tales, temos que considerar que nas “horas ideais” variam de projeto a projeto e essa variação no final de contas é um chute mesmo. Muitos atribuem 30% para a variação, outros preferem até 50%.

Não entendi esse esquema de que horas-ideais variam de projeto para projeto, mas concordo que é um chute mesmo, mas com um certo controle, com uma certa técnica. É só uma forma de dar uma macroestimativa do projeto, de ter uma noção de grandeza. Aí entra o que citei sobre o acompanhamento, como o planejamento é encarado pelos agilistas. Quando uma gravadora dá um ano para uma banda produzir um disco, não quer dizer que a coisa é feita da seguinte forma: serão quinze canções, então vocês devem me entregar uma canção a cada 24 dias.

Por: CMilfont

CMilfont — Sat, 04 Jul 2009 20:07:19 +0000

Esses mitos de XP são bem curiosos mesmo, considerando a larga bibliografia já lançada nos últimos 10 anos, creio que XP tem maturidade sufiente para planejar adequadamente um projeto de software, mas é aquela coisa, não tem o charme “Project Management” que o Scrum atraiu. vai entender.
Sobre as métricas, Tales, temos que considerar que nas “horas ideais” variam de projeto a projeto e essa variação no final de contas é um chute mesmo. Muitos atribuem 30% para a variação, outros preferem até 50%.
Qualquer dia escrevo um post sobre homem/hora e porque o tempo é ralativo
Blogue mais, tá muito parado aqui e estamos ansiosos pelos seus textos…