Agile não é um conceito exatamente novo. A metodologia já está aí no mercado há alguns anos e extremamente bem difundida e aplicada por alguns segmentos. No entanto, para algumas empresas onde o tipo de atuação não proporciona o mesmo cenário que àquelas onde o método ágil já é utilizado em larga escala, a empreitada se torna um pouquinho mais complicada. Nos diferentes capítulos desse Diário AGILE, vamos debater sobre a metodologia e a abordagem na hora de provocar uma mudança para se utilizar mais dos métodos Ágeis em projetos.

É importante dizer que a metodologia Ágil, ou Agile, foi primeiramente utilizada para desenvolvimentos de software, onde o método clássico de gestão de projetos tornava tudo mais penoso já que a premissa básica é se ter um escopo firme com requisitos do cliente bem definidos para então se iniciar a construção do produto final. Mas o que acontece quando esses requisitos precisam sofrer alterações constantes e se adaptar a um mercado agressivamente em evolução?

Imagine o seguinte: Você como cliente solicita à uma empresa terceira que desenvolva um aplicativo para executar o gerenciamento financeiro da sua empresa, com fluxo de caixa, custos, tabelas de preços, relatórios com aqueles sinais verdes, amarelos e vermelhos e tudo isso que gostamos de ver em softwares de gestão. Na cabeça do cliente (você) tudo é claro como água e todos os requisitos e interfaces já estão desenhados. A equipe de desenvolvimento então extrai esses requisitos, desenha um plano, um mapa, coleta sua validação e começa os trabalhos. Após seis meses, eles entregam o trabalho final e o aplicativo com todas as suas funcionalidades.
Qual o problema com esse cenário?

A história acima parece simples e sem muitos riscos, mas os grandes desafios em projetos de softwares são: a.) se manter atualizado frente ao mercado e b.) ainda atender as expectativas do cliente (vamos falar mais detalhadamente sobre “expectativas” em uma outra hora aqui no blog).
Em uma maioria massiva, projetos com o escopo acima e desenvolvidos seguindo esse roteiro clássico de gestão de projetos, falham miseravelmente. É esse justamente o gatilho que vai dar início ao método Ágil de projetos.

Quando se desenvolve um aplicativo, um software ou um sistema (como quiser chamar), uma prática extremamente saudável é a constante entrega de pequenos pacotes ao cliente para que ele(a) possa ir testando algumas funcionalidades e interfaces em paralelo ao desenvolvimento. Essa prática minimiza o esforço (consequentemente o custo e o tempo) em potenciais grandes modificações ao final dos trabalhos, ainda alinhando as expectativas do cliente conforme o bonde anda. Esse método, dentro do mundo Ágil, gera ciclos de entregas + testes + feedback + ajustes + desenvolvimentos e isso se repete até a última entrega derradeira, quando o cliente já sabe exatamente o que está prestes a receber.

Se isso tudo fez sentido até agora, como fazemos para aplicar o mesmo approach em projetos nos quais o escopo de forma mandatória precisa ser congelado ao início do projeto, sem muito espaço para revisões intermediárias? Por exemplo o desenvolvimento de um novo motor, ou uma nova transmissão. No mundo automotivo é muito comum se trabalhar arduamente com os clientes e as equipes de engenharia para atingir o estado de “design freeze”, ou seja, quando as especificações de qualidade e performance foram alinhadas e tecnicamente sabe-se o que deve ser feito. Somente então, as construções se iniciam para preparar fornecedores, sistemas de manufatura e equipes para produzir o novo vindouro produto. Nesse cenário, modificações ao longo do projeto são extremamente caras e podem levar meses ou anos até serem testadas e validadas por ambas as partes, cliente e fornecedor. Esse é o que chamamos de um cenário mais clássico em gestão de projetos, onde os requisitos iniciais são a lei, e o escopo se enrijece muito mais rápido do que em um ambiente Ágil.

Importante frisar que não há certo ou errado aqui. A natureza do seu produto e do seu business vai ditar qual a melhor ferramenta de trabalho. Se quiser martelar um parafuso ao invés de usar uma chave de fenda, você vai conseguir, mas nem precisamos detalhar aqui a diferença no esforço. Existe por aí no mercado um zilhão de métodos e ferramentas de gestão de projetos e só uma certeza: nenhuma é perfeita para todas as aplicações. Seja flexível, crítico e teste as ferramentas até achar a ideal.

Voltando ao nosso caso acima, o que acontece quando a indústria automotiva e a indústria de tecnologia se colidem? Esse é exatamente o cenário em que estamos agora, onde carros se tornam mais inteligentes todo dia e sabemos que a grande meta é fazer com que andem sozinhos por aí de forma eficiente e mais sustentável. Nessa grande mistura qual a melhor ferramente a ser utilizada, já que estamos pegando um pouco dos dois mundos?

Ainda não tenho a resposta…

Nesse Diário AGILE vou trazer algumas das experiências que temos enfrentado na tentativa de consolidar as diferentes necessidades desse novo mundo automotivo, incluindo gestão de projetos, método Ágil e minimizado esforços ao longo dos desenvolvimentos (custo, tempo e modificações), mas ainda se utilizando dos conceitos básicos Agile dentro do time de projeto. Será que vai dar? No próximo capítulo eu conto mais.

Rafa Vulcani