posso usar essa sua citação para um Post no meu Blog ???
Abs []
[quote=adriano_si][quote=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
[/quote]
posso usar essa sua citação para um Post no meu Blog ???
Abs [][/quote]
UAI! Pondo meu nome, é claro! 
[quote=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.[/quote]
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)
[quote=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…
[/quote]
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.
[quote=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.
[/quote]
De boas intencoes o inferno esta cheio, procurar fazer de forma certa é diferente de fazer de forma certa. Ninguem, ou quase, escreve Pog quando ja tem outra solucao em mente, normalmente o faz porque nao consegue pensar em algo melhor (seu repertorio de solucoes é pequeno), e entao atribui ao tempo curto o codigo ruim. Se tivesse mais tempo pensa que faria melhor, mas provavelmente nao faria porque nao sabe como.
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 
)
[quote=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 )
[/quote]
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
[quote=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 )
[/quote]
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?