Gestão de projetos ágil versus cascata

Os usuários iniciais do desenvolvimento ágil eram, em geral, equipes pequenas e independentes que trabalhavam em projetos pequenos e independentes. Eles provaram que o modelo ágil pode funcionar para a alegria e melhoria de fabricantes de software ao redor do mundo. Acontece que o modelo de desenvolvimento em cascata não era tão eficaz para o desenvolvimento de software quanto a gestão de projetos ágil foi para a maioria das equipes

A popularidade da gestão de projetos ágil fez com que mais organizações escalassem a agilidade além de equipes ou projetos individuais e a aplicassem a programas inteiros. O método ágil se espalhou para além das equipes de desenvolvimento e chegou às de TI, marketing, desenvolvimento comercial, entre outras.

A gestão de projetos ágil é uma abordagem iterativa para a entrega de projetos, com foco em versões contínuas que incorporam os feedbacks dos clientes. A capacidade de se ajustar a cada iteração impulsiona a velocidade e flexibilidade. Essa abordagem é diferente de uma abordagem de gestão de projetos em cascata, linear, que segue um caminho predefinido com um limite para desvios.

Com os clientes e empresas atuais exigindo respostas e mudanças rápidas, a agilidade oferece a flexibilidade para ajustar e iterar durante o processo de desenvolvimento. A gestão de projetos ágil também é um pilar das práticas de DevOps, em que as equipes de desenvolvimento e operações trabalham em colaboração.

A abordagem de gestão de projetos em cascata envolve uma sequência de execução claramente definida com fases que avançam apenas quando a fase anterior recebe a aprovação final. Quando uma fase é concluída, pode ser difícil e caro voltar para uma etapa anterior. As equipes ágeis podem seguir uma sequência parecida, porém em avanços menores com ciclos de feedback periódicos.

A abordagem de gestão de projetos em cascata segue uma fórmula sequencial e linear. Ela funciona bem para trabalhos com processos recorrentes e previsíveis, mas pode deixar as equipes de desenvolvimento sem recursos e incapazes de superar a concorrência.

A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.

Abaixo, vemos uma ilustração de um projeto em cascata padrão com blocos de tempo de segmentação rígida. Este fato cria uma mentalidade de "use ou perca" que incentiva os desenvolvedores, proprietários de produtos e partes interessadas a solicitar o máximo de tempo possível em cada janela de tempo, uma vez que pode não haver oportunidade de repetição no futuro. Em geral, as equipes que usam a cascata tentam controlar o desvio de escopo com o "controle de mudanças", em que todos concordam que o contrato original não será alterado.

O modelo em cascata pode agravar alguns dos desafios conhecidos no desenvolvimento de produtos:

• Bloqueadores e gerenciamento de dependências: estilos de gestão de projetos tradicionais muitas vezes criam "caminhos críticos", nos quais o projeto não pode avançar até que um item bloqueador seja resolvido.
• Dificuldade em conseguir feedback dos usuários e validação dos produtos: para piorar a situação, o cliente final não consegue interagir com o produto até ele estar totalmente concluído. Assim, problemas importantes no design do produto e do código só são descobertos depois do lançamento.

As vantagens da cascata

• Requer menos coordenação devido a processos sequenciais em fases definidas com clareza
• Uma fase clara do projeto ajuda a definir com clareza as dependências do trabalho.
• O custo do projeto pode ser estimado após a definição dos requisitos
• Melhor foco na documentação de projetos e requisitos
• A fase de design é mais metódica e estruturada antes de qualquer software ser escrito

As desvantagens da cascata

• Mais difícil de separar e compartilhar o trabalho por causa de equipes de sequências de fases mais rígidas e mais especializadas
• Risco de perda de tempo devido a atrasos e contratempos durante as transições de fase
• Requisitos adicionais de contratação para atender equipes de fase especializadas, enquanto a agilidade incentiva uma composição mais multifuncional da equipe.
• Sobrecarga de comunicação extra durante a transferência de tarefas entre transições de fase
• A propriedade e o engajamento do produto podem não ser tão fortes quando comparados à agilidade, pois o foco é trazido para a fase atual.

O método ágil foi adotado primeiro por equipes de software, que passaram de uma abordagem de cascata sequencial tradicional para um método que une o feedback e o ajuste consistentes ao longo do ciclo de vida do desenvolvimento.

A gestão de projetos ágil traz uma abordagem iterativa ao desenvolvimento, criando várias etapas incrementais com intervalos periódicos de feedback. Ela estimula a flexibilidade, já que a equipe pode se adaptar ao longo do processo de desenvolvimento do produto em vez de ficar restrita a um caminho linear. Assim é possível lançar versões periódicas de alto impacto que permitem que as equipes obtenham uma série de vitórias ao longo do tempo.

Versões iterativas abrem diversas oportunidades para que a equipe:

• se adapte às novas situações, desde requisitos recém-descobertos até um bloco de trabalho que estava travado.
• colete feedback das partes interessadas durante o processo e faça iterações responsivas sem o estresse com um prazo de entrega final.
• desenvolva relacionamentos e conexões entre as funções, o que facilita a conexão e a comunicação eficientes entre as pessoas.

O método ágil permite que as equipes sejam mais resilientes às mudanças que vão ocorrer durante um projeto.

Um benefício ainda maior é o compartilhamento de conjuntos de habilidades na equipe de software. Os conjuntos de habilidades sobrepostos da equipe adicionam flexibilidade ao trabalho em todas as partes da base de código da equipe. Desse modo, trabalho e tempo não são desperdiçados se a direção do projeto mudar. (Para saber mais, consulte o artigo sobre a criação de ótimas equipes ágeis).

• Um projeto ágil é segmentado em várias etapas incrementais que incluem intervalos periódicos de feedback.
• Um requisito de um projeto é segmentado em pedaços menores, que são priorizados por ordem de importância.
• Promove colaboração, principalmente com o cliente.
• Faz ajustes em intervalos regulares para garantir que as necessidades do cliente sejam atendidas.
• Integra o planejamento com a execução, o que permite a resposta efetiva da equipe aos novos requisitos.

As vantagens da gestão de projetos ágil

• Ciclos de feedback mais rápidos
• Identifica problemas com antecedência
• Maior potencial de satisfação do cliente
• O tempo de entrega para o mercado apresenta melhoras drásticas
• Melhor visibilidade / responsabilidade
• Equipes dedicadas geram melhor produtividade ao longo do tempo
• Priorização flexível focada na entrega de valor

As desvantagens da agilidade

• O caminho crítico e as dependências entre projetos podem não ter definições claras como na cascata
• Há um custo de curva de aprendizado organizacional
• A verdadeira execução ágil com um pipeline de implementação contínua tem muitas dependências técnicas e custos de engenharia para estabelecer

Pode ser desafiador passar a usar o método ágil, em especial quando uma equipe ou empresa está apegada a uma abordagem de gestão de projetos mais tradicional. Passar a usar práticas ágeis pode exigir uma série de mudanças no processo, ainda mais ao se adotar uma abordagem de DevOps, em que as equipes de desenvolvimento e operações trabalham em estreita colaboração para desenvolver e manter um software. Ao adotar princípios ágeis, a equipe e as partes interessadas devem usar dois conceitos importantes:

• O foco do proprietário do produto é otimizar o valor da produtividade da equipe. A equipe depende do proprietário do produto para priorizar o trabalho mais importante.
• A equipe de desenvolvimento só pode aceitar o trabalho que tem capacidade para realizar. O proprietário do produto não envia trabalho para a equipe ou compromete a equipe com prazos arbitrários. A equipe de desenvolvimento puxa o trabalho do backlog do programa à medida que consegue aceitar novos trabalhos.

Vamos explorar os mecanismos que os programas ágeis usam para organizar, executar e estruturar o trabalho de uma forma iterativa.

Um roteiro do produto mostra como um produto ou solução se desenvolve ao longo do tempo. Um roteiro no desenvolvimento ágil oferece um contexto importante que capacita as equipes a atingir metas incrementais e relacionadas ao projeto todo. Os roteiros são compostos por iniciativas, que são grandes áreas de funcionalidade, e incluem cronogramas que comunicam quando uma função vai ser disponibilizada. À medida que o trabalho avança e as equipes aprendem mais, o roteiro pode passar por mudanças para refletir as novas informações que chegaram — talvez de formas sutis e gerais. A meta é manter o roteiro focado nas condições atuais que impactam o projeto e nas metas a longo prazo para trabalhar com eficácia com as partes interessadas e responder ao cenário competitivo.

A seguir, apresentamos um roteiro simples para uma equipe de produto, com iniciativas nos boxes e cronogramas indicados pelos markers de marcos em vermelho.

Cada iniciativa no roteiro é dividida em um conjunto de requisitos. Os requisitos ágeis são descrições breves da funcionalidade exigida, em vez de documentos com 100 páginas associados a projetos tradicionais. Eles são desenvolvidos ao longo do tempo e usam o entendimento sobre o cliente e o produto desejado compartilhado pela equipe. Os requisitos ágeis permanecem enxutos enquanto todos na equipe desenvolvem um entendimento compartilhado por meio de colaboração e conversas contínuas. Apenas quando a implementação está para começar, eles serão pormenorizados.

O backlog define as prioridades para o programa ágil. A equipe inclui todos os itens de trabalho no backlog: funções novas, bugs, melhorias, tarefas técnicas e de arquitetura, etc. O proprietário do produto prioriza o trabalho no backlog para a equipe de engenharia. Então, a equipe de desenvolvimento usa a lista de pendências priorizada como fonte única da verdade para o que o trabalho precisa ser feito.

Equipes ágeis prosperam com métricas. Os limites do trabalho em andamento (WIP) mantêm a equipe e a empresa focadas na entrega dos trabalhos de prioridade mais alta. Os gráficos, como os de burndown e os de controle, ajudam a equipe a prever a frequência de entrega, e os diagramas de fluxo contínuo ajudam a identificar os obstáculos. Essas métricas e artefatos mantêm todos focados em grandes metas e aumentam a confiança na capacidade da equipe de entregar trabalho futuro.

Os processos ágeis não podem funcionar sem um nível elevado de confiança entre os membros da equipe; eles, portanto, criam essa confiança. É preciso sinceridade ao ter conversas difíceis sobre o que é certo para o programa e o produto. Como as conversas acontecem em intervalos regulares, ideias e preocupações são expressas com regularidade. Então os membros da equipe também devem confiar na capacidade (e disposição) do outro para executar as decisões tomadas durante as conversas.

A gestão de projetos ágil é uma abordagem inovadora não apenas para projetos de software, mas para projetos de todos os tipos. Ao oferecer flexibilidade na resposta a mudanças durante o ciclo de vida do desenvolvimento, o método ágil permite que as equipes lancem produtos de melhor qualidade que atendam às necessidades dos clientes. O método ágil capacita equipes, desenvolve o senso de responsabilização e incentiva a inovação, ao mesmo tempo que promove a melhoria contínua. O método ágil oferece a capacidade de responder a mudanças sem sair dos trilhos. É uma capacidade ótima para qualquer programa.

Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.