Metodologias tradicionais x Agile - O que resolve?

[Alexandre_Saudate]

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?

[Rubem_Azenha]

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.

[Alexandre_Saudate]

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

[marcio_gs]

[quote=asaudate]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[/quote]

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.

[Rubem_Azenha]

[quote=asaudate]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[/quote]

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.

[Alexandre_Saudate]

[quote=marcio_gs][quote=asaudate]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[/quote]

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.[/quote]

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

[Leonardo3001]

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

[quote=asaudate]
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.[/quote]

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.

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.

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.

[Alexandre_Saudate]

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

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.[/quote]

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.

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.

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.

[sergiotaborda]

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

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.[/quote]

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.

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.

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…

[Alexandre_Saudate]

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

[Jorge_Diz]

…
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

[Rubem_Azenha]

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.

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.

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í

[Jorge_Diz]

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.

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.

[Rubem_Azenha]

[quote=sergiotaborda][
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…

[/quote]

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;

[Leonardo3001]

[quote=asaudate]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.[/quote]

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.

[quote=asaudate]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.[/quote]

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.

[Alexandre_Saudate]

…

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

Pois não deveria ser assim!

[mario.fts]

[quote=asaudate][quote=sergiotaborda]
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.
[/quote]

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[/quote]

O própio Sérgio escreveu um artigo sobre isso: http://sergiotaborda.javabuilding.com/2009/11/scrum-para-tradicionalistas-previsoes/

li um post aqui uam vez com uam estrutura bem definida para estimar com scrum, vou procurar e depois posto aqui.

[Leonardo3001]

[quote=Rubem Azenha]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.[/quote]

Não menosprezo quem pensa diferente. Mas discordo veementemente.

Estamos buscando desesperadamente um número mágico que preveja o futuro… que as pessoas simplesmente o inventa numa equação complicada e sem sentido. Precisamos chegar a um ponto e dizer: assim não dá.

[quote=Rubem Azenha]
Você já trabalhou com engenharia civil?
Cuidado com o que blogueiros postam por aí :)[/quote]

O ônus de conhecer engenharia civil não é meu, é de quem compara nossa profissão com a deles. Eu apenas soltei algumas coisas pra invalidar essa argumentação.

[Alexandre_Saudate]

Não menosprezo quem pensa diferente. Mas discordo veementemente.

Estamos buscando desesperadamente um número mágico que preveja o futuro… que as pessoas simplesmente o inventa numa equação complicada e sem sentido. Precisamos chegar a um ponto e dizer: assim não dá.

Acontece que não estamos procurando um número mágico! Acredito, sinceramente, que no futuro nós seremos capazes de dizer com razoável precisão. Mas precisamos discutir isso hoje para chegar numa técnica de previsão suficientemente boa. E obviamente não adianta falar “ah, nós somos diferentes do pessoal da engenharia civil e portanto não precisamos dar estimativas de tempo apuradas”. O que nós precisamos fazer é ter técnicas apuradas o suficiente pra fazê-lo.

Não conhecia o artigo do Sérgio, mas percebí que ele calcula o tempo de acordo com o tempo dado para fazer cada história no Scrum - o que pode dar igualmente errado, já que as histórias podem ter sido estimadas com prazos ruins.

Penso que alguma metodologia mais “científica”, tipo Pontos de Função, deveria resolver o problema - caso é que, mesmo para PF, há um desvio enorme!

[sergiotaborda]

[quote=asaudate][quote=sergiotaborda]
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.
[/quote]

Perdoe a ignorância, mas o que é Software Craftmanship?
[/quote]

É considerar que fazer software é uma arte. Toda a arte tem ferramentas, toda a arte tem regras e toda a arte é baseada numa ciencia (explicita ou implicitamente, a pintura, por exemplo, é baseada na teoria das cores que é baseada na teoria da luz.)

É mais do que o manifesto apresentado pelo Rubens. Para entender melhor precisa ler o Clean Code do Robert C Martin.

A grande diferença dos agilistas é que os agilistas se preocupam em entregar software de qualidade mas a qualidade dele é imediata, enquanto que craftmanship a qualidade tem que ser eterna. Um exemplo classico, é o nomenclaturas. Vc pode fazer um sistema sem nomenclatura especificia passar em todos os testes e funcionar perfeitamente, mas daqui a 3 anos quando alguem for dar manutenção ele não entender nada.
Craftmanship é sobre ter qualidade no codigo que se produz e orgulho nele, da mesma forma que o pintor tem orgulho em usar a tinta vermellha XPTO345 em vez da tinta vermelha GHTT3244.

E a idéia do tópico é como fixar o tempo de desenvolvimento (de uma maneira que realmente funcione).

Não ha segredo. Simplesmente fixe um prazo.

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.

Esse negocio de que agil = tempo aberto é uma falácia.

Para compreender agil vc precisa primeiro compreender que Tamanho do software é diferente de Tempo que o software demora a ser produzido. Os livros Software Estimation: Demystifying The Black Art , Code Complete do mesmo autor e Agile Estimation and Planning. Não tenha preconceito com o nome “agile” no titulo.
Além disso vc precisa entender o conceito do triângulo de projeto.

O erro de todos os projetos “clássicos” é achar que o tamanho do software se mede em horas.

Podem existir projeto de prazo indeterminado, mas normalmente isso não acontece.

Desenvolvedores devem saber estimar o tamanho do software, não o tempo. A estimativa de tempo é calculavel a partir do tamanho.