Eu uso metodologia ágil, e você?

Como vender a utilização de metodologias ágeis em projetos para organizações tipicamente tradicionais?

por Fabio Camara

Como vender a utilização de metodologias ágeis em projetos para organizações tipicamente tradicionais? Diferente de outros assuntos técnicos que beiram questões religiosas (ver discussões entre Java e .Net), há nos diretores e gerentes das corporações uma prudência racional que independe de metodologia. Na verdade, todo gestor sensato quer avidamente três premissas realizadas em seus projetos: o negócio atendido, o orçamento respeitado e o cliente satisfeito (não necessariamente nesta ordem).

Um caso prático

Iniciamos a reunião na grande sala, muito luxuosa para os padrões que estamos acostumados a trabalhar. Havia cerca de três empresas representadas na sala e aparentemente todas na mesma situação.

Um diretor de TI de uma respeitável organização me perguntou: _O que está acontecendo com os projetos hoje? _ Simples, a TI é lenta demais e os negócios são muito rápidos - ele mesmo respondeu. Isso tem 10 anos no máximo e seu surgimento confunde-se com a utilização da Internet, mas é a dura realidade atual dos projetos de software.

_ Seu papel hoje nesta reunião é me fazer compreender o motivo pelo qual eu permitiria você implantar suas técnicas ágeis em meu departamento de TI, me disse o diretor com verdadeiro desdém. E continuou falando: Argumentos relacionados com o controle do sucesso do projeto, principalmente do ponto de vista financeiro, são argumentos inválidos se compararmos técnicas ágeis de controle e técnicas baseadas em PMBok. Portanto seja mais criativo que isto!

Ele passou ainda uns 30 minutos expondo toda sua descrença, eu até pensei que a reunião acabaria e eu não teria chance de falar. Abruptamente ele cala-se e olha para mim. Entendi imediatamente que chegou minha vez. Cerca de oito pessoas caladas numa mesa oval esperando um argumento mágico vindo de mim.

Colhendo a motivação

Comecei trazendo novas questões, não que eu quisesse ganhar tempo para estruturar os meus argumentos, mas eu precisava entender porque este diretor com a opinião contra metodologias ágeis resolveu me receber numa reunião. Eu simplesmente queria entender o que estávamos fazendo ali naquela sala de reunião luxuosa.

_ Parece-me que os problemas foram bem explanados, contudo não consegui captar a motivação. Qual a motivação de vocês para buscar mudanças? Entendi que não estão plenamente satisfeitos com as técnicas que utilizam hoje, entretanto percebi que estão acostumados com as técnicas e acomodados com os resultados alcançados. Sendo assim, para que conhecer possibilidades diferentes de técnicas e conseqüentemente de resultados?

O diretor imediatamente questionou-me em tom mais alto ao invés de responder: _ Você está afirmando que estamos acomodados? Minha resposta politicamente inadequada foi: _ Independentemente de classificar se há ou não há "zona de conforto", quero apresentar a minha leitura sobre o significado da palavra insanidade. Insanidade para mim é esperar por resultados diferentes sem fazer nada diferente. Há alguns anos se praticam as mesmas técnicas, como podemos esperar resultados diferentes?

_ Aonde você quer chegar? Retrucou o diretor irritado.

Quero encontrar a motivação! Respondi sem mostrar intimidação. As propostas ágeis são tão sérias como todas as propostas de metodologias que você conhece, portanto se não há motivação para mudanças e o objetivo é apenas comparar uma técnica com outra, avise-me, pois trilharei por caminhos mais teóricos neste caso.

Neste momento eu sabia que a reunião iria longe, porém eu precisava "recuperar" o diretor. Procuro uma resposta simples, a mais simples que vier em sua mente agora, por favor me responda o que estamos fazendo aqui agora.

_ Meu cliente não está se sentindo bem atendido! Escapuliu da boca do diretor. Muito obrigado, eu respondi em cima.

Obtendo o cenário

A organização de nosso departamento de TI é formada por três sub-áreas: uma espécie de escritório de projetos, uma área de qualidade e a área de desenvolvimento propriamente dita. Obviamente temos pessoas de infra-estrutura que também são responsáveis pelos ambientes de desenvolvimento, testes e produção.

Com este cenário procuramos ter controle de todas as atividades, porém mesmo assim vivemos um dilema: _ se atendemos aos pedidos dos usuários após o escopo definido, perdemos o controle sobre o orçamento e prorrogamos o prazo; _ se congelamos o escopo previamente definido, apesar de entregar com o orçamento previsto e no prazo combinado, nossos clientes afirmam que não foram atendidos.

_ Afinal, o que podemos fazer diferente? Perguntou o diretor em tom mais amigável.

Explicando os motivos

Vejo muito naturalmente em seu cenário o conflito de atividades de controle, também chamadas atividades de conformidade, com atividades de resultado. Apesar de ser um problema comum, não há literatura acessível ou cursos que orientem a compreensão e resolução deste conflito.

As atividades de controle focam em corrigir desvios e não no aprendizado, ou seja, partem do principio que o plano sempre tem que ser perfeito. Se o plano inicial precisa ser alterado, refaz-se imediatamente todo o plano. Isto explica também porque os técnicos não gostam quando os usuários pedem mudanças, pois é muito trabalho seja lá qual for o tamanho da mudança.

Quando afirmo que não há aprendizado neste cenário, caracterizo assim porque ninguém se propõe a entender o porquê do novo pedido do usuário ou da mudança sobre algo previamente combinado. É uma atitude binária, "sim" vamos fazer e o impacto será revelado posteriormente ou "não" podemos, pois o impacto será fatal ao projeto.

Deve haver uma razão para tantas mudanças ou para inúmeros pedidos novos, quando vamos nos responsabilizar em compreender isso e transformar nossa atitude?

O controle de qualidade, da forma automatizada que vocês usam, consome uma enormidade de tempo. Este tempo extra com qualidade, além de consumir mais atividades de conformidade, também são muito questionadas pelos "sponsors 1" dos projetos.

A mistura de atividades de controle e atividades de qualidade no seu cenário, criam um efeito "bola de neve" em seus projetos. Nestes projetos com problemas, vocês aumentam a prioridade das atividades de conformidade na tentativa de retomar o plano perfeito ao invés de aumentar o foco nas atividades de resultado. Vocês aumentam os testes acreditando que a inspeção é a melhor forma de proteger-se da decepção do cliente. No fim, mesmo tendo trabalhado arduamente durante todo o projeto, há uma sensação em todos de que não foi legal.

Uma direção diferente

É necessário quebrar o paradigma de replicabilidade e adotar o paradigma da confiabilidade.

• Replicabilidade: entradas e saídas planejadas inicialmente e com pouca variação;
• Confiabilidade: foco na saída, flexibilidade na entrada e aproximação do cliente.

Muitas metodologias propõem uma espécie de framework para encaixotar o relacionamento com clientes e desenvolvedores como se fossem robôs. Os seres humanos são dotados de uma fantástica criatividade capaz de surpreender, sempre. "Robotizar" o comportamento de nossos clientes e desenvolvedores é transformar a expectativa de um projeto solucionador para o negócio na monotonia de mais um sistema de software.

Se você não confia em seu cliente e na sua equipe de desenvolvimento, porque está iniciando este projeto?

Se o cliente não é confiável, use de prototipação e entregas freqüentes de código funcionado, se possível em intervalos de 2 semanas.

Se a equipe não é confiável, estabeleça estimativas junto com eles, ou seja, todos participam da medição do projeto. Faça reuniões diárias em pé, de aproximadamente 15 minutos, respondendo as seguintes perguntas:

1. O que nós conseguimos fazer ontem?
2. O que nós iremos fazer hoje?
3. O que pode nos impedir alcançar nosso objetivo?

Classifique e priorize as atividades junto com seu cliente, deixando atividades de menor valor para o final de projeto. É quase que afirmar: faça do mais difícil para o mais fácil.

Desta forma, novos requisitos podem ser trocados por requisitos de menor valor que seriam desenvolvidos mais para o final do projeto.

Nos testes, pense que automação é muito bom para garantir que determinados comportamentos do software não sejam perdidos diante as alterações. Na fase de construção, isso não tem tanto valor. Recomendo aplicar técnicas baseadas em "testes comportamentais 2" durante esta fase, pois são mais simples, mais econômicas e eficientes.

Pratique isso por 3 meses e avalie os resultados.

A receita final

Mesmo entendendo que muitos executivos querem simplesmente comprar uma metodologia como um segredo mágico, fala-se a palavra certa e tudo funciona, não constatamos isso em nosso mundo real.

Metodologia não se compra, se implanta. Depende dos próprios executivos, dos gerentes de projetos e principalmente do fator humano presente. Entenda-se por fator humano o respeito a intuição criativa dos clientes e desenvolvedores.

Temos comprovado que quando se trabalha sério com propostas de mudanças e motivação na equipe, com 3 meses já alcançamos resultados diferentes. Para a autonomia técnica plena da equipe pode ser necessário mais tempo, entretanto quando sponsors percebem progresso, qualquer investimento se justifica e tudo fica mais fácil.

A participação de um consultor externo fora da dinâmica dos projetos existentes tem se demonstrado um acelerador providencial. Apenas recomendamos cuidado para ratificar o conhecimento prático deste profissional, pois implantar ciclo de vida de desenvolvimento é sempre bem mais profundo que as teorias podem alcançar. A melhor forma de se certificar sobre o consultor é verificando seu histórico de realizações.

Resumindo conclusivamente, é necessário entender a diferença entre risco e atividade. Quando você cadastra uma atividade em seu aplicativo específico de controle de atividades, você espera uma tarefa detalhada e um produto resultante desta atividade associado.

Quando você cadastra um risco no mesmo aplicativo, o que fazer? Todo risco impõe uma mudança de atitude para que resultados diferentes aconteçam.

1 Sponsors: são executivos e / ou clientes que aprovam o orçamento do projeto e são responsáveis pelo pagamento.

2 Testes Comportamentais ou Behavioral Tests: Técnicas de testes baseadas na interação do ser humano com os produtos desenvolvidos. Destaca-se pela facilidade de implantação e pelo baixo investimento. Para saber mais visite o site http://www.fcamara.com.br.

Sucesso em seus projetos,

Fábio Câmara

Fabio Camara (fabio.camara@vstsrocks.com.br) é MCT, MCP, MCAD, MCPD, MCITP, MCTS, MCSD.NET, MSF Practitioner, Certified ITIL Foundations e Certified SCRUM Master - Acredita em bons resultados em projetos com técnicas ágeis, principalmente para as características do mercado brasileiro. Ministra treinamentos e "coaching" para projetos conforme pode ser verificado no site http://www.fcamara.com.br.