Planejamentos ágil e tradicional — Um é de marte, outro de vênus

Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect.
Andy Hunt – signatário do Manifesto Ágil

Vira e mexe ouve-se a famigerada acusação de que no Agile não há planejamento.

Arrrrrg! Não é bem assim, isso é um mito. O que o Agile faz é dar mais ênfase no planejamento que no plano em si, mas vamos ver um pouco mais sobre as diferenças.

Um mundo de incertezas

Os dois tipos de planejamento são de mundos diferentes, mais ou menos como naquele livro “Homens são de marte, mulheres são de vênus”.

O Agile assume que estamos em um ambiente de grande incerteza e, portanto, tentar planejar previamente todo o projeto traria consigo um alto grau de especulação, já a abordagem tradicional acredita em um mundo linear com causas e efeitos muito claros e que assim, seria possível planejar com exatidão o projeto antes mesmo do início de sua execução.

Dessa forma, poderíamos dizer que “O Agile é do complexo e caótico, o tradicional do simples e complicado”.

O método cascata

Primeiro vamos tirar a confusão que existe entre gerência de projetos tradicional e método cascata: Apesar dos dois andarem costumeiramente de mãos dadas, o primeiro está mais relacionado com o PMBOK (Project Management Body of Knowledge)  e o segundo com uma forma recomendada pela engenharia de software tradicional.

Como na mentalidade tradicional existe a presunção de que todas as funcionalidades levantadas são indispensáveis e serão, portanto, implementadas, pouco importaria para o cliente a ordem como seriam implementadas. Dessa forma, opta-se por fazer o que parece, à primeira vista, a maneira mais inteligente e eficiente de se fazer software: por meio de etapas bem definidas, com grandes “entregas” de artefatos intermediários de uma fase para a outra.

Um dos problemas dessa abordagem é o tempo prolongado para se obter qualquer feedback, fazendo com que os problemas sejam descobertos tardiamente. Só para exemplificar, imagine que na fase de Análise um primeiro trabalho pode servir como base para completar todo o resto do trabalho antes de haver uma entrega para a próxima fase. Ao entregar o trabalho para a equipe que trabalhará na fase de Codificação, descobre-se que há um problema em todo o material entregue, devido a um problema que poderia, se houvesse um ciclo maior de feedback, ser descoberto mais cedo.

Como se não bastasse, um outro problema comum com essa abordagem é a propensão a gerar silos e pouca responsabilidade compartilhada da equipe pelo projeto. É comum nesse cenário se ouvir a “querida” frase “Fiz minha parte!”.

O planejamento tradicional

A primeira coisa que salta aos olhos no planejamento tradicional é o foco no plano, ou seja, uma vez estabelecido existe uma grande dificuldade em mudá-lo. A busca não é pelo valor para o cliente, e sim em entregar no prazo e no custo tudo que o cliente imaginou de antemão ser necessário para resolver seu problema.

Dado que vamos seguir um plano idealmente sem alterá-lo, e que todas as funcionalidades requisitadas pelo cliente precisam ser feitas, pouco importaria para o cliente a ordem em que serão desenvolvidas. Dessa forma, acaba-se dando enfoque em atividades. Você se lembra dos processos da fase de planejamento do PMBOK? Vou citar só alguns dos envolvidos com levantamento de escopo e definição do cronograma para exemplificar isso:

Coletar os requisitos;
Definir o escopo;
Criar a EAP (Para quem não sabe, EAP é a WBS, algum louco decidiu chamar de estrutura analítica de projeto);
Definir as atividades;
Sequenciar as atividades;
Estimar os recursos das atividades;
Estimar as durações das atividades;

Deu para perceber que o planejamento tradicional foca em atividades, não em funcionalidades? O problema é que normalmente não se produz valor para o cliente a cada atividade concluída, mas sim a cada funcionalidade entregue.

Ok, não é só isso, acontece que em geral as atividades não terminam antes do planejado, por algumas razões como a Lei de Parkinson (não, não é o mal de Parkinson), a Síndrome do estudante e uma extraordinária falta de incentivo para tal.

Lei de Parkinson: Diz que o trabalho ocupará o tempo disponível para ele.
Síndrome do estudante: Se houver um prazo para concluir algo, o aluno ou estudante (ou no caso o desenvolvedor) deixará para a última hora.
Falta de incentivo: Quando alguém termina cedo, costuma-se culpar essa pessoa por supostamente adicionar muito padding à estimativa ou, então, querer exigir que termine as demais atividades mais cedo também. Ou seja, em geral não há qualquer incentivo para o desenvolvedor dizer que terminou algo antes do prazo.

Outro ponto é que os atrasos são transferidos no encadeamento de atividades. A ideia de que um atraso se compensa, na média, com atividades entregues mais cedo quase nunca é verdade. Um dos motivos disso é que apenas uma combinação de resultados permite que uma atividade possa começar mais cedo, enquanto um único problema pode atrasar o começo de uma atividade. Aliás, há outro motivo para os atrasos não se compensarem na média, é que  as atividades não são eventos independentes.
Jogar uma moeda múltiplas vezes é uma atividade independente. Já no desenvolvimento de software as variações nos tempos de conclusão das atividades tendem a se repetir. Por exemplo, se criar um interface gráfica demorou mais que o estimado, há uma tendência de que outras atividades similares também levem mais tempo que o esperado.

O foco em atividades ainda leva a um outro problema: devido às atividades não serem desenvolvidas por prioridade, normalmente leva-se muito tempo para se ter algo em funcionamento e, mesmo assim, dificilmente serão as funcionalidades de maior valor para o negócio. Caso o dinheiro acabe antes do tempo ou seja preciso adiantar a data de lançamento do produto, não haverá algo muito útil para se entregar, nem tampouco é dada a oportunidade ao negócio para encerrar o projeto antes da hora se a maior parte do valor já foi entregue.

Esse último não está ligado às atividades, mas talvez seja o problema mais irritante em relação ao planejamento tradicional, as estimativas tornam-se compromissos. Estimativas são probabilidades; e compromissos não devem ser tomados sobre probabilidades. É quase como pedir para um meteorologista se comprometer com a previsão de um dia específico num futuro mais distante que um mês.

O planejamento ágil

Dada a premissa que estamos em um ambiente de incertezas (mundo da complexidade), todo ato de planejar e estimar é um ato de especulação. Isso não significa que o Agile entenda que estamos completamente no escuro, apenas que nossa visão é limitada e cada vez menos nítida conforme nos lançamos a “ver o futuro”.

Outro ponto de fundamental diferença é o foco, não mais no triângulo de ferro, escopo, prazo e custos, mas na entrega de valor. É óbvio, contudo, que prazo, escopo e custo não são desprezados, apenas deixam de ser o objetivo principal do projeto.

O que é diferente, afinal, no planejamento ágil?

Encoraja mudanças. Como o enfoque está na entrega de valor, é necessário aceitar e encorajar as mudanças caso entreguem mais valor que o planejado.

Um dos primeiros efeitos desse entendimento é que o foco passa a ser no plajenamento e não mais no plano. Isso facilita que o plano possa ser facilmente alterável.

Planejamento por funcionalidade e não por atividade. Como o Agile visa a entrega de valor, não importa a ordem pela qual as atividades são executadas, mas importa a ordem pela qual as funcionalidades são entregues, afinal, as que entregam mais valor deveriam ser priorizadas e entregues antes.

A incerteza é aceita como “parte do processo”.

O planejamento é iterativo. deve ser feito em níveis de Release, Sprint (Iteração timeboxed e incremental) e dia; evoluindo o plano de forma incremental. Em outras palavras, o planejamento é diluído pelo projeto, afinal, conforme o projeto progride, aprendemos mais sobre o projeto (o como) e sobre o produto (o que).

Estimativas não são compromissos, são estimativas.

Medida primária do progresso do projeto é software funcional (Entrega real). Consequentemente há uma contribuição maior para uma evolução apurada do planejamento.

Estabelece confiança. Entregas constantes de software funcional ajudam a estabeler a confiança entre o negócio e o desenvolvimento.

É importante saber em que mundo você está antes de escolher um tipo de planejamento, mas nunca perca de vista o foco na entrega de valor. É muito triste entregar um projeto no prazo, no escopo e no custo se no final das contas o projeto falhar no mais importante que é resolver o problema do seu cliente.

They had “achieve failure” — successfully, faithfully, and rigorously executing a plan that turned out to be utterly flawed.

Eric Ries, no Livro “Lean Startup”

Sobre o autor:

Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, Atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando como Scrum Master e agente de mudanças na Editora Abril. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é graduado em Direito pela Universidade Presbiteriana Mackenzie e aprovado pela OAB.  E também é instrutor associado na Adaptworks treinamentos, onde ministra o treinamento de EPC (Estimating, Planning and Contracting).
LinkedIn: @leonardocampos