Como introduzir a modelagem de software em um ambiente ágil

As exaustivas horas empregadas em transitar desde a concepção de um sistema de software até a sua entrega, passando pelos ajustes normalmente necessários, são prazerosamente recompensadas quando vemos o nosso cliente utilizando as tecnologias que desenvolvemos. Entretanto, desenvolver um software de médio/grande porte é um desafio e tanto. Que o digam aqueles diretamente envolvidos nas árduas atividades de levantar os requisitos, implementar, testar e entregar as soluções para atender as necessidades dos clientes.

A complexidade dessas atividades é tão grande e o processo de desenvolvimento de um sistema de software tende tão facilmente a se tornar caótico que diversas abordagens de desenvolvimento vêm sendo propostas desde o início da engenharia de software, normalmente como respostas a necessidades e problemas específicos identificados nos ambientes reais.

Uma das práticas comumente defendidas é a de que modelar uma solução técnica preferencialmente utilizando UML (vide seção Links) melhora a qualidade da solução e a manutenibilidade de um produto de software. Mas, quando uma empresa se depara com a necessidade real de escolher entre codificar rapidamente ou elaborar modelos e especificações em um projeto que está atrasado, normalmente tenho visto que se tende à primeira alternativa.

É claro que quando olhamos para notações como a UML,com os seus 14 diferentes diagramas (versão 2.5), e para a nossa necessidade de entregar software cada vez mais rapidamente, podemos pensar que esse grande volume de diagramas foi criado somente para nos deprimir, somente para que pensemos: “É claro que temos muitos bugs para resolver... Não fizemos nenhum diagrama”.

Como resposta aos processos prescritivos, e muitas vezes pesados, de desenvolvimento, que acabaram impondo uma carga excessiva de documentação para determinados ambientes e equipes na tentativa de dar mais rigor e formalidade ao caos, surgiram diversas abordagens ágeis. Como definido desde o início no manifesto ágil (vide seção Links), a proposta central das abordagens ágeis de desenvolvimento de software valoriza:

• Indivíduos e interações, mais que processos e ferramentas;
• Software em funcionamento, mais que documentação abrangente;
• Colaboração com o cliente, mais que negociação de contratos;
• Responder a mudanças, mais que seguir um plano.

Daí se observa a tendência de que práticas das abordagens ágeis já estejam estabelecidas em grande parte das organizações de software brasileiras, como: as reuniões diárias, ciclos curtos de desenvolvimento, entregas frequentes, interação face-to-face com fornecedores de requisitos, entre outras. Assim, muitas organizações de software encontraram na adoção de práticas das abordagens ágeis uma interessante alternativa para desenvolver seus projetos.

Entretanto, uma infeliz interpretação de “software em funcionamento, mais que documentação abrangente” no dia a dia das organizações de software tem resultado na redução ou quase extinção da modelagem nos projetos. Nas minhas andanças ministrando aulas, cursos e consultorias, já ouvi muitas vezes a expressão: “...aqui nós não fazemos nenhum tipo de modelagem porque somos ágeis ...”. Parte-se do princípio de que ser ágil resulta em necessariamente abandonar qualquer tipo de modelo que possa representar o software que está sendo desenvolvido. Infelizmente essa é uma interpretação errônea.

Esse comum abandono do uso de modelos no desenvolvimento de software, na verdade, tem origem no entendimento das motivações que nos levam a modelar. Antes de pensar se devemos, ou o quanto de esforço devemos aplicar para elaborar modelos, a pergunta essencial a ser feita é: Porque modelamos um software?

Para responder a essa complexa pergunta, podemos tomar como base o que pensam Martin Fowler (vide seção Links), Scott Ambler (vide seção Links) e muitos outros: nós modelamos para entender,comunicar e documentar, exatamente nessa ordem de importância.E aqui começamos a discutir sobre a ideia central da modelagem ágil:nós não modelamos somente para documentar, nós modelamos em primeiro lugar para entender (Figura 1).

Vamos pensar no seguinte cenário: um analista vai até o cliente para entender um problema específico que esteja enfrentando e que precisa ser resolvido com apoio de um sistema de software. Juntamente com o cliente, o analista rascunha em alguns “quadradinhos e bolinhas” a arquitetura da solução que irá atender as necessidades do cliente. Ao final da reunião, o analista desenhou o que está na Figura 2. Ambos ficam muitos satisfeitos com o desenho da arquitetura proposta e o analista volta para a sua empresa.

Para o entendimento do problema e definição de uma arquitetura básica de solução, os “quadradinhos” do analista foram perfeitos, mas para poder repassar essa ideia para os demais membros da equipe de desenvolvimento o analista terá que explicar o que cada símbolo representa: “Veja bem... Os quadrados são computadores, os círculos são sistemas, ou coisa parecida, já as linhas tracejadas...”. ...