Metodologias tradicionais x Agile - O que resolve?

Pessoal,

em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem "acertar" estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).

Então, gostaria de saber de vocês... O que vocês consideram que seria uma solução para o problema?

Alexandre,

Conforme já conversamos pessoalmente, essa história de "trabalhar com dados definidos" para acertar uma estimativa é balela. Nunca funciona e neste exato projeto vendo isso na prática.

Mas como alguém conseguiria vender um projeto se alguma coisa não estivesse definida (seja prazo, custo, escopo) ? Acho (veja bem, acho!) que um cliente não gostaria de ouvir "olha, nós temos um prazo XYZ pra isso. Selecione o que você quer, marque o que é mais importante,que nós vamos usar somente esse prazo XYZ pra isso".

[]´s

JavaEvangelist Membro desde: 11/08/2008 08:10:37 Mensagens: 492 Offline

asaudate wrote:Mas como alguém conseguiria vender um projeto se alguma coisa não estivesse definida (seja prazo, custo, escopo) ? Acho (veja bem, acho!) que um cliente não gostaria de ouvir "olha, nós temos um prazo XYZ pra isso. Selecione o que você quer, marque o que é mais importante,que nós vamos usar somente esse prazo XYZ pra isso".

[]´s

acho que os clientes preferem ouvir isso do que ouvir que vão ter tudo pronto em XYZ, depois receber o programa em XYZ * 2 e ainda assim cheio de bugs que seriam corrigidos se ele tivesse acesso a alguma coisa em XYZ/2.

asaudate wrote:Mas como alguém conseguiria vender um projeto se alguma coisa não estivesse definida (seja prazo, custo, escopo) ? Acho (veja bem, acho!) que um cliente não gostaria de ouvir "olha, nós temos um prazo XYZ pra isso. Selecione o que você quer, marque o que é mais importante,que nós vamos usar somente esse prazo XYZ pra isso".

[]´s

Eu nunca precisei vender isso, quando participei dum projeto utilizando Scrum, o cliente havia se dado conta das vantagens de um projeto desenvolvimento de forma iterativa e incremental e ele decidiu usar Scrum.

marcio_gs wrote:

asaudate wrote:Mas como alguém conseguiria vender um projeto se alguma coisa não estivesse definida (seja prazo, custo, escopo) ? Acho (veja bem, acho!) que um cliente não gostaria de ouvir "olha, nós temos um prazo XYZ pra isso. Selecione o que você quer, marque o que é mais importante,que nós vamos usar somente esse prazo XYZ pra isso".

[]´s

acho que os clientes preferem ouvir isso do que ouvir que vão ter tudo pronto em XYZ, depois receber o programa em XYZ * 2 e ainda assim cheio de bugs que seriam corrigidos se ele tivesse acesso a alguma coisa em XYZ/2.

Fato, mas ainda assim, acho que o ideal seria dizer pro cliente que ele vai receber tudo num prazo X a custo Y . Mesmo que esse prazo seja aparentemente grande.

Concordo com vocês que, de fato, metodologias ágeis são imbatíveis na questão de comunicação com o cliente. Mas ainda acho que o mundo ideal seria fazer projetos com tempo fechado. E acho que as coisas são do jeito que são porque Engenharia de Software ainda é uma coisa bastaaaaante imatura (mal comparando com a Engenharia Civil, todos que pedem projetos de casas sabem que é possível mudar alguma coisa no projeto se ele estiver no começo. E se estiver no final, todo mundo sabe que, se quiser mudar alguma coisa, corre sério risco de demorar o dobro do tempo, com o dobro do custo. Me parece que o mesmo não acontece com Eng. de Software...).

[]´s

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Bobagens e bobagens sem sentido. É só a repetição das velhas desculpas esfarrapadas dos cascateiros.

asaudate wrote:
acho que os clientes preferem ouvir isso do que ouvir que vão ter tudo pronto em XYZ, depois receber o programa em XYZ * 2 e ainda assim cheio de bugs que seriam corrigidos se ele tivesse acesso a alguma coisa em XYZ/2.

Vamos a uma metáfora: um paciente preferiria ouvir que daqui há seis meses está curado do cancer, do que ouvir que sempre precisa ficar atento pois há qualquer momento pode haver reincidência. Ainda assim, quando o médico percebe que a segunda opção é mais provável, ele não vai dizer a primeira.

Nós programadores sabemos muito bem que não dá pra ter a miníma idéia de quanto determinado projeto vai durar. Ainda assim, maquiamos números quebrados e jogamos tudo no Project para dar uma ilusão de certeza para o cliente. Desculpe, essa atitude só tem um nome: "mentira".

Não importa o que o cliente preferiria ouvir; como profissionais, deveríamos simplesmente dizer a verdade.

asaudate wrote:Fato, mas ainda assim, acho que o ideal seria dizer pro cliente que ele vai receber tudo num prazo X a custo Y . Mesmo que esse prazo seja aparentemente grande.

Ou seja, já que não temos a miníma idéia, vamos pegar bastante o dinheiro do cliente.

asaudate wrote:Concordo com vocês que, de fato, metodologias ágeis são imbatíveis na questão de comunicação com o cliente. Mas ainda acho que o mundo ideal seria fazer projetos com tempo fechado. E acho que as coisas são do jeito que são porque Engenharia de Software ainda é uma coisa bastaaaaante imatura (mal comparando com a Engenharia Civil, todos que pedem projetos de casas sabem que é possível mudar alguma coisa no projeto se ele estiver no começo. E se estiver no final, todo mundo sabe que, se quiser mudar alguma coisa, corre sério risco de demorar o dobro do tempo, com o dobro do custo. Me parece que o mesmo não acontece com Eng. de Software...).

Quem disse que engenheiros civis fazem isso? Nós nunca perguntamos aos "top" desses profissionais como é sua rotina de trabalho.

Mas tenho dúvidas quanto à previsibilidade dessa profissão. Exemplo:a obra do Metrô da linha amarela já deveria estar concluído há algum tempo, e certos imprevistos, como aquele buracão em Pinheiros jamais passou pela cabeça de alguém.

E existem coisas que fazem com que, na construção de um prédio, as decisões possam ser tomadas o mais tarde possível, como paredes "dry-wall". Ou seja, pra que certas coisas não custem "o dobro do tempo", o engenheiro precisa adiar as decisões irreversíveis.

Leonardo3001 wrote:Bobagens e bobagens sem sentido. É só a repetição das velhas desculpas esfarrapadas dos cascateiros.

asaudate wrote:
acho que os clientes preferem ouvir isso do que ouvir que vão ter tudo pronto em XYZ, depois receber o programa em XYZ * 2 e ainda assim cheio de bugs que seriam corrigidos se ele tivesse acesso a alguma coisa em XYZ/2.

Vamos a uma metáfora: um paciente preferiria ouvir que daqui há seis meses está curado do cancer, do que ouvir que sempre precisa ficar atento pois há qualquer momento pode haver reincidência. Ainda assim, quando o médico percebe que a segunda opção é mais provável, ele não vai dizer a primeira.

Nós programadores sabemos muito bem que não dá pra ter a miníma idéia de quanto determinado projeto vai durar. Ainda assim, maquiamos números quebrados e jogamos tudo no Project para dar uma ilusão de certeza para o cliente. Desculpe, essa atitude só tem um nome: "mentira".

Não importa o que o cliente preferiria ouvir; como profissionais, deveríamos simplesmente dizer a verdade.

asaudate wrote:Fato, mas ainda assim, acho que o ideal seria dizer pro cliente que ele vai receber tudo num prazo X a custo Y . Mesmo que esse prazo seja aparentemente grande.

Ou seja, já que não temos a miníma idéia, vamos pegar bastante o dinheiro do cliente.

asaudate wrote:Concordo com vocês que, de fato, metodologias ágeis são imbatíveis na questão de comunicação com o cliente. Mas ainda acho que o mundo ideal seria fazer projetos com tempo fechado. E acho que as coisas são do jeito que são porque Engenharia de Software ainda é uma coisa bastaaaaante imatura (mal comparando com a Engenharia Civil, todos que pedem projetos de casas sabem que é possível mudar alguma coisa no projeto se ele estiver no começo. E se estiver no final, todo mundo sabe que, se quiser mudar alguma coisa, corre sério risco de demorar o dobro do tempo, com o dobro do custo. Me parece que o mesmo não acontece com Eng. de Software...).

Quem disse que engenheiros civis fazem isso? Nós nunca perguntamos aos "top" desses profissionais como é sua rotina de trabalho.

Mas tenho dúvidas quanto à previsibilidade dessa profissão. Exemplo:a obra do Metrô da linha amarela já deveria estar concluído há algum tempo, e certos imprevistos, como aquele buracão em Pinheiros jamais passou pela cabeça de alguém.

E existem coisas que fazem com que, na construção de um prédio, as decisões possam ser tomadas o mais tarde possível, como paredes "dry-wall". Ou seja, pra que certas coisas não custem "o dobro do tempo", o engenheiro precisa adiar as decisões irreversíveis.

Leonardo, antes de mais nada...
Este fórum não é feito para que as pessoas fiquem atacando umas às outras, de graça, chamando-as de "cascateiras" ou "mentirosas". Se você acha que argumentação é feita assim, desculpe, seu lugar não é aqui.

E o que quis dizer foi que eu sei muito bem que não temos assertividade nas previsões de prazo. Mas deveríamos ter metodologias que equillibrassem isso ou fossem ao menos mais assertivas.

O exemplo do médico foi simplesmente péssimo. Porque o médico pode muito bem falar ao paciente que ele deverá ficar sempre de olho, mas terá que fazer uma cirurgia e pode ir embora. Produção de software é a mesma coisa! Produzimos um software e, quando ele vai para a produção, o cliente SABE que , ainda assim, terá risco de bugs. Porque não dizer que o software demorará um tempo X para ser produzido com certo nível de qualidade? De qualquer maneira , o cliente sempre sabe que deverá ficar atento quanto a possíveis bugs.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3417 Offline

Leonardo3001 wrote:Bobagens e bobagens sem sentido. É só a repetição das velhas desculpas esfarrapadas dos cascateiros.

asaudate wrote:
acho que os clientes preferem ouvir isso do que ouvir que vão ter tudo pronto em XYZ, depois receber o programa em XYZ * 2 e ainda assim cheio de bugs que seriam corrigidos se ele tivesse acesso a alguma coisa em XYZ/2.

Vamos a uma metáfora: um paciente preferiria ouvir que daqui há seis meses está curado do cancer, do que ouvir que sempre precisa ficar atento pois há qualquer momento pode haver reincidência. Ainda assim, quando o médico percebe que a segunda opção é mais provável, ele não vai dizer a primeira.

Nós programadores sabemos muito bem que não dá pra ter a miníma idéia de quanto determinado projeto vai durar. Ainda assim, maquiamos números quebrados e jogamos tudo no Project para dar uma ilusão de certeza para o cliente. Desculpe, essa atitude só tem um nome: "mentira".

Não importa o que o cliente preferiria ouvir; como profissionais, deveríamos simplesmente dizer a verdade.

asaudate wrote:Fato, mas ainda assim, acho que o ideal seria dizer pro cliente que ele vai receber tudo num prazo X a custo Y . Mesmo que esse prazo seja aparentemente grande.

Ou seja, já que não temos a miníma idéia, vamos pegar bastante o dinheiro do cliente.

asaudate wrote:Concordo com vocês que, de fato, metodologias ágeis são imbatíveis na questão de comunicação com o cliente. Mas ainda acho que o mundo ideal seria fazer projetos com tempo fechado. E acho que as coisas são do jeito que são porque Engenharia de Software ainda é uma coisa bastaaaaante imatura (mal comparando com a Engenharia Civil, todos que pedem projetos de casas sabem que é possível mudar alguma coisa no projeto se ele estiver no começo. E se estiver no final, todo mundo sabe que, se quiser mudar alguma coisa, corre sério risco de demorar o dobro do tempo, com o dobro do custo. Me parece que o mesmo não acontece com Eng. de Software...).

Quem disse que engenheiros civis fazem isso? Nós nunca perguntamos aos "top" desses profissionais como é sua rotina de trabalho.

Mas tenho dúvidas quanto à previsibilidade dessa profissão. Exemplo:a obra do Metrô da linha amarela já deveria estar concluído há algum tempo, e certos imprevistos, como aquele buracão em Pinheiros jamais passou pela cabeça de alguém.

E existem coisas que fazem com que, na construção de um prédio, as decisões possam ser tomadas o mais tarde possível, como paredes "dry-wall". Ou seja, pra que certas coisas não custem "o dobro do tempo", o engenheiro precisa adiar as decisões irreversíveis.

Tens toda a razão.
O ponto é que se tentou injetar um metodologia de administração em um trabalho que não tem uma metodologia. E não funciona. Desenvolvimento de software tem processos diferentes do resto dos oficios. As analogias com construção civil não funcionam, nem com fábrica de carros, nem com coisa alguma que seja classificado como "industria", logo o processo industrial não pode ser usado para software.

Existem duas partes do problema. Um é as pessoas entenderem o que é um software. E o outro é as pessoas saberem gerenciar um projeto de software. A produção de software é algo recente, tem menos de 50 anos e é por isso que ha imaturidade. Contudo ha muita gente neste momento entendendo que é preciso virar a mesa e maturar a produção de software.

Respondendo ao topico, o que resolve é parar de pensar no cliente como um deus e dar mais atenção ao oficio de produção de software. Agile (o verdadeiro) é legal, mas Software Craftmanship é melhor. Para gerenciamento Scrum, sem duvida alguma.

O problema que atravessamos hoje é que os juniors acham que agile significa bandalheira quando é excatamente ao contrário. As pessoas acham que podem ter design e arquitetura incrementais... é absurdo.

Coisas legais para aprender seria sobre Arquiteura Sustentável, Espaço de Opções, Responsive Design, Processo de Estimativa, o mecanismo de sprint e backlogs do Scrum. Além disso cultivar valores profissionais e orgulho na profissão.
Na prática, acomodar e saber utilizar corretamente práticas como pair programing, repositorio partilhado, nomenclatura correta, padrões de codificação, design,arquitetura, etc...

sergiotaborda wrote:
Respondendo ao topico, o que resolve é parar de pensar no cliente como um deus e dar mais atenção ao oficio de produção de software. Agile (o verdadeiro) é legal, mas Software Craftmanship é melhor. Para gerenciamento Scrum, sem duvida alguma.

Perdoe a ignorância, mas o que é Software Craftmanship?

E a idéia do tópico é como fixar o tempo de desenvolvimento (de uma maneira que realmente funcione). O conceito de agile que tenho (corrija-me se eu estiver errado, só conheço agile na teoria) é o de desenvolver um software num período determinado de tempo, dadas as prioridades do próprio cliente, ou desenvolver em tempo aberto. Minha preocupação é saber se temos alguma forma de desenvolver o software inteiro , com uma estimativa de tempo que realmente funcione.

[]´s

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 104 Offline

asaudate wrote:
...
Minha preocupação é saber se temos alguma forma de desenvolver o software inteiro , com uma estimativa de tempo que realmente funcione.
...

Infelizmente, em desenvolvimento de software não há como fazer uma estimativa confiável de qualquer escopo fechado além de
poucas horas de trabalho. Todo cliente gostaria, quase todo fornecedor de TI gostaria, mas a realidade é outra.

É como tentar controlar preços por decreto. Todo governante gostaria, desde os imperadores romanos até o Hugo Chávez
eles vêm tentando. Nunca deu certo.

Lamento ser portador de más notícias ...

Jorge

Leonardo3001 wrote:Bobagens e bobagens sem sentido. É só a repetição das velhas desculpas esfarrapadas dos cascateiros.

Mais respeito com os colegas que tem opiniões diferentes que a sua.

Leonardo3001 wrote:
Vamos a uma metáfora: um paciente preferiria ouvir que daqui há seis meses está curado do cancer, do que ouvir que sempre precisa ficar atento pois há qualquer momento pode haver reincidência. Ainda assim, quando o médico percebe que a segunda opção é mais provável, ele não vai dizer a primeira.

Nós programadores sabemos muito bem que não dá pra ter a miníma idéia de quanto determinado projeto vai durar. Ainda assim, maquiamos números quebrados e jogamos tudo no Project para dar uma ilusão de certeza para o cliente. Desculpe, essa atitude só tem um nome: "mentira".

Não importa o que o cliente preferiria ouvir; como profissionais, deveríamos simplesmente dizer a verdade.

Cara, eu concordo com você que é difícil dar uma estimativa precisa.

Mas eu também concordo com o Saudate que na grande maioria das vezes o cliente quer saber duas coisas: quanto vai custar e quanto tempo vai levar.
Nós temos duas opções: Mostrar que isso não da certo trabalhar dessa forma (e muitas vezes perder o cliente) ou tentar fazer o nosso melhor para dar um custo e prazo de um projeto com escopo fixo. A maioria dos projetos sai de clientes que querem saber o custo e o prazo baseado no escopo que eles passaram e não aceitam uma forma iterativa e incremental - eles simplesmente não acreditam ou não estão prontos para trabalhar dessa forma.

Existem pessoas que simplesmente se recusam a trabalhar com clientes que não aceitam projetos desenvolvidos de forma iterativa e incremental - preferem perder o cliente e trabalhar com clientes que aceitam projetos desenvolvidos de forma iterativa e incremental. Essas pessoas acreditam que vão ganhar mais dinheiro trabalhando da forma certo ou preferem ganhar menos dinheiro e trabalhar da forma que eles acham profissionalmente correta.

Mas existem outras pessoas que aceitam as restrições do cliente (ou realmente acreditam que projetos de custo e escopo fechado tem altas chances de dar certo se forem "bem planejados"). Não acho que elas são mentirosas ou menos profissioanais. O cliente tem uma demanda e elas tem a capacidade de executar um serviço.

São duas formas de se pensar, eu particularmente prefiro a primeira, mas não acho correto menosprezar quem pensa diferente.

Leonardo3001 wrote:
Quem disse que engenheiros civis fazem isso? Nós nunca perguntamos aos "top" desses profissionais como é sua rotina de trabalho.

Mas tenho dúvidas quanto à previsibilidade dessa profissão. Exemplo:a obra do Metrô da linha amarela já deveria estar concluído há algum tempo, e certos imprevistos, como aquele buracão em Pinheiros jamais passou pela cabeça de alguém.

E existem coisas que fazem com que, na construção de um prédio, as decisões possam ser tomadas o mais tarde possível, como paredes "dry-wall". Ou seja, pra que certas coisas não custem "o dobro do tempo", o engenheiro precisa adiar as decisões irreversíveis.

Você já trabalhou com engenharia civil?

Cuidado com o que blogueiros postam por aí

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 104 Offline

sergiotaborda wrote:
O problema que atravessamos hoje é que os juniors acham que agile significa bandalheira quando é excatamente ao contrário.

Não acho que essa opinião seja apenas ou principalmente de juniors. Para muita gente experiente também não caiu a ficha.

sergiotaborda wrote:
As pessoas acham que podem ter design e arquitetura incrementais... é absurdo.

Não entendi. Design e arquitetura podem e devem evoluir incrementalmente:
ambos devem sempre se basear mais nas premissas do momento que em previsões sobre
o futuro.

sergiotaborda wrote:[
Respondendo ao topico, o que resolve é parar de pensar no cliente como um deus e dar mais atenção ao oficio de produção de software. Agile (o verdadeiro) é legal, mas Software Craftmanship é melhor. Para gerenciamento Scrum, sem duvida alguma.

O problema que atravessamos hoje é que os juniors acham que agile significa bandalheira quando é excatamente ao contrário. As pessoas acham que podem ter design e arquitetura incrementais... é absurdo.

Coisas legais para aprender seria sobre Arquiteura Sustentável, Espaço de Opções, Responsive Design, Processo de Estimativa, o mecanismo de sprint e backlogs do Scrum. Além disso cultivar valores profissionais e orgulho na profissão.
Na prática, acomodar e saber utilizar corretamente práticas como pair programing, repositorio partilhado, nomenclatura correta, padrões de codificação, design,arquitetura, etc...

Ops, peraí... Você não esta falando disso aqui não, né? http://manifesto.softwarecraftsmanship.org

Mas eu acho que eu tenho mais ou menos a idéia que você tem e que vários profissionais que trabalham com desenvolvimento ágil tem notado, muitas pessoas acham que Agile é reposicionar post-it na parede a cada 15 dias, quando na verdade existem muitas outros valores e práticas envolvidas;

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

asaudate wrote:Leonardo, antes de mais nada...
Este fórum não é feito para que as pessoas fiquem atacando umas às outras, de graça, chamando-as de "cascateiras" ou "mentirosas". Se você acha que argumentação é feita assim, desculpe, seu lugar não é aqui.

Caramba! Houve um mal entendido! Pelo que sei, cascateiro é aquele quem defende o desenvolvimento de software em cascata. E falei de "mentira" a atitude de quem tenta florear a situação para não perder cliente, não dei nomes aos bois.

asaudate wrote:E o que quis dizer foi que eu sei muito bem que não temos assertividade nas previsões de prazo. Mas deveríamos ter metodologias que equillibrassem isso ou fossem ao menos mais assertivas.

O exemplo do médico foi simplesmente péssimo. Porque o médico pode muito bem falar ao paciente que ele deverá ficar sempre de olho, mas terá que fazer uma cirurgia e pode ir embora. Produção de software é a mesma coisa! Produzimos um software e, quando ele vai para a produção, o cliente SABE que , ainda assim, terá risco de bugs. Porque não dizer que o software demorará um tempo X para ser produzido com certo nível de qualidade? De qualquer maneira , o cliente sempre sabe que deverá ficar atento quanto a possíveis bugs.

Se médicos praticassem medicina como nós desenvolvemos software:

(Médico) - Você precisa fazer uma cirurgia antes de ir embora. E ainda assim, precisa ficar sempre de olho.
(Paciente) - Cirurgia? Mas isso é muito caro, não? Acha mesmo que tem necessidade?
(Médico) - Olha, dá até pra ficar sem, mas aí é por sua conta e risco.
(Paciente) - Tá, e quanto tempo demora a cirurgia?
(Médico) - Pode levar até oito horas...
(Paciente) - Oito horas!? Isso é muito! Não dá pra fazer uma força-tarefa pra diminuir isso? Sei lá, pedi pros enfermeiros darem um gás...
(Médico) - É complicado. A gente tem que se esterilizar antes e...
(Paciente) - Ah, não precisa! O pessoal já não toma banho todos os dias? Não precisa nem lavar as mãos!

Desculpe, mas os médicos, mesmo com todos os seus defeitos, são mais profissionais que nós.

Notícias, artigos e o maior fórum brasileiro sobre Java