Desenvolvimento de softwares estão em constantes mudanças. Logo, metodologias de gerenciamento ageis são bastante aplicáveis a essa mudança. Dentre os impecilhos do Waterfall para o desenvolvimento de softarwares, podemos ressaltar: dificultade de responder a mudanças, demora do feedback, dentre outros.
Olá, Gabriela. Tudo bem?
Obrigada por compartilhar sua resposta conosco.
Parabéns por responder à atividade e continue assim.
Bons estudos!
Em se tratando da sociedade complexa, na qual as transformações muito rapidamente (até mesmo ao que se refere ao conhecimento humano, incluindo o científico) o desenvolvimento de softwares não pode (nem é possível) ficar aquem a este cenário, já que os softwares são importantes propulsionadores da maioria das mudanças que assistimos/vivenciamos cotidianamente. Assim sendo, embora tenha suas qualidades, o Waterfall, dada sua composição sequencial rígidamente estabelecida, tem demonstrado não ter os requisitos necessários para atender as demandas do cenário atual, o que é mais possível ao utilizarmos o Ágile.
O software é projetado para desenvolver uma função ou atividade, a qual pode sofrer alteração do meio ou da aplicação, métodos prescritivos tendem a seguir o fluxo planejado até que se atinja o objetivo programado. Esse sistema engessado faz com que as mudanças aconteçam apenas no final do escopo, além de entregar um resultado que talvez nao seja satisfatório. Os métodos ágeis podem resolver os problemas de métodos mais rigidos, se adaptar melhor as necessidades do resultado desejado.
Penso que é necessário considerar o cenário global, de constante mudanças e dinamismo. Modelos engessados de gestão dificulta a adaptação de projetos e produtos ao mercado, o que pode causar insatisfação ao cliente. Se não sou flexível e atento a essas mudanças, o resultado final do projeto pode deixar de atender o seu propósito.
o modelo Waterfall é muito semelhante a outros projetos, em que se realiza o levantamento das necessidades e expectativas do cliente e se faz o Plano do Projeto, sua discussão, validação e execução. Não se pode, por exemplo, na área química, mudar um processo de reações para geração de um determinado produto, cosmético por exemplo, quando a sua formulação já foi testada, aprovada pela ANVISA, MS etc. Ou seja, um projeto de desenvolvimento de um novo produto cosmético segue o modelo Waterfall e, se for requerida alguma mudança, passa a ser outro processo e outro produto, sendo necessária nova validação e aprovação pelos órgãos competentes. Assim, na área química de cosméticos, o principal empecilho do modelo Waterfall é a adoção de processos rígidos e que seguem regulamentos normativos e legais da área de saúde e higiene. Belinda, Sorocaba, SP.
O mundo VULCA exige maior adaptabilidade dos projetos o que se torna muito complicado com o modelo Waterfall.
Desenvolvimento de software estão sempre em constantes mudanças, o modelo Waterfall dificulta as entregas gerando assim frustração entre cliente e empresa.
O método Waterfall dificulta a evolução da solução desde o início do processo de desenvolvimento, pois toma como premissa que o que já foi definido não pode ser alterado. No entanto, como o processo de desenvolvimento de softwares, assim como os processos de vendas, são em sua essência muito dinâmicos, tudo pode mudar durante o processo de levantamento ainda.
Para desenvolvimento de softwares, ou implantações de projetos voltados para área de Tecnologia, é realizado a análise, o planejamento, mas mudanças ocorrem continuamente durante. Não é possível estabelecer estratégias fixas para o ambiente de Tecnologia.
No desenvolvimento de softwares são necessários realizar ajustes constantes, o que pode trazer a necessidade de retomar um passo anterior ou modificar a ordem das etapas do desenvolvimento do projeto, o que não é possível através do Waterfall.
O método Waterfall é apenas mais um método dentre os inúmeros que existem para entrega de valor, seja qual área for. No caso do desenvolvimento de software (que tem a característica principal da maleabilidade e a possibilidade reconstrução de valor continuamente, diferente por exemplo de um hardware - equipamento eletrônico fisico ou paredes de uma casa, ou uma ponte, que para reconstrução de valor envolve a destruição do entregável para posterior reconstrução) o uso de waterfall pode levar a processos engessados, morosos e que geram entregáveis desatualizados em relação ao objetivo de valor (que pode ter evoluído durante a execução do processo de análise->concepção->engenharia, qual demanda que o software tenha que ser pensado como um grande elemento monolítico e que tenha que ter cada fase totalmente concluídas antes de prosseguir para a próxima, onde a análise fica muito distante da engenharia em relação a tempo). O modelo waterfall faz sentido para soluções de hardware (placas eletrônicas, casas, pontes, etc) ou de softwares críticos (como por exemplo softwares voltados para o mercado militar) mas para softwares comerciais, seja b2b, b2c ou b2c2b acaba que sendo uma escolha bastante questionável devido ao seu pouco dinamismo e capacidade de adaptação às constantes e rápidas mudanças de necessidade dos usuários.
Os empecilhos que o método Waterfall pode trazer são: -Reajuste ágil na execução do projeto; -Autonomia sobre o projeto; -Melhorias no decorrer dos erros e acertos; -Tracionamento mais preciso.
Os empecilhos que o método Waterfall pode trazer são: -Reajuste ágil na execução do projeto; -Autonomia sobre o projeto; -Melhorias no decorrer dos erros e acertos; -Tracionamento mais preciso.
Os empecilhos que o método Waterfall pode trazer são: -Reajuste ágil na execução do projeto; -Autonomia sobre o projeto; -Melhorias no decorrer dos erros e acertos; -Tracionamento mais preciso.
"O software é projetado para desenvolver uma função ou atividade, a qual pode sofrer alteração do meio ou da aplicação, métodos prescritivos tendem a seguir o fluxo planejado até que se atinja o objetivo programado. Esse sistema engessado faz com que as mudanças aconteçam apenas no final do escopo, além de entregar um resultado que talvez nao seja satisfatório. Os métodos ágeis podem resolver os problemas de métodos mais rigidos, se adaptar melhor as necessidades do resultado desejado"
@IGOR THONKE RODRIGUES
acredito que um dos maiores empecilhos que o modelo waterfall coloca para o desenvolvimento de software é a rigidez. Tive a impressão que uma vez assinado um contrato e prazos estabelecidos, a revisão desse contato é algo burocrático, talvez até impossível. Num contexto em que alguma imposição externa à empresa é colocada e por consequência à equipe de desenvolvimento, esse tipo de modelo não consegue dar resposta rápida para mudanças, pois falta flexibilidade.
O modelo Waterfall é muito restrito e deve funcionar bem em projetos pequenos onde os requisitos do softwares são bem definidos, mas mesmo assim pode acontecer que alguma ideia apareça quando está chegando ao final do projeto e com esse modelo a ideia ou mudança seria simplesmente descartada? podendo perder uma ótima funcionalidade do software.
@matheusmottas, lançou um termo desconhecido pra mim "mundo VULCA", o que seria isso?
@matheusmottas, lançou um termo desconhecido pra mim "mundo VULCA", o que seria isso?
A metodologia Agile esta bem ligada aos conceitos do Lean, e agregação de valor. Interessante notar que ele atende aos requisitos da criação de softwares e projetos vivos, e também a outras engenharias, mas o contrário (Waterfall) aplica somente às engenharias.
Hoje as informações e mudanças ocorrem de maneira muito rápida, e com isso o planejamento de software pode sofrer diversas alterações até seu resultado final. Por isso, usar o Waterfall para construção de softwares hoje em dia não seria a melhor maneira, porque esse modelo em cascata visa a concepção e criação de um projeto do inicio ao fim sem da muitas opções para mudança até sua entrega e isso pode impacta de maneira negativa os novos produtos a serem lançados, pois os softwares evoluem durante sua construção para se adaptar ao mercado que esta em constante evolução então usar o waterfall hoje em dia não é a solução mais viável.
A utilização do método Waterfall não é a melhor para se aplicar a realidade de construção de software devido os seus processos em cascatas, ou seja, sequenciais, para algo ocorrer, precisa de tudo que seja anterior a ele já esteja pronto. Na programação isso não é bom, podemos realizar atividades simultaneamente caso essas atividades não precisem uma da outra, assim o RH reaproveita recurso humano do inicio ao fim do projeto, também gera mesmo custos e caso algo seja mudado haverá menos burocracias e mais efetividade na entrega para o cliente.