Então releia, porque não é nada disso. O tempo é baseado em Story Points , que são uma medida de tamanho.
O tempo depende da velocidade.
É como ir do Rio a São Paulo. O tempo que eu demoro não depende da distancia (que é fixa) mas sim da velocidade (que é variável conforme o meio de transporte que eu escolher).
Conheço (melhor do que gostaria, aliás) o triângulo de projeto… mas acho que ele ainda é ignorado por muitas consultorias E clientes (minha opinião).
Teoricamente, o dimensionamento do software deveria ser dada por uma WBS bem feita, certo? Porque, mesmo assim, os conceitos do triângulo e WBS (parece que) são ignorados?
[quote=asaudate]
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![/quote]
Aqui está o problema. Veja, é um problema de conceito. Devenvolvimento de Software não precisa de metodologias
"cientificas" porque não é uma ciencia. É uma arte. Precisa de boas práticas.
É nesta diferenciação que entra o Software Craftmanship.
[quote=sergiotaborda][quote=asaudate]
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.
[/quote]
Então releia, porque não é nada disso. O tempo é baseado em Story Points , que são uma medida de tamanho.
O tempo depende da velocidade.
É como ir do Rio a São Paulo. O tempo que eu demoro não depende da distancia (que é fixa) mas sim da velocidade (que é variável conforme o meio de transporte que eu escolher).
[/quote]
Exatamente por isso alguns preferem perguntar ao desenvolvedor quanto tempo leva, certo? Um desenvolvedor que conheça a arquitetura do sistema (teoricamente) sabe o que precisa ser feito e como.
[quote=sergiotaborda][quote=asaudate]
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![/quote]
Aqui está o problema. Veja, é um problema de conceito. Devenvolvimento de Software não precisa de metodologias
"cientificas" porque não é uma ciencia. É uma arte. Precisa de boas práticas.
É nesta diferenciação que entra o Software Craftmanship.[/quote]
Bem, aí caímos numa situação que já é discutida há tempos por vários profissionais (de renome, inclusive). Alguns dizem que é uma arte, outros dizem que é uma ciência (e, se bobear, tem os que dizem que não é nem um nem outro, que é uma coisa esotérica =P ).
Eu tendo a acreditar que é uma ciência. Quem me conhece sabe que eu tenho um perfil mais de acadêmico do que de artista.
[quote=asaudate]
Teoricamente, o dimensionamento do software deveria ser dada por uma WBS bem feita, certo? Porque, mesmo assim, os conceitos do triângulo e WBS (parece que) são ignorados?[/quote]
WBS = Work Breakdown Structure
Sim, deveriam. O problema é que se o seu modelo de WBS for falho, a estimativa é falha.
E repare que a WBS lhe mostra o quê vc deveria estar estimando e não a estimativa em si mesma, nem lhe diz em que unidade deveria ser essa estimativa.
[quote=asaudate][quote=sergiotaborda][quote=asaudate]
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.
[/quote]
Então releia, porque não é nada disso. O tempo é baseado em Story Points , que são uma medida de tamanho.
O tempo depende da velocidade.
É como ir do Rio a São Paulo. O tempo que eu demoro não depende da distancia (que é fixa) mas sim da velocidade (que é variável conforme o meio de transporte que eu escolher).
[/quote]
Exatamente por isso alguns preferem perguntar ao desenvolvedor quanto tempo leva, certo? Um desenvolvedor que conheça a arquitetura do sistema (teoricamente) sabe o que precisa ser feito e como.[/quote]
Mas não quanto tempo vai demorar. Esse é o problema.
veja por outro lado, o cliente está comprando o quê ? O seu tempo ? ou o software ?
Ele está comprando o software. Ele está pagando pelo tamanho do software, não pelo quanto demora a fazer.
Mas vc está cobrando pelo seu custo e o seu custo depende do tempo. Contudo o tempo que vc demora depende do seu skill.
Veja, um cara com bom skill, demora menos para desenolver uma feature de igual tamanho que um com pouca.
O primeiro irá demorar pouco e portanto , se cobrar pelo tempo, cobrar pouco.
O segundo irá demorar muito, e portanto, se cobrar pelo tempo, cobrar muito.
Este modelo não justo, porque o cara com mais skill se dá mal.
Agora imagine que o cliente paga pelo tamanho. O tamanho é o mesmo. Portanto os dois ganham o mesmo.
Mas o primeiro executa rápido e portanto com pouco custo, logo o lucro é maior.
Mas o segundo executa lentamente (e pode nem executar nunca) logo o lucro é menor podendo dar prejuizo.
Este é o modelo correto. Porque o primeiro cara, terminando antes irá produzir mais no mesmo tempo do segundo, e portanto ganhando mais.
O cliente diz-lhe o que quer, vc lhe diz o tamanho e o preço (não o custo). Preço é função do tamanho. O tamanho é fixo. Logo o preço é fixo. Ai vc estima o tempo que demora. Eu disse estima. Não é certeza. Vc pode acabar antes ou depois desse prazo. Vc entrega um preço e uma estimativa de tempo. As suas não está relaciondas por um “preço/hora”. O primeiro é um contrato, o segundo é um bonus auxilar.
É na diferença entre preço e custo que está o lucro. E portanto é no skill do cara que está o lucro. Isto faz sentido, mas é aplicado. Pelas regras de hoje uma equipa de juniors é melhor que uma de seniors porque eles demoram mais e portanto a empresa cobrará mais do cliente.
[quote=sergiotaborda][quote=asaudate][quote=sergiotaborda][quote=asaudate]
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.
[/quote]
Então releia, porque não é nada disso. O tempo é baseado em Story Points , que são uma medida de tamanho.
O tempo depende da velocidade.
É como ir do Rio a São Paulo. O tempo que eu demoro não depende da distancia (que é fixa) mas sim da velocidade (que é variável conforme o meio de transporte que eu escolher).
[/quote]
Exatamente por isso alguns preferem perguntar ao desenvolvedor quanto tempo leva, certo? Um desenvolvedor que conheça a arquitetura do sistema (teoricamente) sabe o que precisa ser feito e como.[/quote]
Mas não quanto tempo vai demorar. Esse é o problema.
veja por outro lado, o cliente está comprando o quê ? O seu tempo ? ou o software ?
Ele está comprando o software. Ele está pagando pelo tamanho do software, não pelo quanto demora a fazer.
Mas vc está cobrando pelo seu custo e o seu custo depende do tempo. Contudo o tempo que vc demora depende do seu skill.
Veja, um cara com bom skill, demora menos para desenolver uma feature de igual tamanho que um com pouca.
O primeiro irá demorar pouco e portanto , se cobrar pelo tempo, cobrar pouco.
O segundo irá demorar muito, e portanto, se cobrar pelo tempo, cobrar muito.
Este modelo não justo, porque o cara com mais skill se dá mal.
Agora imagine que o cliente paga pelo tamanho. O tamanho é o mesmo. Portanto os dois ganham o mesmo.
Mas o primeiro executa rápido e portanto com pouco custo, logo o lucro é maior.
Mas o segundo executa lentamente (e pode nem executar nunca) logo o lucro é menor podendo dar prejuizo.
Este é o modelo correto. Porque o primeiro cara, terminando antes irá produzir mais no mesmo tempo do segundo, e portanto ganhando mais.
O cliente diz-lhe o que quer, vc lhe diz o tamanho e o preço (não o custo). Preço é função do tamanho. O tamanho é fixo. Logo o preço é fixo. Ai vc estima o tempo que demora. Eu disse estima. Não é certeza. Vc pode acabar antes ou depois desse prazo. Vc entrega um preço e uma estimativa de tempo. As suas não está relaciondas por um “preço/hora”. O primeiro é um contrato, o segundo é um bonus auxilar.
É na diferença entre preço e custo que está o lucro. E portanto é no skill do cara que está o lucro. Isto faz sentido, mas é aplicado. Pelas regras de hoje uma equipa de juniors é melhor que uma de seniors porque eles demoram mais e portanto a empresa cobrará mais do cliente.
[/quote]
Aí entram as regras de mercado: o fornecedor que fizer o serviço mais rápido e mais barato leva, certo?
[quote=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.[/quote]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…
[quote=luistiagos][quote=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.[/quote]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Exatamente nesse ponto eu considero que engenharia de software deveria ser igual às outras engenharias: não existe mágica. E os clientes devem levar isso em conta, seja por causa de inúmeros projetos que atrasam, seja por conta da resistência dos desenvolvedores de software. Acho que deveríamos nos manifestar nesses casos e dizer: não, eu não vou fazer a água da cascata cair pra cima, muito menos nesse prazo ridículo!
[quote=asaudate]
Aí entram as regras de mercado: o fornecedor que fizer o serviço mais rápido e mais barato leva, certo?[/quote]
Sim, mas repare que a qualidade não está sendo considerada nem o que significa “fazer”.
O que signfica, na prática que a empresa A faz mais barato que B ?
Ela irá fazer exatamente o mesmo codigo, ter os mesmos cuidados, aderir aos mesmos padrões, ter a mesma qualidade, ter a mesma preocupação, etc… Não. A irá fazer do jeito que der. Só o preço interessa e só a precepção do cliente/usuario interessa.
Mas a precepção muda rápidamente se o cliente escolher uma empresa C para auditar e manter um padrão de qualidade. Assim A pode ser mais barato que B, mas ter menos qualidade e se ferrar na presença de C.
Repare que para um profissional com bom skill codigo de qualidade é mais rápido e mais simples de fazer do que sodigo sem qualidade. um empresa com profissionais assim, gera software de qualidade a um preço baixo, logo, tendo em consideração que existiria uma auditoria, a empresa que ganha é que a fizer com qualidade e barato.
Enfim, sem poder comparar a qualidade - que é um pilar fixo - é impossível comparar licitações.
Para produtos normais vc tem a ProTest e Procon, mas para software não… lamentávelmente.
Precisamos ter organismos que permitam comparar a qualidade das soluções apresentadas pelas empresas.
Isso é simples num linux vs windows, mas num ERP proprietário vs outro é muito complexo.
Essa é uma falácia comum.
O bom desenvolvimento/arquitetura é aquele que é sustentável.
“Sustainable Development is development that meets
the needs of the present without compromising the
ability of future generations to meet their own
needs” in http://www.fortuneconferences.com/brainstormgreen2008/docs/slides-innosight.pdf
Portanto sim vc tem que prever o futuro, mas vc não implementa o futuro.
A metáfora do espaço de opções é muito boa. Vc tem N opções do que o seu sistema/arquitetura/framework pode fazer. Sempre que vc restringe alguma coisa, o espaço de opções diminui para todo o sempre.
Então o desafio é desenvolver de um jeito que atenda as suas necessidades sem destruir as necessidades que vc não conhece. Requisitos que tenham palavras como “todo”, “nenhum”, “sempre”, “nunca”, são possíveis restrições prematuras.
Por exemplo, quando vc define um Id vc usa integer , certo ? Ai vc vai e faz um framework que tem classes com getId():Integer por todo o lado.
No futuro a sun faz os integer serem mutáveis… hummm problemas para vc. Como garantir que o programador não faz um getId().incrementandSet() ?
No futuro o seu sistema vira distribuido e as chaves tem que ser universalmente unicas (usar UUID). Hum… lá vamos faze rum refactor monstruoso…
Se vc definir o Id como sendo um objeto que implementa a interface Identity (por exemplo) e obtem os valores de fábricas, facilmente vc mudar o objeto real de um integer para um long ou um UUID e ou mesmo tempo impede que algum louco altere o id on-the-fly.
É um exemplo simples, mas a ideia é : não fixe nada agora que vc pode manter arbitrário. Isso inclui não apenas tipos, mas regras, decisões, etc… O objetivo é adiar ao máximo qq decisão (que dminua o espaço de opções) e ao mesmo tempo ter um sistema funcionado.
Mas como eu sei se a decisão altera o espaço de opções? bom, ajudaria se eu soubesse as opções que existirão, pelo menos algumas. Isso vc consegue se informando sobre outros projetos, ler opne source e ver como outras pessoas decidem para depois não decidir como elas 
É isso! A criação de órgãos de avaliação de qualidade poderia levar ao desenvolvimento de software num tempo justificável.
Alguns desses órgãos já existem, obviamente, mas são órgãos independentes, que o cliente deve contratar. Se fosse algo obrigatório, talvez as consultorias pensassem duas vezes antes de “enxugar” o tempo de desenvolvimento.
Métricas para estimativa adequada de tempo existem, mas elas só podem ser levadas em consideração quando corretamente aplicadas… o que não acontece sempre. Se tivéssemos esses órgãos de auditoria (que mensurassem não só a qualidade do software, mas o tempo previsto versus tempo atingido, etc.), então poderíamos ter uma Engenharia de Software decente.
Concordam?
[quote=asaudate]É isso! A criação de órgãos de avaliação de qualidade poderia levar ao desenvolvimento de software num tempo justificável.
Alguns desses órgãos já existem, obviamente, mas são órgãos independentes, que o cliente deve contratar. Se fosse algo obrigatório, talvez as consultorias pensassem duas vezes antes de “enxugar” o tempo de desenvolvimento.
Métricas para estimativa adequada de tempo existem, mas elas só podem ser levadas em consideração quando corretamente aplicadas… o que não acontece sempre. Se tivéssemos esses órgãos de auditoria (que mensurassem não só a qualidade do software, mas o tempo previsto versus tempo atingido, etc.), então poderíamos ter uma Engenharia de Software decente.
Concordam?[/quote]
No geral sim.
Ah… precisamos escrever um manifesto a respeito ^^
[quote=luistiagos]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Cara… depende do cliente. Embora existam muitos clientes completamente leigos, muitas empresas tem equipes de TI internas (com CIOs, Diretores de TI, Superintendentes de TI, Gerentes de TI) justamente pra cuidarem da aquisição ou desenvolvimento de sistemas de software (entre muitas outras coisas). Essas equipes, teoricamente, deveriam estar capacitadas para pelo menos discutir uma metodologia com o fornecedor.
É claro que em muitos casos que existe essa equipe, a equipe não é muito bem qualificada ou simplesmente esta desatualizada…
Mas se você for no mercadinho da esquina ou na loja de doces do bairro, dificilmente você vai encontrar uma equipe de TI 
Mas em empresas de tamanho razoável, sempre tem uma equipe de TI.
[quote=Rubem Azenha][quote=luistiagos]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Cara… depende do cliente. Embora existam muitos clientes completamente leigos, muitas empresas tem equipes de TI internas (com CIOs, Diretores de TI, Superintendentes de TI, Gerentes de TI) justamente pra cuidarem da aquisição ou desenvolvimento de sistemas de software (entre muitas outras coisas). Essas equipes, teoricamente, deveriam estar capacitadas para pelo menos discutir uma metodologia com o fornecedor.
É claro que em muitos casos que existe essa equipe, a equipe não é muito bem qualificada ou simplesmente esta desatualizada…
Mas se você for no mercadinho da esquina ou na loja de doces do bairro, dificilmente você vai encontrar uma equipe de TI
Mas em empresas de tamanho razoável, sempre tem uma equipe de TI.[/quote]
Nesse caso, também se aplica a criação de um órgão de avaliação obrigatório. Se fosse algo que todos confiassem (tanto clientes quanto fornecedores), então o cliente não precisaria de uma equipe de TI para fazer a avaliação, porque esse órgão deixaria explícita se uma determinada solução funciona ou não, se o tempo é bom ou não, etc.
Isso poderia ser um selo, como o CMM, mas essa avaliação em todos os sistemas gera onus, e a maioria das empresas não gosta muito dessa palavra. 
O problema desses selos é que a gente sabe que na maioria dos casos a empresa treina uma equipe, passa na certificação e dane-se as práticas, o importante é o título. Sou CMM666.
Mas ai dificultou. avaliar todo software é custoso, avaliar só uma vez gera picaretagem, e ai? qual seria um modelo sustentável para garantir a qualidade do processo? (desvio de tópico detected)
[quote=mario.fts]Isso poderia ser um selo, como o CMM, mas essa avaliação em todos os sistemas gera onus, e a maioria das empresas não gosta muito dessa palavra.
O problema desses selos é que a gente sabe que na maioria dos casos a empresa treina uma equipe, passa na certificação e dane-se as práticas, o importante é o título. Sou CMM666.
Mas ai dificultou. avaliar todo software é custoso, avaliar só uma vez gera picaretagem, e ai? qual seria um modelo sustentável para garantir a qualidade do processo? (desvio de tópico detected)[/quote]
Acho que uma espécie de auditoria pública seria legal.
Quanto ao selo, não seria uma empresa que seria certificada… seria um projeto. E isso seria uma avaliação de acordo com a qualidade, tempo estimado… sendo que essas avaliações seriam aplicadas antes E depois de um projeto, para verificar se os prazos e qualidade acordados diferem muito de outros cases. E as empresas poderiam investir nisso como forma de marketing, tipo assim “90% de nossos projetos estão de acordo com o especificado pelo órgão XYZ” .
[quote=luistiagos][quote=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.[/quote]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Esse tipo de situação tem que ser tratada do mesmo jeito que o cara que dizia que podera fazer pontes apenas com a canalização das energias sem usar pilares ou sustentação. Ou com o cara que não deixa que o seu filho leve uma trasnfusão de sangue por causa da religião dele ( dele, não do filho, entenda-se). Vc simplesmente os ignora.
O problema é quando algum idiota lhes dá ouvidos e entra na onda.
Existe o conceito de cliente saudável. Este é aquele que vc quer ter. Essas antas sem cabeça vc quer ficar é longe.