Arquivo Discussoes de Programacao e Tecnologia 
Olá,
Hoje em dia, com tantas metodologias e processos de desenvolvimento temos muitas opções para desenvolver software.
Mas mesmo assim, muitos métodos acabam sendo ineficientes e nós, desenvolvedores, acabamos tendo muitos problemas no dia-a-dia.
Se você pudesse mudar alguma coisa no processo de desenvolvimento de software que atualmente é utilizado na sua empresa, o que você mudaria?
Incluiria documentação de tudo o que for desenvolvido…(pois é minha gente…a unica documentação aqui é o codigo fonte, critica isso aqui é joga merda no ventilador…)
++
O que eu fiz foi começar a documentar eu mesmo. Escrevo/altero alguma coisa, vou lá e comento/documento o que fiz/alterei… com o tempo, alguns outros desenvolvedores começaram a fazer isso também.
Agora fiquei curioso: por que vocês querem mais documentação exatamente? TDD+Pair Programming não seriam o suficiente pra ajudar no caso de vocês?
Na empresa onde trabalho, eu digo que eu mudaria absolutamente tudo! Tudo, tudo, tudo e tudo!
Possivelmente… mas o caso é o “de sempre”: sistema feito às pressas, com uma pessoa semi-responsável por um módulo inteiro, sem nenhum teste unitário/documentação/whatever e testes feitos nas coxas. Entregue, os desenvolvedores pegam outro sistema - a muito custo está sendo implementada a metodologia SCRUM no novo desenvolvimento.
O problema é que os bugs começam a aparecer, e os desenvolvedores novos na empresa que vão resolver eles - assim como implementar novas funcionalidades. TDD não é uma opção num sistema pronto… e Pair Programming não é possível pois quem fez aquele módulo já está envolvido em outro e muito provavelmente já esqueceu metade. Resolver bugs é um problema dos menores; Tente entretanto implementar funcionalidades não planejadas em um sistema com uma arquitetura mal-definida, cheio de POG (inner classes a mais de metro, encadeamento de if/else, métodos com 300-400 linhas… já cheguei a ver 5 switchs encadeados), e não documentado… :roll:
Possivelmente… mas o caso é o “de sempre”: sistema feito às pressas, com uma pessoa semi-responsável por um módulo inteiro, sem nenhum teste unitário/documentação/whatever e testes feitos nas coxas. Entregue, os desenvolvedores pegam outro sistema - a muito custo está sendo implementada a metodologia SCRUM no novo desenvolvimento.
O problema é que os bugs começam a aparecer, e os desenvolvedores novos na empresa que vão resolver eles - assim como implementar novas funcionalidades. TDD não é uma opção num sistema pronto… e Pair Programming não é possível pois quem fez aquele módulo já está envolvido em outro e muito provavelmente já esqueceu metade. Resolver bugs é um problema dos menores; Tente entretanto implementar funcionalidades não planejadas em um sistema com uma arquitetura mal-definida, cheio de POG (inner classes a mais de metro, encadeamento de if/else, métodos com 300-400 linhas… já cheguei a ver 5 switchs encadeados), e não documentado… :roll:
Some isso a um ERP que esta a 15 anos sendo incrementado…sem nenhuma documentação…
:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
Trocaria de cargo todos lideres / chefes / gerentes / … que não tivesse graduação (NA ÀREA) + experiencia; depois iria pensar no processo de desenvolvimento.
Nada contra quem não tem graduação (NA ÀREA) mas saber administrar um projeto e LIDAR COM PESSOAS é fundamental.
flws
:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
Trocaria de cargo todos lideres / chefes / gerentes / … que não tivesse graduação (NA ÀREA) + experiencia; depois iria pensar no processo de desenvolvimento.
Nada contra quem não tem graduação (NA ÀREA) mas saber administrar um projeto e LIDAR COM PESSOAS é fundamental.
flws
Acho que no caso do ERP de 15 anos, não basta trocar de cargo os líderes / chefes / gerentes / …, tem é que despedaçá-los vivos e dar a carne deles de comida aos abutres. :twisted: :twisted: :twisted:
:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
Trocaria de cargo todos lideres / chefes / gerentes / … que não tivesse graduação (NA ÀREA) + experiencia; depois iria pensar no processo de desenvolvimento.
Nada contra quem não tem graduação (NA ÀREA) mas saber administrar um projeto e LIDAR COM PESSOAS é fundamental.
flws
Acho que no caso do ERP de 15 anos, não basta trocar de cargo os líderes / chefes / gerentes / …, tem é que despedaçá-los vivos e dar a carne deles de comida aos abutres. :twisted: :twisted: :twisted:
Quanto magoa nesse seu coração victor, isto faz mal a saude.
Limitar as alterações de “ultima hora” que o cliente pode fazer no projeto.
if(alterações>0)
System.out.println("você não tem privilégios suficientes para fazer esta alteração!");
Possivelmente… mas o caso é o “de sempre”: sistema feito às pressas, com uma pessoa semi-responsável por um módulo inteiro, sem nenhum teste unitário/documentação/whatever e testes feitos nas coxas. Entregue, os desenvolvedores pegam outro sistema - a muito custo está sendo implementada a metodologia SCRUM no novo desenvolvimento.
O problema é que os bugs começam a aparecer, e os desenvolvedores novos na empresa que vão resolver eles - assim como implementar novas funcionalidades. TDD não é uma opção num sistema pronto… e Pair Programming não é possível pois quem fez aquele módulo já está envolvido em outro e muito provavelmente já esqueceu metade. Resolver bugs é um problema dos menores; Tente entretanto implementar funcionalidades não planejadas em um sistema com uma arquitetura mal-definida, cheio de POG (inner classes a mais de metro, encadeamento de if/else, métodos com 300-400 linhas… já cheguei a ver 5 switchs encadeados), e não documentado… :roll:
Some isso a um ERP que esta a 15 anos sendo incrementado…sem nenhuma documentação…
E que tal documentar o processo ao invés do código ?
documentar o processo ??? Ou seja RUP?
nao aguento mais essa burocratizacao do processo de desenvolvimento!!! =S
documentar o processo ??? Ou seja RUP?nao aguento mais essa burocratizacao do processo de desenvolvimento!!! =S
Nope, o processo ao qual o SW está sendo baseado… Se vc conhecer esse processo o resto é moleza.
SW?
Software.
Possivelmente… mas o caso é o “de sempre”: sistema feito às pressas, com uma pessoa semi-responsável por um módulo inteiro, sem nenhum teste unitário/documentação/whatever e testes feitos nas coxas.
Pelo visto vocês sabem os problemas, então por que não ir atrás de resolvê-los ao invés de criar um novo? Produzir documentação não só não vai resolver nenhum destes problemas como vai ser mais uma preocupação pra uma equipe que já está se quebrando com o resto.
Com um codigo bem feito e documentado se consegue gerar documentacao automaticamente quando for preciso!!! =D
Documentação = Javadoc + comentarios pertinentes ao negocio sempre atualizados.
Diagramas e documentos fora do sistema só ajudam a complicar já que ninguem irá atualiza-los e quando o fazem costumam escrever qualquer coisa para “se livrar”.
:arrow: Treinaria os gerentes e coordenadores para que eles saibam impor limites ao cliente (ja que desenvolvedor nao tem esse poder) . A maioria dos problemas surgem pois os superiores nao sabem ou nao conhecem a importancia de um processo bem definido com tempo suficiente para que os desenvolvedores nao estraguem os sistemas. Se depender do cliente tudo é para ontem, menos a qualidade do que é feito, resultando em retrabalho e manutenções cada vez mais demoradas e propensas a erros.
:arrow: Incluiria também em todas as equipes pelo menos 1 desenvolvedor senior para monitorar o que é feito, sugerir melhorias e acima de tudo programar.
:arrow: Implementaria par programming e removeria com o tempo os famosos desenvolvedores “donos” de sistemas.
:arrow: Incluiria um designer para os projetos, pois muita pog é causada por falta de conhecimento na parte visual pelos programadores.
:arrow: Incluiria padroes de codificacao como sun code convention, uso de ferramentas como checkstyle e adotaria o principio kiss em todos os projetos, retirando frameworks proprietarias e arquiteturas globais.
:arrow: Incentivaria um ambiente saudavel entre os desenvolvedores, removendo a famosa guerra do ego, recompensando aqueles que mais agregam a toda equipe e nao as estrelinhas.
:arrow: Incentivaria a pesquisa de melhores tecnologias e processos que agreguem valor a empresa.
:arrow: Testes unitarios? Nao existe sistema sem isso, apenas acochambrados de codigo que um dia caem ou ficam complicaos d+ para se manter.
:arrow: Colocaria uma maquina de refrigerante e doces a disposicao de todos. Quem nao trabalharia feliz com um chocolate nas horas de tensao? 
Tudo que falei eu tento na medida do possivel implementar nas empresas em que presto consultoria, nem sempre consigo, mas com certeza consigo fazer as pessoas pensarem pelo menos no que proponho demonstrando com exemplos reais o ganho de cada mudança, pois não adianta nada ficar falando das maravilhas do mundo moderno sem provar.
É bem por ai mesmo Aleck =D
Aleck aqui na empresa que eu trabalho nos temos mais ou menos isso.
Como nos provemos a nossa propria framework para nossos clientes nos temos uma equipe especializada em documentacao (50% deles sao desenvolvedores que conhecem bem os nossos produtos) entao eles produzem manuais de instalacao, manual voltado aos desenvolvedores, etc. Temos tb, uma pagina web que descreve toda a nossa api parecida com a da sun java api.
O tempo de desenvolvimento aqui eh super razoavel, trabalhamos com SCRUM e geramente um sprint leva mais ou menos um 1 e o nosso gerente nao tenta colocar o maximo de coisas possivel em 1 sprint. Ele tem reunioes com bussiness e coloca prioridades. Raras as vezes que eu tive que fazer horas extras ou trabalhar em casa. Raras as vezes tb que uma tarefa demora mais tempo que o planejado.
Nos nao temos isso aqui, mas todo mundo eh super prestativo em ajudar e dar dicas, sempre fazemos pra programming. Quando alguem tem problemas nos sempre fazemos uma rapida reuniao apos a nossa scrum meeting pra propor solucoes, etc.
Fazemos pair programming e claro que tem gente que realmente manja tudo sobre o nossos sistemas, mas ng fica escondendo coisas de ng, tudo eh compartilhado, todo mundo aprende sobre o sistema.
Aqui tb tem uma equipe de designers, que incluir ate gente que fez master em interacao humano maquina, entao geralmente os desenvolvedores so implementam os designes e cores que eles definem.
Nos temos alguns padroes de desenvolvimento, nos usamos um plugin pro visual studio que faz a verificacao desses padroes e verifica se os desenvolvedores estao usando o mesmo que todos mundo. O codigo fica limpo e legivel pra todo mundo.
Isso eh uma coisa que aqui nao acontece. No Brasil tem essa famosa guerrinha, vejo aqui no forum mesmo que tem gente que literalmente SE ACHA. Nas empresas um falando mal do outro, falando mal do chefe, etc. Aqui nao rola nada disso, todo mundo eh amigo e todo mundo se respeita, fica um clima super bom.
Nos temos uma equipe de pesquisa tb, que pesquisa novas tecnologias, implementa novas ideias, agora eles estao bem focados em aplicacoes pra iPhone.
Somos muito chatos quanto testes unitarios. E levamos isso a serio. O nosso project leader definiu um guidelines pra desenvolvimento de testes unitarios.
Aqui nao tem chocolate, senao seria todo mundo gordo. Mas nos temos aqui refrigerante, agua com gas e frutas a vontade. Nas reunioes sempre tem sandwiches. Temos tb todos os videogames (wii, xbox360 e ps3), pista de autorama e sinuca. Ah e fora isso, tem sempre cerveja sextas e a empresa tb organiza torneio de golf (no verao claro, ng gosta de jogar na neve heheh) e no inverno viagens pra esquiar.
Uma outras coisa legal que temos aqui eh uma reuniao semanal com todo mundo da empresa, cada gerente apresenta o que esta trabalhando, resultados e objetivos, entao todo mundo sabe o que todas as areas da empresa estao fazendo e eu acredito que isso faz os funcionarios ficarem super envolvidos com a empresa.
//Daniel
Pelo visto vocês sabem os problemas, então por que não ir atrás de resolvê-los ao invés de criar um novo? Produzir documentação não só não vai resolver nenhum destes problemas como vai ser mais uma preocupação pra uma equipe que já está se quebrando com o resto.
Convencer a gerência de que refactoring/documentação é necessária é uma tarefa realmente ingrata, e sou só um estagiário (quiseram me efetivar, mas nisso aqui, deus me livre. Saio em fevereiro…). O sistema novo é considerado uma evolução do antigo, e nele foram aplicadas (algumas) regras básicas no desenvolvimento; até onde vi, está bastante melhor - ainda que longe do ideal…
Vendendo software pro governo, com um sistema novo a caminho, quem que iria investir em um produto que está prestes a ficar ultrapassado? Ainda mais se você pode colocar estagiários pra manter… :?
porra cara, se vc for abrir uma empresa e conseguir fazer tudo isso, certeza que eu vou trabalhar vc!! é quase um sonho!!! :lol: :lol: :lol:
Atualmente pegaria os ternos e gravatas que sou obrigado a usar todo santo dia, picaria eles em 4578 pedaços e botava fogo. :twisted:
Arrebentaria a cara dos usuarios, pois os mesmos não sabem oque quer, e a gerencia fala amém. :twisted:
Pegaria os mais seniors e daria responsabilidades de cordenadores, nada de cordenadores de prancheta, faz um curso ali e outro lá e já acha que pode mandar em um monte de pessoas super capacitadas.
basicamente é isso que eu gostaria!
[/quote]
windsofhell vc trabalha no google???
cara, vou mandar meu cv para vc!! a empresa pelo oque vc está falando é perfeita!!!
qual empresa vc trabalha?
abs
windsofhell, nao sei como te dizer isso. Mas vc deve estar morto e deve ter sido bonzinho a vida toda.
Sou obrigado a concordar com vc!!! rsrsrs
abs
Olá,Hoje em dia, com tantas metodologias e processos de desenvolvimento temos muitas opções para desenvolver software.
Mas mesmo assim, muitos métodos acabam sendo ineficientes e nós, desenvolvedores, acabamos tendo muitos problemas no dia-a-dia.Se você pudesse mudar alguma coisa no processo de desenvolvimento de software que atualmente é utilizado na sua empresa, o que vocês mudaria
Mas pensando em muitas das técnicas que já colocaram aqui, é simples que existe um abismo do mundo real frente o mundo ideal, para mim o processo de desenvolvimento de software começa no pensamento e ideologia da Empresa, que sabe contratar profissionais e isso não implica somente nos trilhões de cursos ou certificados, e sim na cultura de saber que reciclagem e treinamentos em ferramentas e novas adoções são requisitos constantes e primordiais.
Aqui se coloca, o que você mudaria no processo de desenvolvimento de software, mas eu rebato você para ser agilista deve ser conhecedor de várias tecnologias e tendências, e nisso saber como a implementação se deve e acontece em determinado aspecto tecnológico, a decisão e a intenção sobre o uso de uma metodologia se deve bem no seu intimo aspecto cultural da Organização isso deve ser bem frisado aqui.
Aleck aqui na empresa que eu trabalho nos temos mais ou menos isso.blablabla
//Daniel
Sim, nós acreditamos!
Aleck aqui na empresa que eu trabalho nos temos mais ou menos isso.blablabla
//Daniel
Sim, nós acreditamos!
Ueh? porque eh dificil de acreditar? Eu nao trabalho no Brasil (se vc nao notou) e ja tive experiencia de trabalhar em duas empresas aqui fora e posso te afirmar que eh completamente diferente das quase 10 empresas que eu trabalhei no Brasil. Nao eh porque no Brasil nao tem bons profissionais, MUITO pelo contrario, mas simplesmente pelo fato que as circunstancias sao diferentes, as pessoas agem de maneira diferente tb (so ver aqui no forum os posts de alguns ou tipo o seu “sim, nos acreditamos”). De qualquer forma, eu nao acredito que essas coisas que eu citei sao impossiveis, alias sao bem comuns.
Se alguem nao trabalha seguindo o minimo de boas praticas de programacao e padronizacao, nao tem bons colegas de trabalho que ajudam e trabalham legal em equipe, o seu gerente eh um chato que so enche o saco e nao sabe nada, tem que trabalhar extra direto porque ta tudo atrasado a ponto de explodir. Entao eh melhor trocar de empresa. Acho que isso que eu citei pra falar a verdade eh o minimo.
Qtos as outras coisas, comidinhas e bebidas de graca, videogames, sinuca, isso nao eh muita coisa pra empresa e fazer os funcionarios felizes, tb nao acho um absurdo. Mas pra falar a verdade, pode ter videogame, etc etc… mas pouca gente usa, eu mesmo joguei umas 2 ou 3 vezes game e 1 vez sinuca. Na minha opiniao coisas desse tipo sao mais pra fazer o funcionario se sentir bem por trabalhar num local que tem videogame (que ele quise jogar) mesmo que nunca jogue.
Provavelmente toda aquela frescurada que tem no google ng usa.
Mas enfim, so estava contando a minha experiencia, nao pedi pra ng acreditar ou deixar de acreditar 
ps: e nao eu nao trabalho no google. Gracas a Deus.
Olá!
Acho que o pessoal não viu o “Localização: Stockholm - Sweden” ali no teu perfil e tava achando que tu tava tirando um barato hehehe… pra você ver como a realidade no Brasil é beeeem diferente de alguns paises de fora. Quem tem uma boa mordomia também era o Shoes se não me engano…
Quanto à qualidade no processo, isso depende bastante dos líderes, apesar que se você começa a adotar boas práticas todo mundo copia… a questão está em mostrar que aquilo que você está fazendo vai trazer benefício futuro para a equipe.
Abraços
Olá!Acho que o pessoal não viu o “Localização: Stockholm - Sweden” ali no teu perfil e tava achando que tu tava tirando um barato hehehe… pra você ver como a realidade no Brasil é beeeem diferente de alguns paises de fora. Quem tem uma boa mordomia também era o Shoes se não me engano…
Quanto à qualidade no processo, isso depende bastante dos líderes, apesar que se você começa a adotar boas práticas todo mundo copia… a questão está em mostrar que aquilo que você está fazendo vai trazer benefício futuro para a equipe.
Abraços
Nossa e ainda ter o prazer de sair do trabalho e caminhar para o pub mais perto com várias galegas maravilhosas… Aahh as suécas !!!
heheh :lol:
Olá!Acho que o pessoal não viu o “Localização: Stockholm - Sweden” ali no teu perfil e tava achando que tu tava tirando um barato hehehe… pra você ver como a realidade no Brasil é beeeem diferente de alguns paises de fora.
Só é diferente porque os brasileiros a deixam ser diferente. E eles deixam porque querem.
Ninguém é obrigado a nada, mas muita gente se auto-obriga a muita coisa com medo de represálias.
Enquanto a qualidade não estiver acima desses medo pessoal, nada pode ser feito.
Só é diferente porque os brasileiros a deixam ser diferente. E eles deixam porque querem.
Ninguém é obrigado a nada, mas muita gente se auto-obriga a muita coisa com medo de represálias.Enquanto a qualidade não estiver acima desses medo pessoal, nada pode ser feito.