Sim, m cronograma “de verdade” (e eu jah irritei muitos PMs camando os cronogramas deles de “de mentira”) precisa saber a produtividade para ter um mnimo de precisao. O ponto eh que isso nao eh dado desta forma.

Recomendo a leitura sobre o conceito de “velocidade” que eh aplicado a times ageis. Eh ma metrica factivel e bem proxima da realidade para ser utilizada nestes casos.

[]s

Os comentários que você tece fazem todo sentido, mas preciso fazer uma ressalva. O exemplo da alvenaria não se propõe a comparar um pedreiro com um programador, o que aliás seria desprovido de sentido. O que quis alertar é que o conhecimento das produtividades é crucial para um cronograma factível. Programadores também têm produtividade. Ou não?

Parabéns pelos textos!

Vou escrever sobre gerenciamento de projetos de software na MJ de novembro. Sugerí o mesmo tema para a MundoPM, para ver se esses GPs abrem a cabeça. Mas acho que está Xiita demais para a MundoPM. A alma do artigo é “não confunda tradicionalismo com burrice”.

Rodrigo Yoshima

A galera esta toda lendo você… realmente teus post são campeões de audiência… aprendeu com quem?

Olha construção civil não esta tão bem assim não, mesmo sendo projetos com caracteristicas muito menos complexas, incertas, e imutaveis….

Existe um método muito parecido a Scrum, da Lean Construction Institute, que se utiliza de Post-Its e onde quem planeja são as pessoas que executam, ele se chama LPS (Last Planner System) e com ele tem conseguido em construções complexas reduzir o time to market em até 50%, e em complexos hospitalares onde a quantidade de detalhes é muito grande estão conseguindo baixar o retrabalho, aumentar o valor e criar soluções sob demanda difíceis de ser planejadas upfront.

O problema todo é definir quais são os requisitos e parâmetros mínimos de funcionamento de cada método e suas tolerância, por exemplo:

Qual o grau de tolerancia de variancia?
30x de produtividade entre desenvolvedores

Qual o grau de Tolerancia de incertezas?
Os usuarios e clientes tem dificuldade em determinar o que precisam antes de ver alguma coisa.
Até 70% das funcionalidades não agrega valor.
Grandes partes da solução podem perder valor rapidamente por mudanças no mercado, nas tecnologias, ou no modelo de negócios, durante o projeto.

Qual o grau de Tolerância a mudanças?
Grande maioria dos detalhes das funcionalidades do produto mudam durante o projeto, por conta do conhecimento que vai sendo gerado durante o processo.

Se usamos um metodo para um trabalho que requer parametros que estão dentro da zona impossivel estamos usando o metodo errado, e ponto.

Não é bala de prata é bobagem por exemplo eu querer fazer um plano “tatico” de compras e vendas de ações no day trading de 1 mês, vou me ferrar legal a menos que tenha bola de cristal. Porem posso fazer um plano “estrategico” definindo objetivos, pontos de compra e venda para garantir uma margem x%, um conjunto de ações com as quais vou trabalhar, etc. mais não quando vou comprar e vender o que, porque estou trabalhando com niveis de incertezas maiores que as que esse metodo pode me dar bons resultados, ele “sempre vai falhar” ou se tiver sucesso será por conta de uma sucessão de fatores externos dos quais não tenho controle, mesmo que faça analises de risco, trabalhe a moral do meu operador de bolsa, beije um santinho antes, as chances vão estar contra mim na maior parte do tempo.

Bom me inspirei… um blog dentro de um blog… sacanagem….

Abraços,
Juan.

Nunca gostei de tentar colocar engenharia num processo ‘artistico’. Uma das piores abordagens é o mal uso do conceito de “Fábricas de Software”. Tem empresas que realmente tratam (ou tentam) o processo de criação de software como um processo segmentado e fragmentado. Já vivi absurdos onde um analista analisa (tudo) passa para a Fábrica (tudo) e os programadores devem implementar isso sem recorrer aos analistas, se procurassem um analista e porque ou o analista não produziu um documento conciso ou o programador não entendeu o documentos…. um processo onde Analista cria produto A, programador com produto A implementa e entrega software, sem poder voltar, como numa esteira…. Temos muito o que aprender e rever E MAIS IMPORTANTE NÃO ACEITAR TUDO ASSIM TÃO FACILMENTE….

Perfeito! Substituindo a frase por algo menos tendencioso.

Gostei muito do texto e também de saber que vc é fã do trabalho do Brooks. Parabéns!

Mas o chato não podia deixar de colocar um alerta: a frase abaixo pode parecer a descoberta de uma ‘bala de prata’:

“A solução que nós estamos achando é simples: métodos ágeis.”

Ok: “estamos achando”. Pq tem muita bobeirinha que aparece também em algumas propostas ágeis. Do nível daquelas do Aldo.

Abraços,