[quote=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.
[/quote]
Bem vindo ao mundo real!
No mais eu concordo, a falta de material em portugues é um grande entrave para melhor formação desses profissionais.
[quote=mochuara][quote=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.
[/quote]
Bem vindo ao mundo real!
No mais eu concordo, a falta de material em portugues é um grande entrave para melhor formação desses profissionais.[/quote]
[quote=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.[/quote]
[quote=Erike Mitts][quote=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.
[/quote]
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.[/quote]
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.
[quote]
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.[/quote]
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.
[quote=sergiotaborda][quote=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).
[/quote]
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.
[/quote]
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.
[quote=marcosalex][quote=sergiotaborda][quote=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).
[/quote]
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.
[/quote]
heheh
Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe
[/quote]
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.
[quote=sergiotaborda][quote=marcosalex][quote=sergiotaborda][quote=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).
[/quote]
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.
[/quote]
heheh
Em um tópico atras você abominou a comparação da nossa profissão com a área médica. hehehehe
[/quote]
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.[/quote]
Discordo. Falando de software, o software não é um produto??
[quote=asaudate][quote=sergiotaborda][quote=marcosalex]
Acho que uma analogia melhor seria você ter de escolher comprar entre um Corsa que te atende ou um Astra. É
[/quote]
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.[/quote]
Discordo. Falando de software, o software não é um produto?? [/quote]
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.
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. 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.
[quote=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. [/quote]
Essa analogia é pessima, o Corsa é um produto e o Astra é outro produto, assim como um simples sistema de gestao de estoque e um ERP completo sao coisas diferentes. Mas qualquer um dos dois que seja entregue com baixa qualidade é sim uma coisa errada.
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.
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”…
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.
[/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.
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
