Gente, estou fazendo uma pesquisa sobre satisfação no desenvolvimento e qualidade de entrega de software de acordo com a metodologia usada
Ou seja, que problemas vocês estão encontrando para desenvolver um trabalho de qualidade?
Arquitetura ruim e mal elaborada.
[quote=better]Arquitetura ruim e mal elaborada.
[/quote]
E em termos de engenharia de software?
Sendo sincero, pelo menos comigo as empresas(duas ultimas) onde a metodologia eram mais ageis e menos burocraticas, vi maior qualidade no produto final e maior satisfação do cliente.
Agora no resto eu vi soh isso aqui:
Metodologias “compradas” com documentação excessiva e desnecessária tiram o foco da boa analise e do bom desenvolvimento, pois passamos a maior parte do tempo nos reportando sobre uma documentação burra e nos sobre o minimo de tempo pra um bom desenvolvimento.
Dependendo da empresa, o pobre desenvolvedor antes de começar no projeto já está com a corda no pescoço, a documentação que é repassada é pobre normalmente um diagrama de sequencia, alguns usecases(Não suplementados, mal suplementados e alguns hilários). Vc acaba desenvolvendo tudo pra ontem, se der algum problema o desenvolvedor acaba levando a culpa.
O gerente de projetos em muitas empresas não passa de um fantoche de terno, que passa o dia inteiro preenchendo planilha, sem saber nada do que está acontecendo, é dificil encontrar um mediador e alguns quando vc cobra alguma atituldade só fazem promessa politica.
Nas famosas fabriquetas de software, todo projeto que bate na porta já aceitam mesmo sem avaliar os riscos do projeto. Verificar qual será a arquitetura mais adequada ou pensar em reaproveitar algum serviço não passam de mito e em alguns lugares em não consigo entender pq q querem SOA.
Disse tudo.
o principal problemas são arquitetura ruim, mal elaborada e analise mal feita e ma especificada… desde o cliente ate o desenvolvimento… mas o problema ocasionado é que para as empresas o que vende mais:
software bem elaborado em 6 meses ou um software gambiarrento e mal feito em 1 semana?
oi llemosjr
O maior problema que eu tenho hoje é a falta de documentação suficiente, nós não temos os requisitos necessários e suficientes para desenvolver o sistema… mas temos que desenvolver assim mesmo
Bom, eu nunca trabalhei em uma FS, em um lugar onde eu recebesse um monte de diagramas e só precisasse me preocupar em escrever código e testar então acho que já estou acostumado com esse caos
abs
[quote=André Fonseca]oi llemosjr
O maior problema que eu tenho hoje é a falta de documentação suficiente, nós não temos os requisitos necessários e suficientes para desenvolver o sistema… mas temos que desenvolver assim mesmo
Bom, eu nunca trabalhei em uma FS, em um lugar onde eu recebesse um monte de diagramas e só precisasse me preocupar em escrever código e testar então acho que já estou acostumado com esse caos
abs[/quote]
eu ja trabalhei em uma FS e não é muito legal pois vc perde muito tempo em entender oq o cara quer fazer… e muitas vezes o cara faz merda vc acaba fazendo merda por que ele fez merda vc leva a culpa da merda por causa dele… outros casos ele faz de uma forma gambiarrenta o diagrama e vc tenque fazer um monte de gambiarra por causa disto… prefiro assim com liberdade de vc poder fazer a coisa do seu jeito e saber que é o melhor jeito… agora especificação tenque ter o suficiente… nem muito exagerado e nem pouco… o suficiente para fazer algo com qualidade…
Acho que concordo com o pessoal, mas no meio de tantos problemas, a mà definição dos requisitos acho que ainda é um dos maiores.
Com certeza má definição de requisitos, levantamento e especificação. Ao meu ver o sistema depende do levantamento e da documentação do negócio…se é mal feito ou mesmo feito de forma pobre, o restante das fases está fadada a sair ruim também.
ate mais…
Legal esse topico…
e sobre o Processo?
RUP, OpenUP, Scrum? XP?
Vcs acham que usar algum deles foi ruim? ou não usar algum deles foi o problema?
Já trabalhei em lugar que juntava tudo: Falta de Padrão de Projeto + falta de Processo + Requisitos Indefinidos + Cliente Ausente + Prazos Indefinidos(era tudo pra logo)…
A questão com os requisitos serem mal levantados vai muito além de pouco investimento nessa tarefa. Geralmente o cliente não sabe o sistema que quer. Não conhece os requisitos, tem apenas uma idéia. Os requisitos vão evoluindo com o passar do tempo e com o cliente vendo o sistema construído até então. Essa é a abordagem do XP, por exemplo.
Veja que não estamos construíndo uma casa ou uma peça mecânica, onde podemos até simular o comportamento do produto final. Software é muito abstrato, começa com um conjunto de idéias que vão evoluindo até chegar no ponto “ideal”.
Outra coisa que atrapalha bastante o desenvolvimento é a abordagem de muitas empresas que acham que qualquer idiota pode programar. Desenvolver sistemas está muito mais para artesanato do que linha de montagem.
Gostei disso: “Desenvolver sistemas está muito mais para artesanato do que linha de montagem.”
Além de ser muito verdade… Infelizmente nem todos os “gerentes” entendem isso.
Falando em “gerentes”, um ponto que eu acho interessante e não concordo é o do PMI dizer que o “gerente” não precisa ter conhecimento técnico NENHUM. Não é a toa que os piores gerentes que tive até hoje foram desse gênero. Um mínimo de conhecimento ajuda muito numa conversa… numa troca de idéias… Sim, pode até não ser necessário… mas que ajuda, ajuda… e muito.
- Cliente ausente, passivo e/ou omisso.
- Cliente não conhece o próprio negócio.
- Waterfall.
- Programadores sem direito de opinar no projeto ou na análise.
- Projeto mal-feito ou ausente.
- Resistência a mudanças.
- Prazos impossíveis.
- Apego a ferramentas e metodologias obsoletas e/ou inadequadas.
- Cultura de desviar dos bugs ao invés de corrigi-los.
- Ocultação de problemas, bugs e falhas.
- Big Brother corporativo.
- Falta de qualificação técnica.
- Cultura a POG.
- Congelamento de código.
- Atenção excessiva a documentação em detrimento da implementação.
- Ausência de documentação.
- Documentação falha, mentirosa, desatualizada e/ou contraditória.
- Não compreensão do negócio na implementação.
- Requisitos mal-definidos.
- Requisitos em constante alteração.
- Requisitos conflitantes.
- Desmotivação no trabalho.
- Alta rotatividade de pessoal.
- Interrupções constantes.
- Dificuldade de efetuar teste.
- Falta de padronização e uniformidade no código.
[quote=victorwss]1. Cliente ausente, passivo e/ou omisso.
2. Cliente não conhece o próprio negócio.
3. Waterfall.
4. Programadores sem direito de opinar no projeto ou na análise.
5. Projeto mal-feito ou ausente.
6. Resistência a mudanças.
7. Prazos impossíveis.
8. Apego a ferramentas e metodologias obsoletas e/ou inadequadas.
9. Cultura de desviar dos bugs ao invés de corrigi-los.
10. Ocultação de problemas, bugs e falhas.
11. Big Brother corporativo.
12. Falta de qualificação técnica.
13. Cultura a POG.
14. Congelamento de código.
15. Atenção excessiva a documentação em detrimento da implementação.
16. Ausência de documentação.
17. Documentação falha, mentirosa, desatualizada e/ou contraditória.
18. Não compreensão do negócio na implementação.
19. Requisitos mal-definidos.
20. Requisitos em constante alteração.
21. Requisitos conflitantes.
22. Desmotivação no trabalho.
23. Alta rotatividade de pessoal.
24. Interrupções constantes.
25. Dificuldade de efetuar teste.
26. Falta de padronização e uniformidade no código.[/quote]
Precisa falar mais alguma coisa? rs
[quote]13. Cultura a POG.
[/quote]
Essa foi boa! :lol:
++++++++++++++++++++++++++++++++++++++
[quote=victorwss]1. Cliente ausente, passivo e/ou omisso.
2. Cliente não conhece o próprio negócio.
3. Waterfall.
4. Programadores sem direito de opinar no projeto ou na análise.
5. Projeto mal-feito ou ausente.
6. Resistência a mudanças.
7. Prazos impossíveis.
8. Apego a ferramentas e metodologias obsoletas e/ou inadequadas.
9. Cultura de desviar dos bugs ao invés de corrigi-los.
10. Ocultação de problemas, bugs e falhas.
11. Big Brother corporativo.
12. Falta de qualificação técnica.
13. Cultura a POG.
14. Congelamento de código.
15. Atenção excessiva a documentação em detrimento da implementação.
16. Ausência de documentação.
17. Documentação falha, mentirosa, desatualizada e/ou contraditória.
18. Não compreensão do negócio na implementação.
19. Requisitos mal-definidos.
20. Requisitos em constante alteração.
21. Requisitos conflitantes.
22. Desmotivação no trabalho.
23. Alta rotatividade de pessoal.
24. Interrupções constantes.
25. Dificuldade de efetuar teste.
26. Falta de padronização e uniformidade no código.[/quote]
“Tecnologia depende de muito investimento”, dinheiro e tecnologia também é uma combinação traiçoeira nas empresas, algo como bolsa de valores
Mas ao chegar no momento da entrega, o que acontece com maior frequência…
Tenta prolongar o prazo?
Entrega com menos funcionalidades?
Corre pra entregar e perde muito tempo com manutenção e correção de bugs?
O que mais ocorre?
Acho que as tres coisas junto e mais algumas coisas que só passando pra saber