O que é o gerenciamento de programa ágil?

O gerenciamento ágil de programas é uma abordagem voltada à condução de vários projetos inter-relacionados, com base em princípios ágeis como flexibilidade, colaboração, desenvolvimento iterativo, foco no feedback do cliente e melhoria contínua.

O ágil é uma filosofia baseada em princípios, mais do que uma metodologia específica. No entanto, existem metodologias ágeis consolidadas que costumam compor o gerenciamento ágil de programas, como Scrum, programação extrema (XP) e Kanban. O gerenciamento ágil de programas surgiu na indústria de software, criado por e para profissionais da área, com o objetivo de entregar mais valor ao cliente de forma mais rápida. Hoje, ele se aplica a muitos outros setores.

O gerenciamento ágil de programas normalmente abrange vários projetos inter-relacionados. Projetos individuais podem ser conduzidos com frameworks ágeis, mas o gerenciamento ágil de programas reúne vários projetos em um conjunto coeso ao longo de todo o ciclo de vida. Em um nível mais amplo, vários programas e seus respectivos projetos podem ser organizados dentro de uma estratégia abrangente de gerenciamento de portfólio.

O gerenciamento ágil de projetos se concentra em um projeto específico, cuidando dos objetivos, prazos, recursos e equipes ligados a ele. O gerenciamento ágil de programas supervisiona um conjunto de projetos relacionados e a estratégia que os alinha a metas organizacionais mais amplas. Essas duas áreas compartilham várias funções, mas diferem em escopo: os gerentes de programas ágeis atuam de forma mais ampla na estratégia do programa, no gerenciamento de riscos, na comunicação com stakeholders e em outras frentes.

Uma forma rápida e simplificada de entender é que o gerenciamento de projetos foca mais na execução tática e pontual de um projeto específico. Já o gerenciamento de programas adota uma abordagem mais estratégica para coordenar o sucesso integrado de projetos distintos sob sua responsabilidade.

O gerenciamento de projetos, como disciplina, começou a se consolidar nos Estados Unidos na década de 1950. Na década de 1990, métodos conhecidos como “cascata” foram formalizados, exigindo que cada fase do projeto fosse concluída antes de a equipe avançar para a próxima. Com o crescimento da importância e da complexidade do software, o gerenciamento de projetos tradicional e os métodos em cascata se mostraram pesados e pouco eficazes para projetos ágeis e sujeitos a mudanças frequentes.

Em 2001, um grupo de desenvolvedores de software criou o Manifesto Ágil para o gerenciamento ágil de projetos, com quatro valores centrais e 12 princípios. Os principais valores são:

• Indivíduos e interações mais do que processos e ferramentas
  
  
• Software trabalhando com documentação abrangente
  
  
• Colaboração do cliente mais do que negociação de contratos
  
  
• Respondendo à mudança em vez de seguir um plano

Os valores preferenciais não exigem o abandono dos que não são priorizados. Por exemplo, a filosofia ágil não proíbe o uso de um plano, mas dá mais ênfase à resposta e à preparação para mudanças inevitáveis.

Esses princípios ágeis se tornaram cada vez mais populares no desenvolvimento de software, mas a filosofia vai muito além da aplicação em projetos de software ágil. Hoje, os princípios ágeis são aplicados em diversos setores, como moda, biotecnologia e governo.

O que diferencia a abordagem ágil de métodos anteriores como o cascata é que, desde o início, ela foi projetada para ser iterativa, colaborativa e flexível. Em um sistema de gerenciamento ágil de programas, os projetos são criados rapidamente e passam por avaliações, discussões e ajustes frequentes conforme o retorno da equipe ou do cliente. Desde o início, parte-se do princípio de que planos e abordagens precisarão mudar, sem apego rígido ao planejamento inicial. Os membros individuais da equipe têm poder para se manifestar, sem uma hierarquia tão firme como em outras abordagens.

Como o gerenciamento de programas ágeis é uma filosofia e não uma metodologia concreta, as especificidades das práticas ágeis podem variar drasticamente de organização para organização, ou de programa para programa. Mesmo com variações, há aspectos que costumam estar presentes no gerenciamento ágil de programas.

O gerenciamento ágil de programas envolve diversos projetos individuais; tanto o conjunto quanto cada projeto podem seguir um framework ágil. O gerenciamento ágil de programas adota uma visão ampla e integrada do conjunto de projetos. Geralmente, ele abrange elementos ausentes na gestão de projetos isolados, como orçamento, estratégia geral e análise de longo prazo.

Responder rapidamente às mudanças é um princípio fundamental da filosofia ágil. Por isso, o gerenciamento ágil de programas encara a mudança como uma chance de redirecionar o curso e implementar melhorias em tempo real que gerem valor ao cliente. Dividir os projetos em partes menores permite que as organizações sejam mais flexíveis e reajam com mais agilidade.

Um dos aspectos centrais do gerenciamento ágil de programas é a abordagem iterativa. Os projetos que compõem o programa passam por diversas versões, nas quais as equipes de desenvolvimento discutem e aprimoram os resultados continuamente. É fundamental entregar continuamente resultados funcionais, seja o projeto completo ou apenas uma parte dele. Também é importante refinar o produto a cada iteração, com base no feedback do cliente, nos KPIs e nas exigências que mudam ao longo do tempo.

A priorização ágil valoriza a conversa presencial em vez de longas trocas de e-mails ou outras comunicações escritas. Enquanto uma troca de e-mails pode levar horas, dias ou até semanas por conta de atrasos ou mensagens perdidas, uma conversa presencial resolve a mesma questão em poucos minutos.

O gerenciamento ágil de programas, por ter uma visão ampla do programa, precisa manter o foco na eficiência e na eliminação de elementos desnecessários ou complicados. A documentação serve como um meio, não como um fim, e deve conter apenas o que for necessário.

Honestidade e franqueza são fundamentais para o sucesso de um programa ágil. As conversas devem permitir que todos os membros da equipe se manifestem. Nessa abordagem de gerenciamento, a voz de todos é válida e ouvida.

Ao mesmo tempo, deve ser aceitável filtrar ideias impraticáveis sem que o progenitor da ideia se sinta desencorajado a se manifestar no futuro. O sucesso das “retrospectivas” (ou “retros”, que são avaliações feitas após o projeto para coletar feedback) também depende da transparência da equipe.

O gerenciamento ágil de programas, por ser uma filosofia, não exige a adoção de nenhum framework específico. Mas muitos frameworks de gerenciamento de projetos, como Scrum e Kanban, passaram a ser fortemente ligados à filosofia ágil. Veja alguns dos frameworks mais populares.

Scrum é um framework para trabalho colaborativo de projeto em equipe. Embora pareça uma sigla, o nome vem do rúgbi, onde o “scrum” é uma formação em que os jogadores se unem fisicamente para avançar juntos contra o time adversário. É uma espécie de ataque de cavalaria, sem os cavalos.

No ágil, uma equipe Scrum é composta por três papéis:

• Gerente de projeto: atua como elo entre a equipe Scrum e os stakeholders, que podem ser usuários, clientes ou a empresa controladora. O gerente de projeto comunica fatores externos como orçamento, equipe e feedback à equipe Scrum, além de atualizar os stakeholders sobre o progresso do time.
  
  
• Scrum master: não atua como um “chefe” tradicional, mas sim como um orientador da metodologia Scrum, promovendo orientação, comunicação e resolução de problemas. Os Scrum masters normalmente não são responsáveis por contratar e demitir.
  
  
• Desenvolvedores ou membros da equipe: esse termo pode variar em contextos fora da área de software, por exemplo. Seja chamado de desenvolvedor, membro da equipe ou colaborador, esse papel não tem hierarquia. O ideal é que a equipe tenha entre três e nove membros; grupos maiores costumam ser mais difíceis de orientar para o scrum master. Isso também inclui equipes auto-organizadas, nas quais os próprios integrantes definem quem participa e o que é necessário para alcançar os objetivos, sem depender de planejamento excessivo da gestão.

O Scrum possui alguns conceitos específicos que o diferenciam de outros modelos organizacionais baseados em equipe. O backlog do produto é um repositório com todas as tarefas, ideias, requisitos, entregas e recursos que a equipe pode precisar durante o Scrum. A equipe pode (e realmente deve) atualizar e monitorar esse repositório de forma contínua para garantir sua eficiência e integridade.

No Scrum, o trabalho é dividido em sprints, que geralmente duram de uma a quatro semanas. Durante o sprint, os membros da equipe trabalham para alcançar uma meta específica e entregável. Essa meta pode ser um modelo funcional, um mockup, um protótipo ou até mesmo uma função ou elemento do produto ou solução final.

Durante o sprint, os membros da equipe se reúnem diariamente em um “daily scrum”, também conhecido como “stand-up”. Segundo os princípios do Scrum, essas reuniões devem ser extremamente objetivas e de alto nível. Com no máximo 15 minutos de duração, o daily scrum é um momento em que os membros da equipe informam brevemente seu progresso e eventuais obstáculos, com o mínimo de detalhes possível. Em alguns casos, certos membros da equipe podem se reunir depois do daily scrum para aprofundar algum ponto levantado na reunião.

Ao fim de um sprint, todos os envolvidos, membros da equipe, scrum master e gerente de projeto, se reúnem para revisar e discutir o que foi desenvolvido. O gerente de projeto pode apresentar mudanças solicitadas por stakeholders, como usuários ou a organização principal, e, após a discussão, a equipe pode incluir essas alterações no próximo sprint.

O Kanban é um sistema visual para gerenciar e acompanhar projetos. Os quadros Kanban mostram visualmente o progresso da equipe em um projeto, com as subtarefas distribuídas em categorias específicas. Essas categorias normalmente incluem:

• Backlog: todas as tarefas que ainda não foram migradas para outra categoria; no início do projeto, todas as tarefas estarão no backlog
  
  
• Processando: tarefas em andamento
  
  
• Em avaliação: tarefas para as quais o estágio inicial de conclusão foi alcançado, que está sendo avaliado por outra pessoa
  
  
• Concluídas: Tarefas que foram concluídas.

“Kanban” vem da junção das palavras japonesas para sinal (“kan”) e quadro (“ban”), formando algo próximo de “quadro de avisos” ou “painel de mensagens”. O Kanban pode ser criado em formas analógicas e digitais. Na versão analógica, costuma-se usar Post-its para representar tarefas individuais, que são movidos entre colunas conforme forem concluídas.

Também existem várias versões digitais dos quadros Kanban, especialmente úteis para equipes de projeto em que alguns ou todos os membros trabalham remotamente.

A programação extrema, ou XP, é uma metodologia ágil criada originalmente para engenheiros de software, com foco em melhorar a qualidade, a agilidade e a velocidade do desenvolvimento. O conceito central segue a lógica ágil, mas com ciclos ainda menores e prazos curtos voltados à criação de funcionalidades testáveis.

No XP, cada elemento individual do projeto é testado repetidamente, às vezes até submetido a testes que buscam causar falhas. Esses elementos individuais são então testados em conjunto, geralmente semanalmente, para garantir a máxima compatibilidade.

Na comunicação, o XP se baseia na simplicidade ao extremo. A documentação deve ser a mais enxuta possível para que os demais membros da equipe compreendam, usando linguagem, conceitos e metáforas simples. Essa simplicidade também vale para o design das tarefas; projetos XP geralmente não consideram funcionalidades extras futuras, vendo-as como supérfluas para o lançamento. Isso às vezes é conhecido como YAGNI, ou You Aren't Gonna Need It (Você não vai precisar disso).

O XP não é adequado para todos os projetos; é importante utilizá-lo apenas em projetos que não exigem escalabilidade ou grandes revisões.

SAFe é um conjunto de princípios e práticas fundamentadas no método de desenvolvimento lean-agile, DevOps e no pensamento sistêmico. O Scaled Agile Framework (SAFe) foi criado (como o nome indica) para escalar frameworks ágeis em grandes organizações, alinhando múltiplos projetos e garantindo a colaboração entre áreas e a interoperabilidade. Isso é feito principalmente por meio de uma estrutura que inclui roteiros de Planning Increment (PI).

As tarefas nesses roteiros recebem diferentes nomes para facilitar sua identificação de uma visão geral. Essas designações incluem “enablers” (tarefas dependentes de outras), “epics” (iniciativas maiores para uma necessidade específica do negócio) e “stories” (funcionalidades desejadas, do ponto de vista do usuário ou do negócio).

A metodologia ágil disciplinada é considerada um conjunto de princípios, promessas e diretrizes em vez de uma metodologia completa. É uma abordagem leve, simples e híbrida para a gestão de programas, com muita liberdade para os membros individuais da equipe.

Alguns frameworks ágeis, como Scrum e SAFe, trazem metodologias e etapas prescritas. Essa especificidade pode ser vantajosa para alguns projetos, mas o Disciplined Agile (DA) busca oferecer mais liberdade e agilidade aos membros da equipe. O conceito básico permite que cada pessoa selecione os conceitos e frameworks ideais para seu fluxo de trabalho específico. O Scrum pode funcionar para alguns, mas não para outros, especialmente em programas maiores. O DA coloca muito poder nas mãos dos indivíduos, o que o torna mais adequado para projetos com membros de equipe altamente qualificados, independentes e já familiarizados com conceitos ágeis básicos.

O Large-Scale Scrum, conhecido como LeSS, é uma versão do Scrum criada especialmente para equipes maiores, ou grupos de equipes, além do que o Scrum tradicional suporta. Embora o LeSS mantenha sprints, reuniões diárias e revisões, ele adiciona algumas diretrizes para garantir que equipes maiores atinjam seus objetivos escalando o ágil sem perder sua essência.

No LeSS, todas as equipes trabalham em um sprint comum, diferente do gerenciamento ágil de projetos, onde cada time planeja seu sprint individual. Existe também um backlog compartilhado, que reúne todas as tarefas necessárias para todo o programa. O planejamento do sprint inclui dois tipos de reuniões: uma geral para todas as equipes e reuniões específicas de planejamento para cada equipe.

O Nexus é um framework semelhante ao Scrum, com algumas adições, subtrações e alterações. A principal diferença é a inclusão da Equipe de Integração Nexus, um grupo separado de membros da equipe que atuam como orientadores. O NIT geralmente inclui membros das equipes Scrum e é responsável por lidar com bloqueios, fornecer assistência e treinar as equipes através de processos Ágil. O NIT tem suas próprias reuniões, separadas do Scrum diário.

Embora o Scrum seja um conceito excelente para projetos específicos no gerenciamento ágil, no gerenciamento ágil de programas estamos falando, na verdade, de equipes formadas por outras equipes. É aí que entra o Scrum@Scale.

No Scrum@Scale, todos os membros ágeis fazem parte de uma equipe Scrum intercambiável, o que permite colaboração entre diferentes disciplinas. Para lidar com os desafios de programas maiores em tempo real, alguns novos membros são adicionados à equipe. O Chief Product Owner (CPO) cria um backlog único para todos os scrums e coordena o trabalho dos product owners individuais. Um papel semelhante é o Scrum of Scrums Master, que coordena as ações entre os Scrum Masters.

Lean é uma metodologia focada em reduzir desperdícios e promover melhorias contínuas na qualidade das entregas. Ela é frequentemente considerada parte do guarda-chuva ágil. Enquanto o ágil é uma filosofia, o Lean é uma metodologia com ferramentas e diretrizes mais específicas. O Lean preocupa-se principalmente em minimizar ineficiências e desperdícios, enquanto o ágil prioriza iteração, feedback e flexibilidade.

O Lean tem cinco princípios fundamentais:

• Identifique valor: Essencialmente, descubra exatamente qual é a meta e elimine qualquer coisa que não agregue valor.
  
  
• Mapeie o fluxo de valor: use uma ferramenta de gerenciamento, como quadros Kanban, para visualizar o roteiro do produto. Essencialmente, a visualização do plano do projeto do início ao fim.
  
  
• Criar fluxo de trabalho: desenvolva o processo de produção com etapas específicas, identificando quaisquer obstáculos possíveis. O objetivo é criar um fluxo de trabalho o mais fluido possível.
  
  
• Estabeleça um sistema de extração: um sistema pull baseia-se em criar novas tarefas somente conforme a demanda do cliente e quando a equipe estiver disponível para mais trabalho. Isso geralmente é feito com uma fila de tarefas.
  
  
• Melhorar continuamente: use uma variedade de técnicas para criar valor continuamente e melhorar o produto. Isso pode envolver metodologias e filosofias como Lean Six Sigma e Kaizen, ou frameworks estruturados como Scrum, que incentivam testes persistentes e ciclos de feedback produtivos.

O gerenciamento ágil de programas, junto com suas metodologias associadas, oferece diversas formas de aprimorar a entrega de projetos.

• Especificidade: ao iterar continuamente, as equipes ágeis conseguem focar exatamente no que o cliente deseja, em vez de tentar melhorar o projeto todo de forma aleatória.
  
  
• Eficiência: o gerenciamento ágil de programas inclui princípios voltados para reduzir desperdícios, documentação e burocracia.
  
  
• Versatilidade: com respostas rápidas ao feedback do cliente, a versatilidade é parte fundamental do gerenciamento ágil de programas. As equipes ágeis sabem, antes mesmo do início do projeto, que mudanças ocorrerão durante o processo.
  
  
• Moral da equipe: o gerenciamento ágil do programa incentiva a abertura, a transparência e a capacitação dos membros individuais da equipe para se expressarem. A hierarquia é menos relevante que a honestidade e o trabalho em equipe dedicado.