lições aprendidas

Lembrei de alguns pontos positivos...
Melhora a comunicação entre os membros da equipe e facilita que se obtenha um entendimento comum do assunto que está sendo tratado.
O analista de negócios e o gerente de projetos conseguem ter um acompanhamento melhor das atividades que estão sendo realizadas, das dificuldades que surgem ao longo do projeto, pois eles tem um feedback constante dos demais membros da equipe. Alem disso, facilita na definição de prazos de entrega, na comunicação com o cliente....
O uso do processo de testes é fundamental em todo o projeto, pois evita-se muitos erros que possam ocorrer na mão do usuário. Além disso pode servir como validação interna do trabalho realizado, verificando se todas as regras de negócio foram atendidas se os requisitos foram cumpridos, ....

Pessoal, alguém tem mais informações ou experiências sobre o assunto para compartilhar?

bem que eu queria, mas infelizmente não.

não tenho nenhuma experiencia com desenvolvimento.

Faz parte... Imagino que a maioria das empresas não seguem exatamente os passos sugeridos por uma metodologia ágil, ou, na maioria das vezes, nem possuem uma metodologia definida.

isso acontece em empresas pequenas e medias geralmente.

Tem fundamento! Porque é díficil imagina uma empresa grande sem uma boa gestão e bons gerentes de projetos.

um outro detalhe, se o foco da empresa não for dev, aew geralmente o bicho pega.

A medida que todos nós concebermos algumas lições aprendidas no processo de desenvolvimento de nossas empresas, laboratórios e etc , podemos compartilhar neste post.

Tenho algumas experiências negativas, mas que serviram de lição. Trabalhei muitos anos em uma empresa de desenvolvimento, onde o dono é extremamente conservador e adotava a ideia de que o software poderia ser sempre adaptado de acordo com o que o cliente pedia.

1) O cliente nunca para de pedir alterações, muitas vezes desnecessárias.
2) Quanto mais alterações no software você tem para fazer, menos tempo tem para entregar.
3) Desenvolvendo com pressa, você não tem tempo para fazer uma alteração bem feita.
4) Se você colocar um sistema mal feito no mercado, o cliente vai reclamar, e o problema volta para você, demando mais tempo, fora o desgaste emocional.
5) Sistemas abertos demais, nessas situações citadas, geralmente deixam o código fonte mal comentado, e desorganizado.
6) Um código fonte desorganizado é difícil de dar manutenção, principalmente por outra pessoa que não o conhece.

Passei por tudo isso e muitas outras situações que não citei. Hoje tenho meu software, que é 99% fechado (clientes raramente me pedem alterações), e por consequência quase não tenho que dar suporte para meus clientes, uma vez que o sistema raramente dá problema (bem raramente mesmo).

Isso tudo resultou em uma coisa para mim: qualidade de vida. Não tenho estresse nem pressão por parte dos meus clientes.

Abraço a todos!

Marcos

Puxa, também passei por isso...
Trabalhei em um lugar onde os sistemas são muito antigos e são realizadas alterações, manutenções corretivas, evolutivas, preventivas, tudo o que vcs puderem imaginar o tempo todo...
E é complicado de trabalhar assim, porque acontece exatamente o que o Marcos mencionou...

Mas, esqueci e devo comentar que, alguns meses antes da minha saída eles estavam implementando o SCRUM no desenvolvimento de projetos.
Participei de um projeto onde seguimos todos os passos e os resultados foram bem significativos.
Aumentou a comunicação entre a equipe de desenvolvimento e os usuários tiveram uma participação mais ativa na definição do projeto.
Mas sempre vai ter as manutenções pois são mais de 200 aplicações e a maioria são bem antigas e foram sofrendo alterações, conforme mudaram as leis e a legislação.
Então, isso de fazer um sistema fechado e não fazer alterações para os usuários, eu considero como algo relativo, pois depende do ramo de negócio que o sistema contempla.
Na empresa onde eu trabalho agora, o ERP gera o SPED fiscal das empresas e, seguido, o governo cria uma lei nova ou suspende uma existente.. Então, sempre tem que ter alguém que acompanhe tudo isso e faça as alterações nos sistemas para atender as novas demandas.

Marisiana,

Onde trabalhei, o sistema era bem antigo, e como você citou, eram feitas várias alterações, inclusive por exigência de legislações. Mas lá o SCRUM não iria funcionar não. A mentalidade conservadora do administrador, não permitia novas ideias, novas tecnologias. E isso foi o ponto crucial para que eu saísse da empresa. Uma empresa de tecnologia que não quer evoluir... Já viu isso?

Quando eu falei que meu sistema é fechado, digo que é até certo ponto. Faço alterações para adequações do SPED, por exemplo, mas meus clientes não ficam me pedindo alterações desnecessárias. O que eu NÃO faço é personalizar meu sistema de acordo com o que meus clientes pedem. E tem funcionado dessa forma. Só se for pequenas alterações, como acrescentar uma informação em um relatório, etc... Isso facilita muito meu suporte, uma vez que fazendo poucas alterações, teria poucas correções.

Abraço!

Marcos

Nossa, deve ser mesmo complicado trabalhar numa empresa assim, parece que tudo é feito "nas coxas"...
Essa forma de trabalho que vc adotou sem dúvida é a melhor e mais correta!