Acho que o mercado Java esta longe de acabar, existe uma grande demanda por projetos CRUDs e farta oferta de mao de obra barata.[/quote]
Sim, esse é um ponto de vista valido, o mercado esta cheio de mao de obra barata sim.[/quote]
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.
[/quote]
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.
[quote=Rubem Azenha] Geralmente desenvolvimento ágil não é uma boa opção quando temos problemas políticos nas empresas e nas equipes.
[/quote]
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.
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?
[/quote]
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.[/quote]
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. . .
[quote]
Errado. É o desenvolvedor que define a qualidade. É isso que significa ser “bom”.[/quote]
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…
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.
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?
[/quote]
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.[/quote]
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.[/quote]
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.
[quote=oandrade][quote]
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.
[/quote]
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.
[/quote]
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.
[quote=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…[/quote]
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.
[quote=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.[/quote]
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:
[quote=mochuara][quote=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…[/quote]
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.
[quote=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.[/quote]
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: [/quote]
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.
[quote=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.[/quote]
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.
[quote=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.[/quote]
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?
[quote=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.[/quote]
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?
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
[quote=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[/quote]
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.
).