Decepção

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

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

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 é:

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:

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:

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.

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.

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.

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

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.

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:

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

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.

asaudate:

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.

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:

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

kicolobo:

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

Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol:

asaudate:

Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol:

Você não tem noção do quão preciso você foi. Isto ocorreu na época em que eu trabalhava com engenharia de minas.

kicolobo:

asaudate:

Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol:

Você não tem noção do quão preciso você foi. Isto ocorreu na época em que eu trabalhava com engenharia de minas.

Engenharia de minas? Conta essa história!

Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?

kicolobo:

Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?

ViniGodoy:

Aliás, você também deveria criar mecanismos para mostrar para chefia o quanto “Go Horse” custa caro.

Isso pra mim, , é o que diferencia um profissional bom de um profissional excelente.

asaudate:

kicolobo:

Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?

Ou, ai que tá. Foi REALMENTE enriquecedor (sem qualquer tipo de irônia), porque no processo, as duas partes cresceram muito:

• Eu compreendi melhor as dificuldades do cliente em entender o nosso oficio
• O cliente compreendeu melhor o modo como nós trabalhamos

E, pra surpresa de todos, não houve nenhum Go Horse. Houve tentativas, mas eram frustradas por causa do diálogo. Este nem sempre era lá AQUELA maravilha, muitas vezes você precisa pisar em ovos e tal, mas no final das contas, quando rola este tipo de troca todo mundo sai ganhando.

kicolobo:

asaudate:

kicolobo:

Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?

Ou, ai que tá. Foi REALMENTE enriquecedor (sem qualquer tipo de irônia), porque no processo, as duas partes cresceram muito:

• Eu compreendi melhor as dificuldades do cliente em entender o nosso oficio
• O cliente compreendeu melhor o modo como nós trabalhamos

E, pra surpresa de todos, não houve nenhum Go Horse. Houve tentativas, mas eram frustradas por causa do diálogo. Este nem sempre era lá AQUELA maravilha, muitas vezes você precisa pisar em ovos e tal, mas no final das contas, quando rola este tipo de troca todo mundo sai ganhando.

Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?

asaudate:

Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?

Exatamente. É outra realidade que muitas vezes a gente ignora.
É muito comum a gente pensar: “XGH é coisa de gerente”. Nem sempre. Muitas vezes é decorrente do próprio cliente, que na ansiedade de ver o resultado rápido te força a isto.

Quer ver um exemplo? É muito comum você virar pro cliente e dizer que se for por este caminho vai dar merda, e este achar que o fornecedor está fazendo drama, que o problema não é tão grave assim. Não é raro você ouvir coisas do tipo “tu tá dourando a pílula”.

No final, é aquela questão: você tem de ter jogo de cintura, mostrar que o cara tá errado e ir em frente.

kicolobo:

asaudate:

Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?

Exatamente. É outra realidade que muitas vezes a gente ignora.
É muito comum a gente pensar: “XGH é coisa de gerente”. Nem sempre. Muitas vezes é decorrente do próprio cliente, que na ansiedade de ver o resultado rápido te força a isto.

Quer ver um exemplo? É muito comum você virar pro cliente e dizer que se for por este caminho vai dar merda, e este achar que o fornecedor está fazendo drama, que o problema não é tão grave assim. Não é raro você ouvir coisas do tipo “tu tá dourando a pílula”.

No final, é aquela questão: você tem de ter jogo de cintura, mostrar que o cara tá errado e ir em frente.

Quanto à questão do resultado rápido, uma metodologia ágil muitas vezes resolve o problema, não? Nesse caso, vocês usaram alguma metodologia ágil?

hehehe o pior são empresas que se dizem “não adeptas ao XHG”, dizendo que são diferentes e utilizam como argumento para te pagar pouco

oh yeah, smells like (put a company here)

tirando um pouco das piadas, qual a sugestão para acabar com o GoHorse? acabar com as fábricas de javeiros fast-food? exigir literatura básica?

Não devemos simplesmente criticar, mas achar maneiras de melhorar as coisas.

Acho esse tema extremamente complexo, pois muitas vezes há falta um “norte” pra dizer o que é certo ou errado. Você vai ver gente que reclama de XGH sendo que algo de verdade nem chega a ser XGH ou então, só pelo fato de ter uma idéia contrário já é taxado de XGH.

Agora. Temos que reconhecer que “Go Horse” é um problema nosso.

1. São os desenvolvedores que acabam optando por essa técnica. Você, como membro de um time, não deve fazer isso, e deve orientar seus colegas e não irem pro “go horse” também. Deve mostrar a eles os problemas que as abordagens deles estão gerando, e que eles estão sendo pouco produtivos assim.

2. O cliente não tem qualquer obrigação de entender o que você faz. Ou vocês fazem curso de engenharia aeronáutica antes de pegar um vôo? Falar claramente pra o cliente e orienta-lo é nosso papel. E, infelizmente, não sabemos falar a lingua da clientela.

3. O chefe é um cliente. Um cliente interno, mas um cliente mesmo assim. Então, o caso 2 se aplica a ele também. Ele deveria conhecer mais sobre seu trabalho, mas o papel dele é gerencial, não técnico. Você deve aprender o que o seu chefe valoriza e por que ele faz as coisas daquela forma. Deve aprender a argumentar com o vocabulário dele, fornecendo dados que são relevantes para ele. Não adianta falar em UML, design patterns, etc. Você tem que falar em custo, tempo, metas de qualidade. Deve se preocupar em criar indicadores relevantes. Mostrar a economia (de pessoal, de custo, de tempo, mas não de código) que reuso e boas práticas trazem. Só assim se convence chefias.

4. Você deve aprender a dizer não para seu chefe. É difícil, eu sei. Mas muitas vezes, o chefe espera que o bom profissional saiba quando pisar no freio, e dizer não abre palco para negociar prazos e meios factíveis de fazer o trabalho.

5. Nem sempre você irá concordar com a empresa que trabalha. Ou seu chefe pode mesmo ser um boçal. Pode ser que ao entender seu chefe, você descubra que a empresa que você trabalha é um lixo, ou que ele é um cara intragável. Nessas horas: troque de empresa.

asaudate:

Quanto à questão do resultado rápido, uma metodologia ágil muitas vezes resolve o problema, não? Nesse caso, vocês usaram alguma metodologia ágil?

Neste caso, acabou sendo uma metodologia ágil “acidental”, porque como o cliente estava presente o tempo inteiro (eu estava lá dentro), e havia um consenso a respeito do que devia ser produzido, tinhamos alguns atributos ágeis:

• Presença forte do product owner
• Iterações muito curtas

asaudate:

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…

Sim, funciona, e a grande maioria dos profissionais da nossa area so consegue fazer funcionar usando Go Horse.

Com funcionar eu quero dizer, conseguir chegar ao ponto de entregar e manter o sistema vivo. E isso muitas vezes acontece, mesmo em ambientes sem um minimo de organizacao.

Quando eu disse que só o Go Horse funciona para a maioria eu estava tentando enfatizar que o correto nao eh o que a maioria ve como correto. Que normalmente eh documentacao detalhada, bduf, congelamento de fases dos projetos e etc…

Quem nunca teve um gerente que em um momento ou outro disse: “A partir de hoje vamos especificar e documentar tudo”. Os que de fato fizeram isso devem ter afundado o projeto, os que nao fizeram continuaram com Go Horse e talvez tenham conseguido entregar aquela parafernalha.

Eu disse isso porque eu ja estou cansado de ver, ouvir e ler gente reclamando de codigo ruim, codigo isso e aquilo, mas essas mesmas pessoas nao sao capazes elas mesmas de escrever algo melhor, nao sao elas mesmas capazes de arrumar o que esta errado.

Ai se irritam quando tem que dar manutencao em codigo de outro e saem aos quatro ventos reclamando, mas quando finalmente descobrem o que precisa ser feito, poem mais um “if” la, viram as costas e vao embora.

Entao, o que eu quero dizer é: se voce nao eh capaz de lidar com código ruim e melhora-lo, voce nao pode reclamar, porque no fim das contas faz a mesma coisa, e se pegar codigo bom pela frente, vai acabar estragando.

Concluindo, Go Horse nao funciona, mas entrega. O contrario, nao funciona e nao entrega.

Só para concluir, nao sou a favor do Go Horse, muito pelo contrario. Mas infelizmente eh uma realidade, e o que eh pior, o antidoto pouquissima gente tem. A maioria dos que pensam ter nao tem.

YvGa:

asaudate:

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…

Sim, funciona, e a grande maioria dos profissionais da nossa area so consegue fazer funcionar usando Go Horse.

Com funcionar eu quero dizer, conseguir chegar ao ponto de entregar e manter o sistema vivo. E isso muitas vezes acontece, mesmo em ambientes sem um minimo de organizacao.

Quando eu disse que só o Go Horse funciona para a maioria eu estava tentando enfatizar que o correto nao eh o que a maioria ve como correto. Que normalmente eh documentacao detalhada, bduf, congelamento de fases dos projetos e etc…

Quem nunca teve um gerente que em um momento ou outro disse: “A partir de hoje vamos especificar e documentar tudo”. Os que de fato fizeram isso devem ter afundado o projeto, os que nao fizeram continuaram com Go Horse e talvez tenham conseguido entregar aquela parafernalha.

Eu disse isso porque eu ja estou cansado de ver, ouvir e ler gente reclamando de codigo ruim, codigo isso e aquilo, mas essas mesmas pessoas nao sao capazes elas mesmas de escrever algo melhor, nao sao elas mesmas capazes de arrumar o que esta errado.

Ai se irritam quando tem que dar manutencao em codigo de outro e saem aos quatro ventos reclamando, mas quando finalmente descobrem o que precisa ser feito, poem mais um “if” la, viram as costas e vao embora.

Entao, o que eu quero dizer é: se voce nao eh capaz de lidar com código ruim e melhora-lo, voce nao pode reclamar, porque no fim das contas faz a mesma coisa, e se pegar codigo bom pela frente, vai acabar estragando.

Concluindo, Go Horse nao funciona, mas entrega. O contrario, nao funciona e nao entrega.

Mas aí, você só está vendo como se fosse uma moeda e só tivesse dois lados. E metodologias ágeis, já viu? Não tem documentação, mas também não tem Go Horse. Tem software funcionando =)

Você já viu códigos em empresas como Caelum? Thoughtworks? Posso te garantir que eles não dão a mínima pra documentação, mas o software sai de lá redondinho.

Quanto a dar manutenção no código, é uma ótima oportunidade para exercitar o princípio do escoteiro (esboçado pelo Uncle Bob): sempre, sempre, sempre, deixe o lugar um pouco melhor do que quando você chegou. Mesmo que seja pra deixar uma variável com nome mais legível, é importante sempre refatorar de modo a melhorar um pouco o código.

E, insisto… não adianta “entregar” e o software não durar um ano. Software tem vida útil e, quanto mais XGH, menor a vida.

É por isso que vivo afirmando que “fazer funcionar” é diferente de “implementar um software corretamente”.

Você pode ter 4 rodas sobre um eixo, e um jegue puxando na frente. E não é porque a carroça anda, que você tem um carro.
E, cuidado, no “Go Horse”, quem é o jegue é você.

asaudate:

Mas aí, você só está vendo como se fosse uma moeda e só tivesse dois lados. E metodologias ágeis, já viu? Não tem documentação, mas também não tem Go Horse. Tem software funcionando =)

Você já viu códigos em empresas como Caelum? Thoughtworks? Posso te garantir que eles não dão a mínima pra documentação, mas o software sai de lá redondinho.

Quanto a dar manutenção no código, é uma ótima oportunidade para exercitar o princípio do escoteiro (esboçado pelo Uncle Bob): sempre, sempre, sempre, deixe o lugar um pouco melhor do que quando você chegou. Mesmo que seja pra deixar uma variável com nome mais legível, é importante sempre refatorar de modo a melhorar um pouco o código.

E, insisto… não adianta “entregar” e o software não durar um ano. Software tem vida útil e, quanto mais XGH, menor a vida.

Eu entendo o que voce diz e concordo, eu sei q eh possivel fazer bem feito sem precisar documentar tudo, nem sair fazendo a primeira coisa que vem a cabeca.

Talvez eu nao esteja sabendo me explicar, mas eu nao estou defendendo o Go Horse sob nenhuma hipotese, o que me preocupa sao os que ao lerem sobre o Go Horse acharem que a outra ponta eh a correta.

Por isso eu digo: Go Horse eh ruim? Sim, eh ruim. Mas BDUF eh pior ainda. A minha critica eh aos que criticam o codigo dos outros incessantemente, mas nao conseguem criar codigo decente eles mesmos.

Eu também já vi o malefício de “vamos documentar tudo, burocratizar tudo”. Isso geralmente é associado a definir hierarquias entre analistas e programadores, e tornar o ciclo waterfall, e encher a sala de diagramas inúteis.

Entre um ambiente assim e um go-horse, não sei… mas acho que também ficaria no go horse. Pelo menos no go horse todo mundo sabe que está fazendo errado, e você pode tentar mostrar para a chefia que você não tem processo e implementar mudanças…

YvGa:

Eu entendo o que voce diz e concordo, eu sei q eh possivel fazer bem feito sem precisar documentar tudo, nem sair fazendo a primeira coisa que vem a cabeca.

Talvez eu nao esteja sabendo me explicar, mas eu nao estou defendendo o Go Horse sob nenhuma hipotese, o que me preocupa sao os que ao lerem sobre o Go Horse acharem que a outra ponta eh a correta.

Por isso eu digo: Go Horse eh ruim? Sim, eh ruim. Mas BDUF eh pior ainda. A minha critica eh aos que criticam o codigo dos outros incessantemente, mas nao conseguem criar codigo decente eles mesmos.

Ah, sim. Mas acredito que isso é uma questão de maturidade do desenvolvedor. Como o ViniGodoy já disse (e eu reitero), nós mesmos somos culpados pela aplicação do XGH.

Bom aqui não tem equipe de teste e o sistemas são baseados em aplicações legadas.(defasadas)
Onde nós mesmos fazemos a especificação baseada em códigos antigos e muitas vezes incompletos.

Onde se da para ter uma noção quase sempre superficial da regra de negócio sobre um domínio que não sabemos ao certo.

Resumindo é tudo na raça,na cara,na coragem e na persistência.(A rotatividade aqui é ± a mesma que de um call center , em seis meses mais da metade da empresa é nova)

posso usar essa sua citação para um Post no meu Blog ???

Abs []

adriano_si:

kicolobo:

• 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
  

posso usar essa sua citação para um Post no meu Blog ???

Abs []

UAI! Pondo meu nome, é claro!

asaudate:

Ah, sim. Mas acredito que isso é uma questão de maturidade do desenvolvedor. Como o ViniGodoy já disse (e eu reitero), nós mesmos somos culpados pela aplicação do XGH.

Isso q eu estou tentando dizer, nao adianta esperar que o gerente venha com tudo definido, bonitinho, como vai ter que ser daqui pra frente, e a partir dali o codigo vai ser lindo, e os problemas acabaram.

Codigo ruim eh culpa nossa, so nossa e de mais ninguem. Se o gerente ta dando murro na mesa querendo algo pronto, ele tem culpa por ter deixado as coisas chegarem ao ponto em que ele (sem ter competencia para fazer outra coisa) tem que ficar esbravejando com todo mundo. Mas tambem o desenvolvedor tem culpa por nao ter feito um codigo decente, que seja facil de dar manutencao, que aceite mudancas facilmente e etc…

Eu acho muito facil o pessoal correr pro GUJ, ou pra sala do cafe com os colegas ou tomar uma cerveja e ficar falando que a empresa eh uma M, que nada funciona, que eh tudo uma zona, que eh Go Horse e nao sei mais o que. Se eh assim a maior parte da culpa eh nossa. Afinal quem eh o desenvolvedor da aplicacao senao eu?

Ah, mas eh legado, quem fez ja saiu, o gerente so cobra, etc… Olha, nao eh querer desanimar quem esta comecando, mas como desenvolvedor voces vao passar 90% da vida profissional de voces lidando com codigo escrito por outros. Entao ta na hora de parar de chorar e comecar a aprender a lidar com sistemas legados.

Como lidar com o legado? Esse eh um problema maior ainda. A maioria dos programadores, principalmente aqueles que vivem reclamando, nao se dao ao trabalho de aprender a fazer, melhorar, correr atras de escrever codigo limpo. Sao raros os profissionais que eu encontro que tem um minimo de nocao de como programar para interface, de atribuicao de responsabilidades, de injecao de dependencia, desacoplamento etc…

Quando muito leem algo aqui e ali num blog sobre refactoring e olhe la. Isso nao basta, tem que ler e reler e ler de novo livros como Clean Code, Refactoring, TDD, DDD, Pragmatic Programmer, Effective Java, Lean, entre muitos outros. Ao inves disso perdem tempo (quando perdem) lendo sobre um framework novo, um JSF, Hibernate, sei la mais o que…

Nao que nao possam, ou nao devam aprender essas coisas, mas elas sao menos importantes que a base teorica da Orientacao a Objetos, sao menos importantes do que os conceitos Lean.

eu creio que nunca XGH nunca morrerá…
pois paras as empresas qdo um projeto eh entregue no prazo o lucro eh maior…e geralmente os prazos sao curtos…
assim XGH tende ao infinito…

Acho que vc não deve sí colocar como culpado de todos os códigos ruins.
A maioria dos caras que eu conheço procuram fazer da forma certa.

Mas ninguém alí ou quase ninguém tem mais de um ano de projeto.(A maioria digasse de passagem é marinheiro de primeira viagem no mundo do desenvolvimento java)
Nós melhoramos sim a medida do possível, porque não tem como chegar para o cliente que aprovou meses e meses de trabalho e dizer , ei!
Vamos otimizar ou vamos corrigir tudo que foi feito nas coxas, ok? ( O cliente questionaria o porquê de tantas mudanças).

A vários motivos para quem reclama fazer direito ou pelo menos é o que eu penso.
E na minha opinião talvez seja a melhor forma de aprender a importância das fases de engenharia de software e da uml, mais que isso compreender
quais os impactos da não utilização de tais técnicas.
Nesse ponto sentimos na péle…
E isso é bom, melhor do qualquer aula teorica massante de engenharia de software.
Aprendemos o que não fazer e quais padrões não seguir.

Creio que o conhecimento de dominio do negócio seja algo que deveria ser disseminado de cima para baixo.(não que o inverso não possa acontecer, só não é normal ou não deveria ser).
Só porque uma má prática é comum no mercado não quer dizer que seja correta.

O ruim é essa mania de atribuir funções que não são condizentos com o nome do cargo e nem com o salario.
E é por essas e outras que as coisas não são feitas como deveriam ser, delegar funções que não são do escopo de um determinado cargo == 2 X retrabalho
Infelizmente esse é um problema muito comum no mercado.

Se nós fossemos os responsáveis por tudo não existiria essa divisão em uma empresa: estratégico , tático e operacional.
Um exemplo prático do impacto de um erro na parte estratégica e tática: Temos um projeto
prestes a entregar e só agora fomos informado que o software poderá funcionar em rede).

Por esses motivos citados acima que 70% do tempo de projeto é gasto em correções.(Retrabalho)

karlinhos987:

eu creio que nunca XGH nunca morrerá…
pois paras as empresas qdo um projeto eh entregue no prazo o lucro eh maior…e geralmente os prazos sao curtos…
assim XGH tende ao infinito…

E desde quando Go Horse entrega no prazo? So com muita sorte.

Se voce quer ser rapido mesmo voce tem que eliminar tudo que é perda de tempo num projeto, e perder duas horas só pra entender o que um codigo faz é perda de tempo das grandes.

É como eu digo, muita gente critica Go Horse, mas nao conhece o antidoto.

Rocklee6544:

Acho que vc não deve sí colocar como culpado de todos os códigos ruins.
A maioria dos caras que eu conheço procuram fazer da forma certa.

Isso so reforça o que disse antes. Ok, quem contrata somente pessoal inexperiente tem culpa tambem. Programador inexperiente, sistema problematico. E voce nao tem, nao pode, nem nunca deve chegar pro cliente e dizer que algo vai demorar muito mais porque voce tem que arrumar o codigo. As vezes voce precisa de um pouco mais de tempo para arrumar alguma coisa, mas isso tem que estar dentro do aceitavel. Se algo for levar dois dias e voce chegar e dizer, olhe se eu levar tres dias eu consigo melhorar este ponto e depois tal e tal funcionalidade vai ser mais facil de implementar. Isso ele aceita numa boa.

Se voce chegar pra ele e dizer que vai levar 2 semanas o que deveria levar dois dias, ele seu chefe, o chefe do seu chefe, a tia do cafezinho e eu vamos achar que ha uma grande possibilidade de voce nao saber o que esta fazendo.

Contra este tipo de pensamento que estou lutando ferrenhamente nesse topico, inclusive escrevendo posts no minimo estranhos, aparentando defender o Go Horse. Mas o fato eh que Go Horse eh ruim sim, pessimo. Mas as fases da Engenharia de Software “tradicional” o uso de uml como especificacao, a separacao entre analise e programacao tem o efeito ainda piores que o Go Horse. Use Go Horse, mas nao use Waterfall.

Waterfall vai terminar em Go Horse com certeza, ou em fracasso total.

Esse eh o grande ponto, nós somos os desenvolvedores, nós somos OBRIGADOS a dominar as tecnicas de desenvolvimento, nós temos que saber o que é melhor ou pior para um projeto no nivel tecnico. O conhecimento do dominio nao vem de cima, vem do cliente. A parte tecnica é responsabilidade dos desenvolvedores e se a coisa nao funciona a culpa eh deles.

Se uma pratica eh comum no mercado é porque nao existe alternativa a ela que seja de conhecimento de todos. De novo eu digo, a alternativa para Go Horse nao eh dominada por 90% dos desenvolvedores. A alternativa tida como melhor ao Go Horse é ainda pior que ele, que eh o uso de praticas waterfall.

Nao entendi muito bem essa colocacao, ou espero nao ter entendido. Seria algo como a diferenca entre o engenheiro e o pedreiro?

Mais um erro da equipe tecnica atribuido a outros. Voce tem que validar e inspecionar o seu trabalho com frequencia, sempre que nao o faz esta sujeito a surpresas.

As mudancas em um projeto sao frequentes, enquanto nao aprender a preparar o codigo pra elas e aprender a fazer com que elas aparecam o mais cedo possivel voce vai perder seu tempo com correcoes.

Na verdade, o waterfall nunca foi pregado como prática de desenvolvimento pela Engenharia de Software.

O waterfall surgiu como uma tentativa “Go Horse” de burocratizar o ambiente de desenvolvimento. Muitas empresas começaram a adota-lo por tentarem se sentir seguras, mas não efetivamente por se basearem em algum tipo de engenharia de software.

O próprio RUP, que é tido como o mais waterfall dos modelos, e que tem divisão clara entre análise e programação, é extremamente iterativo e prega ciclos de no máximo 2 meses. Outra coisa que o RUP deixa claro, é que não existe (e nem deve existir) hierarquia de cargos entre analistas e programadores, coisa que muitas empresas “waterfall” adoram implementar.

Acho que o mais importante que o Yvga tem colocado é que, realmente, Go Horse não é solução, mas waterfall é pior que Go Horse. Waterfall, na minha opinião, é o Go Horse burocratizado e idiotizado. E, claro, é nossa obrigação como desenvolvedores conhecer processos e conhecer software. Ser iniciante não é explica alguns erros, mas não justifica. E, se você é iniciante e está só com iniciantes num projeto, é seu papel cobrar da empresa a presença de um profissional mais experiente, ou deixar seus gerentes bem alerta dos riscos de não ter um coordenador técnico com mais anos de cancha.

Não, não seria a diferença do engenheiro e do pedreiro.
Apenas quis dizer que o correto seria tirar proveito das habilidade de cada pessoa da melhor forma possível.
Programador não é designer e muito menos DBA e cobrar um como tal é um erro no mínimo grosseiro.
Creio que quem geri pessoas deveria saber quais são as habilidades de cada pessoa gerida, quais são os pontos
fracos e forte. Gestão é mais que dizer apenas faça, é saber usar bem os recursos que tem em mãos.

Não que as coisas não possam mudar e as pessoa não possam evoluir, só digo que isso deve ser devidamente acompanhado.

Uma coisa comum de acontecer é isso erros de gestão sendo colocados como erros de operação.
Mas talvez não esteja dizendo nenhuma novidade, afinal o que penso mesmo é que a maioria sabe muito bem o que faz
e o que é pior se as coisas são feitas dessa forma, no mínimo é porque é conveniente .(sacrifício de muitos em virtude de 1/2 duzia)

falta maturidade para sabermos fazer a “coisa” de forma correta =)

se ainda estão encontrando novas metodologias, processos, estratégias para desenvolvimento de software, é por que ainda não sabemos qual o melhor jeito…

Gostaria de fazer uma correção aqui, as metodologias ágeis nunca falaram para abandonar documentações, o proposito do ágil é usar aquilo que realmente traga valor, então se um documento de requisitos trás valor pro teu desenvolvimento, você deve usa-lo!

por favor galera, é por isso que tem muitas empresas com medo do ágil, por causa dessa confusão de que ágil é feito de qualquer jeito, sem controle ou documentação, NÃO É ISSO!!

quando ao go horse, concordo com os demais que apontam os culpados como nós mesmo, o go horse só existe porque temos medo de bater de frente e falar que não vamos colocar a própria reputação em jogo pq o prazo foi mal definido ou os riscos não foram mapeados.

na minha opinião, quando a pessoa responsável mensurar a quantidade de retrabalho, bugs e desperdícios que ocorre quando um sistema é construído de qualquer jeito, ela vai para de pressionar a equipe de desenvolvimento pra produzir que nem máquinas e vai se preocupar mais com a qualificação desse pessoal partindo para investimentos em estudos em relação a fremawork, código limpo e aprofundamento na própria linguagem.

o que falta nesses projetos são os famosos números, só com números podemos provar que go horse trás muito mais custo que um desenvolvimento planejado e bem feito!

( faltava uma mulher aqui pra dar pitaco )

MaYaRa_SaN:

Gostaria de fazer uma correção aqui, as metodologias ágeis nunca falaram para abandonar documentações, o proposito do ágil é usar aquilo que realmente traga valor, então se um documento de requisitos trás valor pro teu desenvolvimento, você deve usa-lo!

por favor galera, é por isso que tem muitas empresas com medo do ágil, por causa dessa confusão de que ágil é feito de qualquer jeito, sem controle ou documentação, NÃO É ISSO!!

quando ao go horse, concordo com os demais que apontam os culpados como nós mesmo, o go horse só existe porque temos medo de bater de frente e falar que não vamos colocar a própria reputação em jogo pq o prazo foi mal definido ou os riscos não foram mapeados.

na minha opinião, quando a pessoa responsável mensurar a quantidade de retrabalho, bugs e desperdícios que ocorre quando um sistema é construído de qualquer jeito, ela vai para de pressionar a equipe de desenvolvimento pra produzir que nem máquinas e vai se preocupar mais com a qualificação desse pessoal partindo para investimentos em estudos em relação a fremawork, código limpo e aprofundamento na própria linguagem.

o que falta nesses projetos são os famosos números, só com números podemos provar que go horse trás muito mais custo que um desenvolvimento planejado e bem feito!

( faltava uma mulher aqui pra dar pitaco )

Mayara, concordo plenamente com você na questão da documentação. Porém, acredito que em lugares que já têm cultura Go Horse, vale mais a documentação do que o feito. Sendo a proposta do agile justamente o contrário, logo, vem o medo da mudança. Aliás, vale lembrar que até mudanças de cultura custam bastante dinheiro.

[]'s

MaYaRa_SaN:

Gostaria de fazer uma correção aqui, as metodologias ágeis nunca falaram para abandonar documentações, o proposito do ágil é usar aquilo que realmente traga valor, então se um documento de requisitos trás valor pro teu desenvolvimento, você deve usa-lo!

por favor galera, é por isso que tem muitas empresas com medo do ágil, por causa dessa confusão de que ágil é feito de qualquer jeito, sem controle ou documentação, NÃO É ISSO!!

quando ao go horse, concordo com os demais que apontam os culpados como nós mesmo, o go horse só existe porque temos medo de bater de frente e falar que não vamos colocar a própria reputação em jogo pq o prazo foi mal definido ou os riscos não foram mapeados.

na minha opinião, quando a pessoa responsável mensurar a quantidade de retrabalho, bugs e desperdícios que ocorre quando um sistema é construído de qualquer jeito, ela vai para de pressionar a equipe de desenvolvimento pra produzir que nem máquinas e vai se preocupar mais com a qualificação desse pessoal partindo para investimentos em estudos em relação a fremawork, código limpo e aprofundamento na própria linguagem.

o que falta nesses projetos são os famosos números, só com números podemos provar que go horse trás muito mais custo que um desenvolvimento planejado e bem feito!

( faltava uma mulher aqui pra dar pitaco )

Concordo contigo em tudo nesse post. E, sim tem muita gente que confunde nao perder tempo com documentacao desnecessaria com nao fazer documentacao nenhuma. Tem gente que confunde deixar o codigo simples com fazer a primeira coisa que vem a cabeca. Que confunde implementar e inspecionar com tentativa e erro.

Documentacao desnecessaria eh perda de tempo, mas ter que reaprender alguma coisa toda vez que precisa mexer nela tambem eh.

O que nos temos eh que provar que tanto Go Horse como Waterfall e sao barreiras que se poem entre a empresa e um lucro maior.

Temos que mostrar que um projeto bem planejado nao significa ficar tres meses fazendo reuniao e tentando definir tudo de antemao. Que bem feito eh bem implementado e nao superdocumentado.

Porque assume que números estão faltando e não que eles sugerem o contrário, que tratar programadores como recursos substituíveis, pelo menos no curto prazo, é mais vantajoso?