Nunca imaginei que no mercado corporativo o XGH seria tão presente igual é…alguem sente o mesmo que eu?
XGH?
A tá po! É só falar GoHorse! Mahuahua
Mano, é triste mas é realidade presente… E sempre vai ter… sempre mesmo! =/
É 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…
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.
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
[quote=Rocklee6544]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[/quote]
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.
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.
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 é:
- Programar com código claro e organizado. É importante que seus programadores conheçam bem refatoração e padrões de projeto;
- Projetos iterativos: Com prazos claros e curtos, preferencialmente com entregáveis a cada 2 semanas.
- Ter testes organizados. Preferencialmente automáticos, mas ter não automáticos é melhor do que não ter teste nenhum.
- 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.
[quote=kicolobo]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.[/quote]
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:
- Gerentes de projeto péssimos (o tipo: “tá pronto? E agora?”)
- Pessoal despreparado (ou seja, coloca um monte de estagiários pra fazer trabalho de programadores sênior)
- 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.
- Como já falaram, testar não é Go Horse. Logo, testes automatizados morrem no processo.
- 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).
[quote=asaudate][quote=kicolobo]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.[/quote]
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:
- Gerentes de projeto péssimos (o tipo: “tá pronto? E agora?”)
- Pessoal despreparado (ou seja, coloca um monte de estagiários pra fazer trabalho de programadores sênior)
- 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.
- Como já falaram, testar não é Go Horse. Logo, testes automatizados morrem no processo.
- 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).
[/quote]
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.
[quote=YvGa]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.[/quote]
Antes de mais nada: Go Horse NÃO funciona. Essa é a maior ilusão que pode haver. Dá impressão que funciona porque, no começo, as funcionalidades são, sim, entregues mais rapidamente. O problema é que o software tem um ciclo de vida muito, muito maior do que a fase de desenvolvimento. Quando outros começam a desenvolver funcionalidades em cima de uma base “quebrada”, todo o software começa a ruir. Mas tem sempre um gerente de projeto, ou gerente comercial, ou gerente não sei das quantas, que é um especialista na arte do tapinha nas costas. Quando o software começa a ir pro buraco, ele já fez amizade com o cliente e aí, é só dar tapinha nas costas que está tudo resolvido. Se está indo pro buraco, a culpa é dos programadores que são incompetentes, não do gerente, já que, no começo, estava indo tão bem…
é possivel existir um projeto complexo que tenha 0 de POG ?
e use recursos ajax,javascript,facilidade de interação, integrações com outros sistemas, “escopo aberto”… hehe peguei pesado
acho que até tem como, mais tem que ter uma excelente arquitetura…
essa arquitetura não pode ser estatica, tem que estar sempre se adaptando,
se a empresa inteira sabe trabalhar, flui bem…se não o XGH entra no campo :twisted:.
[quote=kicolobo]
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.[/quote]
Nossa, eu também!!! Já ví isso inúúúúúmeras vezes! E, invariavelmente, é algo só pra “conseguir pegar a conta”. O problema (e que, inexplicavelmente, as empresas fazem vista grossa) é que nunca funciona! Sempre se aposta no tal do risco calculado, pra conseguir pegar uma conta ou algo assim, só que quando o cliente vê que o barco está afundando, nunca mais quer fazer negócio com a empresa.
O que, aliás, pelo menos serve de consolo: quanto mais empresas afundarem por causa desse tipo de problema, mais as boas sobrevivem. Ou não :lol:
[quote=douglaskd]é possivel existir um projeto complexo que tenha 0 de POG ?
e use recursos ajax,javascript,facilidade de interação, integrações com outros sistemas, “escopo aberto”… hehe peguei pesado
acho que até tem como, mais tem que ter uma excelente arquitetura…
essa arquitetura não pode ser estatica, tem que estar sempre se adaptando,
se a empresa inteira sabe trabalhar, flui bem…se não o XGH entra no campo :twisted:.[/quote]
Com escopo aberto, não. Ou, pelo menos, com um escopo em que o cliente pague pelas modificações. Acho que foi o próprio kico já falou sobre isso no blog dele: não existe modificação sem pagar a mais por isso. Deve-se fazer com que respeitem nosso trabalho.
Quanto à arquitetura adaptável, a Rebecca Parsons, CIO da Thoughtworks, falou sobre isso no QCon e na InfoQ : http://www.infoq.com/br/articles/entrevista-rebecca-parsons-p1 . É óbvio que uma arquitetura tem que ser adaptável, mas isso não leva a POG’s. Só o que leva a POG’s é Go Horse ou más práticas. Lembrando que existe uma teoria chamada princípio da janela quebrada: se o prefeito de uma cidade perdoar um ou outro vandalismo em uma janela, logo, todas as janelas da cidade estarão quebradas. Mas se cada janela for mantida “nos conformes”, nenhuma janela vai se quebrar. A mesma coisa acontece com software (o que, aliás, até o Go Horse fala): se surgir uma POG, outra vai ter que surgir no lugar daquela. E a bola de neve vai aumentando até que o sistema seja todo feito de POG’s e quase impossível de ser mantido. Então, ele morre.
[quote=asaudate][quote=kicolobo]
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.[/quote]
Nossa, eu também!!! Já ví isso inúúúúúmeras vezes! E, invariavelmente, é algo só pra “conseguir pegar a conta”. O problema (e que, inexplicavelmente, as empresas fazem vista grossa) é que nunca funciona! Sempre se aposta no tal do risco calculado, pra conseguir pegar uma conta ou algo assim, só que quando o cliente vê que o barco está afundando, nunca mais quer fazer negócio com a empresa.
O que, aliás, pelo menos serve de consolo: quanto mais empresas afundarem por causa desse tipo de problema, mais as boas sobrevivem. Ou não :lol: [/quote]
O grande problema é que desenvolvimento de software é visto como manufatura convencional quando não é. Acredito que dai surjam todos os problemas.
- Nossa produtividade não é constante (tem dias em que você produz mais, noutros, menos)
- O que produzimos não é tangível, e portanto cria a impressão de ser “fácilmente modificável”
- O cliente não entende os dois fatos anteriores
- Quem gerencia e deveria instruir o cliente também não
E as quatro dificuldades essenciais do software também são normalmente ignoradas:
- Complexidade
- Conformidade (você precisa estar de acordo com outras interfaces e com seu requisito)
- Invisibilidade (software é difícil de visualizar por ser intangível)
- Mutabilidade (software, ao contrário de prédios, muda o tempo todo, o que justifica a necessidade de uma base sólida)
Ai entram as sabedorias “lugar comum”. Já trabalhei em uma empresa que escutei o seguinte de um dos clientes internos: “já gerenciei N construções de IMENSA escala. Você tá me dizendo que gerenciar este projeto de software não é a mesma coisa?”