Decepção

Thread.start() Membro desde: 11/04/2009 00:58:50 Mensagens: 41 Offline

Nunca imaginei que no mercado corporativo o XGH seria tão presente igual é....alguem sente o mesmo que eu?

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4191 Offline

XGH?

Thread.start() Membro desde: 11/04/2009 00:58:50 Mensagens: 41 Offline

http://forum.imasters.com.br/topic/380577-metodologia-de-desenvolvimento-xgh/

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4191 Offline

A tá po! É só falar GoHorse! Mahuahua

Mano, é triste mas é realidade presente... E sempre vai ter.... sempre mesmo! =/

Thread.start() Membro desde: 11/04/2009 00:58:50 Mensagens: 41 Offline

É triste mesmo =/

muito presente sim amigo...

e infelizmente isso é cultura corporativa.

só que é complicado, na nossa área a gente chupa cana e assovia, com cobrança administrativa então....é triste...=/

imagina por exemplo, um desarmador de bombas, um trabalho extremamente complexo, com alto risco, sob uma extrema pressão de tempo...TI haha...

fica tranquilo que vi uma matéria que isso vai mudar com a geração Y, que ao invés de cobrar "trabalho" vai cobrar "estudo" da geração Z e etc...

pensando em tempo...uns 20~30 anos...

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

O problema nao esta no Go Horse em si, mas na necessidade de usa-lo. Sempre que um novo projeto eh comecado, todo mundo quer fazer certinho, planejar, documentar, especificar e etc...

E como nao sabem fazer isso, perdem um monte de tempo fazendo uma infinidade de coisas que nao vao servir pra nada, o tempo corre os prazos estouram e la estao eles fazendo a unica coisa que sabem. Go Horse.

Eu acho impressionante esse espanto todo com o Go Horse, se ele eh o padrao eh porque ele funciona, se ele esta em todo lugar eh porque só ele funciona, as outras coisas todas maravilhosas que aprendemos na faculdade NAO FUNCIONAM, Go Horse sim.

Entao o que temos que fazer nao eh ficar rindo disso, eh organizar ISSO, mas organizar isso comeca aprendendo a reconhecer porque Go Horse funciona e o resto nao, pegar essas praticas que funcionam e organiza-las um pouco, para que possamos chama-las de organizadas e elas ainda assim continuarem funcionando.

Debugger Membro desde: 02/03/2010 03:05:46 Mensagens: 50 Offline

A necessoidade do XGH é construida a partir da falta de preparo e da necessidade de resultado em curto período de tempo.
Ou seja , pouco investimento por parte das empresas e muita cobrança.

Para algumas empresas a qualidade é o de menos e a produção o d+.

Qualquer coisa realizamos correções e fica nesse ciclo vicioso

This message was edited 1 time. Last update was at 09/01/2012 10:37:40

Rocklee6544 wrote:A necessoidade do XGH é construida a partir da falta de preparo e da necessidade de resultado em curto período de tempo.
Ou seja , pouco investimento por parte das empresas e muita cobrança.

Para algumas empresas a qualidade é o de menos e a produção o d+.

Qualquer coisa realizamos correções e fica nesse ciclo vicioso

Falta de preparo eu concordo, talvez discorde no significado do que é estar bem preparado.

Necessidade de resultado em curto periodo de tempo eh realidade, se voce nao consegue mostrar resultado em um periodo de tempo curto voce nao serve, eh isso e pronto.

Se num projeto se perde tempo fazendo coisas que nao estao diretamente relacionadas ao desenvolvimento da aplicacao, por mais que todo mundo diga q eh o ideal e como isso seria maravilhoso, cedo ou tarde, vai chegar a hora em que o Go Horse vai salvar o projeto, se salvar.

Debugger Membro desde: 02/03/2010 03:05:46 Mensagens: 50 Offline

Cara sei do que estou falando pois trabalho em uma empresa onde 90% é trainee e adivinhas , nenhum de nós foi treinado.
De qualquer forma é bom trabalhar em um lugar assim porque vc aprende a correr atrás.

E mesmo que não seja lá essas coisas , consegue ver o que tem de bom no mercado.

Java Ninja Membro desde: 26/02/2008 15:35:14 Mensagens: 254 Offline

chupa cana e assovia

kkkkkkkkkkkk Boa!!

XGH é complicado mesmo, já vi muitas coisas bizarrassss

Nunca vi o Go Horse funcionar. Na verdade, sempre abominei programadores Go Horse na minha equipe ou projeto. Programadores assim corrigem bugs gerando outros bugs, muitas vezes piores.

Mas concordo numa coisa com o Yvga: Também nunca vi projetos com muita documentação funcionarem.

O que eu noto que funciona é:
1. Programar com código claro e organizado. É importante que seus programadores conheçam bem refatoração e padrões de projeto;
2. Projetos iterativos: Com prazos claros e curtos, preferencialmente com entregáveis a cada 2 semanas.
3. Ter testes organizados. Preferencialmente automáticos, mas ter não automáticos é melhor do que não ter teste nenhum.
4. Ter alguém que saiba organizar classes para reuso. Criar classes reusáveis é uma forma da empresa evoluir com o que conhece, e não perder tempo refazendo coisas através dos anos.

É claro, todos os projetos tem momentos de correria, onde você vai ser pressionado a deixar boas práticas de lado. Mas é seu papel, como profissional, não abrir mão de um mínimo. Aliás, você também deveria criar mecanismos para mostrar para chefia o quanto "Go Horse" custa caro.

Sabe o que é mais engraçado? Todo este papo de Go Horse é velho pra kcte!

Este mês peguei pra ler o "Mythical Man Month" do Fred Brooks, e é impressionante como todos os atributos que geram o nosso "amado problema" estão descritos lá.

* Documentação ineficiente
* O mito de que software pode ser medido em homens/hora
* O mito de que você constrói software exatamente como contrói algo material

E muitos outros. No final das contas, sabe o que eu acho que realmente gera o "Go Horse"? A falta de preparo de quem gerencia, que ao invés de se focar em pesquisar mais sobre a própria área "desenvolvimento de SOFTWARE", acabam lendo uma série de livros de gerência de engenharia civil.

kicolobo wrote:Sabe o que é mais engraçado? Todo este papo de Go Horse é velho pra kcte!

Este mês peguei pra ler o "Mythical Man Month" do Fred Brooks, e é impressionante como todos os atributos que geram o nosso "amado problema" estão descritos lá.

* Documentação ineficiente
* O mito de que software pode ser medido em homens/hora
* O mito de que você constrói software exatamente como contrói algo material

E muitos outros. No final das contas, sabe o que eu acho que realmente gera o "Go Horse"? A falta de preparo de quem gerencia, que ao invés de se focar em pesquisar mais sobre a própria área "desenvolvimento de SOFTWARE", acabam lendo uma série de livros de gerência de engenharia civil.

Boa! O detalhe é que na saudosa página do Go Horse (por algum motivo não esclarecido, ela teve que ser tirada do ar), mostrava alguns cases de obras físicas construídas utilizando o Go Horse. O mais memorável era o palco do show do Guns N Roses no Rio, uns dois anos atrás, quando o palco desabou antes mesmo do show. O mesmo acontece com software Go Horse: desaba antes mesmo de entrar em produção e, quando entra... bom, o Go Horse diz pro programador sempre manter o CV na Apinfo.

O que acontece, que também domina, é que a empresa sempre prefere reduzir os custos. E aí, entra um conjunto de coisas:

1) Gerentes de projeto péssimos (o tipo: "tá pronto? E agora?")
2) Pessoal despreparado (ou seja, coloca um monte de estagiários pra fazer trabalho de programadores sênior)
3) Departamento comercial que sempre acha que a funcionalidade pedida a mais é "tão pequena, que nem vou cobrar a mais por isso" -> resultando num escopo cada vez maior e maior. Aliás, se não me engano, o livro do Fred Brooks também fala sobre isso.
4) Como já falaram, testar não é Go Horse. Logo, testes automatizados morrem no processo.
5) Falta de cultura, como um todo, dos programadores. Sim, porque se o programador for experiente, não importa o quanto gritem com ele que ele deve entregar uma funcionalidade, ele vai entregar com testes.

Trabalhei em algumas empresas em que o modus operandi era sempre o mesmo. Moral da história: o projeto era entregue (bem meia boca), no dobro, triplo, ou até quatro (quatro!!) vezes o tempo em que foi estimado (sim, passei por um projeto que foi estimado em três meses, mas levou mais de um ano).

asaudate wrote:

kicolobo wrote:Sabe o que é mais engraçado? Todo este papo de Go Horse é velho pra kcte!

Este mês peguei pra ler o "Mythical Man Month" do Fred Brooks, e é impressionante como todos os atributos que geram o nosso "amado problema" estão descritos lá.

* Documentação ineficiente
* O mito de que software pode ser medido em homens/hora
* O mito de que você constrói software exatamente como contrói algo material

E muitos outros. No final das contas, sabe o que eu acho que realmente gera o "Go Horse"? A falta de preparo de quem gerencia, que ao invés de se focar em pesquisar mais sobre a própria área "desenvolvimento de SOFTWARE", acabam lendo uma série de livros de gerência de engenharia civil.

Boa! O detalhe é que na saudosa página do Go Horse (por algum motivo não esclarecido, ela teve que ser tirada do ar), mostrava alguns cases de obras físicas construídas utilizando o Go Horse. O mais memorável era o palco do show do Guns N Roses no Rio, uns dois anos atrás, quando o palco desabou antes mesmo do show. O mesmo acontece com software Go Horse: desaba antes mesmo de entrar em produção e, quando entra... bom, o Go Horse diz pro programador sempre manter o CV na Apinfo.

O que acontece, que também domina, é que a empresa sempre prefere reduzir os custos. E aí, entra um conjunto de coisas:

1) Gerentes de projeto péssimos (o tipo: "tá pronto? E agora?")
2) Pessoal despreparado (ou seja, coloca um monte de estagiários pra fazer trabalho de programadores sênior)
3) Departamento comercial que sempre acha que a funcionalidade pedida a mais é "tão pequena, que nem vou cobrar a mais por isso" -> resultando num escopo cada vez maior e maior. Aliás, se não me engano, o livro do Fred Brooks também fala sobre isso.
4) Como já falaram, testar não é Go Horse. Logo, testes automatizados morrem no processo.
5) Falta de cultura, como um todo, dos programadores. Sim, porque se o programador for experiente, não importa o quanto gritem com ele que ele deve entregar uma funcionalidade, ele vai entregar com testes.

Trabalhei em algumas empresas em que o modus operandi era sempre o mesmo. Moral da história: o projeto era entregue (bem meia boca), no dobro, triplo, ou até quatro (quatro!!) vezes o tempo em que foi estimado (sim, passei por um projeto que foi estimado em três meses, mas levou mais de um ano).

Sabe o que pesa demais também? A arrogância do "risco calculado".
Muitas vezes a empresa aposta em uma implementação tosca pra pegar o cliente e, posteriormente, quem sabe, lá pra 3014 dar uma arrumada na casa.

"Se algo der errado, tudo bem: nós já prevíamos este risco, vamos arrumando e tocando o barco.
Nada pode dar errado."

Já vi isto tantas vezes que da até vontade de vomitar.

Notícias, artigos e o maior fórum brasileiro sobre Java