Agile Project Management

Debates fervorosos acontecem, atualmente, na comunidade de gestão de projetos de sotware. O grande centro das discussões encontra-se na questão sobre qual seria a melhor metodologia a ser aplicada no gerenciamento desses projetos. Devemos seguir as boas práticas do PMBOK ou aplicar uma abordagem ágil, utilizando métodos como Scrum e XP? Minha resposta: devemos sempre adotar o que for melhor para cada projeto em particular.

Não devemos gerenciar projetos no estilo "by the book". Procurar por cartilhas que nos digam exatamente o que fazer é um caminho perigoso e que tem poder de levar um projeto ao fracasso. Um profissional sério deve se aprofundar no conhecimento dos frameworks e metodologias existentes no mercado para, como um médico, diagnosticar um quadro geral e indicar o tratamento mais adequado. É preciso entender a situação primeiro para depois poder traçar uma estratégia coerente, um plano de ação que seja eficaz para o case específico.

E por que não mesclar as técnicas para preencher as lacunas que cada método possui?

Podemos estar gerenciando com foco no PMBOK e mesmo assim aplicar técnicas ágeis como abordagem iterativa, cliente-onsite e reuniões de retrospectivas. Analogamente, podemos utilizar Scrum e aplicar técnicas como gestão de riscos e construção de uma visão para o produto. Conhecer mais ferramentas dá maior poder de escolha para o gestor, evitando vícios como a incessante procura pela "bala de prata" das metodologias, comportamento que engessa a atuação de qualquer profissional (não apenas de gestão).

Sendo assim, independente do método utilizado, há sempre dois pontos que são os mais importantes em qualquer projeto (especialmente os de software): pessoas e comunicação. Qualquer abordagem que priorize os complexos relacionamentos que existem entre os interessados de um projeto, facilitando a comunicação entre os envolvidos e buscando dar mais autonomia e responsabilidade às pessoas tem muito mais chance de terminar com sucesso.

O Poder do Pensamento Negativo

Recentemente, li um artigo intrigante sobre o poder do pensar negativamente a respeito das coisas. Esse autor defende uma tese muito interessante: de que ter uma visão mais pessimista nos torna mais preparados diante das situações do dia a dia, devido ao comportamento "pé atrás" que passamos a assumir ao agir. Em vários pontos do texto, ele mete o malho nos "polianas" de plantão e nos propagadores de ideias como "lei da atração", o "segredo" e outras baboseiras clássicas. 

De fato, esse "pessimismo defensivo" é um excelente neutralizador de surpresas desagradáveis. Ao pensar no que pode dar errado, bolamos maneiras de contornar o problema e proteger nossas atividades dos inevitáveis imprevistos.

Em gestão de projetos essa atitude tem um nome: chama-se Gestão de Riscos.

E o que seria um risco para o projeto? Segundo o PMBOK, a definição é a seguinte:

"Evento ou condição incerta que, caso ocorra, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade."

Esssa definição é interessante pois mostra que há também riscos positivos para qualquer projeto. Muitos acreditam que o risco é sempre algo negativo e que sempre resultará em efeitos adversos à atividade realizada. Obviamente, não estamos preocupados com os efeitos positivos inesperados e sim com os de efeito negativo.

Métodos e frameworks como RUP, PMBOK e CMMI encorajam uma abordagem disciplinada a respeito dos riscos de um projeto. A ideia é listar, tão cedo quanto possível, os riscos principais do projeto e tratá-los logo nas primeiras iterações. Entretanto, frequentemente essa prática é sumariamente ignorada pelas equipes, em prol da realização de atividades que mostrem "mais serviço pronto" ao chefe, como o desenvolvimento dos cadastros de uma aplicação. Essa atitude é a que provoca falsos inícios em um projeto, postergando as atividades de maior risco que podem gerar surpresas desagradáveis mais à frente (e é o que geralmente acontece).

Por isso, entre sempre com o "pé atrás" em qualquer projeto.

Ajuda a evitar dores muito fortes de cabeça...

Scrum e a Gestão Ágil

É consenso de que em projetos ágeis de software não há lugar para o gestor do tipo sabe-tudo,  aquele que controla o projeto por completo, assumindo a total responsabilidade pelo seu sucesso ou fracasso. Esse papel é frequentemente desempenhado pelos profissionais que seguem a cartilha do PMI, criando pouco (ou nenhum) espaço para adaptação e colaboração.

Por outro lado, há sim a necessidade de um modelo de gestão. É um erro achar que projetos ágeis se auto-gerenciam, como corretamente apontam Mike Cohn e Ken Schweber no artigo "The Need for Agile Project Management":

"One of the common misperceptions about agile processes is that there is no need for project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception."

Para gerenciar projetos, o Scrum trabalha com o modelo de gestão compartilhada, distribuindo responsabilidades entre os vários papéis presentes na equipe do projeto, a saber:

1 - Product Owner 

• Responsável pela Visão do produto.
• Controla o Product Backlog.
• Monitora o projeto contra os objetivos de ROI e Visão.
• Prioriza e refina o Product Backlog, medindo o seu sucesso.

2 - Scrum Master

• Monitora o processo para garantir o sucesso da equipe.
• Permite que o time se auto-organize.
• Remove obstáculos.
• Blinda o time contra perturbações externas.
• Promove rápidas reuniões diárias.
• Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint.

3 - The Team

• Seleciona e desenvolve as estórias do Sprint Backlog
• Expande as estórias em tarefas mais detalhadas.
• Completa 100% de cada tarefa escolhida.
• Gerencia e auto-organiza o próprio trabalho.
• Diariamente inspeciona o projeto para atingir os objetivos do Sprint

Cada papel dentro da Gestão Ágil direciona esforços para entrega frequente de valor e antecipação do ROI do projeto. Em projetos tradicionais espera-se a finalização completa do projeto para se ter retorno sobre o investimento aplicado; em Scrum gera-se valor a cada pequeno incremento durante o tempo, retornando o investimento muito antes da entrega do release final e oferecendo oportunidades reais de lucro antecipado.

 

Na Gestão Ágil a responsabilidade pelo sucesso de cada projeto depende da colaboração e do comprometimento de cada um dos papéis da equipe, o que diminui o risco de se ter o destino da empreitada nas mãos de uma única pessoa.