O processo de desenvolvimento de software é uma via de mão dupla: a equipe de desenvolvimento e o(s) domain expert(s) aprendem sobre o domínio em questão.
A equipe de desenvolvimento aprende, na maioria das vezes, sobre uma área de atuação completamente nova e o domain expert, ou a equipe de domain experts, descobrem novas funcionalidades que a principio, não haviam sido identificadas, é um processo evolutivo.
Eu diria que é impossível, o cliente ter uma idéia 100% correta com relação às funcionalidades a serem implementadas em um sistema. Alguns têm uma noção muito boa, com esses, o trabalho normalmente flui muito bem, mas muitos, têm uma noção bem distante da realidade de seus domínios.
Nesse contexto, é comum surgirem os 'cadastrinhos', como eu costumo chamar. O domain expert, por não ter uma noção muito correta do que precisa, ou por querer de certa forma, minimizar a complexidade do próprio processo, diz: "Esse sistema é só um cadastrinho, é muito simples, basta salvar meia dúzia de campos de um formulário."
Por vezes, a afirmação anterior se mostra verdadeira. Para uma primeira iteração, entregar um simples cadastro de seis campos, pode atender às necessidades do momento. Mas é normal que, idéias comecem a borbulhar na cabeça do domain expert, após ver o 'cadastrinho' funcionando.
Aí vem o problema:
Partindo do princípio que desenvolvimento de software é um processo evolutivo, isto é, novas necessidades surgem e mudanças ocorrem em funcionalidades já existentes, a escolha de uma metodologia de desenvolvimento apropriada, que privilegie extensibilidade e
manutenibilidade, é essencial para o sucesso do projeto, pois o cadastrinho de 6 campos pode facilmente evoluir para o
Cthulhu.
Estudos e a prática, mostram que a maior parte do tempo de um projeto de software, é gasto na fase de manutenção e melhorias. Muitas vezes, por questões de prazos apertados, escolhas inadequadas acabam sendo feitas com relação à implementação, por oferecerem produtividade alta e imediata. Isso pode gerar um design "engessado", pouco extensível e de difícil manutenção, a complexidade pode rapidamente engolir a equipe de desenvolvimento.
Já ouvi muitos colegas dizerem que o sucesso se mede pela satisfação do cliente. Concordo que satisfação é essencial, mas no meu ponto de vista, deixar o cliente satisfeito, é o mínimo que se pode esperar quando se oferece um produto.
Satisfação do cliente e software com qualidade, não são (ou não deveriam ser) objetivos mutuamente exclusivos. A filosofia de
Domain-Driven Design (Eric Evans), introduz ao processo de desenvolvimento de software:
- uma arquitetura em camadas, para organização de responsabilidades;
- ubiquitous language, para facilitar a comunicação entre equipe técnica e domain experts, além de gerar documentação em nível de código;
- patterns que simplificam e consolidam o design.
Ao utilizá-la, associada ao paradigma orientado a objetos, uma equipe ágil, deve ser capaz de vencer cenários onde os prazos são curtos e os clientes exigentes, com a vantagem de gerar um produto final que reflete o domínio do cliente, com um design extensível, de manutenibilidade e legibilidade simplificadas, tanto para os profissionais envolvidos, quanto para futuros profissionais que venham a se envolver no projeto.
Para saber mais:
