Metodologias tradicionais x Agile - O que resolve?

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

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

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:

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:

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

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

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

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.

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.

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

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:

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

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.

Leonardo3001:

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

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…

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

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

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

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.

Você já trabalhou com engenharia civil?
Cuidado com o que blogueiros postam por aí

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

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:

[
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;

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.

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:

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.

Pois não deveria ser assim!

asaudate:

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.

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

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.

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.

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á.

Rubem Azenha:

Você já trabalhou com engenharia civil?
Cuidado com o que blogueiros postam por aí :)

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.

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!

asaudate:

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.

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

É 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.

Não ha segredo. Simplesmente fixe um prazo.

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.

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?

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!

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.

sergiotaborda:

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.

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).

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.

sergiotaborda:

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!

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.

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.

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?

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.

asaudate:

sergiotaborda:

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.

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).

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.

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.

sergiotaborda:

asaudate:

sergiotaborda:

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.

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).

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.

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.

Aí entram as regras de mercado: o fornecedor que fizer o serviço mais rápido e mais barato leva, certo?

Rubem Azenha:

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

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.

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…

luistiagos:

Rubem Azenha:

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

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.

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…

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!

asaudate:

Aí entram as regras de mercado: o fornecedor que fizer o serviço mais rápido e mais barato leva, certo?

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?

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?

No geral sim.

Ah… precisamos escrever um manifesto a respeito ^^

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…

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.

Rubem Azenha:

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…

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.

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)

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)

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” .

luistiagos:

Rubem Azenha:

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

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.

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…

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.

Um órgão de auditoria seria apenas para enxugar gelo. Afinal, se o cliente não consegue avaliar uma boa consultoria para si, porque avaliaria bem uma empresa de auditoria? E outra, quem fiscaliza a auditoria? A empresa D?

A relação só vai mudar quando mexerem na raiz do problema: a cobrança de software por horas trabalhadas, que valoriza sempre os profissionais medíocres e projetos de software insignificantes (como atualização de ERP ou projetões SOA). Quando se passar a vender software pelo valor que agrega, será um passo rumo a uma melhor qualidade.

Hummm… quem controla o Procon ? Qual é o cliente que sabe escolher um produto para si na prateleira do supermercado corretamente ?

Essa conversa de controle é que destroi todo o conceito. Ninguem tem que controlar. aliás o proprio conceito de auditoria implica que seja um orgão independente.

Isso é tudo verdade. Mas veja bem, porque a empresa vai faturar um milhão quando pode faturar 2 ? Para o “mercado” não importa o lucro, e sim o faturamento. Esse é o problema.

Muitas pessoas sem conceitos de TI acham que a Accenture é o máximo e ninguem se importa de pagar 60 horas para alterar um ponto-e-virgula. O cliente fala que precisa de mudar e é cobrado por isso.
No mundo real quando vc vai numa loja e o preço é o quadruplo do resto das loja vc vai embora.

O problema é que software é considerado artigo de luxo, ou seja, quanto mais caro, melhor.
Os diretores não estão preocupados em ter boas soluções e sim em ter bodes espiatórios. Se a empres cobra caro é porque ela assume o risco das asneiras do cliente.

Mas mesmo na ferrari ou na rolls royce , cliente é cliente, e a qualidade do produto é a empresa produtora que define, é a reputação da empresa que está em jogo.

Para empresas que têm desenvolvimento interno ( ou seja, produzem o seu proprio produto , ou ferramentas, mas o seu business core não é vender software) o problema é ainda pior. Tudo fica dentro de 4 paredes e não ha para quem apelar. é uma especie de trabalho escravo. É preciso que algo dê muito errado (tipo falencia) para que o modelo seja repensado por esse tipo de empresas. Algumas simplesmente treceirizam, mas a terceirização da produção de software é simplesmente um erro estratégico quando o seu negocio depende daquele software. Por exemplo, vc tem um site de e-comerce e a sua empresa só ganha dinheiro através do site. Vc vai terceirizar o seu ganha pão? É diferente de um ERP que não é o business core da empresa.

Ha duas frentes aqui: os desenvolvedores e os clientes. É pela pressão de ambos que as empresas mudarão.
Algumas empresas com diretores e gerentes visionários já entenderam o conceito e estão ajudando os desenvolvedores, mas falta respingar isso nos clientes para que eles exigem qualidade e saibam ver quando estão sendo enganados. Como ?

quando vc vai comprar um diamante ou uma casa, vc leva um avalista. Ele irá verificar a autenticidade e estado do objeto. Ele vai ajudar vc a fazer a compra certa. O mesmo pode ser feito para software. O cliente contrata uma empresa de avalismo de software. Os representantes dessa empresa vão na produtora de software e veêm se dá. Como ? participando do dia-a-dia da empresa durante um tempo. Se o aval for negativo o contrato cai. Repare que a produtora tem que aceitar a presença do avalista , caso contrario não ha contrato com o cliente.
Existem vários tipos de auditoria possível.

Agora, do outro lado. quem faz essa auditoria? Obviamente pessoas que tendam de criação de software, mas, vc deixaria um Martin Fowler ou um James Glosing meter o bedelho no seu codigo ? Ser famoso não significa ser bom de auditoria… E além disso ha as diretrizes, mas comumente chamadas normas. Não ha norma ISO para como um bom software deve ser. Existem algumas normas ISO para como o processo deve ser (deve ser documentado, por exemplo, mas não diz em que midia ) Se essas regras todos temos as mãos atadas.
Mas temos algo suficiente próximo. Temos convenções e congressos onde as pessoas discutem padrões. Dos mais vários níveis. Pattern, Anti-Pattern, boas prática, etc… essas coisas são reais e funcionam como guias para o que é certo e o que é errado.

Fundamentalmente a comunidade de desenvolvimento (todas as linguagens) tem que adotar Principios e aplicá-los.
Algumas coisas que eram boas no passado ( como a nomenclatura hungara usada no windows) sabemos que não são. Vamos falhar em algumas coisas, mas se 80% estiver bom, já é um avanço extraordinário.

Eu fico emocionado quando alguem usa o padrão Money ou tem a sua própria API de tratamento de datas e tempos ou usa BigDecimal em vez de double ou se vejo alguem usar Produtor-Consumidor ou decorator… o problema é que não vi isso até hoje. As pessoas tendem a pensar “vamos usar o framework X , o Y e o Z e misturar tudo no caldeirão, se daqui a 10 anos a tecnologias mudar, quem vier atrás que feche a porta, o meu já tá ganho”

Rubem Azenha:

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…

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.

Tem muita empresa grande que sua equipe de TI é a pirralhada que cuida de suporte e infra-estrutura ou uns pseudo-analistas de sistemas mas que são formados em administração que não sabem nem o que é um select… dai discutir metodologias com este pessoal é o mesmo que discutir com um leigo… o que eles vão querer é simplismente o software magico ou que a gente de uma de Shiryu do CDZ e faça a cascata mudar de lado com um “Colera do dragão”…

sergiotaborda:

luistiagos:

Rubem Azenha:

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

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.

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…

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.

O problema e que 99% dos clientes são estas antas… pois geralmente são da area administrativa… gerente de não sei o que la… diretor de não sei o que la… alias ja vi até gerentes de TI que tem esta mentalidade… dai é complicado…

De fato, a mentalidade corporativa esta mais voltada para um modo de operação fixa e repetitiva deixando a desejar quando o assunto é saber tirar proveito das inovações tecnológicas.

O que eu acho curioso é a quantidade de gente querendo matar o monstro com receitas as mais “criativas”, como essa da auditoria, ao invés de simplesmente evitá-lo. Porque não voltam pro seu software e invistam a mesma energia para agregar valor a ele e depois va procurar outros mercados!

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

mochuara:

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?

sergiotaborda:

mochuara:

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?

Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.

mochuara:

sergiotaborda:

mochuara:

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?

Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.

Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?

Existe sim uma metodologia adequada para prever custos e desenvolver software. A essa metodologia se chama experiência e auto-melhoria.

Você só vai conseguir prever e lidar com os problemas que surgirem, e dar um preço para o software se a tua equipe já tiver passado pela situação antes, tê-la revisto, entendido, classificado e quantificado o que ela fez, naquele momento e contexto em que ela fez. E com tudo isso, a equipe define o que ela fez de errado e o que fez de certo, e põe em prática as melhorias, para que ela faça melhor na próxima vez. Esta é a visão estratégica do processo.

A visão tática é o que acontece dentro do próprio projeto em desenvolvimento, estas melhorias ainda acontecem, mas num escopo muito menor. A solução aqui é adotar um processo iterativo de desenvolvimento no escopo do projeto, a cada semana você revê o que fez, entende, classifica, quantifica, e se melhora para a próxima semana.

O que resultado físico de tudo isso são boas práticas, padrões a serem adotados, e a maior eficiência possível.

Seja desenvolimento de software, engenharia civil, medicina, qualquer coisa, esta é o princípio a ser seguido por todas as áreas. A diferença de maturidade é que as outras vem fazendo isso há milhares de anos.

Bruno Laturner:

Existe sim uma metodologia adequada para prever custos e desenvolver software. A essa metodologia se chama experiência e auto-melhoria.

Você só vai conseguir prever e lidar com os problemas que surgirem, e dar um preço para o software se a tua equipe já tiver passado pela situação antes, tê-la revisto, entendido, classificado e quantificado o que ela fez, naquele momento e contexto em que ela fez. E com tudo isso, a equipe define o que ela fez de errado e o que fez de certo, e põe em prática as melhorias, para que ela faça melhor na próxima vez. Esta é a visão estratégica do processo.

A visão tática é o que acontece dentro do próprio projeto em desenvolvimento, estas melhorias ainda acontecem, mas num escopo muito menor. A solução aqui é adotar um processo iterativo de desenvolvimento no escopo do projeto, a cada semana você revê o que fez, entende, classifica, quantifica, e se melhora para a próxima semana.

O que resultado físico de tudo isso são boas práticas, padrões a serem adotados, e a maior eficiência possível.

Seja desenvolimento de software, engenharia civil, medicina, qualquer coisa, esta é o princípio a ser seguido por todas as áreas. A diferença de maturidade é que as outras vem fazendo isso há milhares de anos.

Você acabou de descrever o CMM …

asaudate:

mochuara:

sergiotaborda:

mochuara:

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?

Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.

Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?

Esta perguntando se conheco algum lugar onde software agrega valor ao negócio do cliente? A resposta é claro que sim!

Não entendi o que consultorias tem a ver com a discussão.

Pasmém

Só o CMM? Acho que citei a história da humanidade aqui.

Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.

mochuara:

asaudate:

mochuara:

sergiotaborda:

mochuara:

asaudate:

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?

Acho que sua analise não faz sentido.

Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.

Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?

Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.

Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?

Esta perguntando se conheco algum lugar onde software agrega valor ao negócio do cliente? A resposta é claro que sim!

Não entendi o que consultorias tem a ver com a discussão.

Porque você respondeu a pergunta errada. O tópico discute sobre tempo de entrega com qualidade. Não sobre valor agregado. Obviamente, um software (atrasado ou não) tem que agregar valor, senão o cliente não tem porque contratar.

Pasmém

Só o CMM? Acho que citei a história da humanidade aqui.

Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.

Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.

Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.

Pasmém

Só o CMM? Acho que citei a história da humanidade aqui.

Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.

Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.

Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.

Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona. Tem uns juniors por aqui que acham que fazer hora extra é excelente porque ganham mais dinheiro. E isso faz com que o gerente ache que pode cortar o tempo do projeto para metada porque a equipa vai trabalhar o dobro. Afinal eles não são pessoas, a privação de sono e diversão não afeta a eficiencia deles.

O que falta , caros, é tomates. É coragem de dizer não. Quer que eu faça horas proque ? Porque o cronograma está atrazado ? E quem fez o cronograma ? vc ? E porque vc não seguiu as orientações e estimativas que lhe dei ?
Porque vc não quiz? bom, agora eu tb não quero trabalhar extra. Vai me despedir ? o problema é seu, menos um na sua equipa, mais atrazo no cronograma.

É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.

Pasmém

Só o CMM? Acho que citei a história da humanidade aqui.

Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.

Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.

Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.

Consultorias jogam o tempo de desenvolvimento lá embaixo porque o negócio delas não é criar software, e sim vender contratos de prestação de serviços nos moldes que o cliente corporativo esta acostumado para contratar um serviço pra arrumar o telhado, por exemplo. Para elas não interessa a metodologia ou engenharia de software, enquanto houverem programadores dispostos a serem recrutados pra fazer o trabalho pesado.

Não chega ser um problema de metdologia X ou Y, muito menos que “a engenharia de software” está um caos.

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Pasmém

Só o CMM? Acho que citei a história da humanidade aqui.

Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.

Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.

Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.

Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona. Tem uns juniors por aqui que acham que fazer hora extra é excelente porque ganham mais dinheiro. E isso faz com que o gerente ache que pode cortar o tempo do projeto para metada porque a equipa vai trabalhar o dobro. Afinal eles não são pessoas, a privação de sono e diversão não afeta a eficiencia deles.

O que falta , caros, é tomates. É coragem de dizer não. Quer que eu faça horas proque ? Porque o cronograma está atrazado ? E quem fez o cronograma ? vc ? E porque vc não seguiu as orientações e estimativas que lhe dei ?
Porque vc não quiz? bom, agora eu tb não quero trabalhar extra. Vai me despedir ? o problema é seu, menos um na sua equipa, mais atrazo no cronograma.

É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.

A única vez que vi isso foi numa consultoria que trabalhei, tinha um gerente que fez todo mundo fazer hora extra e a galera não recebeu o salário depois. No dia seguinte, ninguém apareceu. ninguém. Só ai a diretoria quiz saber o que tava acontecendo, chamou os desenvolvedores pra conversar, acertar os valores e etc. Pior é que da equipe foi todo mundo embora, e o gerente continua lá até hoje.

mario.fts:

sergiotaborda:

É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.

A única vez que vi isso foi numa consultoria que trabalhei, tinha um gerente que fez todo mundo fazer hora extra e a galera não recebeu o salário depois. No dia seguinte, ninguém apareceu. ninguém. Só ai a diretoria quiz saber o que tava acontecendo, chamou os desenvolvedores pra conversar, acertar os valores e etc. Pior é que da equipe foi todo mundo embora, e o gerente continua lá até hoje.

Então, o problema é esse. Como as coisas são organizadas hoje em dia o gerente haje como um buffer. Seja ele ruim ou bom, nada do que acontece na equipa ou com a equipa vaza para o resto da empresa. A equipa não é livre de ir ao superior do gerente e se queixar ou ir no RH e se queixar (que seria o natural em empresas onde o RH é sério). Então é como no exercito. Se o teu superior te manda fazer algo e tu não obdeces é desacato (dá cadeia e castigos militares… no nosso caso vai para a rua. O que pode ser bom ou mau).
mas quando o chefe dá uma ordem “inobedecivel” qual é a reação que se espera? no mundo militar é seguir e logo se vê pois os subalternos nunca são prejudicados pelas decisões dos chefes, mas no mundo de desenvolvimento no brasil é ao contrário. Vc tem que seguir porque senão o gerente vai convencer o diretor que a culpa é sua, ou da equipe com um todo.

Porque os diretores são mais alienados que os gerentes e muitas vezes estão de conluio com eles (afinal se o gerente nunca reportar problemas eu sou otimo diretor) essa hierarquia nunca muda. É por isso que o Scrum tem tão pouca penetração, porque ele destroi a hierarquia e se o gerente é ruim isso transparece nos primeiros meses. Ai ele tenta dizer que scrum é que é culpado, e não funciona, mas é ele que “não funciona”.

Se vc é CLT , infelizmente, vc está vinculado pelas mesmas regras que no exercito. Vc tem que obedecer. Mas se vc é PJ, vc não tem que aturar isso, e vc vai falar com quem vc quiser. Quem não gostar que grite. Vc pode sempre ir embora.

Quando a equipa reage e os diretores mantém o gerente ou as práticas, a mensagem é :“quem não goste que se mude” e é por isso que todo o mundo acaba indo embora. Ninguem observa a estratégia por detrás. Ninguem aufere o risco de perder todo o know-how de uma vez só. E ninguem está preocupado. Se eles não estão, porque estamos nós? Porque temos ética. E a ética é uma doença incurável. Então parte em busca de um ambiente melhor.

Quando o cinto aperta quem vc acha que será sacrificado primeiro ? o desenvolvedor de quem depende o sucesso do projeto ou o gerente que na realidade não faz nada ?

A questão é: Sair e ir pra onde? Tem muitas empresas bem legais, mas o mercado de consultorias é mais dos mesmos… essas empresas tem mais ou menos os mesmos problemas em graus diferentes.

Rubem Azenha:

sergiotaborda:

Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona.

A questão é: Sair e ir pra onde? Tem muitas empresas bem legais, mas o mercado de consultorias é mais dos mesmos… essas empresas tem mais ou menos os mesmos problemas em graus diferentes.

Eu também não sei a resposta a essa pergunta e também estou procurando por ela. Por enquanto a resposta é :ir para a próxima.

Pessoalmente acho que só dá para resolver isso num modelo em que os descontentes formam as suas empresas e filtram os que trabalham com eles não pelo mérito técnico (isso se ensina) mas pela etica profissional e pela forma como levam a sério o oficio de desenvolvedor.

O problema é: como enquadar esse tipo de empresa na lei e como colocar esse tipo de empresa no mapa.

sergiotaborda:

Rubem Azenha:

sergiotaborda:

Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona.

A questão é: Sair e ir pra onde? Tem muitas empresas bem legais, mas o mercado de consultorias é mais dos mesmos… essas empresas tem mais ou menos os mesmos problemas em graus diferentes.

Eu também não sei a resposta a essa pergunta e também estou procurando por ela. Por enquanto a resposta é :ir para a próxima.

Pessoalmente acho que só dá para resolver isso num modelo em que os descontentes formam as suas empresas e filtram os que trabalham com eles não pelo mérito técnico (isso se ensina) mas pela etica profissional e pela forma como levam a sério o oficio de desenvolvedor.

O problema é: como enquadar esse tipo de empresa na lei e como colocar esse tipo de empresa no mapa.

Restrinja seu problema para “como colocar esse tipo de empresa no mapa.”. O resto é fácil.

mario.fts:

sergiotaborda:

Rubem Azenha:

sergiotaborda:

Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona.

A questão é: Sair e ir pra onde? Tem muitas empresas bem legais, mas o mercado de consultorias é mais dos mesmos… essas empresas tem mais ou menos os mesmos problemas em graus diferentes.

Eu também não sei a resposta a essa pergunta e também estou procurando por ela. Por enquanto a resposta é :ir para a próxima.

Pessoalmente acho que só dá para resolver isso num modelo em que os descontentes formam as suas empresas e filtram os que trabalham com eles não pelo mérito técnico (isso se ensina) mas pela etica profissional e pela forma como levam a sério o oficio de desenvolvedor.

O problema é: como enquadar esse tipo de empresa na lei e como colocar esse tipo de empresa no mapa.

Restrinja seu problema para “como colocar esse tipo de empresa no mapa.”. O resto é fácil.

Para a colocar no mapa ela precisa existir, e para existir ela precisa ser um conglomerado das pessoas certas… entende o problema ?

hum… pensei que seu problema seria fazer ela aparecer, o problema do primeiro cliente, alguém que aposte inicialmente.

mario.fts:

hum… pensei que seu problema seria fazer ela aparecer, o problema do primeiro cliente, alguém que aposte inicialmente.

Sim, isso também. É claro que eu posso começar uma empresa de uma pessoa só e ir adicionando pessoas depois, mas parece-me incoerente se eu não sei quem essas pessoas são ( como eu disse antes, estamos falando de um tipo particular de desenvolvedor).

Na realidade é ambas as coisas. Pegar o primeiro cliente e ter uma equipa (mesmo que de 1) Eu vejo nisso o problema da galinha e do ovo. se alguem quiser elucidar como quebrar esse ciclo vicioso…

ai é que entra o networking. vc já trabalhou com um monte de gente, deve saber quem é bom e quem não é. a partir dai, é só ir fazendo os convites. pegar alguem do mercado sempre é arriscado quando se precisa de alta qualidade. Indicações funcionam melhor neste caso.

Então, agora, pense do ponto de vista do cara. Imagine que é vc. eu convido vc a trabalhar comigo, mas não tenho cliente, vc vem ?
Vc vai deixar o seu trabalho que tem um incom fixo para se aventurar ?

Não tem uma empresa que preste aí por essas bandas? Ou tem que criar uma ou sair atrás de alguma que exista. De qqr forma tem q levantar da cadeira e se aventurar.

Eu acho que deve até existir, mas é raro você entrar lá e os que estão dificilmente acabam saindo…

Então, agora, pense do ponto de vista do cara. Imagine que é vc. eu convido vc a trabalhar comigo, mas não tenho cliente, vc vem ?
Vc vai deixar o seu trabalho que tem um incom fixo para se aventurar ?

e voltamos no ovo e na galinha…kkkkk

é como o vinicus teles disse em uma palestra. “Se vc tem reservas, isso significa que vc tem liberdade”

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java. Já foi a época que Java representava grande parte do mercado. Hoje Java é utilizado apenas nesse tipo de consultoria porque descobriram que é um grande negócio pagar salario de miseria para os programadores e cobrar por linhas de código produzida (que não é pouca). Se quer trabalhar com projetos interessantes precisa comecar estudar outras linguagens mais modernas o quanto antes.

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java. Já foi a época que Java representava grande parte do mercado. Hoje Java é utilizado apenas nesse tipo de consultoria porque descobriram que é um grande negócio pagar salario de miseria para os programadores e cobrar por linhas de código produzida (que não é pouca). Se quer trabalhar com projetos interessantes precisa comecar estudar outras linguagens mais modernas o quanto antes.

E quem falou que eu trabalho SÓ com Java ?

Na boa, a cada post seu, eu acredito mais e mais que você é daqueles caras que se acham o máximo e pensa que é só você que conhece tecnologia. Em momento algum eu disse que as consultorias de Java fazem isso porque eu falo COM CONHECIMENTO DE CAUSA.

O que representa grande parte do mercado no Brasil? Pode até estar havendo uma mudança pra outras linguagens, mas acho que Java ainda tem a maior parte do mercado ainda.

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java.

Vc está enganado. O mesmo problema existe para o pessoal de .NET e outras linguagens. O problema da gerencia de projetos ruim não é dependente da linguagem do projeto, é dependente da cultura da gerencia e da equipe.

asaudate:

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java. Já foi a época que Java representava grande parte do mercado. Hoje Java é utilizado apenas nesse tipo de consultoria porque descobriram que é um grande negócio pagar salario de miseria para os programadores e cobrar por linhas de código produzida (que não é pouca). Se quer trabalhar com projetos interessantes precisa comecar estudar outras linguagens mais modernas o quanto antes.

E quem falou que eu trabalho SÓ com Java ?

Bom pra vc…

Mas vc é dono de alguma consultoria? Porque se for trabalhar pra alguma provavelmente irão colocar vc pra programar em Java porque é a tecnologia que tudo é de graça e os profissionais aceitam trabalhar por miseria.

mario.fts:

mochuara:

…
Já foi a época que Java representava grande parte do mercado.
…

O que representa grande parte do mercado no Brasil? Pode até estar havendo uma mudança pra outras linguagens, mas acho que Java ainda tem a maior parte do mercado ainda.

Java tem a maior parte do mercado que não presta para nos programadores.

mochuara:

asaudate:

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java. Já foi a época que Java representava grande parte do mercado. Hoje Java é utilizado apenas nesse tipo de consultoria porque descobriram que é um grande negócio pagar salario de miseria para os programadores e cobrar por linhas de código produzida (que não é pouca). Se quer trabalhar com projetos interessantes precisa comecar estudar outras linguagens mais modernas o quanto antes.

E quem falou que eu trabalho SÓ com Java ?

Bom pra vc…

Mas vc é dono de alguma consultoria? Porque se for trabalhar pra alguma provavelmente irão colocar vc pra programar em Java porque é a tecnologia que tudo é de graça e os profissionais aceitam trabalhar por miseria.

Sou desenvolvedor SOA. Isso quer dizer que eu trabalho com Java E tecnologias SOA E com outras linguagens (tipo .NET ). Então, naturalmente eu não ganho “miséria”. Mas sou explorado como todos os outros.

sergiotaborda:

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java.

Vc está enganado. O mesmo problema existe para o pessoal de .NET e outras linguagens. O problema da gerencia de projetos ruim não é dependente da linguagem do projeto, é dependente da cultura da gerencia e da equipe.

O problema não é gerencia de projetos ruim, pelo contrário, a forma como eles gerenciam os projetos é espetacular: paga salario de peao pra um programador Java que precisa fazer hora extra pra colocar no ar uma simples aplicação web porque o concorrente fez o mesmo em 1 semana (só que usando Rails).

As consultorias estão ganhando dinheiro, não estão perdendo. Pode ser o mesmo com .NET, talvez com o programador ganhando um pouquinho melhor que o programador Java.

mochuara:

sergiotaborda:

mochuara:

asaudate:

Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.

E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.

Daí a idéia de tornar obrigatórias as auditorias…

Amigo, como eu disse, este não é um problema do mercado de TI como um todo, apenas do mercado de Java.

Vc está enganado. O mesmo problema existe para o pessoal de .NET e outras linguagens. O problema da gerencia de projetos ruim não é dependente da linguagem do projeto, é dependente da cultura da gerencia e da equipe.

O problema não é gerencia de projetos ruim, pelo contrário, a forma como eles gerenciam os projetos é espetacular: paga salario de peao pra um programador Java que precisa fazer hora extra pra colocar no ar uma simples aplicação web porque o concorrente fez o mesmo em 1 semana (só que usando Rails).

Hum… ainda lá atraz vc diz que programador java ganha miséria… vc não está sendo coerente e me parece que não sabe do que está falando. Como já pedi antes e peço de novo informe-nos de dados que validem o que vc está dizendo. Dê exempos de gerencias boas e empresas boas. Suborno ainda não é uma forma de gerencia.

Eu disse que programador Java ganha miseria, e agora disse que recebe salario de peão.

Estou mentindo? Aonde que fui incoerente? Esta viajando?

mochuara:

sergiotaborda:

Hum… ainda lá atraz vc diz que programador java ganha miséria… vc não está sendo coerente e me parece que não sabe do que está falando. Como já pedi antes e peço de novo informe-nos de dados que validem o que vc está dizendo. Dê exempos de gerencias boas e empresas boas. Suborno ainda não é uma forma de gerencia.

Eu disse que programador Java ganha miseria, e agora disse que recebe salario de peão.

A sua logica é que o gerente é excelente porque obriga o cara a trabalhar horas extra ganhando um salario base pequeno.
Vc precisa primeiro justificar que o salario é pequeno e segundo que isto é uma boa forma de gerenciar.

O “suborno” se refere ao valor da hora extra.
Infelizmente tem muito junior que adora fazer horas extras, mas nas horas normais ele não faz nada. Isto é real. E isto não é uma boa forma de gerencia. O bom gerente é aquele não pede horas extras e ainda dá folgas. O bom desenvolvedor é aquele que não incha as estimativas nem é preguiçoso e faz o trabalho nas horas normais de trabalho.

Trabalhar horas extra é um sinal de “junioridade”

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar. Ok?

Esqueca o bom desenvolvedor, este ja migrou e esta cada vez mais escasso no mercado Java.

Você acha uma boa dizer que não existem bons programadores Java num fórum de Java?

luistiagos:

Rubem Azenha:

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…

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.

Tem muita empresa grande que sua equipe de TI é a pirralhada que cuida de suporte e infra-estrutura ou uns pseudo-analistas de sistemas mas que são formados em administração que não sabem nem o que é um select… dai discutir metodologias com este pessoal é o mesmo que discutir com um leigo… o que eles vão querer é simplismente o software magico ou que a gente de uma de Shiryu do CDZ e faça a cascata mudar de lado com um “Colera do dragão”…

auhauhauhauahuahaua muito boa a analogia, eu vi esse espisódio

mochuara:

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar.

Se o objetivo da empresa é lucrar, quanto menor o salário que pagar, melhor. Quanto maior o valor que conseguir cobrar, melhor. Se conseguir conquistar um cliente com um software de qualidade fraca mas que foi feito rápido, melhor.

A maioria dos clientes preferem o tempo à qualidade. Não concordo, mas o mercado hoje está nesse caminho. Claro, com exceções.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

Ruby, Scala, etc ainda tem um mercado pequeno. Se é que um dia vai crescer. É saudável estudar outras linguagens e tecnologias, mas o maior mercado ainda é Java, .NET e algumas linguagens legadas, como Delphi e VB.

marcosalex:

mochuara:

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar.

Se o objetivo da empresa é lucrar, quanto menor o salário que pagar, melhor. Quanto maior o valor que conseguir cobrar, melhor. Se conseguir conquistar um cliente com um software de qualidade fraca mas que foi feito rápido, melhor.

A maioria dos clientes preferem o tempo à qualidade. Não concordo, mas o mercado hoje está nesse caminho. Claro, com exceções.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

Ruby, Scala, etc ainda tem um mercado pequeno. Se é que um dia vai crescer. É saudável estudar outras linguagens e tecnologias, mas o maior mercado ainda é Java, .NET e algumas linguagens legadas, como Delphi e VB.

Concordo plenamente

[]´s

Então, agora, pense do ponto de vista do cara. Imagine que é vc. eu convido vc a trabalhar comigo, mas não tenho cliente, vc vem ?
Vc vai deixar o seu trabalho que tem um incom fixo para se aventurar ?

e voltamos no ovo e na galinha…kkkkk

é como o vinicus teles disse em uma palestra. “Se vc tem reservas, isso significa que vc tem liberdade”

Em 110% das consultorias onde trabalhei a história foi a mesma.

Lá pelo final do anos 80, começo do 90, dentro de alguma grande empresa existia uma area de TI a qual esta empresa queria terceirizar. Mas estavam no começo do boom das terceirizações, então não havia “consultorias” de TI a quem terceirizar esta area.
Ai o gerente da area que seria terceirizada recebe a proposta de sair da empresa, montar uma “consultoria” e pegar a terceirização. De cara este cara começavam com um grande cliente e que eles conheciam por dentro.

Esta é história de qualquer consultoria de média pra cima que existe no Brasil.

PS: E esta história não se repete apena no Brasil, a empresa em que trabalho atualmente, que é uma empresa alemã, a história foi a mesma.

marcosalex:

mochuara:

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar.

Se o objetivo da empresa é lucrar, quanto menor o salário que pagar, melhor. Quanto maior o valor que conseguir cobrar, melhor. Se conseguir conquistar um cliente com um software de qualidade fraca mas que foi feito rápido, melhor.

A maioria dos clientes preferem o tempo à qualidade. Não concordo, mas o mercado hoje está nesse caminho. Claro, com exceções.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

O assunto do topico não é dizer que as empresas são vampiros de dinheiro. Isso já sabemos que são. O objetivo é chamar a atenção para que elas são assim, porque os desenvolvedores são coniventes. Segundo, saber como inverter essa situação. Que tipo de coisas um desenvolvedor pode exigir que outro desenvolvedor (qualquer outro) também exigiria. E aqui,a palavra “desenvolvedor” significa profissional que trabalha com construção de software. Não inclui amadores e mercenários. Terceiro, saber como alertar os clientes de que estão sendo roubados. Que tem direitos como consumidor de um serviço, que ha que ter forma de medir a qualidade do software e poder comparar empresas baseados nessa qualidade. Isto é comum em qq profissão, tem quem faz, tem quem fiscaliza. Porque não na de desenvolvimento ?

sergiotaborda:

marcosalex:

mochuara:

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar.

Se o objetivo da empresa é lucrar, quanto menor o salário que pagar, melhor. Quanto maior o valor que conseguir cobrar, melhor. Se conseguir conquistar um cliente com um software de qualidade fraca mas que foi feito rápido, melhor.

A maioria dos clientes preferem o tempo à qualidade. Não concordo, mas o mercado hoje está nesse caminho. Claro, com exceções.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

O assunto do topico não é dizer que as empresas são vampiros de dinheiro. Isso já sabemos que são. O objetivo é chamar a atenção para que elas são assim, porque os desenvolvedores são coniventes. Segundo, saber como inverter essa situação. Que tipo de coisas um desenvolvedor pode exigir que outro desenvolvedor (qualquer outro) também exigiria. E aqui,a palavra “desenvolvedor” significa profissional que trabalha com construção de software. Não inclui amadores e mercenários. Terceiro, saber como alertar os clientes de que estão sendo roubados. Que tem direitos como consumidor de um serviço, que ha que ter forma de medir a qualidade do software e poder comparar empresas baseados nessa qualidade. Isto é comum em qq profissão, tem quem faz, tem quem fiscaliza. Porque não na de desenvolvimento ?

Sérgio,

Eu acho muito utópica a sua idéia, fazer com que a classe de desenvolvedores se una e obrigue profissionalismo na construção do SW e tb alerte os clientes para as burradas que eles estão fazendo…
Eu particularmente sou bastante niilista - não pessimista - pra mim o que resolve sempre é o dinheiro, se as coisas são assim até hoje é porque alguém - não nós - está ganhando dinheiro
Talvez uma forma de fazer isso seja sim a fiscalização, mexendo no bolso daqueles que fazem porcaria, talvez assim os que fazem direito passem a ser mais rentáveis e ai sim se tornem a maioria das empresas…

abs

A ideia da regulamentação é justamente essa. Só que nossos políticos querem aproveitar pra colocar taxas, conselhos, exigência de diploma e outras coisas no meio, daí vai ficar pior ainda.

Já fui idealista de tentar mudar as coisas. Hoje jogo o que mandarem e não remo mais contra a maré. E meu salário subiu proporcionalmente. É triste, mas ideologia não paga as contas. Como não estou fazendo nada anti-ético, ilegal ou imoral, me preocupo só com o que está ao meu alcance.

André Fonseca:

Sérgio,

Eu acho muito utópica a sua idéia, fazer com que a classe de desenvolvedores se una e obrigue profissionalismo na construção do SW e tb alerte os clientes para as burradas que eles estão fazendo…
Eu particularmente sou bastante niilista - não pessimista - pra mim o que resolve sempre é o dinheiro, se as coisas são assim até hoje é porque alguém - não nós - está ganhando dinheiro
Talvez uma forma de fazer isso seja sim a fiscalização, mexendo no bolso daqueles que fazem porcaria, talvez assim os que fazem direito passem a ser mais rentáveis e ai sim se tornem a maioria das empresas…

abs

Vc acha utopico porque não percebeu que para haver fiscalização tem que haver regras e para haver regras é preciso que os desenvolvedores cheguem a um consenso de quais são elas. e para haver consenso é preciso que todo eles estejam conscientes que são eles que têm a responsabilidade de encontrar e aplicar essas regras.

De nada me vale saber que existe uma regra relativamente à nomenclatura de classes e métodos que é apoiada pela maioria dos autores e desenvolvedores experientes se o estagiário sem noção ou um junior metido a sênior vem com a conversa de que não temos que nos preocupar com a nomenclatura. Se houver um consenso eu posso dizer :“fulano, vai ler no xpto.org qual é a regra para nomes e não me venhas com essas conversa furada”. E isto é algo que qq um poderia fazer - junior ou senior, gerente ou desenvolvedor.

O dinheiro sim é O fator mas as pessoas só se preocupam com ele se estão informadas. Porque as empresas querem ser verdes ? porque as pessoas estão dispostas a pagar mais por isso. E porque as pessoas vão se queixar no procon ? É porque levaram o seu dinheiro ? sim, mas apenas porque foi em circunstâncias que as regras revelam terem sido desonestas. Porque a empresa X escolhe a Y em vez da Z para fazer o imóvel da sua sede ? Dinheiro ? claro, mas qualidade tb. Todos sabem que nem sempre o mais barato nem o mais caro é o melhor. É esta escolha que precisa ser dada às empresas que procuram produtores de software, mas que não existe. Então o cliente assume que todas tem a mesma qualidade - ou pior, assume que as mais famosas têm maior qualidade - e aposta o seu dinheiro. Porque os gerentes vão enganar esses clientes, eles nunca percebem que foram enganados, até trabalharem com outra empresa melhor.

É muito fácil classificar as coisas como utópico, pois isso é a forma mais simples das descartar. Mas sem observar que essas coisas são a base para a sua proprias ideias essa classificação é perigosa. Afinal, se vc acha que é o dinheiro que mexe as coisas, qual é a sua ideia para aumentar a concorrência e alterar a balança financeira ?

marcosalex:

André Fonseca:

Talvez uma forma de fazer isso seja sim a fiscalização, mexendo no bolso daqueles que fazem porcaria, talvez assim os que fazem direito passem a ser mais rentáveis e ai sim se tornem a maioria das empresas…

A ideia da regulamentação é justamente essa. Só que nossos políticos querem aproveitar pra colocar taxas, conselhos, exigência de diploma e outras coisas no meio, daí vai ficar pior ainda.

Já fui idealista de tentar mudar as coisas. Hoje jogo o que mandarem e não remo mais contra a maré. E meu salário subiu proporcionalmente. É triste, mas ideologia não paga as contas. Como não estou fazendo nada anti-ético, ilegal ou imoral, me preocupo só com o que está ao meu alcance.

Tem a certeza?

-Papai como é que o teu salário é tão grande ?

• Porque faço exatamente o contrário do que aprendi que era correto , daquilo que a comunidade das pessoas têm o mesmo trabalho que eu acham que é correto e não me preocupo com as conseqüências disso.

sergiotaborda:

marcosalex:

André Fonseca:

Talvez uma forma de fazer isso seja sim a fiscalização, mexendo no bolso daqueles que fazem porcaria, talvez assim os que fazem direito passem a ser mais rentáveis e ai sim se tornem a maioria das empresas…

A ideia da regulamentação é justamente essa. Só que nossos políticos querem aproveitar pra colocar taxas, conselhos, exigência de diploma e outras coisas no meio, daí vai ficar pior ainda.

Já fui idealista de tentar mudar as coisas. Hoje jogo o que mandarem e não remo mais contra a maré. E meu salário subiu proporcionalmente. É triste, mas ideologia não paga as contas. Como não estou fazendo nada anti-ético, ilegal ou imoral, me preocupo só com o que está ao meu alcance.

Tem a certeza?

-Papai como é que o teu salário é tão grande ?

• Porque faço exatamente o contrário do que aprendi que era correto , daquilo que a comunidade das pessoas têm o mesmo trabalho que eu acham que é correto e não me preocupo com as conseqüências disso.

Cada um de vocês têm razão, tanto o sérgio quanto o marcos. Isso porque é fato, ninguém deveria se orgulhar de fazer as coisas incorretas, mas é fato que o que é incorreto é o que é , em algumas empresas, o mais praticado. Logo, você acaba se colocando no “perfil” da empresa e acaba ganhando mais. (Sim, passa a ganhar mais pra fazer o que é incorreto).

Problema é que nós deveríamos, sim, nos unir pra mudar as coisas e fazer as coisas do jeito certo, e pra fazer isso não tem jeito: não adianta falar “desenvolvedores, unam-se!”, se não tivermos motivos sérios pra fazer isso.

Daí vem a idéia de uma auditoria.

Conversei bastante com algumas pessoas sobre isso e a conclusão geral é de que as empresas se merecem, ou seja, se o cliente levanta uma RFP e escolhe o projeto que for mais barato, então ele merece um projeto de mais baixa qualidade (e acho que, muitas vezes, a qualidade do projeto independe do nível dos programadores, porque se o projeto tem um tempo mais apertado, algumas coisas não vão receber tanta atenção).

Vocês concordam com isso?

[]´s

O problema é que a categoria não tem representação. Um consenso entre desenvolvedores? Entre os milhões? Não tem regra nem em identificar quem é desenvolver ou não é. O ‘estagiário metido a senior’ não é um desenvolvedor? E ele discordou de você, logo, não vai ter consenso da nomenclatura.

sergiotaborda:

Tem a certeza?

-Papai como é que o teu salário é tão grande ?

• Porque faço exatamente o contrário do que aprendi que era correto , daquilo que a comunidade das pessoas têm o mesmo trabalho que eu acham que é correto e não me preocupo com as conseqüências disso.

Existe uma diferença entre correto e melhor. A forma que as consultorias trabalham não é a melhor, mas está longe de ser incorreto, ilegal ou imoral. Ou mesmo com consequencias. Essas teorias bolivarianas que fazem que o Brasil mesmo com um imenso potencial para software, não consiga o espaço que merece globalmente.

asaudate:

sergiotaborda:

marcosalex:

André Fonseca:

Talvez uma forma de fazer isso seja sim a fiscalização, mexendo no bolso daqueles que fazem porcaria, talvez assim os que fazem direito passem a ser mais rentáveis e ai sim se tornem a maioria das empresas…

A ideia da regulamentação é justamente essa. Só que nossos políticos querem aproveitar pra colocar taxas, conselhos, exigência de diploma e outras coisas no meio, daí vai ficar pior ainda.

Já fui idealista de tentar mudar as coisas. Hoje jogo o que mandarem e não remo mais contra a maré. E meu salário subiu proporcionalmente. É triste, mas ideologia não paga as contas. Como não estou fazendo nada anti-ético, ilegal ou imoral, me preocupo só com o que está ao meu alcance.

Tem a certeza?

-Papai como é que o teu salário é tão grande ?

• Porque faço exatamente o contrário do que aprendi que era correto , daquilo que a comunidade das pessoas têm o mesmo trabalho que eu acham que é correto e não me preocupo com as conseqüências disso.

Cada um de vocês têm razão, tanto o sérgio quanto o marcos. Isso porque é fato, ninguém deveria se orgulhar de fazer as coisas incorretas, mas é fato que o que é incorreto é o que é , em algumas empresas, o mais praticado. Logo, você acaba se colocando no “perfil” da empresa e acaba ganhando mais. (Sim, passa a ganhar mais pra fazer o que é incorreto).

Problema é que nós deveríamos, sim, nos unir pra mudar as coisas e fazer as coisas do jeito certo, e pra fazer isso não tem jeito: não adianta falar “desenvolvedores, unam-se!”, se não tivermos motivos sérios pra fazer isso.

Daí vem a idéia de uma auditoria.

Conversei bastante com algumas pessoas sobre isso e a conclusão geral é de que as empresas se merecem, ou seja, se o cliente levanta uma RFP e escolhe o projeto que for mais barato, então ele merece um projeto de mais baixa qualidade (e acho que, muitas vezes, a qualidade do projeto independe do nível dos programadores, porque se o projeto tem um tempo mais apertado, algumas coisas não vão receber tanta atenção).

Vocês concordam com isso?

[]´s

Não. Isso seria como concordar que um paciente deve escolher o médico por quanto ele cobra e se o médico cobra pouco e faz um trabalho ruim e a pessoa tem prejuizo com isso, a culpa é dela por ter escolhido um médico barato. O mesmo argumento se aplica a caro. Se a escolha é baseada apenas no preço, sempre é uma má escolha.

A pessoa tem direito a saber qual é o bom e qual é o mau médico e comprar isso com o preço.

Agora do ponto de vista do desenvolvedor, seria como eu ser da equipa de um cirurgião de cobra muito mas não tem noção nenhuma do que está a fazer e eu e meus colegas na sala de cirurgia é que aguentamos a operação. Isto, independemente dele repassar para nós o valor cobrado do cliente ou não. O problema ético é que se eu for embora, ele vai colocar outro no meu lugar provavelmente pior já que ele vai aproveitar para repassar menos. Se acontecer com a equipe toda, vai acontecer que pessoas começarão a morrer.
Ou então, os caras novos pegam o problema nos ombros como os que estão agora, e a vida continua como antes. A cada reciclagem a qualidade diminui , o repasse diminui, mas o esforço é o mesmo. A solução ? 1) Denunciar o médico aos outros colegas. Dessa forma ninguém irá trabalhar para ele (além de mercenários que não deixarão que o repasse diminua). 2) Denunciar o médico à ordem.

é este mesmo ciclo que acontece em desenvolvimento, a qualidade decai porque quem sabe vai saindo. A um certo ponto a empresa contrata mercenários, porque o trabalho precisa ser feito. Eles pagam mais, para quem só está ali pelo dinheiro. Isso tem um nome: corrupção moral.

marcosalex:

sergiotaborda:

Tem a certeza?

-Papai como é que o teu salário é tão grande ?

• Porque faço exatamente o contrário do que aprendi que era correto , daquilo que a comunidade das pessoas têm o mesmo trabalho que eu acham que é correto e não me preocupo com as conseqüências disso.

Existe uma diferença entre correto e melhor. A forma que as consultorias trabalham não é a melhor, mas está longe de ser incorreto, ilegal ou imoral. Ou mesmo com consequencias. Essas teorias bolivarianas que fazem que o Brasil mesmo com um imenso potencial para software, não consiga o espaço que merece globalmente.

Este é o primeiro problema. Muitos desenvolvedores pensam como você. Que não ha conseqüências.

marcosalex:

sergiotaborda:

Vc acha utopico porque não percebeu que para haver fiscalização tem que haver regras e para haver regras é preciso que os desenvolvedores cheguem a um consenso de quais são elas. e para haver consenso é preciso que todo eles estejam conscientes que são eles que têm a responsabilidade de encontrar e aplicar essas regras.

O problema é que a categoria não tem representação. Um consenso entre desenvolvedores? Entre os milhões? Não tem regra nem em identificar quem é desenvolver ou não é.

Já parou para pensar porquê ? como vc identifica um médico ? como vc o distingue de um trapaceiro ? Não precisa ir tão longe. Como vc escolhe um encanador para resolver um problema em casa? como vc sabe que ele fará um trabalho de qualidade ?
A resposta é simples: vc não sabe. No fim tudo se resume ao trabalho do cara. O quanto demorou, o quanto custou e o quanto durou.
A durabilidade do serviço é que é o principal fator aqui. O mesmo seria para o software. Se o software que vc mandou fazer fica obsuleto em 2 anos de quem é a culpa ? sua ? ou do desenvolvedor ?

por definição não. Ele é aprendiz de desenvolvedor. Caso contrário não seria estagiário. Sim, eu sei que o nome “estagiário” é usado livremente por ai, mas isso é um outro problema. O ponto é que estagiário, por definição, está ali para aprender. Se está a aprender ele ainda não é desenvolvedor. É o mesmo que um médico fazendo residência. Sem ela ele não é médico.

O ponto não é se A discorda de B, mas se a discorda da comunidade das pessoas com a mesma profissão.
Não necessariamente concordar é bom, mas discordar necessita de evidencias. Vc não quer uma nomenclartura como a organização xpto define, ok, mas porquê ? Não tem argumentos? Ou os argumentos são do tipo “não gosto dessa nomenclatura” ?

O ponto é que existem dezenas de autores explicando o que é melhor e pior. quais decisões vc deve fazer e quais evitar, quais escolhas o levarão pelo bom caminho e quais não. Não é mágico, é ciência. Dezenas de pessoas fazendo estudos e comparações em empresas ao redor do mundo. A nomenclatura hungara é um must em C++ do anos 70 e 80, hoje é uma embecilidade em Java e C#.
Antes variáveis como i, k, j e a e b eram comuns - hoje são piada e proibidas. Mas veja, elas eram usadas não porque eram boas, mas porque as linguagens ambientes tinham limitações. Existe o que é o certo e existem os constrangimentos culturais e tecnológicos. Mas o principal aqui é que a notação hungara violava um principio básico : o encapsulamento, e isso é o que a destituiu como a regra a seguir.

O Sergio tocou num ponto interessante, muitos que estão começando, estágiários, juniors, pessoal que está na faculdade, muitas vezes eles não são apresentados as boas práticas. O fato de não ter um lugar centralizando essas idéias só agrava esse problema. Se vc for ver, não existe nenhum modelo a ser seguido, logo cada um segue o modelo que achar melhor, seja ele bom ou ruim.

asaudate:

marcosalex:

mochuara:

Não é minha lógica que estamos discutindo, e sim das consultorias Java. E independente do que vc acha que é bom ou ruim, as consultorias estão ganhando rios de dinheiro explorando trabalho de juniores. Vai falar pra elas que esta não é uma boa forma de gerenciar.

Se o objetivo da empresa é lucrar, quanto menor o salário que pagar, melhor. Quanto maior o valor que conseguir cobrar, melhor. Se conseguir conquistar um cliente com um software de qualidade fraca mas que foi feito rápido, melhor.

A maioria dos clientes preferem o tempo à qualidade. Não concordo, mas o mercado hoje está nesse caminho. Claro, com exceções.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

Ruby, Scala, etc ainda tem um mercado pequeno. Se é que um dia vai crescer. É saudável estudar outras linguagens e tecnologias, mas o maior mercado ainda é Java, .NET e algumas linguagens legadas, como Delphi e VB.

Concordo plenamente

[]´s

Não é isso que alguns programadores chamam de “a morte do Java”?

O cara acabou de descrever uma forma que empresas fazem pra ganhar muito dinheiro usando Java, mas sem precisar contar com programadores competentes e linguagens de ultima geração. Como programador essa não é bem minha definição de que o mercado cresceu, ou talvez, mercado crescido não seja necessariamente coisa boa.

Sinceramente, espero que o mercado que usa linguagens mais modernas não cresca e continue pagando tão bem quanto Java pagou em 2003, 2004. Inclusive com projetos interessantes que na época existia aos montes em Java, mas hoje alguém entrando no mercado Java não vai encontrar nem por reza braba. Porque mais do que nunca, tempo é importante, como vc falou, e Java sempre fica pra trás no quesito produtividade comparada com essas novas linguagens.

mario.fts:

O Sergio tocou num ponto interessante, muitos que estão começando, estágiários, juniors, pessoal que está na faculdade, muitas vezes eles não são apresentados as boas práticas. O fato de não ter um lugar centralizando essas idéias só agrava esse problema. Se vc for ver, não existe nenhum modelo a ser seguido, logo cada um segue o modelo que achar melhor, seja ele bom ou ruim.

Bem vindo ao mundo real!

No mais eu concordo, a falta de material em portugues é um grande entrave para melhor formação desses profissionais.

mochuara:

mario.fts:

O Sergio tocou num ponto interessante, muitos que estão começando, estágiários, juniors, pessoal que está na faculdade, muitas vezes eles não são apresentados as boas práticas. O fato de não ter um lugar centralizando essas idéias só agrava esse problema. Se vc for ver, não existe nenhum modelo a ser seguido, logo cada um segue o modelo que achar melhor, seja ele bom ou ruim.

Bem vindo ao mundo real!

No mais eu concordo, a falta de material em portugues é um grande entrave para melhor formação desses profissionais.

A realidade é dura só pra quem é mole

Erike Mitts:

Desenvolvimento de software exige uma formacao em exata e dominio em outro idioma , sendo esse fundamental. Infelizmente esses padroes de projetos nao sao de comprossimos ou de normas pra muitas empresas e o mix de Metodologia hoje atrapalha mais ainda quem esta querendo entender novas adocoes em linguagem e conceitos.
Acredito que essa cultura de desenvolvimento de software seja lapidada mas la para de uns 10 anos, para tornar esses conceitos objetivos nas corporacoes ao menos no Brasil.

Marcio Duran detected?

Erike Mitts:

mochuara:

Sinceramente, espero que o mercado que usa linguagens mais modernas n? cresca e continue pagando t? bem quanto Java pagou em 2003, 2004. Inclusive com projetos interessantes que na ?oca existia aos montes em Java, mas hoje algu? entrando no mercado Java n? vai encontrar nem por reza braba. Porque mais do que nunca, tempo ?importante, como vc falou, e Java sempre fica pra tr? no quesito produtividade comparada com essas novas linguagens.

Temos que olhar mais para a Ciencias do que em exato a tecnologia em si, voce aplica e uma solucao em qual linguagem e dizer qual linguagem vai ser ? , - isso e muito Marketeiro demais, a verdade e que o maior legado foi deixado pela Sun Microsystems, e tem muita coisa ja escrita em Java linguagem e em sua plataforma, melhorar ou querer evoluir ,tormar decisao tambem muito pessoal a querer ser um profissional moderno e atualizado, especificacoes aparecem e devem ser utlizadas em projetos com as novas versoes de suas JRS, mas querer normalizar , querer melhorar o processo isso e uma decisao corporativa tambem de uma empresa atualizada.

Marcio Duran detected!

o que podemos fazer?

:arrow: termos uma postura ética com todos os envolvidos no processo e esperar que o mercado se auto-regulamente

Esse é o grande equivoco que tenho visto por aí. Achar que baixa qualidade eh mais rapido do que ter preocupacao com qualidade. Exceto em projetos muito pequenos, a má qualidade do codigo começa a atrasar o projeto muito antes da implantacao. Desenvolver software de qualidade é mais rapido do que desenvolver “na louca”.

E por que entao quase nao existe qualidade no desenvolvimento? Porque diretores, gerentes e desenvolvedores nao sabem fazer software. Sabem “cortar custos”, bater na mesa e programar. Quando muito. Nao ha interesse dos profissionais em melhorar.

Hoje em dia é um falatorio desenfreado, pelos artigos e blogs da vida, sobre Scrum, XP, boas praticas e etc… Mas a maioria das empresas nao compra a ideia. Nao compram porque essas metodologias sao vendidas como hippies, como “paz e amor” no desenvolvimento de software. Nao vejo ninguem procurando falar a lingua dos diretores, que é a língua do lucro e do resultado.

Qualquer um que ja tenha visto as metodologias ageis serem aplicadas com sucesso sabe que elas nao apenas aumentam a qualidade do software e satisfacao do cliente, elas sao mais baratas, mais eficazes e mais lucrativas.

Qual o diretor de empresa nao vai querer ter um lucro maior e mais qualidade no seu produto? O problema é encontrar quem saiba provar que as boas praticas sao lucrativas, porque a grande a maioria só sabe ficar de blablablá, mas na hora do pega pra capar, se enrola todo e transforma o que era pra ser agil no caos.

Isso nao eh verdade, eles querem velocidade, mas qualidade é o principal e eles nao trocam qualidade por velocidade, nao em sa consciencia.

Mas ainda vejo os melhores programadores trabalhando com Java, em soluções específicas e nichos estratégicos. Java é muito amplo pra afirmar que “só profissional do tipo x trabalha com Java”.

Ruby, Scala, etc ainda tem um mercado pequeno. Se é que um dia vai crescer. É saudável estudar outras linguagens e tecnologias, mas o maior mercado ainda é Java, .NET e algumas linguagens legadas, como Delphi e VB.

Concordo plenamente, como qualquer um que ja tenha alguns anos nessa area eu ja vi muitas promessas morrerem na casca. Eu procuro estudar e saber o que esta acontecendo, atualmente, estou fazendo alguns projetos pessoais em grails e outros com rails como forma de estudo e pra saber como funcionam. Mas continuo com Java porque o mercado continua com Java e quando o mercado mudar eu mudo tambem.

sergiotaborda:

asaudate:

Conversei bastante com algumas pessoas sobre isso e a conclusão geral é de que as empresas se merecem, ou seja, se o cliente levanta uma RFP e escolhe o projeto que for mais barato, então ele merece um projeto de mais baixa qualidade (e acho que, muitas vezes, a qualidade do projeto independe do nível dos programadores, porque se o projeto tem um tempo mais apertado, algumas coisas não vão receber tanta atenção).

Não. Isso seria como concordar que um paciente deve escolher o médico por quanto ele cobra e se o médico cobra pouco e faz um trabalho ruim e a pessoa tem prejuizo com isso, a culpa é dela por ter escolhido um médico barato. O mesmo argumento se aplica a caro. Se a escolha é baseada apenas no preço, sempre é uma má escolha.

heheh
Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe
Acho que uma analogia melhor seria você ter de escolher comprar entre um Corsa que te atende ou um Astra. É óbvio que o Astra é muito melhor, mas se você não puder ou não estiver a fim de arcar com seu custo, você optaria pelo Corsa, mesmo sabendo que suas peças tem menor durabilidade e que você pode ter uma manutenção maior no futuro. Mas a escolha é consciente sua.

Agora, bolivariana é a ideia de que em fabrica e vende o corsa está fazendo alguma coisa errada, já que não está vendendo o melhor carro.

Eu acho que isso é verdade em muitos casos, mas eu já trabalhei com muitos gerentes que eram programadores antes, infelizmente, porque o certo seria se você é programador e gosta disso conseguir desenvolver sua carreira toda como programador…

Nisso eu concordo plenamente

Neste ponto eu tb já vi muitos gestores trocarem qualidade por velocidade, coisas do tipo, se está funcionando não mexa é muito comum, ou então, faz um remendo ai e depois a gente vê uma forma melhor de fazer - o que nunca vai acontecer

Neste caso, caberia as pessoas que trabalham com essas metodologias e que tiveram sucesso expor isso, através de estudos de caso por exemplo. Só assim se forma a base teórica para começar a propor essas mudanças, além de chamar a atenção de outras áreas, como administração por exemplo.

marcosalex:

sergiotaborda:

asaudate:

Conversei bastante com algumas pessoas sobre isso e a conclusão geral é de que as empresas se merecem, ou seja, se o cliente levanta uma RFP e escolhe o projeto que for mais barato, então ele merece um projeto de mais baixa qualidade (e acho que, muitas vezes, a qualidade do projeto independe do nível dos programadores, porque se o projeto tem um tempo mais apertado, algumas coisas não vão receber tanta atenção).

Não. Isso seria como concordar que um paciente deve escolher o médico por quanto ele cobra e se o médico cobra pouco e faz um trabalho ruim e a pessoa tem prejuizo com isso, a culpa é dela por ter escolhido um médico barato. O mesmo argumento se aplica a caro. Se a escolha é baseada apenas no preço, sempre é uma má escolha.

heheh
Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe

O assunto era outro.
Aqui o assunto é prestação de serviço e a escolha do prestador baseado no preço.

Não, não é melhor porque um carro não é um serviço, comprar um carro não é um serviço. Se vc não gosta do carro ou escolhe o carro errado, o fabricante não tem culpa. É diferente de vc escolher o médico errado ou o encanador errado.

Exactamente.
Eu acho que ou 1) não ha realmente ninguem trabalhando com agil a sério ( ou seja, as empresas sabem que os desenvovledores trabalham assim e apostam nisso) ou 2) não ha bons resultados porque as empreas podam os processos e os adaptam tanto que deixam de ser comparáveis.

Com certeza! Acho que TI é uma das únicas áreas que não leva a sério publicar estudos de caso de projetos que deram certo…

sergiotaborda:

marcosalex:

sergiotaborda:

asaudate:

Conversei bastante com algumas pessoas sobre isso e a conclusão geral é de que as empresas se merecem, ou seja, se o cliente levanta uma RFP e escolhe o projeto que for mais barato, então ele merece um projeto de mais baixa qualidade (e acho que, muitas vezes, a qualidade do projeto independe do nível dos programadores, porque se o projeto tem um tempo mais apertado, algumas coisas não vão receber tanta atenção).

Não. Isso seria como concordar que um paciente deve escolher o médico por quanto ele cobra e se o médico cobra pouco e faz um trabalho ruim e a pessoa tem prejuizo com isso, a culpa é dela por ter escolhido um médico barato. O mesmo argumento se aplica a caro. Se a escolha é baseada apenas no preço, sempre é uma má escolha.

heheh
Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe

O assunto era outro.
Aqui o assunto é prestação de serviço e a escolha do prestador baseado no preço.

Não, não é melhor porque um carro não é um serviço, comprar um carro não é um serviço. Se vc não gosta do carro ou escolhe o carro errado, o fabricante não tem culpa. É diferente de vc escolher o médico errado ou o encanador errado.

Discordo. Falando de software, o software não é um produto??

Software é requisito :lol:

asaudate:

sergiotaborda:

marcosalex:

Acho que uma analogia melhor seria você ter de escolher comprar entre um Corsa que te atende ou um Astra. É

Não, não é melhor porque um carro não é um serviço, comprar um carro não é um serviço. Se vc não gosta do carro ou escolhe o carro errado, o fabricante não tem culpa. É diferente de vc escolher o médico errado ou o encanador errado.

Discordo. Falando de software, o software não é um produto??

Para o departamento de marketing e vendas é o que eles quiserem, produto, serviço …
Para o desenvolvimento, desenvolver software não é um produto. Desenvolver software é um serviço. Isso é claro e obvio e é por isso que vc paga ISS (se vc tem a sua ppr empresa PJ)

Comparar a produção de software à produção industrial está mais que sabido que é falho. Portanto, é bom se afastar dessa ideia de que software é um produto. Software é muito mais que isso.

Quando antigamente os reis pediam uma pintura a um pintor, o que eles estavam comprando ? Um produto ? O quadro ? a tinta, a moldura , a tela ? Ou estavam comprando o serviço da pintura ? O serviço da pintura era retratar o rei ? Não. Era apresentá-lo na tela como o rei queria ser mostrado. Preencher este “querer” é que valia dinheiro. O valor do quadro está em cumprir o requisito de retratar o rei do jeito que ele quer. Mas ao mesmo tempo o pintor tem um reputação. As suas cores eram feitas por ele mesmo, os tons e as misturas analisadas e replicadas para conseguir efeitos. A tela era pintada várias vezes, com várias camadas até conseguir o efeito desejado. Aqui o pintor não está preocupado com o requisito, mas com a sua reputação e em angariar mais clientes.

Software é semelhante. Existem requisitos e existe qualidade técnica. A qualidade tecnica não é paga ela é contratada. Se o rei contrata o pintor mais famoso é porque isso lhe dá segurança que trabalho será bom e ele considera pagar um preço alto.

Software é mais que um produto, é um serviço que gera um produto. Não é o produto em si que tem valia, mas o que ele faz pelo cliente. Não é o produto em si que custa, mas o desenvolvimento dele.

Leia Clean Code para uma melhor compreensão.

Acho que o mercado Java esta longe de acabar, existe uma grande demanda por projetos CRUDs e farta oferta de mao de obra barata.

Acho que o mercado Java esta longe de acabar, existe uma grande demanda por projetos CRUDs e farta oferta de mao de obra barata.

Sim, esse é um ponto de vista valido, o mercado esta cheio de mao de obra barata sim. E por isso eh bom sempre manter o olho aberto pra novas ferramentas.

Nao disse que gerente tem que ter sido programador, acho que nao me expressei direito, o que quis dizer é que nem diretoria, nem gerencia, nem programadores sabem ao certo o que fazer pra melhorar a qualidade do software que produzem.

Sim, os gestores fazem isso com frequencia, mas os clientes, se puderem optar nao vao fazer essa opcao. Eles querem qualidade, o quanto mais rapido melhor.

marcosalex:

Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe
Acho que uma analogia melhor seria você ter de escolher comprar entre um Corsa que te atende ou um Astra. É óbvio que o Astra é muito melhor, mas se você não puder ou não estiver a fim de arcar com seu custo, você optaria pelo Corsa, mesmo sabendo que suas peças tem menor durabilidade e que você pode ter uma manutenção maior no futuro. Mas a escolha é consciente sua.

Agora, bolivariana é a ideia de que em fabrica e vende o corsa está fazendo alguma coisa errada, já que não está vendendo o melhor carro.

Se voce compra um Corsa é porque ele te atende, mas voce nao vai aceitar que ele venha com problema nos freios ou que o farol so acenda de vez em quando.

YvGa:

…

Eu não considero uma perda de tempo. Todos saem ganhando, a empresa que passa a ser vista como modelo, o cara que fez o estudo de caso por ser reconhecido como um bom profissional, e a comunidade, por ter acesso a essas informações. é isso o que ajuda os que tem “oportunidades pra mudar alguma coisa mas nao sabem o que fazer”…

No mais eu concordo com vc.

Não existe uma única resposta para essas questões. Por que não encarar que entre o PRETO e o BRANCO existe o CINZA? Cada caso é um caso. Acredito que um bom profissional precisa entender as necessidades da empresa em que trabalha, pois quem deve definir o foco (QUALIDADE, CLIENTE ou RESULTADO) é a diretoria e não o analista de sistemas. Ninguém gosta de entregar (ou trabalhar em um produto sem qualidade), mas precisamos ter em mente que a qualidade tem um custo, e as vezes um executivo tem como meta implantar um produto em 3 - 6 meses com budget limitado, sendo assim os recursos devem ser otimizados e como saída haverá um produto de baixa qualidade mas que atende as necessidades dos acionistas / investidores. Para um investidor o importante é que o resultado final seja positivo (ROI) ;-).

Não podemos comparar o mercado do Corsa com o de uma Mercedez ou BMW. Por que se a GM investir no Corsa de modo a torná-lo com a mesma qualidade de um BMW, o mesmo perderia o mercado para a Fiat (Uno) ou Ford (Fiesta), pois seu produto seria muito mais caro e não ganharia mercado do BMW e Mercedez.

Voltando ao assunto real (Software - Agile), a experiência que tive em projetos com metodologia tradicional serviram apenas para empregar “diagramadores / documentadores” que realizaram um monte de casos de uso e diagramas UML que não serviram para NADA a não ser atender a uma determinada norma corporativa… E que a figura do “Analista de negócios” serve apenas para atrapalhar, pois não conhecem nada do negócio e nada de sistemas. Básicamente tentam entender o requisito do cliente e passar “mastigado” para o analista de sistemas. Sendo assim, servem para aumentar o ruído na linha…

Com relação as experiências que tive com desenvolvimento ágil, gostaria de mencionar o último projeto em que trabalhei e tenho a dizer que foi EXCELENTE. Nada de casos de uso, nada de diagramas UML. Utilizamos apenas uma ferramenta WIKI para controlar os requisitos (Story boards) e uma ferramenta para controlar o andamento das atividades, features, etc… (JIRA). O escopo foi definido no início do projeto, todos os requisitos levantados foram implementados no prazo e com uma qualidade bastante satisfatória. Na minha opinião o sucesso se deu as pessoas envolvidas e ao fato de que ao invés gastar tempo e dinheiro escrevendo casos de uso e diagramas UML, nos preocupamos em entender os requisitos, codificar e testar a aplicação…

Não existe uma única resposta para essas questões. Por que não encarar que entre o PRETO e o BRANCO existe o CINZA? Cada caso é um caso.

Ok, mas em todos vc não pode abrir mão da ética profissional e dos padrões de qualidade da sua profissão. A sua profissão é fazer software não engraxar os sapatos do seu gerente, diretor, etc… o trabalho deles é lidar com os constrangimentos, não o seu.
São eles que têm que cortar features, etc… e não vc que tem que cortar em qualidade.

Errado. É o desenvolvedor que define a qualidade. É isso que significa ser “bom”. O bom profissional é aquele que entrega com qualidade no prazo e no custo e no escopo acertados. Se a qualidade não está lá, não está lá um bom profissional.

Vc está redondamente enganado. É a falta de qualidade que tem custo. É a gambiarra, é a não previsão, é o não dimensionamento, em suma, é tudo aquilo que foi feito sem qualidade. É isso que gera custo excessivo. Uma boa equipe trabalhando sem impedimentos entra em estado de hiperprodutividade e produz mais com qualidade, que um bando de 15 juniors sem padrão algum.
Leia Software Estimation, Desmistfying the black art e Code Complete para numeros e Clean Code e Effective Java para definição de qualidade.

Não ha desculpa para diminuir a qualidade. E é imperdoável que o desenvolvedor o faça.
A resposta a prazos agressivos é design de qualidade

Acho que o mercado Java esta longe de acabar, existe uma grande demanda por projetos CRUDs e farta oferta de mao de obra barata.

Sim, esse é um ponto de vista valido, o mercado esta cheio de mao de obra barata sim.

Não é um ponto de vista e sim uma analise do mercado Java baseado na minha experiencia. E vc? Qual o ultimo projeto Java que participou que não era CRUD?

Se vc trabalha pra alguma consultoria Java não tem outra opção mesmo a não ser “ficar de olhos abertos”, já que da forma que o mercado Java esta configurado na mão das consultorias não cabe a quem entende escolher a tecnologia mais apropriada para cada caso.

Por outro lado, existem bons programadores entrando no mercado a toda hora, e os melhores vão direto para o mercado que melhor atende suas necessidades como profissional de TI, em termos de salário, condição de trabalho, ferramentas. Na verdade minha recomendação para aprender novas linguagens é para os que estão entrando no mercado, não macaco velho.

Concordo plenamente com a parte do ruído na linha (e, inclusive, acho que sei de que projeto você está falando, Osvaldo ).

Mas acho, também, que agile não é bala de prata. Nesse ponto, eu concordo com o Sergio, de que é a equipe quem faz a diferença (seja ágil ou não). Assim, quem tem que prezar pela qualidade do código (o que acaba influindo no tempo de entrega) é a equipe.

There is no silver bullet. Mas das alternativas que temos por aí, eu creio que desenvolvimento ágil seja a melhor para a opção para a maioria dos casos. Geralmente desenvolvimento ágil não é uma boa opção quando temos problemas políticos nas empresas e nas equipes.

There is no silver bullet. Mas das alternativas que temos por aí, eu creio que desenvolvimento ágil seja a melhor para a opção para a maioria dos casos. Geralmente desenvolvimento ágil não é uma boa opção quando temos problemas políticos nas empresas e nas equipes.

Da mesma forma que waterfall da margem a analistas UML, metodologias agile da margem a evangelistas que vivem blogando as maravilhas de ser agil mas quando aperta um pouquinho ele corre pra “implantar agile” em outra empresa.

Ou seja, não existe essa de agile ser melhor para a maioria dos casos, principalmente se a maioria dos casos não esta preocupado com qualidade, como é o caso dessas consultorias Java.

Hoje estou trabalhando em um projeto que realiza automação da separação de caixas com pedidos de uma distribuidora de medicamentos. Envolve comunicação com hardware e atualmente separa 3600 pedidos por noite (mas temos que multiplicar esse valor por 22 = número de terminais).
Acredito que java é mais que uma linguagem é uma plataforma que atende vários segmentos, se existe mão de obra barata é por que existe em quantidade, mas isso não impede do profissional de qualidade cobrar o que é justo pelo seu serviço, e quando digo profissional digo profissional de qualquer tecnologia.

Rubem Azenha:

Geralmente desenvolvimento ágil não é uma boa opção quando temos problemas políticos nas empresas e nas equipes.

Mas esses problemas existem, não ha metodologia que resista.
Agil não é uma metodologia de desenvolvimento preocupada com o software, e sim com o resultado. Ou seja, entregue depressa e a horas. Mas a qualidade do que é entregue não está definido. Se vc usar XP , vc tem que fazer testes. Ok. Mas quem garante que vc faz os testes certos ?
Em Scrum a definição de pronto é definivel pelo implantador. Logo eu posso escolher a minha definição de pronto como : o software roda.
Isso está ok para scrum e agil em geral, mas não para um desenvolvedor preocupado com a qualidade. é aqui que artesanato de software (Software craftmanship). Mas basta que rode, isso é o minimo que se espera de um desenolvimento. Qualquer amador faz isso. O software tem que está bem construido “por dentro”.

A responsabilidade de construir bem por dentro é dos desenvolvedores. Não ha gerente que possa ajudar nisso.

laudenpower:

mochuara:

Não é um ponto de vista e sim uma analise do mercado Java baseado na minha experiencia. E vc? Qual o ultimo projeto Java que participou que não era CRUD?

Hoje estou trabalhando em um projeto que realiza automação da separação de caixas com pedidos de uma distribuidora de medicamentos. Envolve comunicação com hardware e atualmente separa 3600 pedidos por noite (mas temos que multiplicar esse valor por 22 = número de terminais).
Acredito que java é mais que uma linguagem é uma plataforma que atende vários segmentos, se existe mão de obra barata é por que existe em quantidade, mas isso não impede do profissional de qualidade cobrar o que é justo pelo seu serviço, e quando digo profissional digo profissional de qualquer tecnologia.

Na certa vc escreve 1 linha de codigo Java que por sua vez chama o codigo em C que faz toda a comunicação com hardware. O resto (CRUD) vc faz com Java ne?

E onde entra a plataforma nisso?

Ta certo, vc pode cobrar o que quiser, principalmente se vc precisa fazer tunning de GC, ou alterações no nivel do bytecode, mas se for pra criar aplicações Java, ninguém vai te pagar bem porque existe muito programador Java no mercado. A não ser que vc seja 2x mais produtivo fazendo hora extra.

Não concordo com você pois trabalhar de acordo com a estratégia da empresa não anti-ético, pelo contrário… Mas vamos lá, vou te propor um exercício:

Imagine você como arquiteto de software de uma empresa X onde após uma longa reunião, seu diretor visualiza uma estratégia para antecipar a concorrência em um determinado segmento de mercado que além de agregar valor a marca da corporação, geraria uma oportunidade de vendas exclusiva de 5 meses. Para que isso aconteça ele delega a você um orçamento de R$ 500.000,00 e diz que impreterívelmente o seu projeto deve estar em produção nos próximos 3 meses, caso contrário o custo envolvido não valeria apena ser investido diante do risco.

Um líder em sua posição deve otimizar os recursos, isso significa achar a melhor solução com os recursos disponíveis. Entretanto é claro que você não vai desenvolver um produto com a mesma qualidade que desenvolveria se tivesse um ano ao invés de três meses e orçamento ilimitado… Imagine se por exemplo, você definisse sua estratégia de testes da aplicação conforme abaixo:

• Fase: Testes de unidade (Intra-método) / Técnica: Testes funcionais + Testes estruturais (100% de cobertura)
• Fase: Testes integrados / Técnica: Testes estruturais (100% de cobertura)

Com certeza tal estratégia custaria sua cabeça na corporação devido sua grande incompetência.

Por isso disse que entre o branco e o preto existe o CINZA. Pense a respeito. . .

Errado. É o desenvolvedor que define a qualidade. É isso que significa ser “bom”.

Acredito que você não entendeu o que eu disse… Em administração de sistemas, especificamente em planejamento estratégico, os executivos definem o foco da empresa que pode ser: Resultado, Cliente, Qualidade, etc… O desenvolvedor implementa a estratégia e gerente de software deve direcioná-lo de acordo com a estratégia corporativa.

ERRADO, o bom profissional é aquele que entrega a melhor solução compatível com os recursos disponíveis (Tempo, Dinheiro, Máquinas, Ferramentas…) Exemplo: Com recursos ilimitados seria possível fazer o software sem defeitos…

Quanto maior a qualidade do produto, maior seu ciclo de vida e menor o custo de manutenção. Entretanto o custo de implementação é excessivamente MAIOR. Faça um teste, desenvolva um sistema qualquer (Petstore, por exemplo) sem nenhum caso de testes (caixa branca), e peça para um colega implementar o mesmo sistema utilizando casos de testes com o requisito de obter 100% de cobertura (teste estrutural). Garanto a você que o custo de implementação do segundo será execessivamente maior.

Já li Code Code Complete, você leu? Deveria rever alguns conceitos…

Aproveite e leia:

http://libdigi.unicamp.br/document/?did=25141
http://libdigi.unicamp.br/document/?did=24246
http://libdigi.unicamp.br/document/?did=25334

Depois você me diz se o custo de implementação da qualidade não é caro.

Para cada caso existe uma curva que representa o valor máximo em que compensa o investimento na qualidade. Tenha em mente que quanto maior a qualidade maior o tempo de retorno do investimento. Otimizar essa função é uma das tarefas mais dificeis, pois depende de fatores intangíveis. E há casos em que o custo de manutenção não paga o investimento, por exemplo se o ciclo de vida do produto for pequeno suficiente de modo a não pagar o custo de implantação.

um abraço,
Osvaldo

mochuara:

laudenpower:

mochuara:

Não é um ponto de vista e sim uma analise do mercado Java baseado na minha experiencia. E vc? Qual o ultimo projeto Java que participou que não era CRUD?

Hoje estou trabalhando em um projeto que realiza automação da separação de caixas com pedidos de uma distribuidora de medicamentos. Envolve comunicação com hardware e atualmente separa 3600 pedidos por noite (mas temos que multiplicar esse valor por 22 = número de terminais).
Acredito que java é mais que uma linguagem é uma plataforma que atende vários segmentos, se existe mão de obra barata é por que existe em quantidade, mas isso não impede do profissional de qualidade cobrar o que é justo pelo seu serviço, e quando digo profissional digo profissional de qualquer tecnologia.

Na certa vc escreve 1 linha de codigo Java que por sua vez chama o codigo em C que faz toda a comunicação com hardware. O resto (CRUD) vc faz com Java ne?

E onde entra a plataforma nisso?

Ta certo, vc pode cobrar o que quiser, principalmente se vc precisa fazer tunning de GC, ou alterações no nivel do bytecode, mas se for pra criar aplicações Java, ninguém vai te pagar bem porque existe muito programador Java no mercado. A não ser que vc seja 2x mais produtivo fazendo hora extra.

Faltou colocar nessa equação o conhecimento do profissional, eles vão te pagar pouco se você não tiver nada que te destaque isso é fato…
Quando falei em plataforma estava dizendo que existe muito segmento para o profissional investir e se especializar, aposto que os crud’s que tu apontou são em grande maioria web, mas tenho certeza que tem muito espaço para aplicações móveis e desktop, e não me venha dizer que delphi e vb tomaram conta que uma coisa é fato, essas linguagens aos poucos estão se direcionando a nichos e aplicativos legados.

oandrade:

Ok, mas em todos vc não pode abrir mão da ética profissional e dos padrões de qualidade da sua profissão. A sua profissão é fazer software não engraxar os sapatos do seu gerente, diretor, etc… o trabalho deles é lidar com os constrangimentos, não o seu.
São eles que têm que cortar features, etc… e não vc que tem que cortar em qualidade.

Não concordo com você pois trabalhar de acordo com a estratégia da empresa não anti-ético, pelo contrário… Mas vamos lá, vou te propor um exercício:

Imagine você como arquiteto de software de uma empresa X onde após uma longa reunião, seu diretor visualiza uma estratégia para antecipar a concorrência em um determinado segmento de mercado que além de agregar valor a marca da corporação, geraria uma oportunidade de vendas exclusiva de 5 meses. Para que isso aconteça ele delega a você um orçamento de R$ 500.000,00 e diz que impreterívelmente o seu projeto deve estar em produção nos próximos 3 meses, caso contrário o custo envolvido não valeria apena ser investido diante do risco.

Um líder em sua posição deve otimizar os recursos, isso significa achar a melhor solução com os recursos disponíveis. Entretanto é claro que você não vai desenvolver um produto com a mesma qualidade que desenvolveria se tivesse um ano ao invés de três meses e orçamento ilimitado… Imagine se por exemplo, você definisse sua estratégia de testes da aplicação conforme abaixo:

• Fase: Testes de unidade (Intra-método) / Técnica: Testes funcionais + Testes estruturais (100% de cobertura)
• Fase: Testes integrados / Técnica: Testes estruturais (100% de cobertura)

Com certeza tal estratégia custaria sua cabeça na corporação devido sua grande incompetência.

E eu com isso.
O problema se resolve facilmente. Com esse dinheiro da para montar uma equipa decente. Um arquitetura simples e um conjunto bem aplicado de design patterns.

Eu já tive que fazer isso com menos recursos e menos tempo. Se a unica coisa que é o seu limite é uma quantidade em dinheiro vc tem o mundo na sua mão. O problema aconteece quando o gerente/diretor começa com umas conversas de documentação em UML, documentação de casos de uso e o diabo. Isso que atraza.
Nos projetos onde fui arquiteto eu fazia o framework, o pessoal usava e usavamos scrum. Enquanto isso eu tinha que fazer esse documentos idiotas e inuteis porque era no dia a dia que as coisas eram colocadas na mesa. Não vale a pena colocar tudo no UML . isso é simplesmente idiota. Cumpriamos os prazos e faziamos demonstrações. Sabe o resultado ?
A empresa , depois do produto pronto, nunca o usou. Tal era a pressa que tinha…

Não ha espaço para sacrificar a qualidade. A qualidade era o que nos permitia alterar todo o sistema em ciclos de uma semana e sem horas extra. Se fosse POG ainda estavamos lá desenvolvendo.

Sacrificar a qualidade é inadmissível. Quando mais depressa entenderm isso melhor.

Claro, é mais facil deixar a bola cair e culpa a pressão dos chefes. Afinal ler livros e pensar nos problemas é altamente cansativo e estressante. Afinal o objetivo é ter um emprenho, não trabalhar.

laudenpower:

Faltou colocar nessa equação o conhecimento do profissional, eles vão te pagar pouco se você não tiver nada que te destaque isso é fato…

Acho que vc não esta acompanhando a discussão. Nenhuma consultoria Java quer seu conhecimento aprofundado porque o negócio delas consiste em oferecer software de baixa qualidade. O que destaca o profissional aos olhos dela é a capacidade de fazer hora extra sem chorar, pra cumprir os prazos que outros estabeleceram sem a minima noção do trabalho que vai dar.

laudenpower:

Quando falei em plataforma estava dizendo que existe muito segmento para o profissional investir e se especializar, aposto que os crud’s que tu apontou são em grande maioria web, mas tenho certeza que tem muito espaço para aplicações móveis e desktop, e não me venha dizer que delphi e vb tomaram conta que uma coisa é fato, essas linguagens aos poucos estão se direcionando a nichos e aplicativos legados.

Java em aplicações móveis? Isso deve ser piada ne? Java ja perdeu essa briga brow. Qual a próxima piada? TV Digital? :roll:

mochuara:

laudenpower:

Faltou colocar nessa equação o conhecimento do profissional, eles vão te pagar pouco se você não tiver nada que te destaque isso é fato…

Acho que vc não esta acompanhando a discussão. Nenhuma consultoria Java quer seu conhecimento aprofundado porque o negócio delas consiste em oferecer software de baixa qualidade. O que destaca o profissional aos olhos dela é a capacidade de fazer hora extra sem chorar, pra cumprir os prazos que outros estabeleceram sem a minima noção do trabalho que vai dar.

laudenpower:

Quando falei em plataforma estava dizendo que existe muito segmento para o profissional investir e se especializar, aposto que os crud’s que tu apontou são em grande maioria web, mas tenho certeza que tem muito espaço para aplicações móveis e desktop, e não me venha dizer que delphi e vb tomaram conta que uma coisa é fato, essas linguagens aos poucos estão se direcionando a nichos e aplicativos legados.

Java em aplicações móveis? Isso deve ser piada ne? Java ja perdeu essa briga brow. Qual a próxima piada? TV Digital? :roll:

Acho que quem ta fazendo piada aqui é tu, essa visão de que todas as consultorias não dão a mínima para o profissional é falácia, existem empresas que inclusive dão treinamento ao funcionário e o incentivam a tirar a certificação como prova de qualificação e não esperam hora extra por isso.
Em relação aos exemplos que te passei foi apenas para mostrar como a plataforma é extensa, agora se tu acha que o com ruby e seus clojurequedizemqueehlegalporissovouusar é padrão de mercado então tu deves ter algum trauma do java.

laudenpower:

existem empresas que inclusive dão treinamento ao funcionário e o incentivam a tirar a certificação como prova de qualificação e não esperam hora extra por isso.

Quais ? IBM ? Google ? humm… essas não contam.

E entao o arquiteto acabaria com toda a visao estrategica do cara, que descobriu esta brecha pra ganhar uma fortuna entregando pra ele uma bomba? Coitado do diretor, tao competente em visoes de mercado e tao incompetente em recrutar profissionais.

O que as pessoas precisam entender é que desenvolver software de qualidade é mais rapido que desenvolver software sem qualidade. Desenvolver software sem se preocupar com falhas vai gerar constrangimento e trabalho extra antes da implantacao. Toda aquela confusao de codigo “despreocupado” comeca a cobrar seu preco ja no inicio do projeto.

laudenpower:

Acho que quem ta fazendo piada aqui é tu, essa visão de que todas as consultorias não dão a mínima para o profissional é falácia, existem empresas que inclusive dão treinamento ao funcionário e o incentivam a tirar a certificação como prova de qualificação e não esperam hora extra por isso.

Não só para o profissional, mas dão a minima tb para o cliente, que não sabe que seu negócio esta na mão de profissionais que se formaram em cursinho de Java. Mas se receber 1/3 do salario normal (ainda como PJ!) é ser bem tratado só porque vc pode fazer a prova 3 vezes sem pagar pelo voucher, ok ne?

laudenpower:

Em relação aos exemplos que te passei foi apenas para mostrar como a plataforma é extensa, agora se tu acha que o com ruby e seus clojurequedizemqueehlegalporissovouusar é padrão de mercado então tu deves ter algum trauma do java.

Se depois de tudo que foi dito aqui vc continua querendo seguir o padrão do mercado é porque pretende abrir uma consultoria, não seguir carreira como progamador, estou certo?

http://blog.objectmentor.com/articles/2008/11/16/dirty-rotten-scrumdrels

Perfeito.

Por acaso o Uncle Bob é o Sergio Taborda??? =P

A ideia de separar analista de negócios do desenvolvedor era pra resolver o problema (Verdadeiro) dos profissionais que ou eram melhores na área técnica ou melhores na área de especificação e regras de negócio.

Só que do jeito que essas empresas trabalham ficou muito menos produtivo. Além de colocarem equipes com perfil misto trabalhando juntos, separaram o trabalho de tal forma que ficou burocrático demais.

Felizmente é cada vez mais frequente as empresas que estão revendo esse ponto de vista

marcosalex:

A ideia de separar analista de negócios do desenvolvedor era pra resolver o problema (Verdadeiro) dos profissionais que ou eram melhores na área técnica ou melhores na área de especificação e regras de negócio.

Só que do jeito que essas empresas trabalham ficou muito menos produtivo. Além de colocarem equipes com perfil misto trabalhando juntos, separaram o trabalho de tal forma que ficou burocrático demais.

Felizmente é cada vez mais frequente as empresas que estão revendo esse ponto de vista

A verdade verdadeira é que analista de negocios não é um desenvolvedor. É aquilo que agora se chama um Domain Except que atua como filtro e realce para o cliente. Ou seja, ajuda o cliente a desenvolver a ideia do software do ponto de vista do negocio e não do software. Ou seja, ele sugere operações que o sistema pode fazer ou não deve fazer etc… ele ajuda, basicamente, a criar um melhor backlog de estorias porque ele conhece o negocio.

Agora, o “analista de sistemas” , ou seja o desenvolvedor , tem que diferir isso para conversa de desenvolvimento. E ai ha sugestões mais tecnicas. Por exemplo , o desenvolvedor, pode mudar o fluxo das operações para facilitar a compreensão na hora de desenvolvedor, ou mudar o layout visual ( um ui designer tb é um desenvolvedor). Mas as features em si, não são alteradas.

O problema é querer que um domain expert seja um developemtn exper. Isso, simplesmente, não existe.

Sergio, não entendi essa sua definição nem a diferença. Você está dizendo que “Analista de negócios” trabalha mais próximo ao programador e “Domain expert” trabalha mais próximo ao cliente, é isso?

e eu achando que sabia ofender algo/alguém em ingles…

esse povo que fica culpando metodologia, é tudo culpa desse tipo de pensamento :http://martinfowler.com/bliki/FlaccidScrum.html

**** em portugues pra quem se sentir melhor: http://www.akitaonrails.com/2009/02/03/tradu-o-scrum-fl-cido