Planejamento Ágil (Agile). Soa como um paradoxo, não soa? Planejamento envolve estabelecer limites, criar listas de verificação, determinar datas de entrega e seguir um processo passo a passo, não é mesmo?
Mas Agile, não se trata de pessoas fazendo suas próprias coisas? Muitas pessoas pensam no planejamento tradicional como o equivalente musical de uma orquestra clássica disciplinada e no Planejamento Ágil como o caos de forma livre do jazz.
Nada poderia estar mais longe da verdade.
Este artigo explicará por que o pensamento e o planejamento Ágil não são exclusivos e podem trabalhar juntos de forma poderosa para o seu negócio.
Vamos descobrir se o Planejamento Ágil é algo para você.
O Planejamento Ágil é uma forma de planejar o desenvolvimento de produtos em um ambiente Agile desde as metas e objetivos do negócio até a execução diária em equipes de desenvolvimento.
O desenvolvimento de produtos, especialmente o desenvolvimento de software, é dinâmico. Os requisitos do usuário e do cliente mudam. Devido às mudanças em seu ambiente e porque a utilização de um produto à medida que ele evolui aciona ideias de uma maneira que nenhum documento de especificação jamais poderia.
Aceitar mudanças frequentes então e planejar de acordo, é fundamental.
Assim como o Desenvolvimento Ágil de Software, o Planejamento Ágil é iterativo, tornando-o inerentemente adaptável à mudança. Isto permite que você concentre sua atenção nas necessidades dos usuários e clientes em todos os níveis de seu negócio.
Isso também significa que o plano em si não é tão importante assim. O verdadeiro valor do Planejamento Ágil está no pensamento necessário para criar o plano e como ele conecta o trabalho em todos os níveis às metas e objetivos orientados ao cliente da empresa.
O desenvolvimento de software teve uma má reputação nas décadas de 80 e 90 do século passado. Os projetos ultrapassavam seus cronogramas e seus orçamentos.
Descobriu-se que desenvolver qualquer software é um esforço complexo em um ambiente muitas vezes complexo e mutável. Algo que simplesmente não se pode controlar com os métodos de planejamento obtidos através de projetos de construção.
A abordagem cascata simplesmente não serve quando se trata de responder às mudanças no ambiente e nas necessidades de seus clientes.
O desenvolvimento ágil de software evoluiu devido a isso. Entretanto, muitas empresas ainda usavam o método tradicional de planejamento de trabalho para prever seus custos e definir orçamentos.
O Desenvolvimento Ágil de Software elimina a interrupção do trabalho, pelo menos até o último momento. Alguns proponentes ágeis até mesmo defendiam a recusa de apresentar estimativas de tempo e recursos. Afinal, de que serve planejar desta forma quando você sabe que as coisas mudam e qualquer plano é provavelmente impreciso no momento em que é criado.
Entretanto, a necessidade de controlar custos e estabelecer orçamentos não desapareceu, mesmo quando os benefícios da agilidade na entrega de software que funciona e atende às necessidades dos clientes eram óbvios.
Algo tinha que mudar, e o Planejamento Ágil foi a resposta dando aos gerentes e executivos uma forma de estimar custos e estabelecer orçamentos sem exigir que o departamento de desenvolvimento voltasse às tentativas de prever o futuro.
A ideia chave para o Planejamento Ágil é vincular tudo o que é feito no desenvolvimento de volta às estratégias e objetivos do negócio.
Isto significa que o planejamento começa no topo — o nível de direção e gerência sênior — e se torna progressivamente mais detalhado no caminho para o nível das equipes que executam o trabalho.
Uma bela metáfora para este processo de planejamento é a Cebola do Planejamento Ágil.
É como um lembrete visual do espectro que o Planejamento Ágil tem que cobrir em toda uma empresa.
Como você pode ver, a cebola tem seis camadas. Estas correspondem à estrutura hierárquica típica da maioria das empresas.
No Planejamento Ágil, o foco está continuamente no fornecimento de valor ao cliente.
A questão em todos os momentos é: eles valorizam isso? Pouco mais importa.
O trabalho que uma equipe faz é menos importante do que o valor de seu trabalho representa para os clientes.
Para garantir que o trabalho represente valor para os clientes, você quer entregá-lo regularmente para que possa receber feedback imediato e direto do cliente. Isto então permite que você se adapte conforme constrói e melhora o produto que está criando para eles.
Sim, isto significa que tudo que você planejou pode mudar à medida que o cliente precisa mudar. É por isso que o Planejamento Ágil, assim como o desenvolvimento ágil, é iterativo.
E isso não faz mal porque é o valor do cliente que você procura, não executando um plano para desenvolver algo que o cliente não precisa mais.
Colocar o cliente no centro do Planejamento Ágil é diretamente inspirado pelos dois primeiros princípios do Manifesto Ágil:
O Planejamento Ágil favorece a tomada de decisões no último momento responsável. Pelo menos para decisões que são irreversíveis — que não têm como voltar, ou o caminho de volta seria caro.
O problema é que não tomar uma decisão tem um custo, mas tomar uma decisão muito cedo — com conhecimento e dados insuficientes — também acarreta um custo significativo.
Portanto, você quer esperar até o último momento responsável: quando o custo de não tomar uma decisão se torna maior do que o custo de tomar uma decisão.
Isto se aplica a todas as decisões, incluindo as funcionalidades de planejamento de seu produto.
Você quer adiar o refinamento (detalhamento) de novas características até o último momento responsável, porque o que precisa ser feito para uma funcionalidade mudar à medida que outras funcionalidades são implementadas. Em outras palavras: adicionar detalhes (tomar decisões) muito cedo e você terá desperdiçado o esforço quando as circunstâncias mudarem e precisar adiar essa funcionalidade, ou talvez até mesmo eliminá-la completamente.
Portanto, somente refine completamente (partes de) as funcionalidades que você definitivamente implementará durante as próximas duas ou três iterações. E apenas acrescente detalhes suficientes aos recursos que têm que esperar mais tempo para informar suas decisões de planejamento e priorização.
Você verá pelo Manifesto Ágil que há uma ênfase na entrega frequente de software funcional.
Da mesma forma, ele é um componente chave do Planejamento Ágil.
As entregas frequentes de funcionalidades vêm com vários benefícios. Quanto mais frequentes as entregas de software funcional, maior e mais detalhada é a resposta do cliente. Isto tem um efeito em cadeia para o planejamento da próxima iteração e evita que se afaste muito do resultado desejado pelo cliente.
Este é um dos contrastes com o desenvolvimento tradicional de “cascata” e os métodos de planejamento de divisão de trabalho antecipado.
O Planejamento Ágil encoraja uma abordagem probabilística para estimar cronogramas e datas de entrega do projeto.
As características de uma abordagem probabilística são:
As características de uma abordagem determinista são:
A abordagem probabilística no Planejamento Ágil tem vários benefícios para seu projeto:
Em resumo, a Timeline Ágil seria flexível em termos de escopo e tempo (para adaptar-se às mudanças de requisitos), mas fixa em termos de recursos (equipes e, portanto, custo).
E é exatamente isso que torna possível estimar custos e determinar orçamentos sem exigir desenvolvimento para fazer estimativas!
A este respeito, o Planejamento Ágil dá o melhor de dois mundos. Mas lembre-se:
Embora não faça estritamente parte do processo de planejamento em si, vale a pena ter em mente que, na abordagem de cascata, os testes de aceitação pelos usuários e operadores são uma etapa separada após a construção e os testes técnicos do produto pelos próprios desenvolvedores.
No Agile, a ideia é testar cedo e com frequência. Os usuários e operadores revisam e testam cada funcionalidade assim que ela fica disponível, em vez de esperar até que o produto inteiro esteja pronto.
Afinal de contas, o objetivo é entregar um software que funcione.
Quando você entrega uma funcionalidade em um ambiente ágil, ela é testada e aceita. Não isoladamente, mas no contexto do produto, como ele é cultivado até então.
Não há necessidade de um estágio separado ou de uma equipe separada para garantir que tudo se encaixe e funcione em conjunto. Tudo isso faz parte do processo padrão e já está concluído.
Isto torna o planejamento muito mais fácil e as datas de entrega mais previsíveis, pois não haverá grandes surpresas desagradáveis no final, forçando você a fazer um monte de reformulações. As surpresas são sempre limitadas ao que você fez em uma iteração e — com a colaboração e feedback do cliente em cada iteração — o risco de criar algo que o cliente não pretendia também é pequeno.
Um grande obstáculo ao planejamento previsível são os comprimentos que os desenvolvedores têm de percorrer para manter as funcionalidades acabadas fora do produto lançado, porque o calendário da empresa age de forma diferente. Por exemplo, quando um conjunto de novas funcionalidades deve ser lançado durante uma feira de negócios.
O problema é que manter essas funcionalidades ‘em estoque’ apresenta riscos porque o trabalho no produto não para, e incorporá-las em uma data posterior significa ter que refazer o trabalho, especialmente muitos testes.
A maneira de evitar tudo isso é adotar uma entrega contínua com funcionalidades, controlando quais funcionalidades estão disponíveis para quem. Isto permite que você desconecte o momento de lançamento aos clientes a partir do momento em que uma funcionalidade é integrada à base de códigos lançada.
Um componente chave do Planejamento Ágil é sua flexibilidade inerente para se adaptar às mudanças em um ambiente de trabalho.
O desafio de entregar projetos na pandemia é um grande exemplo disso. Durante a pandemia, algumas pessoas adoeceram, e estar localizadas no mesmo prédio se tornou impossível. Isto afetou todos os envolvidos no desenvolvimento e entrega de novas e modificadas funcionalidades.
Ao invés de tentar adivinhar linhas de tempo determinísticas fixas, o Agile usa dados e métricas reais para tomar decisões realistas e informadas.
Há várias ferramentas para fazer isto.
Uma ferramenta frequentemente utilizada são os quadros e métricas Kanban focados no fluxo de trabalho através do processo e utilizando-os para estimar as datas de entrega dos trabalhos em mãos e em pipeline.
Uma abordagem mais matemática é usar simulações de Monte Carlo para prever os custos e as prováveis datas de entrega. Elas são usadas há muito tempo no Gerenciamento de Projetos Lean e são uma ferramenta útil para estimar o rendimento de projetos.
A simulação de Monte Carlo utiliza dados históricos sobre capacidade e desempenho para calcular a porcentagem de chance de atingir uma meta do projeto, como custo ou data de entrega. Isto então permite avaliar o risco associado com o trabalho.
As principais diferenças entre o planejamento tradicional e o Planejamento Ágil:
O risco com a abordagem em cascata de fazer previsões cedo, quando menos se sabe sobre o que está por vir, é que as previsões são extremamente imprecisas. A razão é que uma mudança nas necessidades do cliente significa que o trabalho que já foi feito em estágios anteriores também precisa ser refeito.
A abordagem do Planejamento Ágil é inerentemente iterativa e adaptável. O risco é mitigado com o feedback do cliente durante todo o projeto e com cada funcionalidade de trabalho entregue.
Vale ressaltar que a grande escala de alguns projetos como os realizados pela NASA seguirá uma abordagem mais tradicional de planejamento ou um híbrido de planejamento em cascata e Agile chamado Planejamento em Espiral.
Image courtesy: Nasa
Tendo examinado as semelhanças e diferenças entre Ágil e Cascata, vamos analisar os papéis e responsabilidades-chave no Planejamento Ágil.
Os papéis cruciais no Planejamento Ágil são:
Essas funções e responsabilidades refletem a cebola do Planejamento Ágil discutida anteriormente.
E novamente, é importante ressaltar que é função e responsabilidade de todos adotar o Mindset Ágil e aderir ao conceito de Planejamento Ágil.
O Planejamento Ágil não prescreve realmente nenhuma reunião ou ciclos e cadências específicas, mas há cadências típicas para cada camada na Cebola de Planejamento:
Para que o Planejamento Ágil funcione, o pensamento ágil, conforme estabelecido no Manifesto Ágil, precisa estar no topo da mente de todos em toda a sua empresa, em todos os seus departamentos e em todo o seu pessoal.
Sem o pensamento ágil, o Mindset Ágil, primordial no planejamento através das seis camadas da Cebola de Planejamento, usá-la em seu benefício se torna muito mais difícil.
As armadilhas comuns aos negócios são:
A melhor coisa que você pode fazer para ter um excelente começo em sua campanha de Planejamento Ágil é buscar treinamento e conselhos.
Não apenas para alguns, mas para todos os envolvidos no planejamento em qualquer camada da Cebola de Planejamento Ágil. Afinal, divulgar o conhecimento ajuda a espalhar a mentalidade e coloca todos na mesma página.
Dito isto, não pule para o fundo do poço com todos ao mesmo tempo.
Comece com as camadas internas da Cebola de Planejamento Ágil. Estas são as pessoas que provavelmente já estão bem versadas no planejamento de suas iterações de forma ágil.
Movam-se para fora uma camada de cada vez. Se você tiver vários grupos de produtos, você pode considerar isso primeiro para um único grupo de produtos e usar a experiência com isso para trazer outros grupos de produtos a bordo.
Lembra-se onde começamos? O planejamento ágil soa como um paradoxo?
Bem, agora você sabe que isso não é verdade.
E você sabe o que precisa saber para decidir se é algo para você.
Se for, comece com algum treinamento e conselhos sólidos. Da Digité, é claro.
Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.
Solicitar Demonstração