Claro que sou suspeito para falar deste assunto, já gerenciei muitos e muitos projetos usando cronogramas, estimativas de esforço com uso pontos de função, casos de uso de dezenas de páginas, levantamentos de requisitos de meses, milhoes de reais investidos e no final, NINGUEM satisfeito milhões de reais perdidos e projeto atrasado em meses pra não dizer anos.

Vários aqui já disseram e eu concordo, é IMPOSSIVEL mapear tudo o que vai acontecer em um projeto com meses de antecedencia, com ou sem margem de segurança, requisitos mudam, pessoas mudam, empresas mudam e o mercado muda. Projetos precisam se adaptar rapidamente pois os clientes na maioria das vezes não sabem o que querem, e vão descobrindo isso com o andamento do projeto. Não dá pra trabalhar escrevendo _Change Requests_ toda vez que um cliente muda de idéia, isso vira um inferno de aprovação de documentos, trava o andamento e atrasa de vida de todo mundo.

Depois de passarmos a usar SCRUM, conseguimos adicionar compromisso e comprometimento as pessoas da equipe, demos poder a elas para decidir o que é melhor ser feito para atingir ao Goal do Sprint/Release, e quando vc dá empowerment ao time as coisas decolam sozinhas, as estimativas ficam mais precisas, as entregas são feitas com qualidade e o time melhora sozinho. Estou realmente impressionado com o que conseguimos fazer e no tempo que conseguimos fazer usando SCRUM e o melhor é que nunca tive clientes tão satisfeitos, e não precisamos perder tempo e dinheiro com MS Project.

“Um dia desses conversando com os estagiários de onde trabalho, fiquei assustado, pois todos saem “inocentes” pensando que este tipo de abordagem (cronogramas gigantes e chutados) funciona.”

é verdade! e agora fiquei super decepcionado com o professor, por nos ter ensinado algo inútil e não eficaz para o desenvolvimento de software…
e ele ainda dizia – “coloquem em seus currículos que agora vcs sabem usar MSProject / Gantt Charts” .. meu deus, tirei o mais rápido que pude!!! =))

abraços !

Bom Guilherme, “caso algo aconteça diferente” o seu cronograma vai te dar subsídio para suas ações. Se na tarefa de “integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP” o gerente de projetos, que juntamente com sua equipe ou colhendo opiniões especializadas, estimou 10 dias e colocou junto dessa tarefa, visto o risco percebido no planejamento, uma folga de mais 5 dias, todas essas informações irão estar no cronograma. Ou melhor, porque não prever no cronograma um tempo para planejamento do que ainda estar por vim no projeto, e aí sim, após esse planejamento, que já esta r previsto, definir componentes mais específicos, já que se trata de algo muito específico.

Concordo em parte com as suas colocações, apenas reintero o que falei anteriomente, se é pra generalizar, eu não diria que cronogramas não funcionam, eu diria que existem muitos cronogramas que não funcionam, mas é como falo no posto anterior, depende de muitos fatores.

Fabiano, entendi tua colocação!

[]s

sucesso!

Oi, Márcio!
Tudo beleza?
Este seu questionamento me fez refletir sobre o que havia escrito acima (”é fato que clientes ficam extremamente felizes com pequenas entregas modularizadas”).
Você tem razão, o uso de cronogramas NÃO É inversamente proporcional às pequenas entregas.
Fui pontual e acabei usando um exemplo que acontece MUITO dentro de algumas áreas da nossa fábrica de software: o coordenador do projeto é o ÚNICO a receber/cobrar as pequenas entregas definidas no cronograma.
O cliente só vê/cobra o produto na data final do cronograma e, quando o projeto como um todo atrasa, e quase sempre atrasa, temos problemas …
Não é dos melhores modelos de coordenação/gestão de desenvolvimento de software, de fato, e acabei generalizando e me expressando mal.

No mais, o Thiago foi brilhante!

Grande abraço!

“Mas caso algo aconteça diferente, não precisa jogar fora seu cronograma, pelo contrário, nessa hora ele vai ser extremamente útil.”

Curiosidade: para que exatamente?

[]s

FATO 1: Atuo há 12 anos na área de desenvolvimento de software e NUNCA ví um cronograma acertar em 100% DA MANEIRA INICIAL COMO FOI CONCEBIDO, seja esta maneira uma técnica empregada ou “achismos” dos profissionais envolvidos na elaboração do cronograma. Os casos de sucesso que ví foram estimativas “astronomicamente-bicadas-para-cima-e-entubadas-pelo-cliente”, sendo que alguma delas, ainda assim, andaram por muitas rodadas finais na zona de rebaixamento.

FATO 2: Clientes ficam extremamente mais felizes com pequenas entregas modularizadas, afinal, eles acompanham e participam ativamente da evolução do software – como bem empregou o Guilherme em seu texto -, mesmo que a data final estimada para a entrega do software atrase um pouco.

Infelizmente, o cronograma é um mal necessário. Culturalmente, está enraizado como uma forma de garantir ao cliente a data de entrega do serviço completo. Também acredito que não exista uma fórmula mágica para elaborá-lo e que, por desenvolvimento de software lidar diretamente com o fator humano, é preciso estar atento para os problemas mundanos. Acredito que a melhor prática para a entrega de software ainda é ser bastante transparente com seus clientes com relação ao andamento do desenvolvimento do seu software.
Levantar a bandeira amarela é sempre bem-vindo!

Grande abraço a todos!

Isso serve se você trabalhar sempre em projetos iguais, caso contrário suas experiências de projetos anteriores não valem totalmente para o próximo.

Vamos fazer uma brincadeira. Sou seu cliente e quero que você encha para mim 200 balões. Quero eles todos cheios e amarrados na minha frente. Nas primeiras vezes você não vai conseguir estimar corretamente mas com o tempo você saberá exatamente e velocidade que você leva e poderá fazer cálculos simples para ter estimativas bem precisas independente da quantidade de balões que eu pedir. Ok.

Agora vamos falar de _desenvolvimento de software_:

- De projeto para projeto as pessoas mudam, portanto a velocidade de excução do trabalho muda;
- A quantidade de pessoas muda, o que torna o cúlculo ainda mais difícil (as pessoas nunca produzem igual);
- Pessoas ficam doentes (mês passado fiquei 5 dias fora porque operei o rim, por exemplo);
- Pessoas pedem demissão e você precisa subistituí-las no meio do projeto. As vezes você está perdendo um analista sênior com vastos 5 anos de experiência no negócio e está substituindo por uma pessoa super competente mas que não tem a menor idéia do projeto. Ou seja, a velocidade _vai_ mudar;
- As tecnologias mudam. Hoje você pode ter que desenvolver um site em PHP mas amanhã pode ser em Java e depois Ruby. E a velocidade denovo muda…

Enfim, eu poderia passar duas horas aqui te dando vários motivos para você não conseguir acertar.

Concordo com a seguinte frase que você escreveu: “com o acúmulo das experiências, cada vez a estimativa é feita melhor”.

Se você encher balões para o resto da vida isso será verdade. Para projetos de software que mudam a cada dia isso não funciona!

E pra finalizar, se algum dia você fosse meu cliente e tivesse a oportunidade de participar de um projeto de verdade e entendese isso tudo, certamente você não ia querer ser cliente de mais nenhum outro

[ ]s, gc

Em momento algum disse que Scrum é a solução para todos os problemas. No nosso aqui na Globo por acaso usamos Scrum, mas poderia ser XP, ou “papel de pão” ou qualquer outra coisa. Não usamos nenhuma “fórmula mágica”, apenas usamos ferramentas que funcionam.

O ponto aqui é que _não é possível_ prever uma cadeia de acontecimentos em um projeto de software e acertar na mosca. É _impossível_, simples assim. Na minha opinião só se faz isso para ter uma falsa impressão de controle. O cara quer chegar numa determinada data e olhar para o cronograma para saber se está bem ou não. Mas quem disse que o cronograma vai estar certo? Nada impede de na última semana você descobrir um mega problema e atrasar a entrega em um mês, por exemplo, _mesmo que todo os 6 meses anteriores do projeto tenham sido feitos no tempo_. Eu já ví isso acontecer muitas vezes. Para ser mais exato, só nesse ano aconteceu em aproximadamente 50% dos projetos que participei. E em quase 10 anos de profissão o que eu sempre ví foram cronogramas que não funcionam.

Portanto insisto que não acredito em cronogramas, mas isto é minha observação pessoal baseada na minha experiências ao longo da vida. Ninguém é obrigado a concordar

[ ]s, Guilherme