Em 2019, nós mergulhamos de vez nas práticas de gerenciamento de projetos utilizadas nas metodologias Ágeis. Nós discutimos os desafios e oportunidades de gerenciamento de projetos e como o Agile modifica o papel do gerente de projetos. Agora, utilizar o Agile dentro do gerenciamento de projetos se tornou uma tendência, mas não necessariamente é totalmente compreendido nas organizações em que atuamos provendo soluções. À medida que mais e mais organizações alegam se tornar Agile, pouco se tem falado ou publicado sobre o que o Agile significa para as ferramentas de gerenciamento de projeto.

Este artigo descreve como os princípios fundamentais do Agile são aplicados aos processos de gerenciamento de projetos para escopo, tempo e gestão de custos. Focamos na tríplice de restrições de uma perspectiva do Agile. Também fornecemos recomendações sobre quais são os fatores críticos de sucesso para aplicação e ganhar aceitação destes processos e ferramentas "Agilizados."

Introdução

O que é Ágil? De acordo com o Merriam-Webster, Ágil é "caracterizado pela habilidade de mover-se com rapidez e graça" e "tendo um caráter rápido de adaptabilidade e engenhosidade ."  (Merriam-Webster, 2009)  Agilidade significa a capacidade de se adaptar a mudanças rapidamente e com eficiência em custos. É de conhecimento público que projetos de TI e de desenvolvimento de software têm uma história de estourar orçamentos, entregar algo diferente do que o cliente espera, ou ser entregue atrasado ou sequer ser entregue. A busca pelas causas raiz e ações corretivas tem acontecido desde o reconhecimento do problema em meados dos anos 80. O Standish Group (1995) descobriu que as duas maiores causas são "requerimentos incompletos" e "falta de envolvimento do usuário." As metodologias ágeis de desenvolvimento foram concebidas nos anos 90 com o principal objetivo  de atacar as causas raiz das falhas em projetos de TI e aumentar as chances de sucesso em projetos.

Em 2001, o Manifesto Ágil (Agile Manifesto, 2001) foi criado descrevendo os valores e princípios dos processos Ágeis de desenvolvimento de software. Os três principais pontos focais dentro dos métodos ágeis são (Highsmith, 2002):

1. Organizações são "caos-ordenadas", tendo características tanto de caos como de ordem;
2. Confiança é a base para as relações internas e externas, com foco em colaboração e não em negociação de contratos;
3. O foco recai sobre pessoas e interações em primeiro lugar e em processos em segundo plano.

Os pontos fundamentais das características das metodologias ágeis são (Hazzan, 2008, Schwaber, 2002):

• Desenvolvimento iterativo com pequenas liberações de produto: entregar produtos frequentemente permite aos clientes prover feedback regular e dá ao time a capacidade de reagir a mudanças no mercado;
• Desenvolvimento orientado a testes: desenvolvedores escrevem os casos de teste para o novo software antes de implementar modificações no código. Preparar testes antes da codificação melhora a qualidade e facilita o feedback rápido;
• Alocação comum: membros do time (incluindo os representantes do cliente) são alocados no mesmo local para facilitar a comunicação e minimizar perda de tempo com espera (aqui vai uma observação que após a pandemia isso mudou para acesso imediato de forma remota através de ferramentas de colaboração);
• Times auto-organizados: membros dos times assumem múltiplos papéis, improvisam, e colaboram espontaneamente, enquanto simultaneamente aprendem e ensinam seus pares sem um gerente de comando e controle. Um time normalmente consiste de um coach ou scrum master, dono de produto, representantes do cliente, desenvolvedores, testers e arquiteto;
• Backlog de Produto (requerimentos): uma fila evolutiva e priorizada de requerimentos técnicos e de negócio. A cada iteração, o backlog é revisado pelo time completo e funcionalidades são selecionadas para ser construídas na próxima iteração. O dono do produto é responsável por gerenciar e controlar o backlog de produto.

Desde a criação do Manifesto, a globalização e a tecnologia tem aumentado a velocidade na qual o ambiente em que vivemos e trabalhamos se modifica. No ritmo acelerado do mundo, os objetivos do cliente são constantemente revisados. O direcionador para as metodologias ágeis vieram originalmente de dos staffs técnicos dentro dos projetos. Nos últimos anos, as metodologias de desenvolvimento Ágil se provaram ser uma alternativa válida para as metodologias tradicionais, especialmente para projetos pequenos. A pesquisa sobre Sucesso em Projetos de Desenvolvimento de Software da Ambler de 2008 (Ambler, 2008) afirma que 70% dos projetos Ágeis são completados com sucesso, versus 66% os projetos tradicionais. O Ágil é sobre mover para o próximo nível de maturidade, o que deveria incluir a expansão de processos Ágeis para endereçar o lado do planejamento de grandes projetos e times dispersos.

Princípios Ágeis e Restrições de Gerenciamento de Projetos

O planejamento de projetos foca em responder as questões, o que necessita ser construído, quando necessita estar completado, quanto irá custar, e quem necessita estar envolvido.
Como gerentes de projeto, queremos também saber as dependências entre atividades de forma que minimizemos o tempo ocioso e otimizemos o cronograma.

A sabedoria convencional é que as estimativas se aprimoram à medida que projeto progride. Barry Boehm foi o primeiro a representar graficamente os níveis de incerteza nos diferentes estágios do ciclo de vida de um projeto de alta tecnologia em 1981. O resultado foi mais tarde apelidado de "o cone da incerteza" por McConnel (2006). A ideia por trás do cone é que no início do projeto existe um significativa incerteza sobre "o que" necessita ser construído. Isto torna muito difícil responder às perguntas "quando será completado?" e "quanto irá custar?" . Na medida em que o projeto evolui, o time de projeto obtém maior compreensão do que  precisa ser construído e como eles irão construir. Como consequência, se torna mais simples estimar a data de entrega e o custo do projeto à medida que diminui o nível de incerteza das estimativas. É claro, ao final do projeto não existem mais incertezas, somente a realidade.

Planejamento de projetos tradicionais e ágeis lidam de forma diferente com esta incerteza.  Em última análise o objetivo é criar um plano de projeto que move o projeto do estado inicial até onde o projeto alcança seus objetivos. A abordagem de planejamento de projetos tradicional cria um plano de projeto seguindo diversos passos de planejamento. Estes passos incluem:

1. Determinar os objetivos de projeto;
2. Coletar os requerimentos do projeto;
3. Definir o escopo do projeto em um nível de trabalho;
4. Identificar dependências entre atividades;
5. Estimar esforço de trabalho e dependências;
6. Preparar um cronograma abrangente e um orçamento de projeto;
7. Receber aprovação;
8. Estabelecer a linha de base do plano.

O gerenciamento de projetos tradicional assume que projetos são gerenciados dentro de certas restrições. No gerenciamento de projetos, estas restrições são em geral denominadas como "a restrição tripla." O PMBOK® Guide (PMI, 2004) se refere à tripla restrição como "um framework para avaliar demandas concorrentes." As demandas concorrentes são comumente ilustradas como um triângulo onde cada lado ou ângulo se refere a uma das restrições que são aplicadas ao projeto. Qualidade é geralmente assumida como fixa, e portanto muitas organizações esquecem de estabelecer requisitos de qualidade como parte de sua análise de planejamento escopo, custo e tempo.

Compreender como gerenciar um projeto dentro destas restrições pode fazer a diferença entre o seu sucesso ou fracasso. As restrições estão relacionadas e dependentes entre si. Uma mudança em uma restrição tem impacto nas outras duas (Koppensteiner, 2008). Em geral, mudanças são relacionadas a mudanças de escopo ou alteração de datas alvo. Adicionar funcionalidades ao escopo requereriam aumento de orçamento para custear recursos adicionais de forma a manter a data limite e satisfazer os critérios de qualidade. Se tanto o orçamento como a data limite não puderem ser alteradas, o escopo deve permanecer constante também.

Nas abordagens tradicionais de gerenciamento de projetos, a execução do projeto se inicia após o recebimento da aprovação do escopo, cronograma e orçamento. Ao longo da vida do projeto, o progresso será medido em relação ao plano base. A abordagem lida com as incertezas implementando um rigoroso processo de controle. Qualquer mudança significativa ao escopo do projeto, cronograma, e orçamento necessitará passar por um processo de aprovação antes de ser incorporada ao plano.

Este processo rigoroso de controle conjugado com longos ciclos de desenvolvimento criaram uma mentalidade no cliente que todos os requerimentos precisam ser parte do escopo do projeto (por exemplo: um formulário de especificações) desde o início do projeto, já que é tão difícil mudar qualquer coisa após o início do projeto. O cliente enxerga o desenvolvimento com uma caixa preta, ou seja, ele define seus requerimentos no início do projeto e então precisa esperar até o final do projeto para ver os resultados. Quando a mudança acontece ou é necessária, demora um longo período para ser incorporada ao projeto. Como resultado, é provável que o cliente receba o produto ou serviço que atenda às especificações e não necessariamente às suas necessidades no final do projeto.   

O planejamento de projetos Ágeis assume o fato de que o escopo irá mudar ao longo do projeto. Ele entende que a mudança é inevitável. Somente o escopo de cada iteração é fixo. Isto significa que o cliente pode mudar a prioridade de seus requerimentos e adicionar ou remover requerimentos após cada iteração. Isso proporciona ao cliente uma grande flexibilidade e também o torna parte da equipe durante todo o projeto. Claro que existem limitações para a quantidade de mudanças que o projeto pode absorver, com base, entre outros, na arquitetura escolhida, ou seja, se você estava planejando construir um prédio de dois andares e na metade, o cliente então quer que seja um prédio de 15 andares, você terá que recomeçar do zero.
A Figura 1 mostra a ilustração do triângulo de restrição tripla para um projeto. A qualidade é muitas vezes assumida como fixa e, portanto, muitas organizações esquecem de tornar os requisitos de qualidade uma parte de sua análise de planejamento de escopo, custo e tempo. Assumimos que a qualidade afeta cada uma dessas restrições e deve ser levada em consideração por todas as restrições.

Figura 1:  Triângulo de restrição tripla (Gray-Larsen, 2006; Lewis, 2002)

A Figura 2 mostra as definições do Guia PMBOK® para as restrições triplas e a qualidade.

Figura 2: Definições de restrições chave do projeto (PMI, 2004)

A equipe do projeto faz estimativas detalhadas para a funcionalidade implementada apenas na próxima iteração. O gerenciamento ágil de projetos reconhece que o escopo, o tempo e os custos mudarão como parte das atividades de planejamento iterativo. Da perspectiva da restrição tripla, os projetos ágeis podem ser considerados “encaixotados” no tempo, já que cada iteração de desenvolvimento tem a mesma duração, os recursos podem ser considerados flexíveis e o escopo é o mais flexível.

Métodos e processos de planejamento ágil

Pré-planejamento

Antes do início de um projeto Ágil, a organização identifica uma visão do projeto, um roadmap do produto e um caso de negócio. O ciclo de vida do projeto Ágil começa com uma etapa de pré-planejamento. Isso inclui a coleta e priorização de requisitos técnicos e de negócios, denominado backlog do produto, a formação de equipe e a estimativa de tempo e custo de alto nível. O backlog do produto contém todos os requisitos necessários para entregar o produto, sistema ou serviço final. Ele é coletado de várias fontes e, em seguida, priorizado. A equipe e os especialistas se reúnem e fornecem estimativas de alto nível para cada recurso, que incluem o tempo que leva para executar todas as atividades de arquitetura, desenvolvimento e liberação necessárias. Com base nessas estimativas, uma primeira estimativa aproximada para toda a duração do projeto (tempo), bem como para o custo geral para a realização do backlog (escopo), pode ser determinada. A estimativa é um processo iterativo (Schwaber, 2003). Nesta etapa, a equipe também escolhe a duração das iterações, caso não tenha sido decidida  pela organização antecipadamente.

Planejamento

A próxima etapa é o planejamento de lançamentos e iterações. A organização pode decidir liberar cada iteração para o cliente quando ela se tornar disponível ou liberar uma coleção de iterações de uma vez em uma liberação definida. O planejamento da liberação pode ser feito logo após a criação do backlog do produto (Sliger, 2008) ou após as primeiras iterações terem sido concluídas (Schwaber, 2003).

Figura 3: Processos para planejamento de um projeto ágil (baseado em Sliger, 2008)

Planejamento de Liberação

Durante o planejamento da liberação, o gerente de projeto, o proprietário do produto, a equipe do projeto e outras partes interessadas dividem as funcionalidades no backlog do produto em várias iterações, garantindo que cada iteração possa ser concluída dentro da duração de uma iteração. Em seguida, eles atribuem iterações às liberações (lista de pendências da liberação). Cada lançamento oferece um incremento de produto funcional. Com base neste plano de lançamento, as datas para os marcos de lançamento, bem como para o lançamento do produto final, podem ser identificadas (tempo). O custo geral do projeto pode ser determinado a partir do custo de mão de obra da equipe Ágil e do número de iterações identificadas (Sliger, 2008). Os custos indiretos e de material devem ser adicionados a este número. A Figura 4 mostra as entradas, ferramentas e técnicas, e saídas para o processo de “Planejar Liberações”.

Figura 4: Plano de Lançamento: Entradas, Ferramentas e Técnicas e Saídas para um Projeto Ágil (Sliger, 2008; Schwaber, 2002; PMI, 2004; Highsmith, 2004)

Planejamento de Iteração

O planejamento de projeto ágil se concentra no planejamento da próxima iteração. Após cada iteração, a equipe do projeto se reúne para identificar o conteúdo (escopo) da próxima iteração (backlog da iteração). A Figura 5 mostra as atividades durante a reunião de planejamento da iteração. No início da reunião a equipe verifica se há acordo sobre o backlog do produto e a prioridade dos recursos listados. A repriorização acontecerá se necessário, por exemplo, quando a equipe não tiver certeza da ordem atual dos recursos listados na lista de pendências do produto (etapa 1 na Figura 5). Depois de obter mais detalhes sobre os recursos do cliente (se necessário), a equipe de desenvolvimento escolhe os recursos do backlog do produto que eles acham que podem ser realizados na próxima iteração (etapa 2). Na etapa 3, a equipe identifica as tarefas (histórias de usuário) necessárias para implementar os recursos escolhidos, identifica a sequência inicial de tarefas, atribui proprietários às tarefas e estima as tarefas (tempo). Durante a etapa 3, a equipe pode descobrir que o esforço para concluir os recursos escolhidos é mais ou menos do que o tempo alocado para a iteração. Como resultado, os recursos podem ser removidos ou adicionados ao backlog da iteração (etapa 4). Quando a funcionalidade é movida de volta para a lista de pendências do produto, isso pode levar a uma repriorização da lista de pendências do produto.

Figura 5: Processo de planejamento da iteração
O processo de planejamento é iterativo. A equipe pode passar por todo o círculo de planejamento várias vezes. Ao mesmo tempo, as reuniões de planejamento são limitadas a quatro horas. A diretriz é que a equipe não deve gastar mais do que duas reuniões para identificar o escopo e as tarefas da próxima iteração (Schwaber, 2003). A ideia por trás disso é que a equipe aprende com suas ações e torna-se melhor em estimar com o tempo. Depois de várias iterações concluídas, os membros da equipe podem medir a velocidade da equipe, que é o tempo médio gasto na implementação de um recurso. Quando eles entendem e conhecem a velocidade de sua equipe, eles podem fazer suas estimativas mais rapidamente durante as reuniões de planejamento. Como as iterações são curtas (uma a seis semanas), a incerteza é limitada e as estimativas em geral são muito boas.

O custo de uma iteração pode ser determinado pelo custo de mão de obra da equipe Ágil para a duração de uma iteração. Conforme o backlog do produto e a velocidade da equipe mudam, o custo do projeto também muda.
A Figura 6 mostra as entradas, ferramentas e técnicas, e saídas para o processo "Planejar a próxima iteração".

Figura 6: Planejar a próxima iteração: entradas, ferramentas e técnicas e saídas para um projeto ágil (Sliger, 2008; Schwaber, 2002; PMI, 2004; Highsmith, 2004)
 

Gerenciamento do backlog do produto

Após cada iteração, o tempo para concluir o projeto completo pode ser recalculado com base nos resultados da iteração anterior e em quaisquer alterações que o cliente tenha feito no backlog do produto, incluindo mudanças prioritárias ou adição ou exclusão de recursos no backlog do produto. O escopo é bloqueado apenas durante a iteração em andamento.

Como o backlog do produto pode ser modificado ao longo da duração do projeto, o número de iterações e liberações também está sujeito a alterações. O resultado da iteração e do planejamento de liberação podem influenciar um ao outro (conforme a Figura 3). No caso de menos (ou mais) recursos serem selecionados durante o planejamento da próxima iteração, o conteúdo e o número de iterações futuras podem mudar. Como resultado, a coleção de iterações atribuídas a uma versão também pode ser alterada. As atividades de alteração do escopo, prioridade e estimativas do backlog do produto são resumidas no processo “Gerenciar o backlog do produto.”

Conclusões finais

Descrevemos como os princípios básicos dos Métodos Ágeis são aplicados aos processos de planejamento de projeto de gerenciamento de escopo, tempo e custo. As atividades de planejamento do escopo em projetos Ágeis ocorrem durante toda a duração de um projeto. Dentro da capacidade da arquitetura escolhida, o cliente tem a capacidade de adicionar e remover recursos do escopo geral (backlog do produto) no início de cada iteração. Somente ao final do projeto o escopo completo é conhecido. As abordagens tradicionais de planejamento, por outro lado, tentam fixar o escopo tanto quanto possível no início do projeto.

O gerenciamento do tempo em projetos Ágeis começa na etapa de pré-planejamento, onde o escopo do projeto então conhecido (backlog do produto) é estimado por recurso e em alto nível, planejado por iteração e liberação. Como as iterações têm uma duração fixa (timebox), o cronograma do projeto é baseado no número de iterações necessárias para entregar o produto ou serviço necessário. Nas abordagens de planejamento tradicionais, o cronograma do projeto é calculado identificando cada tarefa, sequenciando as tarefas e estimando as tarefas individuais. Os processos de planejamento ágil consideram apenas as estimativas no nível de tarefa para garantir que uma funcionalidade possa ser concluída em uma iteração.

Um fator chave de sucesso no planejamento de projetos Ágeis é que a equipe do projeto seja conhecida no início do projeto e os membros da equipe sejam 100% dedicados ao projeto. O planejamento de custos ágil é baseado nisso. Os custos são calculados pegando os membros da equipe e suas taxas e multiplicando isso pelo número de iterações e, em seguida, adicionando custos como despesas indiretas, materiais e despesas de terceiros. Esta é uma abordagem de estimativa de cima para baixo. O planejamento de custos tradicional se esforça para fazer estimativas de baixo para cima para aumentar a precisão. Isso pressupõe um escopo fixo que pode ser dividido em pacotes de trabalho, que podem ser estimados com base em quem executará o trabalho.

O planejamento de escopo, tempo e custo caminham juntos tanto para abordagens de planejamento tradicionais quanto para abordagens de planejamento Ágil. Do ponto de vista da restrição tripla, as abordagens tradicionais se concentram em manter o eixo do escopo fixo, enquanto para as abordagens Ágeis o foco está em manter a duração de uma iteração fixa.

Os processos de planejamento Ágeis descritos neste documento são apenas uma parte dos processos e metodologias de gerenciamento de projetos Ágeis. A implementação de processos de planejamento Ágeis pode desafiar o status quo das abordagens e da cultura de gerenciamento de projetos em uma organização. Os fatores críticos de sucesso são equipes dedicadas, incluindo representantes do cliente, iterações de desenvolvimento fixas e aceitação de estimativas de cima para baixo para o cronograma e custo do projeto. Organizações altamente burocráticas enfrentarão desafios para mudar a mentalidade da aplicação de regras e regulamentos de uma forma de comando e controle para a confiança em uma abordagem empírica como o Ágil. Um dos fatores de sucesso é que os membros da equipe de gerenciamento e projeto reconhecem e aceitam que a equipe Ágil irá melhorar suas estimativas ao longo da duração do projeto. Uma cultura organizacional que incentiva o espírito de equipe e o aprendizado é a chave para a implementação bem-sucedida do gerenciamento de projetos Ágeis.