Como Fazer…

Há alguns anos, se bem me lembro em 2008, tomei conhecimento de algumas metodologias de gerenciamento de projetos e desenvolvimento de software ágeis, como XP e Scrum. No início, senti muita curiosidade e apesar de serem metodologias consolidadas (como fiquei sabendo depois), ouvi muitos profissionais da ativa (incluindo ensinadores) falarem contra argumentando que era apenas ‘onda do momento‘. Na época, não concordei com eles por que não fui capaz de entender as preocupações: Eram profissionais ativos que adotaram alguma das metodologias tradicionais (Cascata, prototipação, iterativo, RUP) e analistas com alguns anos de experiência agregada, logo sua vivência sugeria que antes de partir para a implementação de um software, primeiro o analista deveria se debruçar sobre os requisitos e elaborar diagramas descritivos de casos de uso, de classes, de componentes, de atividades, de objetos, etc. Esse era o caminho ‘racional’ para se extrair conhecimento antes da implementação. Não se deixava de conversar com os usuários, claro, mas, uma vez ‘coletados’ os requisitos, era papel do analista destrinchá-los de forma a compreender de que forma a coisa deveria funcionar como sistema. Nesse ponto, aplicar-se-ia um processo cuidadoso de verificação das relações entre as classes/objetos para que se pudesse abstrair e aplicar design patterns de acordo com a necessidade do sistema a ser produzido. Como diziam: ‘Durante a análise, não interessa a linguagem’, mas isso era apenas uma afirmação sem muito nexo, uma vez que a maioria deles já tinham suas linguagens de programação em vista (Object Pascal, Java ou C++). E, sim. Suas preocupações eram legítimas e sustentadas por suas experiências.

Todo mundo erra, se não tem elementos suficientes para tirar uma conclusão

Passado algum tempo, a mesma preocupação me atingiu o queixo com um gancho de esquerda. Eu vinha pensando sobre como trabalhar em equipes usando desenvolvimento ágil na maioria das vezes tornava complicado aplicar corretamente as melhores técnicas de desenvolvimento. Eu conhecia bem os princípios SOLID, usava como referencia constante o ‘Padrões GOF‘ e havia ‘descoberto’ os ‘padrões arquiteturais para aplicações empresariais‘ (perdoem-me se a tradução ou entendimento parecer errado, mas entendi assim) porém para mim parecia complicado aplicar aquilo tudo em um ambiente de elevada concorrência, metas ‘gulosas‘ e exigência de alta produtividade. Isso me levava quase ao desespero (E nem falei em TDD, meu brother)… “Meodeos. Não consigo. É muito difícil escrever código bom‘. Estava encarando desenvolvimento ágil como ‘desenvolvimento rápido’.

Alguns dias atrás, enquanto lia ‘Domain Driven Design – Atacando as complexidades no coração do software‘, então, percebi que estava profundamente equivocado.

Primeiramente, desenvolvimento ágil não consiste em aumento de velocidade dos times e redução de prazos, antes, consiste em incremento real na qualidade final do software produzido. Um software produzido mediante a aplicação de uma metodologia ágil deverá ter muitas iterações de aprofundamento de requisitos e muito poucas iterações de correção, além disso, equipes de desenvolvimento ágil estarão profundamente ligadas a técnicas de desenvolvimento orientado a testes (TDD) e desenvolvimento orientado a comportamentos (BDD), assim, a cada iteração, o time de QA (Quality Assurance / Garantia de Qualidade) será responsável por assegurar que o produto final da sprint/ciclo/iteração responde adequada e corretamente aos requisitos especificados lá no início, e mesmo se ocorrerem mudanças de requisitos, a equipe terá condições de responder a essas mudanças em tempo hábil e com o conhecimento do ‘dono do produto’.

Em segundo lugar, desenvolvimento ágil engloba também a qualidade da comunicação. Exige-se o mais alto nível de esclarecimento de domínio e requisitos e não a mais elevada ‘quantidade de pontos alcançados pela equipe’. Há muita, muita confusão quanto a isso. Deveríamos dar ênfase na qualidade da comunicação em todas as suas manifestações e pontuarmo–nos quanto a isso e não quanto ao produto, uma vez que o código é resultado dessa comunicação: Comunicação clara, software bem feito. Essa comunicação para ser bem processada, deve envolver diretamente todos os interessados naquele requisito: o analista de negócios ou o usuário que ‘captou’ o requisito, os profissionais da garantia de qualidade e os desenvolvedores e a conversa deve ser aberta para que todos expliquem e esclareçam dúvidas. Falo isso quanto a uma reunião de planejamento de Sprint que, por exemplo, deve se estender por um mínimo de 2 horas. Quando se faz isso, se obtem uma lista daquilo que deve ser produzido e a especificação sobre como aquilo que será produzido deve funcionar. “A especificação dos requisitos é clara? Se houveram impedimentos na implementação, há também alguma medida especificada que possa servir para resolver ou superar a situação? Há algum conflito entre os integrantes da equipe? Se há, qual a razão? Houve algum abuso ou algum indício de irresponsabilidade?“… Essa comunicação, lembremos, deve servir à equipe de Garantia de Qualidade como guia na elaboração do plano de testes, e portanto, quanto mais turbulenta e ruidosa a comunicação, mais pobre e inadequado o plano de testes. Por ‘ruidos’ da comunicação, podemos tomar o uso de termos técnicos sem significado esclarecido, presunção de que a complexidade de um requisito é a mesma para todos da equipe, etc. Eliminar esse tipo de ruído é fundamental para que o domínio da aplicação seja corretamente apreendido por todos. Deve-se esclarecer, por exemplo se usamos o termo ‘rota’ falando de ‘endpoint‘ da aplicação ou de um caminho físico a ser traçado num mapa representando o percurso de um veículo. Outro tipo de ‘ruído’ são os problemas de natureza pessoal. Aquela máxima ‘separe o trabalho da vida pessoal’ pra mim é conversa fiada… não dá pra separar. Talvez, quando muito, a gente consegue harmonizar as coisas, mas separar mesmo, não. É ideal que as equipes se escutem. É fundamental que todos conversem sobre os problemas e dificuldades, bem como partilhem de soluções de forma que o clima entre todos seja de companheirismo verdadeiro e cumplicidade.
Quando não temos esse entendimento claro, erramos. Não é vergonhoso admitir-se um equívoco, ao contrário, essa ‘aceitação’ é o primeiro passo para a correção.

Enfim, metodologia ágil não é desculpa para escrever código ‘porco’. Também não é suficiente escrever código ‘DRY’, extrair funções, e nem apenas ‘manter as coisas simples’. É necessário ler os catálogos de padrões e utilizar o que for possível. Também se precisa admitir que padrões de projeto não tem a ver apenas com ‘classes’, mas de fato, referem-se a organização (isso não é novidade alguma, apenas um esclarecimento). Pelo tempo e quantidade de frameworks que conheço, sei que todas elas fazem muito bem uso dos melhores design patterns, porém, mesmo que o framework seja bem organizado, é comum encontrar aplicações usando muito mais antipatterns do que se deveria esperar.

Agora, quanto a antipatterns, aí é outra história…

E me perdoem pela ausência de figurinhas…