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: [/quote]
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[/quote]
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[/quote]
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: [/quote]
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: [/quote]
Some isso a um ERP que esta a 15 anos sendo incrementado…sem nenhuma documentação…[/quote]
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
[quote=rtozati]documentar o processo ??? Ou seja RUP?
nao aguento mais essa burocratizacao do processo de desenvolvimento!!! =S[/quote]
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.[/quote]
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