Em um projeto onde o Modelo Castaca \u00e9 usado, cada ponto desses representa um est\u00e1gio distinto de desenvolvimento de software, e cada est\u00e1gio geralmente termina antes que o pr\u00f3ximo possa come\u00e7ar. Os requisitos geralmente s\u00e3o revisados e aprovados pelo cliente antes que o projeto possa ser iniciado.<\/p>\n
H\u00e1 coisas boas e ruins nessa abordagem. Confira, a seguir.<\/p>\n
Os aspectos positivos do modelo Cascata<\/h2>\n
No modelo Cascata, desenvolvedores e clientes concordam sobre o que ser\u00e1 entregue no in\u00edcio do ciclo de vida de desenvolvimento. Isso torna o planejamento e o design mais simples; o progresso \u00e9 medido mais facilmente, pois o escopo completo do trabalho \u00e9 conhecido antecipadamente.<\/p>\n
Durante todo o esfor\u00e7o de desenvolvimento, \u00e9 poss\u00edvel que v\u00e1rios membros da equipe estejam envolvidos ou continuem com outros trabalhos, dependendo da fase ativa do projeto. Por exemplo, os analistas de neg\u00f3cios podem aprender e documentar o que precisa ser feito, enquanto os desenvolvedores est\u00e3o trabalhando em outros projetos. Os testadores podem preparar scripts de teste a partir da documenta\u00e7\u00e3o de requisitos enquanto a codifica\u00e7\u00e3o est\u00e1 em andamento.<\/p>\n
Outra vantagem do modelo Cascata \u00e9 que, exceto para revis\u00f5es, aprova\u00e7\u00f5es, reuni\u00f5es de status etc., a presen\u00e7a do cliente n\u00e3o \u00e9 estritamente necess\u00e1ria ap\u00f3s a fase de requisitos.<\/p>\n
E mais: como o design \u00e9 conclu\u00eddo no in\u00edcio do ciclo de vida de desenvolvimento, essa abordagem presta-se a projetos em que v\u00e1rios componentes de software devem ser criados (\u00e0s vezes em paralelo) para integra\u00e7\u00e3o com sistemas externos.<\/p>\n
Por fim, o software pode ser projetado de forma completa e cuidadosa, com base em um entendimento mais completo de todos os produtos da aplica\u00e7\u00e3o. Isso proporciona um melhor design com menor probabilidade de \u201cefeito fragmentado\u201d, um fen\u00f4meno de desenvolvimento que pode ocorrer na medida em que peda\u00e7os de c\u00f3digo s\u00e3o definidos e subsequentemente adicionados a um aplicativo em que eles podem ou n\u00e3o se encaixar bem.<\/p>\n
Os poss\u00edveis problemas do modelo Cascata<\/h2>\n
Uma \u00e1rea que quase sempre fica aqu\u00e9m nesse modelo tradicional de trabalho \u00e9 a efic\u00e1cia dos requisitos. Reunir e documentar requisitos de uma forma significativa para um cliente \u00e9, muitas vezes, a parte mais dif\u00edcil do desenvolvimento de software.<\/p>\n
Os clientes \u00e0s vezes s\u00e3o intimidados por detalhes; e detalhes espec\u00edficos, fornecidos no in\u00edcio do projeto, s\u00e3o necess\u00e1rios no Modelo Cascata.<\/p>\n
Al\u00e9m disso, os clientes nem sempre conseguem visualizar um aplicativo a partir de um documento de requisitos. Wireframes e mockups podem ajudar, mas n\u00e3o h\u00e1 d\u00favidas de que a maioria dos usu\u00e1rios finais t\u00eam alguma dificuldade em reunir esses elementos com requisitos escritos para chegar a uma boa imagem do que v\u00e3o ter em m\u00e3os.<\/p>\n
Outra poss\u00edvel desvantagem do desenvolvimento no modelo Cascata \u00e9 a possibilidade de o cliente ficar insatisfeito com o software entregue. Como todos os produtos s\u00e3o baseados em requisitos documentados, um cliente pode n\u00e3o ver o que ser\u00e1 entregue at\u00e9 que esteja quase conclu\u00eddo. Nesse momento, as mudan\u00e7as podem ser dif\u00edceis (e caras) de implementar.<\/p>\n
O modelo \u00c1gil e suas particularidades<\/h2>\n
O modelo \u00c1gil \u00e9 uma abordagem iterativa que enfatiza a entrega r\u00e1pida de uma aplica\u00e7\u00e3o em componentes funcionais completos.<\/p>\n
Em vez de criar tarefas e programa\u00e7\u00f5es, todo o tempo \u00e9 dividido em fases chamadas \u201csprints\u201d. Cada sprint tem uma dura\u00e7\u00e3o definida (geralmente em semanas) com uma lista de entregas planejada em seu in\u00edcio. Entregas s\u00e3o priorizadas pelo valor do neg\u00f3cio, conforme determinado pelo cliente. Se todo o esfor\u00e7o planejado para o sprint n\u00e3o puder ser conclu\u00eddo, o trabalho \u00e9 redimensionado e as informa\u00e7\u00f5es s\u00e3o usadas para o planejamento futuro.<\/p>\n
\u00c0 medida que o trabalho \u00e9 conclu\u00eddo, ele pode ser revisado e avaliado pela equipe do projeto e pelo cliente, por meio de compila\u00e7\u00f5es di\u00e1rias e demonstra\u00e7\u00f5es de final de sprint.<\/p>\n
A metodologia \u00c1gil depende de um n\u00edvel bastante alto de envolvimento do cliente durante todo o projeto, mas especialmente durante as revis\u00f5es.<\/p>\n
Da mesma forma que o modelo Cascata, h\u00e1 tamb\u00e9m coisas boas e ruins no modelo \u00c1gil. Confira, a seguir.<\/p>\n
Os aspectos positivos do modelo \u00c1gil<\/h2>\n
No modelo \u00c1gil, o cliente tem oportunidades frequentes e antecipadas de ver o trabalho sendo entregue e de solicitar mudan\u00e7as ao longo do o projeto; ele ganha um forte senso de propriedade, trabalhando extensivamente e diretamente com a equipe.<\/p>\n
Se o tempo de comercializa\u00e7\u00e3o de um aplicativo espec\u00edfico \u00e9 uma preocupa\u00e7\u00e3o maior do que liberar um conjunto completo de recursos no lan\u00e7amento inicial, o m\u00e9todo \u00c1gil ajuda a produzir mais rapidamente uma vers\u00e3o b\u00e1sica funcional que pode ser constru\u00edda em sucessivas itera\u00e7\u00f5es.<\/p>\n
Por fim, outra vantagem dessa abordagem \u00e9 que o desenvolvimento \u00e9 mais focado no usu\u00e1rio, provavelmente como resultado de uma dire\u00e7\u00e3o mais frequente do cliente.<\/p>\n
Os poss\u00edveis problemas do modelo \u00c1gil<\/h2>\n
Um aspecto comumente visto como uma desvantagem dessa abordagem \u00e9 que o alto grau de envolvimento do cliente, embora \u00f3timo para o projeto, pode ser desconfort\u00e1vel para alguns clientes que simplesmente n\u00e3o t\u00eam tempo ou interesse por esse tipo de participa\u00e7\u00e3o.<\/p>\n
A metodologia \u00c1gil tamb\u00e9m funciona melhor quando os membros da equipe de desenvolvimento s\u00e3o completamente dedicados ao projeto. E como ela se concentra na entrega e na redefini\u00e7\u00e3o frequentes, \u00e9 poss\u00edvel que alguns itens n\u00e3o sejam conclu\u00eddos dentro do prazo previsto. Sprints adicionais podem ser necess\u00e1rios, aumentando os custos.<\/p>\n
As rela\u00e7\u00f5es de trabalho pr\u00f3ximas em um projeto \u00c1gil s\u00e3o mais f\u00e1ceis de gerenciar quando os membros da equipe est\u00e3o localizados no mesmo espa\u00e7o f\u00edsico, o que nem sempre \u00e9 poss\u00edvel. No entanto, existem v\u00e1rias maneiras de lidar com esse problema, como webcams, ferramentas de colabora\u00e7\u00e3o etc.<\/p>\n
Por fim, a natureza iterativa do desenvolvimento \u00e1gil pode levar a uma refatora\u00e7\u00e3o frequente se o escopo completo do sistema n\u00e3o for considerado na arquitetura inicial e no design. Sem essa refatora\u00e7\u00e3o, o software pode sofrer uma redu\u00e7\u00e3o na qualidade geral. Isso se torna mais pronunciado em implementa\u00e7\u00f5es de maior escala ou com sistemas que incluem um alto n\u00edvel de integra\u00e7\u00e3o.<\/p>\n
7 grandes diferen\u00e7as entre o Modelo Cascata e o Modelo \u00c1gil de desenvolvimento<\/h2>\n
Depois de rememorar os conceitos e verificar os pontos fortes e fracos dos modelos Cascata e \u00c1gil, vamos agora coloc\u00e1-los lado a lado para evidenciar suas diferen\u00e7as. Confira:<\/p>\n
- \n
- O processo de desenvolvimento de software \u00e9 dividido em diferentes fases no modelo Cascata, enquanto a metodologia \u00c1gil separa o ciclo de vida de desenvolvimento do projeto em sprints;<\/li>\n
- Cascata \u00e9 uma metodologia estruturada que muitas vezes pode ser bastante r\u00edgida, enquanto a metodologia Agile \u00e9 conhecida por sua flexibilidade;<\/li>\n
- No modelo Cascata, o desenvolvimento de software deve ser conclu\u00eddo como um \u00fanico projeto, que \u00e9 ent\u00e3o dividido em diferentes fases. No entanto, a metodologia \u00c1gil pode ser considerada como uma cole\u00e7\u00e3o de muitos projetos diferentes, que nada mais s\u00e3o do que as itera\u00e7\u00f5es das diferentes fases com foco na melhoria geral do software com feedbacks dos usu\u00e1rios ou da equipe de qualidade;<\/li>\n
- No modelo Cascata, n\u00e3o h\u00e1 espa\u00e7o para alterar os requisitos uma vez iniciado o desenvolvimento do projeto. A metodologia \u00c1gil, por outro lado, \u00e9 bastante flex\u00edvel e permite que sejam feitas mudan\u00e7as nos requisitos de desenvolvimento do projeto, mesmo ap\u00f3s o planejamento inicial ter sido conclu\u00eddo;<\/li>\n
- Todas as fases de desenvolvimento do projeto, como design, desenvolvimento, testes etc. s\u00e3o conclu\u00eddas uma vez no modelo Cascata, enquanto que, como parte da metodologia \u00c1gil, elas seguem uma abordagem de desenvolvimento iterativo. Como resultado, planejamento, desenvolvimento, prototipagem e outras fases podem aparecer mais de uma vez durante todo o ciclo de vida do desenvolvimento;<\/li>\n
- Uma das principais diferen\u00e7as entre \u00c1gil e Cascata \u00e9 sua abordagem individual em rela\u00e7\u00e3o \u00e0 qualidade e aos testes. No modelo Cascata, a fase de teste vem depois da fase de constru\u00e7\u00e3o, mas, na metodologia \u00c1gil, o teste \u00e9 tipicamente executado simultaneamente com a programa\u00e7\u00e3o ou pelo menos na mesma itera\u00e7\u00e3o;<\/li>\n
- O modelo Cascata \u00e9 um processo interno e n\u00e3o exije a participa\u00e7\u00e3o de clientes; a abordagem \u00c1gil se concentra na satisfa\u00e7\u00e3o do cliente e, portanto, envolve a participa\u00e7\u00e3o dele durante praticamente todo o projeto.<\/li>\n<\/ol>\n
Conclus\u00e3o<\/h2>\n
Como voc\u00ea deve ter conclu\u00eddo ao longo da leitura, o modelo Cascata pode ser considerado como um processo sequencial rigoroso, enquanto o modelo \u00c1gil \u00e9 um processo altamente colaborativo, levando a uma melhor participa\u00e7\u00e3o da equipe e \u00e0 resolu\u00e7\u00e3o mais r\u00e1pida de problemas.<\/p>\n
O modelo Cascata \u00e9 mais adequado para projetos que t\u00eam requisitos claramente definidos e nos quais a mudan\u00e7a n\u00e3o \u00e9 esperada, enquanto o desenvolvimento \u00c1gil suporta um processo no qual os requisitos devem mudar e evoluir. Assim, se voc\u00ea estiver planejando desenvolver um software que exigiria revis\u00f5es frequentes e tiver que acompanhar o panorama tecnol\u00f3gico e os requisitos do cliente, o \u00c1gil \u00e9 a melhor abordagem a seguir.<\/p>\n
Por fim, acrescentamos que modelo Cascata exibe uma mentalidade de projeto e foca seu foco estritamente na conclus\u00e3o do desenvolvimento, enquanto a metodologia \u00c1gil introduz uma mentalidade de produto que se concentra em garantir que a aplica\u00e7\u00e3o desenvolvida satisfa\u00e7a seus clientes finais e se modifica conforme os requisitos mudam.<\/p>\n
![\"Ebook](\"https:\/\/no-cache.hubspot.com\/cta\/default\/455690\/6b9ed083-b243-495b-b7a4-a1b85d678385.png\")
<\/a><\/span>