Vou lhe compartilhar um pensamento que talvez pareça um pouco radical, contra-senso, complexo de Peter-Pan  ou que é da influência hippie e comunista que recebi dos meus pais quando criança, porém, caso você esteja iniciando uma empresa nesse momento, permita lhe dar uma pequena sugestão: “Não Cresça!”.

Essa minha humilde opinião é oriunda da constatação de que as empresas ditas como “grandes” têm uma complexidade de funcionamento e de pensamento tão evidente, que simplesmente é muito difícil ou até mesmo impossível fazer as coisas certas acontecerem nessas organizações.

(mais…)

Aqui estou com o “CMMI – Guidelines for process Integration and Product Improvement” na minha frente, tendo acabado de ler o excelente post do Willi sobre PMBok e Agile. (Me lembro agora como fiquei impressionado com a estruturação desse livro. Cada referência é feita com uma precisão cirúrgica. Cada coisa tem um código, cuidadosamente atribuído e utilizado para remeter aos tópicos citados. )

A discussão sobre se “é possível aplicar PMBok/RUP/CMMI/MPS.Br com Agile” não faz mesmo muito sentido, no fim das contas. Todas essas siglas do time das metodologias tradicionais, não passam de diferentes visões a respeito do processo de desenvolvimento. Tratam-se de modos diferentes de se entender um “mundo” específico: o de projetos de desenvolvimento de software (Eu sei, não se aplicam apenas ao desenvolvimento de software, mas isso não é importante agora).

Modo de entender também específico, diga-se de passagem. São visões essencialmente analíticas, que procuram clarear as coisas “destrinchando” ou “separando” seus elementos, numa estratégia “dividir e conquistar”. O oposto seria o entendimento sintético, onde se parte de vários elementos e compõe-se um todo, como fazemos ao concluir um texto: juntamos tudo o que foi dito para se reconstruir a idéia geral novamente.

Sob esse ponto de vista, conjuntos de conhecimento como PMBok e CMMI seriam muito bem apresentados em um MapaMental.

(conteúdo tirado da wikipedia)

Cá pra nós, trata-se de uma bela análise de todos os elementos necessários à grande maioria dos projetos de software. Alguns vão descordar com o meu “necessário”. Muitas dessas coisas podem não ser realmente necessárias… Será? Peguemos alguns elementos como exemplo.

• Controle de mudanças do escopo

“Ora, em meu projeto ágil eu não preciso fazer controle das mudanças do escopo.”

Como não? E o que é que estamos fazendo quando não permitimos, de jeito nenhum, mudanças no backlog ao longo de um sprint? Só permitimos que novas tarefas entrem no planejamento a partir de uma reunião com toda equipe. Pra que? Pra que se possa controlar as mudanças no escopo, oras. Se a equipe não tiver controle sobre as mudanças no planejamento, não poderá lidar com elas.

• Gerênca de riscos

“Não tenho um plano de riscos em meu projeto ágil.”

Pode ser. Mas dizer que não há gerência de riscos já é demais. Os riscos são gerenciados o tempo todo. Pelo product owner ao escolher histórias durante o planejamento; pela equipe ao estimar; pelo coach ao cultivar a disciplina em se escrever testes automáticos. Todos avaliam os riscos de cada passo ao longo do projeto.

Dê uma olhada na estrutura de tópicos desses livros. São análises extremamente detalhadas, completas e estruturadas. Trata-se de um trabalho de mestre. Identificar, estruturar e descrever cada um desses elementos foi sem dúvida um trabalho notável e de grande valor para nossa indústria. Obrigado.

O problema não está exatamente na análise que essas abordagens fazem. As análises são espetaculares. O problema é que, no dia a dia de um projeto, essas análises são inúteis.

É como comprar um manual de direção de automóveis que faz uma análise detalhada de todas as técnicas para se apertar a embreagem, o momento ideal para se passar as marchas, etc. Por mais detalhado e acertado que esteja o manual, não ajuda nada levá-lo no colo na hora de dirigir. Nem adianta estudar cada detalhe e tentar lidar com tudo de uma vez.

No momento de dirigir, o que importa não são os detalhes, mas o todo. Tentar visualizar, compreender e controlar cada um dos elementos envolvidos é ao mesmo tempo inútil e desgastante. É coisa demais.

Isso nos leva diretamente ao argumento do Willi. Ninguém disse que se precisa aplicar tudo o que está nos livros. Pelo contrário, os capítulos iniciais de todos eles afirmam categoricamente que tudo deve ser adaptado, escolhido, filtrado. O problema é que nenhum deles explica como as coisas devem ser escolhidas, nem tampouco adaptadas. As práticas precisam ser modificadas para o seu projeto especificamente. Mas como? Problema seu.

Dessa forma, a leitura subliminar que se faz é que os projetos devem ser gerenciados sob todos os aspectos. Quanto mais detalhes se consegue visualizar e documentar, mais maduro seu processo é. Sobre isso cria-se uma escala de mérito totalmente deturpada, baseada em inspeções, avaliações, provas, exames e outras atrocidades. Elementos artificiais, que contribuem apenas para enviesar ainda mais o processo de melhoria, cuja preocupação maior passa a ser o certificado que se ganha no final. (Não me parece muito um sinal de maturidade… :-/ )

XP e Scrum, ao contrário, não fazem leituras analíticas. Lidam com questões práticas que se sustentam através de uma cadeia de valores explícita e coerente, reflexo das necessidades reais de projetos reais. Você adora cálculos geométricos complicados e instrumentos de precisão. Ótimo, mas para levantar a parede reta seu pedreiro precisa é do fio de prumo.

Pra ser honesto, no livro mais importante sobre XP (na minha opnião), KentBeck faz também uma leitura analítica: XP divide-se em valores, princípios e práticas. Mas veja que nesse caso não se trata de uma análise do processo de desenvolvimento em si. A análise feita refere-se ao modelo de pensamento utilizado para sustentar as práticas.

Essa sim é uma análise relevante. Ela privilegia não uma visão específica de como se deve fazer software, mas uma estrutura de decisão que nos auxilia a definir como as coisas devem ser adaptadas em cada caso. Diferentemente dos livros citados acima, aqui a forma como as coisas devem ser adaptadas é clara e coerente.

O próprio Kent Beck ressalta que os princípios apresentados em seu livro não são os únicos possíveis. Organizações particulares podem cultivar outros valores, outros princípios. E elas devem fazê-lo! O que se coloca é que se deve utilizar uma cadeia de raciocínio análoga para se definir como deve ser o dia a dia dos projetos. Entenda seus valores, expresse seus princípios e deles derive as práticas a serem seguidas.

“Para dirigir, use as duas mãos ao volante.” Isso expressa o princípio da direção defensiva, que se sustenta sob o valor Segurança. Agora, se prefere cultivar o valor do Conforto, então deixe o braço esquerdo escorado na janela, é muito melhor. Qual dos dois valores é mais importante agora? Eis um framework para tomada de decisões realmente útil.

Então, sintetizando , o problema de PMBok/RUP/CMMI/MPS.Br não está exatamente na análise que é feita, mas na leitura (propositalmente?) induzida de que se tratam de manuais de direção. Não são. São instrumentos teóricos maravilhosos. Mas se vc está interessado em dirigir bem, deixe-os em casa e veja as coisas da forma ágil.

(Artigo publicado originalmente no eXPressoCapital)

Sobre o Autor:

Bruno Pedroso

Bruno Pedroso é Bacharel em Ciência da Computação pela UnB, onde atualmente desenvolve seu projeto de mestrado em engenharia de software. Desenvolvedor com mais de 10 anos de experiência, atua hoje como coach de projetos e coordenador da área técnica da SEA tecnologia, dando grande enfoque à aplicação de valores e princípios XP.