Análise, paralisia e agilidade

Por Cesar Brod

Data de Publicação: 11 de Maio de 2014

Desde o início dos anos 2000 trabalho com métodos ágeis. Mas, verificando que os métodos ágeis derivam da ética e atitude hacker (tudo pode ser melhorado, desde que o acesso ao conhecimento seja pleno), confirmo que esse trabalho começou há mais tempo.

Sempre que ministro algum treinamento, seminário ou palestra sobre métodos ágeis, tipicamente envolvendo Scrum ou Extreme Programming, faço uma releitura dos clássicos e acompanho, com ainda mais atenção, o que os agilistas que admiro andam fazendo e escrevendo. Isso acaba por se refletir em meus tweets, posts em meu blog e artigos que escrevo para o Dicas-L. Os amigos mais próximos percebem isso e me perguntam: "Onde será o treinamento dessa vez?" - Os mais recentes aconteceram para equipes da Unicamp.

Tive a grata oportunidade de participar, no intervalo dos cursos que ministrei no início de maio, do 3.o CINFOTEC - evento de Comunicação, Informação e Tecnologia na Unicamp - e de conversar com quase todos os palestrantes. Em especial, o Mauro Cesar Bernardes, da USP, falou sobre modelos e metodologias para a gestão de TI na palestra imediatamente anterior à minha e pude, com seu consentimento posterior, roubar várias de suas ideias para usá-las como mote dos tópicos que cobri na minha. Há muitas coisas que, de tão óbvias, a gente esquece e, por isso, o óbvio deve ser repetido sempre.

Usando o gancho do Mauro, aproveitei para enfatizar, em minha palestra sobre Scrum, que a equipe de desenvolvimento, o Scrummaster e o Product Owner, mais do que sempre manterem em mente e à vista a visão completa do que estão desenvolvendo, devem também zelar pelo alinhamento com o planejamento estratégico da instituição na qual trabalham ou para a qual trabalham. Um dos cheiros ruins de um Scrum é quando o Scrummaster vira o gerentão da equipe, a isola e deixa de colaborar - passando a antagonizar - com o Product Owner, os patrocinadores e cliente. Quem conhece a analogia entre porcos (entram com o toucinho) e as galinhas (entram com os ovos) em uma equipe de projetos, percebe a assustadora metamorfose de uma equipe de porcos comprometidos em uma galinha velha com seus pintinhos embaixo de suas asas, criando pichilingas.

O que tem que acontecer é justamente o contrário: a união, o respeito e a produtividade de uma equipe Scrum, sempre mantendo uma visão holística que combina seu trabalho à estratégia da empresa, faz com que sua atitude ágil se expanda muito além de seus limites.

Mas, voltando ao óbvio, quando Kent Beck definiu a disciplina Extreme Programming, ele propôs uma reflexão sobre a forma como programaríamos se tivéssemos tempo de sobra para isso. Assim, ele juntou uma série de práticas simples que já eram de conhecimento de bons programadores (incluindo seu pai) e as formatou para que, sem burocracia, uma prática servisse de apoio à outra.

O livro Extreme Programming Explained do Kent Beck é uma de minhas leituras de cabeceira quando estou ministrando um curso ou atuando como "coach" de equipes ágeis. Outro é o Scrum Shortcuts without Cutting the Corners, do Ilan Goldstein. Ilan sempre nos alerta sobre a análise exagerada que leva à paralisia: afinal, uma excelente desculpa para não se fazer algo é a de que não sabemos o suficiente para começá-lo. Então voltamos ao Kent Beck, que nos diz que talvez devamos começar a desenvolver algo a partir de um plano simples, que possa ser refinado na medida em que avançamos no desenvolvimento.

Ninguém sabe tudo sobre tudo e ninguém nunca saberá, nem mesmo dentro de um dos muitos domínios de conhecimento. Antes de ser um motivo para angústia, isso deve ser um convite à exploração. Viaje com uma mala leve, com algum espaço para colocar novidades dentro dela e a ciência de que você terá que deixar algumas velharias pelo caminho. Não queira decorar tudo o que está escrito nos guias de viagem para, só daí, botar o pé na estrada. No dia em que você achar que aprendeu tudo sobre o seu destino, ele já não será mais o mesmo descrito no início de sua leitura.

Ao desenvolver um novo sistema, produto ou serviço, use a metáfora da viagem. Comece com o essencial, aquele conjunto de coisas realmente importantes e que podem ser transformadas em algo do qual os usuários, os clientes, a empresa já podem se beneficiar. Faça com que eles participem com dicas para que a jornada da construção seja a mais agradável para todos. Permita que todos sejam passageiros nessa jornada.

Afinal, ou você faz essa escolha ou vai ficar a vida inteira lendo livros de viagem e imaginando o que poderia ter sido e não foi. Ou continuar levantando, eternamente, requisitos para sistemas que jamais evoluirão além da paralisia causada pela análise infinita.

Abraços para os novos amigos das minhas turmas de Scrum na Unicamp: Edmar, Tácio, Fernando, Gustavo, Fábio, Marcelo, Mauricio, Neile, Newton, Sérgio, Takao. Um grande abraço à toda a família Queiroz de Almeida, que mora no meu coração. Grato ao Eugênio Marques, da Sysvale, que contribuiu com a metáfora da criação de Pichilingas.