case study how eliminate flaws waterfall
Modelo Híbrido Ágil em Cachoeira
O modelo em cascata tem sido a escolha ideal para desenvolvimento de software. Nesse modelo, uma ideia torna-se um software utilizável em um processo sequencial que se espalha pelos estágios de Iniciação, Análise, Implementação, Teste e Manutenção.
Mas o modelo em cascata tem algumas desvantagens.
O desenvolvimento ágil de software evoluiu para eliminar os problemas que o modelo Waterfall tem. Tem uma estrutura completamente nova. Enquanto o modelo em cascata tem um design sequencial, o modelo ágil segue uma abordagem incremental.
Quando os clientes que costumavam seguir o modelo em cascata mudaram para o Agile, a transição trouxe muitos problemas. O motivo é inadaptação a uma abordagem diferente para o desenvolvimento de software. O produto final acabou sendo um desastre.
Assim, uma nova metodologia evoluiu, que pode ser chamada de ‘Híbrida’, para garantir um produto final robusto escolhendo os profissionais dos modelos Ágil e Cachoeira.
Vamos primeiro saber sobre os modelos de desenvolvimento em cascata e ágil e, em seguida, passar para o 'modelo híbrido em cascata ágil' com prós e contras de cada um.
O que você aprenderá:
- Modelo de Cachoeira
- Modelo ágil
- Modelo Colaborativo (Híbrido)
- Modelo híbrido ágil em cascata - Aprenda com um exemplo - Um estudo de caso
- Como eliminar falhas de processos de desenvolvimento ágil e em cascata usando um modelo híbrido:
- Conclusão:
- Leitura recomendada
Modelo de Cachoeira
O modelo em cascata é uma abordagem para desenvolver software que divide um projeto em fases finitas. Deve-se passar para a próxima fase apenas quando sua fase anterior for revisada e verificada.
No modelo em cascata, as fases não se sobrepõem.
=> Leia mais sobre o modelo em cascata aqui.
A Figura 1 demonstra o modelo em cascata:
Vantagens do modelo em cascata:
- Simples e fácil de entender e usar.
- Modelo rígido - cada fase tem resultados e processos de revisão específicos.
- Documentação e artefatos mantidos meticulosamente.
- Adequado para projetos onde os requisitos são bem compreendidos.
Desvantagens do modelo em cascata:
- Não adequado para projetos em que os requisitos correm o risco de alteração.
- O custo da correção de defeitos é muito alto quando detectado em um estágio posterior.
- Não é um bom modelo para projetos longos e complexos.
- Nenhum software funcional é produzido até o final do ciclo de vida.
Modelo ágil
A Wikipedia define o Modelo Ágil como “um grupo de métodos de desenvolvimento de software com base no desenvolvimento iterativo e incremental, onde os requisitos e soluções evoluem por meio da colaboração entre equipes multifuncionais e auto-organizadas”.
O modelo tem seus próprios princípios que tendem a colocar os processos em segundo plano.
=> Leia mais artigos sobre a metodologia Agile aqui.
(Clique na imagem para ver ampliada)
Vantagens do modelo Agile:
- Envolvimento do cliente no processo.
- Alto ROI, pois o software de trabalho é entregue com frequência.
- Mesmo as alterações tardias nos requisitos podem ser facilmente acomodadas.
- Melhoria contínua para produto e processo.
Desvantagens do modelo ágil:
- Falta de ênfase no projeto e na documentação.
- A equipe deve ser estável e qualificada.
Modelo Colaborativo (Híbrido)
O Modelo Colaborativo visa combinar os dois modelos - Waterfall e Agile. Aproveitar as abordagens Waterfall e Agile garante o sucesso do projeto. Ele remove as desvantagens de ambos os modelos; ao mesmo tempo em que reúne as vantagens de ambos.
O modelo colaborativo pode ser implementado em um projeto executando:
Portanto, o modelo Colaborativo pode ser representado em diagrama como abaixo:
sabão webservices em perguntas da entrevista java
Vantagens do modelo híbrido
- Combina os benefícios dos processos Agile e Waterfall.
- O design de alto nível está preparado para aplicar princípios em cascata.
- A codificação e o teste são feitos com metodologia ágil.
Modelo híbrido ágil em cascata - Aprenda pelo exemplo -Um estudo de caso
A empresa de software ‘ABC Software Service’ fornece serviços a um cliente, uma universidade chamada ‘XYZ University’, para desenvolver, testar e manter seu software (suporte de produção ao vivo).
As principais características da conta são:
- A ABC Software Services precisa atualizar os aplicativos da Universidade XYZ. O banco de dados precisa ser atualizado e todos os aplicativos precisam ser redesenvolvidos para a tecnologia mais recente disponível no mercado.
- Até o momento, todos os projetos tratados pela ABC Software eram executados no modelo Waterfall.
- Dois dos aplicativos de tráfego pesado e de alta prioridade agora estavam programados para serem desenvolvidos novamente. O primeiro sendo ‘inscrições online’, o segundo sendo ‘exames online’.
- O cliente XYZ University agora queria que esses aplicativos fossem trabalhados usando o modelo Agile de desenvolvimento de software.
O primeiro projeto em um modelo Agile para o Software ABC foram os registros online. Após a execução deste projeto, percebeu-se em uma série de retrospectivas que havia muitas falhas nos processos seguidos.
Essas falhas foram cuidadas durante a execução do segundo projeto 'exames online' e, portanto, foi executado no modelo híbrido.
Como eliminar falhas de processos de desenvolvimento ágil e em cascata usando um modelo híbrido:
Vamos discutir isso em detalhes, um por um.
# 1. Sem documentação:
Um dos princípios ágeis no manifesto ágil afirma que: Agile dá mais valor ao ‘Software de Trabalho em vez de Documentação Abrangente’. A metodologia ágil acredita que a documentação deve ser 'apenas apenas boa o suficiente', e mais ênfase é dada para enviar um software funcional. Não é feito muito esforço na documentação, mas para contas como a Universidade XYZ, com uma equipe de suporte dedicada para trabalhar em defeitos encontrados em projetos ativos, esse hábito pode ser um obstáculo se analisarmos em uma base de longo prazo.
Ao longo dos anos, quando os projetos eram executados no modelo em Cachoeira, os documentos eram mantidos e atualizados para que a equipe de suporte pudesse entender e trabalhar de acordo. Desenho de solução, desenho técnico, documentos de acompanhamento, etc. foram alguns dos documentos preparados. Após o término do projeto, o mesmo foi transferido para a equipe de suporte.
Mas, no caso do projeto de ‘registros online’, nenhum desses documentos foi preparado e isso se provou caro. Quando o projeto foi ao ar, muitos tíquetes foram levantados pelos usuários finais e a equipe de suporte não tinha ideia de como trabalhar com eles. A equipe não tinha nenhum documento para consultar.
Esta foi uma grande lição aprendida e, para o próximo projeto, os documentos de ‘exames online’ foram escritos e transferidos de forma eficaz.
=> Leia mais aqui porque a documentação é importante.
#dois. Sem teste UAT / ponta a ponta:
No modo Agile de desenvolvimento de software, os testadores obtêm as compilações para testar em incrementos. Essas compilações continuam se integrando até que a compilação final esteja completamente construída. Os testadores testam os requisitos cobertos em cada sprint e continuam fazendo o teste de regressão da construção que continua aumentando.
Mas depois que todos os sprints forem concluídos e a compilação final estiver pronta e totalmente integrada, o testador deve testar o sistema completo e realizar testes de ponta a ponta. Isso deve ser feito em um ambiente completamente novo.
=> Teste de ponta a ponta em um projeto ao vivo.
Isso tem seus próprios benefícios:
- O sistema completo é implantado em um novo ambiente e o testador testa o fluxo completo.
- Isso gera confiança porque, em última análise, a construção precisa ser implantada como um todo em um ambiente ativo.
Quando o projeto de Inscrições Online foi testado, ele foi feito no ambiente de teste. Depois de testar e testar novamente todos os defeitos, o sistema foi declarado para aprovação. Idealmente, isso não foi promovido para outro ambiente para outro ciclo de teste do sistema. (Idealmente, UAT acontece após o teste do sistema , mas, neste caso, os membros da equipe UAT estavam envolvidos no primeiro ciclo de teste, então nenhum segundo ciclo foi agendado)
Quando o projeto de exames online começou, SIT (System Integration Testing) foi feito e o código foi promovido para um ambiente UAT onde o segundo ciclo de teste foi feito. Resultado: todos os defeitos de alta prioridade foram capturados e resolvidos. A compilação era estável antes do lançamento go-live.
# 3. Sem Scrum Master:
O Scrum Master é responsável por garantir que uma equipe viva de acordo com os valores e práticas do Scrum. O Scrum Master é considerado um treinador para a equipe, ajudando-a a fazer o melhor trabalho possível. O Scrum Master também pode ser pensado como um proprietário do processo Pela equipa.
A equipe de registros online foi formada sem um Scrum Master. A importância de ter um Scrum Master dedicado não foi considerada importante. Isso resultou em muitos problemas que não foram resolvidos a tempo e, por sua vez, o tempo para terminar o projeto frequentemente ultrapassava o prazo.
No entanto, um Scrum Master dedicado estava envolvido no projeto de exames online. Os problemas e desafios do projeto foram atendidos pelo Scrum Master. Os relatórios do projeto / sprint foram preparados e a equipe pôde ver seu progresso.
Além disso, reuniões de planejamento de sprint adequadas e reuniões de retrospectiva de sprint ocorreram para cada sprint, o que melhorou o desempenho da equipe. A equipe estava apenas se concentrando em seu trabalho e completando suas tarefas designadas para aquele sprint. Todas as tarefas de limpeza adicionais foram feitas pelo Scrum Master.
# 4. Convertendo documentos do projeto para o backlog do produto:
Os documentos iniciais do projeto que são preparados em um modelo em cascata são especificações de requisitos de negócios (BRS), design de alto nível, design funcional, etc. Esses documentos precisam ser transformados em um backlog de produto para executar os estágios de codificação, teste e implementação no modo ágil. Este é um passo muito importante.
é a chave de rede igual à senha
O backlog do produto é o ponto de partida de um projeto ágil. O backlog do produto é uma lista priorizada de requisitos mantidos para um produto. Consiste em recursos, correções de bugs, requisitos não funcionais, etc. É um documento em crescimento que fica maior e melhor com base no feedback do cliente, requisitos em mudança, etc.
Sendo o primeiro artefato de qualquer projeto, é mais importante listar os requisitos e atribuir-lhes prioridades. A conversão de documentos de projeto em cascata em lista de pendências de produto é uma grande tarefa em si mesma e requer brainstorming de toda a equipe junto com o cliente / parte interessada.
Uma vez que todos os requisitos são listados e acordados pelo cliente, a próxima tarefa é priorizá-los a fim de selecioná-los nos sprints.
# 5. Matriz de rastreabilidade:
Outro artefato importante que geralmente é mantido no modelo em cascata é a matriz de rastreabilidade. Portanto, para garantir que nenhum requisito seja omitido; uma matriz de rastreabilidade também deve ser projetada e mantida . Normalmente, no Agile, essa matriz não é projetada.
Esta é uma prática recomendada em qualquer projeto. Uma matriz de rastreabilidade deve ser preparada paralelamente à carteira de produtos. E deve ser verificado em relação aos casos de teste executados durante o teste de aceitação do usuário / teste de ponta a ponta (este estágio é explicado no próximo ponto). Mesmo se algum requisito for omitido, ele pode ser facilmente incorporado mesmo nos estágios finais de desenvolvimento, pois o ágil fornece flexibilidade e adaptabilidade extras.
Depois que o projeto de inscrições online entrou no ar, o aplicativo foi acessado pelos usuários finais (alunos que desejavam se inscrever). Eles enfrentaram muitos problemas no aplicativo. Isso resultou em muitos tíquetes levantados para a equipe de suporte à produção. Os tickets levantados podem ser classificados como incidentes, problemas ou mudanças. Muitos problemas foram resolvidos, antecipando que o aplicativo se tornará estável. Mas, mesmo assim, mais de uma dúzia de solicitações de mudança / melhorias foram planejadas nas versões subsequentes. Essas melhorias foram feitas para estabilizar o aplicativo e melhorar a experiência do usuário final.
Portanto, no final das contas, o custo do projeto disparou várias vezes. Portanto, se a transição de um projeto não for adequada para o ágil, o orçamento poderá ser excedido. Isso é muito necessário para planejar uma transição completa de um projeto para o Agile. Além disso, o planejamento deve ser feito na medida em que o projeto precisa para ser executado no modo ágil. Modelos híbridos adequados devem ser projetados para um projeto específico.
Antes do início do projeto de Entrada para o Exame, esse aspecto foi bem cuidado. Um modelo híbrido foi pensado e foi decidido que a fase de análise de requisitos e a fase de design de alto nível seriam executadas no modelo em cascata e o restante das etapas em um modelo ágil.
O modelo híbrido adotado pode ser representado pictoricamente conforme abaixo:
Conclusão:
É evidente que tanto o modelo Waterfall quanto o modelo Agile têm suas próprias desvantagens. Portanto, é bastante realista optar por um modelo híbrido, que é uma abordagem para aproveitando o melhor dos dois mundos.
O aspecto mais importante do início de qualquer projeto é decidir o modelo que a equipe vai adotar. Isso requer um planejamento extensivo. Fatores como orçamento, tempo, utilização de recursos, complexidade dos requisitos, etc. devem ser considerados na adoção de um modelo de software.
O modelo híbrido ainda está em um estágio inicial. À medida que mais e mais empresas o adotarem, aprenderemos mais sobre esse conceito.
O manifesto Agile nos pede para valorizar:
- Indivíduos e interações sobre processos e ferramentas
- Software de trabalho sobre documentação abrangente
- Colaboração do cliente sobre negociação de contrato
- Respondendo à mudança sobre seguir um plano
Já o modelo híbrido não adere a 100%. Isso sugere que todos os aspectos são de igual importância. Cabe aos clientes / gerentes de projeto decidir quais aspectos valorizar mais e quais aspectos não têm valor.
Sobre o autor: Este é um artigo convidado de Harshpal Singh. Ele tem mais de 7 anos de experiência em manual, banco de dados, automação e teste de desempenho e atualmente trabalha como líder de equipe em uma multinacional líder. Ele trabalhou em muitos projetos de controle de qualidade seguindo os modelos de desenvolvimento Waterfall, Agile e híbridos.
Você tem alguma experiência de trabalho neste modelo híbrido de desenvolvimento e teste? Vamos discutir nos comentários.
Leitura recomendada
- Agile Vs Waterfall: Qual a melhor metodologia para seu projeto?
- O que é SDLC Waterfall Model?
- Revisão da ferramenta de gerenciamento de teste Zephyr Enterprise - Como usar ativos de modelo em cascata na ferramenta ágil
- Modelo espiral - O que é modelo espiral SDLC?
- 4 etapas para desenvolver a mentalidade de teste ágil para uma transição bem-sucedida para o processo ágil
- Tutorial do JIRA Agile: Como usar o JIRA com eficácia para gerenciar projetos Agile
- Fases, metodologias, processos e modelos SDLC (ciclo de vida de desenvolvimento de software)
- Manifesto Agile: Compreendendo os Valores e Princípios do Agile