Práticas Ágeis em Projetos que NÃO são de Software

Os métodos que vêm debaixo do chamado guarda-chuva “Agile” incluem abordagens como, por exemplo, o Scrum, o RUP (Rational Unified Process) e o XP (Extreme Programming), todas feitas para projetos de software. 

Apesar disso, muitos seguidores  do “Agile” costumam apresentar essa filosofia de gestão de projetos como uma verdadeira bala de prata para qualquer tipo de projeto, ou seja, o jeito mais moderno de gerenciar um projeto de software ou de qualquer outro tipo, alinhada a filosofia “lean manufacturing”, que faz o projeto acontecer de forma rápida, que corta desperdícios com coisas desnecessárias, que reduz custos e outros benefícios.  

Essa ideia de entender que o “Agile” (ágil em português) seria o mesmo que rápido, esquecendo as premissas que formam a base do conceito do “Agile”, costuma ser explorada por algumas empresas, na ânsia de convencer seus colaboradores que eles (e elas) precisam trabalhar mais depressa, a ao mesmo tempo sem perder a precisão e o foco, para alcançar o sucesso nos projetos que desenvolvem em um tempo menor do que o de costume. A bala de prata, a tal solução para todos os problemas, para evitar o fracasso dos projetos, está na abordagem “Agile”. Todos querem o tiro certo, sem desperdício, e se você não sabe trabalhar com algum método ágil, você não serve mais para a empresa. Trate de se modernizar, ou será chamado de retrógrado e ultrapassado! E isso será usado até que uma nova bala de prata seja descoberta.

Pesquisas apontam que as causas principais de fracasso em projetos se referem a mudança de escopo, falta de comprometimento das equipes, incorreções no business case, falta de recursos, prazos inexequíveis e riscos não gerenciados. Há ainda outras causas como incapacidade gerencial, falta de comprometimento da alta direção, falta de método para gerenciar o projeto e habilidade técnica insuficiente. Mas, a primeira causa de fracasso de um projeto (aproximadamente 70% das causas de fracassos em projetos) está associada as constantes mudanças de escopo. O projeto é iniciado e apesar de não se saber bem o que precisa ser feito, o projeto segue adiante e em algum momento se descobre que alguma coisa está faltando (ou está incorreta, ou imprecisa, ou a mais, ou a menos), sendo necessário acrescentar alguns itens no escopo não considerados no plano original, ou retirar itens inicialmente inclusos e que nesse ponto do projeto se mostram desnecessários. Então, sim, um planejamento mal feito ou apressado, pode ter graves consequências para o projeto. Da mesma forma pode acontecer do cliente - que está pagando pelo resultado que o projeto se propõe a entregar - não saber exatamente do que precisa. Durante a reunião de aprovação do projeto pode surgir a seguinte frase dita pelo cliente: - É o seguinte pessoal, eu quero um resultado bem legal, e assim vocês vão desenvolvendo e eu vejo se vai ficar bom e se eu gostar, seguimos em frente”.  Nossa, o “máximo”! 

Quando se trata de projetos de software não saber exatamente o que será feito no início do projeto não é algo assim tão incomum. Por exemplo, alguém pode ter uma ideia para um aplicativo que pode gerar milhares de dólares e isso ser apresentado de forma geral do ponto de vista técnico e, ao mesmo tempo, algo bastante atrativo ponto de vista financeiro. Em outras palavras, no início não se sabe exatamente como o aplicativo vai rodar, como serão as opções no menu do usuário para que tudo funcione perfeitamente, além de outros detalhes operacionais. Essas coisas serão feitas durante o projeto. Por conta disso, será necessário ter a mente aberta e ser flexível com o escopo do projeto. 

O pessoal que elaborou o Manifesto Ágil, de 2001, estabeleceu princípios que orientam como o trabalho deve fluir nos projetos de software, e consideram quatro aspectos:

• Comunicação: indivíduos e interação entre eles mais que processos e ferramentas;
• Praticidade: Software em funcionamento mais que documentação abrangente;
• Alinhamento de expectativas e colaboração: colaboração com o cliente e membros do projeto mais que negociação de contratos;
• Adaptabilidade e flexibilidade: responder a mudanças mais que seguir um plano.

A boa comunicação interna e externa (entre os membros da equipe e com o cliente) é ressaltada. Através dessa boa comunicação e constante alinhamento de expectativas o software é produzido de forma prática (mais software funcionando e menos documentação). A equipe do projeto deve estar aberta as mudanças de escopo, ao invés de ficar protegendo o escopo original inicialmente considerado. Essa flexibilidade – diretamente ligada à forma como o projeto trata as mudanças de escopo - é vital para que o resultado seja realmente alinhado aos desejos e anseios do cliente. No Scrum, por exemplo, o método ágil mais utilizado, o projeto é desenvolvido em rodadas de curta duração chamados de sprints. Cada sprint tem, tipicamente, entre 2 a 4 semanas. Um escopo inteiro do projeto - que produz o software completo - é dividido em partes. Digamos, apenas para ilustrar, que para desenvolver o software completo do nosso exemplo, sejam necessários 10 sprints. Durante cada sprint são realizadas reuniões diárias de andamento do projeto e partes do software são desenvolvidas para serem entregues ao cliente. A estratégia aqui é a mesma inventada pelos Romanos: Dividir e vencer. O fato de trabalhar criando partes menores em um curto espaço de tempo (de 2 a 4 semanas) é um facilitador importante para discutir/negociar/fazer modificações no software em função de eventuais solicitações de mudança pelo cliente. Apenas para comparar, seria muito mais difícil responder as mudanças se o projeto estivesse sendo gerenciado considerando fases longas de um cronograma.

Os projetos de software têm suas características próprias e, evidentemente, têm várias diferenças em relação a outros tipos de projetos. Apesar dessa questão óbvia, vale a pena fazer uma comparação com os projetos de construção civil, que costumam usar o método cascata (gerenciamento de projetos tradicional que adota as melhores práticas do guia PMBOK do PMI). Aqui vamos tratar de apenas um aspecto bastante simples, mas que mostra não ser tão fácil ser flexível com o escopo do projeto. Digamos que, por exemplo, o cliente que está comprando um prédio de dez andares decide, depois de concluídas as fundações da edificação e parte das paredes dos primeiros andares, que esse prédio deve ter quinze andares. É óbvio que acrescentar cinco andares à essa edificação causaria problemas ao projeto, uma vez que tudo no prédio foi calculado para um total de dez andares. Na prática, para aceitar essa mudança seria necessário derrubar o que foi feito e reiniciar a construção. Ser flexível com a mudança de escopo aqui não é uma opção. Uma mudança de escopo que geraria impactos negativos (atraso no cronograma, estouro no orçamento, etc). Portanto, essa solicitação de mudança não seria aprovada!  Como o exemplo do prédio de dez andares do ramo da construção civil, há muitos tipos de projetos que necessitam ser muito bem definidos desde o seu início. Esses projetos precisam ser muito bem planejados e seus escopos muito bem definidos, e se isso não é contemplado o risco do projeto fracassar é bem real.

Sim, mas não há nada que possa ser aproveitado dos métodos ágeis em outros tipos de projeto que não sejam de software? Me parece que a resposta é sim. Então, vejamos algumas ideias que, sempre que possível, podemos usar:

Criar uma lista de itens prioritários (similar ao “backlog”do Scrum) – isso ajuda a decidir o que será feito. 

Escrever descrições resumidas sobre o que será feito (similar as “user stories”do Scrum) – isso facilita o planejamento e a discussão sobre o que será feito.

Mostrar em um quadro ou mesmo na parede, para a equipe e as partes interessadas, o progresso do projeto (similar ao Kanban) – isso permite ter uma visão geral do trabalho que está sendo feito. 

Definir períodos curtos de tempo para executar partes do trabalho do projeto (similar aos sprints do Scrum) – isso facilita o planejamento/controle do trabalho da equipe do projeto para executar o que será feito.

Adotar reuniões rápidas e diárias de acompanhamento do progresso do projeto com o pessoal da equipe de pé, e com duração máxima de 10 minutos (similar as standup meetings do Scrum) – isso facilita a comunicação através de reuniões objetivas e focalizadas no trabalho que está sendo feito.

Organizar reuniões de retrospectiva ao final de cada período de trabalho (similar as retrospective meetings do Scrum) – isso possibilita discutir o que funcionou e deu certo e o que não deu certo no projeto e precisa ser melhorado ou mesmo descartado do ambiente do projeto.

Bem, é isso aí! Até a próxima!