Antes de responder diretamente à pergunta do título, é sempre bom deixar claro qual é o objetivo final do projeto que você deseja alcançar
Como ficará o produto daqui a um mês, meio ano e um ano. Mas descreva-o agora. Isso lhe dará alguma perspectiva e definirá as expectativas básicas sobre o nível de previsibilidade, flexibilidade, agilidade, velocidade de lançamento no mercado e fixação de custos no tempo.
Sim, hoje montar projetos em cascata parece uma ideia ridícula. Principalmente se já foi provado inúmeras vezes que se você deseja reagir rapidamente às mudanças nos mercados, não tem outra opção a não ser ser ágil. Mas se o seu objetivo é entregar um produto daqui a um ano com funcionalidades já bastante claras e restritas desde o início, e você tem equipes de pessoas sem experiência anterior com metodologia ágil, então com certeza, seja conservador e vá em cascata.
Nem todos os casos são tão simples de concluir. Vamos dar uma olhada em como avaliar melhor qual metodologia é melhor para o seu projeto.
últimas postagens
Qual é a aparência de uma cachoeira?
Em vez de entrar em algumas definições que todos já conhecem há algumas décadas, o resultado prático de um projeto em cascata geralmente é assim:
Todo esse processo pode levar de alguns meses a alguns anos. Como você pode prever, os usuários verão os resultados somente no final desse processo. Então, depois de uma longa espera, chega o momento da verdade (ou do fracasso).
Se algo mudar durante esse longo período e o produto final parecer um pouco diferente, essa é uma situação que você chama de solicitação de mudança. O projeto deve ser reaberto, retrabalhado e reaprovado. Prolonga todo o cronograma em outra parte. Cada mudança requer o reinício de todo o processo anterior.
Por outro lado, você tem uma definição de fase sólida, um orçamento fixo para cada fase e um tempo fixo. Mesmo que você tenha que esperar muito para obter o primeiro resultado, se as chances de mudanças ao longo do caminho forem mínimas, ainda pode ser uma opção preferível.
Qual é a aparência de um ágil?
Agora, é assim que o projeto pode operar em uma configuração Agile:
Este é apenas um rápido resumo, mas a diferença para a cachoeira já está clara. Feedback rápido, adaptação, reflexão das necessidades atuais que mudam com o tempo, primeiro produto valioso entregue no menor tempo possível. Todas essas são propriedades que você não tem chance de obter em um projeto em cascata.
Ágil vs. Cascata
Um projeto não pode ser bem-sucedido sem uma metodologia de gerenciamento de projetos adequada. Isso significa definir processos, métricas, avaliações e formas gerais de trabalho das equipes que formam o projeto.
As equipes precisam saber quais regras seguir, o que definirá os marcos, quando alcançá-los e como medir e avaliar o sucesso. Ao mesmo tempo, as partes interessadas precisam entender o que esperar do projeto e quando poderão ver os primeiros resultados do trabalho.
Com um pouco de generalização, podemos dizer que os projetos que operam em ambientes de nuvem têm uma probabilidade significativamente maior de se inclinarem para metodologias ágeis (ou deveriam, pelo menos). Projetos que trabalham com infraestruturas locais ainda preferem processos em cascata. Isto surge como uma conclusão natural.
O ambiente de nuvem é construído desde o início para se adequar ao ambiente em constante mudança. Adapta-se o mais rápido possível (com vários serviços “elásticos”) à nova realidade. O ambiente local geralmente é predefinido no início. É difícil mudar isso ao longo do tempo, por isso as equipes trabalham com variáveis determinísticas durante toda a duração do projeto.
Resumo da abordagem Ágil vs. Cascata.
RecursoAbordagem em cascataAbordagem ágilTratamento de requisitos do usuárioA mudança é tratada como um processo formal (solicitação de mudança). O trabalho pode precisar ser refeito, impactando custos e cronogramas.Adota as mudanças como parte do processo padrão, sem impacto significativo nos custos ou cronogramas.Planejamento e escopo do projetoDefine o escopo no início e segue-o. As fases são rígidas e seguem o plano original. Tem uma visão clara do produto final, mas permite alterações. O trabalho é organizado em sprints com flexibilidade na forma como as tarefas são concluídas. Acompanhamento do progresso do projeto Acompanha o progresso em cada fase. Atrasos em uma fase podem afetar todo o cronograma do projeto. Acompanha o progresso por meio de sessões de demonstração no final de cada sprint. Concentra-se no produto viável.Colaboração em equipePessoas diferentes em diferentes fases do projeto, interação limitada.Equipe multifuncional com comunicação constante entre os membros da equipe e as partes interessadas.Gerenciamento de riscosAcompanhamento do status com base no progresso da fase. Responde aos riscos retrospectivamente enquanto adere ao plano. Concentra-se na resolução proativa de dependências entre equipes e atividades. Adapta o plano para eliminar os riscos projetados.Quadro de implementaçãoMetodologia tradicional.Requer práticas de transformação para se adaptar à abordagem ágil. Envolve mudança de hábitos e mentalidades.
Esta escolha definirá, no entanto, vários aspectos das propriedades de execução do projeto.
#1. Requisitos do projeto e gerenciamento de mudanças
Um dos aspectos mais importantes que definem a escolha é como serão atendidos os requisitos do usuário. E também, qual é o processo se for necessária mais tarde uma alteração nos requisitos já acordados?
Com um projeto em cascata, todos os requisitos são definidos e aprovados pelas partes interessadas no início; se surgir alguma alteração nesse estado, o projeto a trata como uma Solicitação de Mudança. Tem que ser novamente validado, acordado e confirmado.
Qualquer trabalho já realizado até aquele momento deve ser revisitado e reiniciado. Os custos precisam ser reajustados (pois se trata de trabalho adicional não coberto pelo contrato original). Na pior das hipóteses, até mesmo todo o cronograma do projeto precisa ser prolongado.
Com uma configuração ágil, as mudanças são bem-vindas. Você trata as mudanças como uma atividade diária padrão. Você concorda com as partes interessadas (provavelmente como resultado da última demonstração do sprint) que as mudanças são cruciais para manter a visão do projeto. Em seguida, você agenda essas alterações imediatamente para os próximos sprints.
O conteúdo anterior mudará com isso, e as equipes continuarão trabalhando com novos requisitos a partir desse dia. Não há perda de tempo ou custos. Você simplesmente se adapta imediatamente à nova realidade e substitui o plano original pelo novo. Não há nenhuma necessidade de gerenciamento especial de Solicitações de Mudança. Tudo faz parte das iniciativas de planejamento do sprint.
#2. Planejamento e Escopo do Projeto
Como seria de esperar, o projeto em cascata define e corrige todo o escopo no início. Você gera o plano do projeto em torno deste escopo. Em seguida, você divide a duração do projeto em fases específicas (normalmente análise, design, desenvolvimento, teste, implantação, suporte e manutenção) e fixa as equipes e os recursos em torno dessas fases. Durante a maior parte do cronograma do projeto, seu principal objetivo é seguir o plano original em termos de custos e prazos, tanto quanto possível.
Um projeto ágil tem uma visão do produto final em vez de um plano rígido. O estado final é claro, mas o caminho para chegar a esse estado pode mudar livremente. Além disso, o cronograma do projeto ainda é definido e acordado com base em uma estimativa preliminar da demanda e da experiência de carga de capacidade das equipes que trabalham no projeto. O plano não tem fases separadas. Em vez disso, cada sprint é uma pequena fase que contém todas as atividades que a equipe precisa para lançar com sucesso o produto incremental.
Em resumo, o projeto cascata trata as mudanças como uma complicação a ser resolvida (e uma oportunidade para os fornecedores adquirirem dinheiro adicional). Em contraste, o projeto ágil trata a mudança como um negócio normal, sem consequências adicionais (além de um produto final mais adequado).
#3. Acompanhamento do progresso do projeto
O projeto cascata acompanha o progresso do plano dentro das fases do projeto. A fase de design não pode começar antes da fase de análise ser concluída, o teste não pode começar antes de toda a construção ser concluída e assim por diante.
Se alguma das fases atrasar, isso afetará o andamento das demais fases do projeto. Por isso é importante acompanhar as atividades de cada fase e garantir que elas progridam linearmente ao longo do tempo. Caso contrário, você aumenta o risco de atrasar aquela fase específica e, consequentemente, todo o projeto.
O projeto ágil acompanha o progresso, principalmente com sessões de demonstração acontecendo ao final de cada sprint. O produto viável é a principal medida de progresso. Naturalmente, você deseja garantir que cada sprint termine com o conteúdo completo do sprint. Nenhuma ou apenas uma história mínima é transportada para os próximos sprints.
Em última análise, é muito mais fácil ver o progresso geral do projeto se você puder testar diretamente o incremento atual do produto e retornar imediatamente à equipe com feedback muito concreto.
#4. Colaboração em equipe
Trata-se de atividades estritamente separadas de cascata versus colaboração contínua com todas as partes de uma equipe ágil.
Um projeto em cascata geralmente tem pessoas diferentes trabalhando em diferentes fases do projeto. Eles podem transbordar uns dos outros até certo ponto, mas ainda são grupos de pessoas diferentes. Quase os silos, pode-se dizer.
A definição de equipe ágil está na comunicação e no valor. Deve também ser uma equipe multifuncional capaz de executar todas as atividades do ciclo de vida do produto. Silos das equipes é algo que você não quer que exista. A comunicação constante entre a equipe e as partes interessadas externas é uma definição básica de um projeto ágil bem-sucedido.
#5. Gerenciamento de riscos
Obviamente, você deseja ter um processo para rastrear quaisquer riscos, problemas ou qualquer tipo de obstáculo que o projeto possa trazer durante seu cronograma.
No caso de um projeto em cascata, isso se traduz no acompanhamento do status da fase atual do projeto. O relatório de status padrão, semelhante a um semáforo, mostrará verde (tudo está OK e de acordo com o plano), amarelo (alguns problemas importantes estão em vigor, mas ainda há uma compreensão clara de como resolvê-los) ou vermelho (significando o projeto tem sérios problemas que podem impactar os cronogramas ou orçamento originais).
O projeto ágil também é diferente aqui. Você realmente não acompanha o progresso em direção à meta. Em vez disso, você resolve dependências entre diferentes equipes e tipos de atividades. O objetivo é garantir que nenhuma equipe fique esperando por outra equipe com as atividades em andamento.
Naturalmente, podem aparecer riscos, mas então a solução deve mudar o plano daqui para frente, para que o risco desapareça, em vez de descobrir a solução para o risco, preservando ao mesmo tempo o plano original.
Ou seja, uma configuração ágil do projeto utiliza todas as formas possíveis para alterar o plano para não enfrentar os riscos projetados, o que significa que a gestão de riscos é proativa. No caso de um projeto em cascata, você responde aos riscos retrospectivamente e tenta resolvê-los no menor tempo possível, mantendo o plano original.
#6. Estrutura de Implementação
A tática de implementação para projetos em cascata é obviamente menos problemática do que para projetos ágeis. Normalmente, a metodologia em cascata é o status quo que as pessoas já praticam há muitos anos.
Por outro lado, os projetos exigem práticas de transformação ágil para mudar seus hábitos, mentalidade e formas de trabalhar. É um processo difícil e muitas vezes também bastante duradouro. As empresas estão investindo quantidades significativas de tempo e recursos para ensinar as pessoas a se adaptarem a processos ágeis.
Os benefícios na forma de rápida adaptação às novas necessidades do cliente são significativos, mas mudar a mentalidade das pessoas e o ambiente de trabalho em geral é a parte mais difícil.
Na maioria das vezes, é também a única forma de se manter competente no mercado, pelo que as compensações são recompensadas com grande sucesso para quem tem sucesso.
Palavras Finais
Vamos afirmar isso claramente. A menos que você tenha um cliente muito conservador e sem grande motivação para entregar resultados rápidos à produção (por qualquer motivo que ele possa ter para isso), sua melhor aposta é começar a modelar as equipes ágeis desde o início. Isto é literalmente um acéfalo no mundo de hoje. Isto é verdade mesmo no caso de configuração de sistemas locais tradicionais. Principalmente se a equipe for nova ou estiver começando do zero com pessoas originais, ainda faz sentido transformar os processos para alinhá-los às metodologias ágeis.
Dito isto, ainda vejo projetos em que as pessoas simplesmente se recusam a seguir esse tipo de processo ágil ou qualquer outra configuração que não seja uma organização de trabalho estritamente específica para cada fase. Eles seguem o caminho usual de contratação da obra por prazo e orçamento específicos. Então, eles esperam que o projeto siga esta configuração sem desvios do plano e do dinheiro (com vários resultados, geralmente não bons).
Esta é uma decisão que eles têm o direito de tomar, mas em última análise, com tal decisão, eles também decidem ficar no passado. Pode funcionar para eles por algum tempo, mas é apenas uma questão de tempo até que não funcione mais.
A seguir, confira o artigo detalhado sobre o ciclo de vida dos testes Agile.