Qualidade de Software: Princípios de projeto

segunda-feira, 11 de maio de 2009

Princípios de projeto - Parte II

Existem alguns motivos principais para um sistema não atender os requisitos para os quais foi contratado o projeto. Vamos analisa-los:

Muitas pessoas entre o cliente e a equipe de desenvolvimento: Os requisitos podem chegar deturpados até os desenvolvedores. Não é culpa da equipe, nem do cliente. Simplesmente, o telefone sem fio não funciona com precisão em área alguma, ainda mais em engenharia de software. Em algumas empresas, a equipe de desenvolvimento, não chega a participar das reuniões de levantamento de requisitos. Assim, os problemas são propagados pelas camadas da empresa, "cascateando" o mal entendido do cliente para o analista, deste para o líder e deste para a equipe. Ainda não tive experiência com esse tipo de divisão de papéis. Com as empresas que trabalhei até hoje, o papel do analista esteve sempre vinculado ao papel do programador. Nos locais onde atuei, a vontade do cliente chega diretamente para a equipe e, assim, analisamos, fornecemos os prazos, desenvolvemos e realizamos os testes unitários

A equipe de desenvolvimento não compreendeu a vontade do cliente: Em outras vezes, o desenvolvedor não conseguiu compreender bem os requisitos. Quanto mais cedo a falha na interpretação for detectada, menos custo vai gerar. A capacidade de interpretação deve ser uma preocupação do desenvolvedor. Se algo não foi bem entendido, não deixe o momento da reunião passar. Alguns minutos a mais utilizados durante o levantamento dos requisitos, podem significar menos horas ou até dias durante o processo de desenvolvimento. Obviamente, não estou falando de nenhuma metodologia ágil, como a XP, que prevê a participação efetiva de alguém do negócio durante o desenvolvimento;

O cliente não sabe o que quer: Acontece com frequência. Entretanto, o nosso papel como consultor, na minha visão, também consiste em ajudar nesse sentido. Traduzir uma chuva de idéias em algo sistemático. Devemos conseguir enxergar os processos repetitivos e automatiza-los. Normalmente o cliente não sabe (e nem tem a obrigação de saber) como as coisas se comportarão quando os requisitos sairem do papel e virarem sistema. O cliente entende do negócio dele e sabe, melhor do que qualquer um, o que vai agregar valor. O desenvolvedor deve ter a perspicácia de encontrar a real necessidade daquele que o contrata. O conhecimento técnico de quem está solicitando o sistema é, normalmente, muito vago.

Salta aos olhos o motivo raiz (root cause) dos três motivos que citei acima: comunicação.

Nesse sentido, a ubiquitous language (linguagem ubíqua), trazida a tona pelo DDD (Domain Driven Design), exerce um papel fundamental.

A princípio, o que seria uma linguagem ubíqua? Ubíqua, segundo o Aurélio, significa:

adj. Que está ao mesmo tempo em toda parte. (Sin.: onipresente.).

Trazendo para a nossa área, é uma linguagem dominada tanto pelo cliente quanto pela equipe de desenvolvimento. Desenvolveremos a questão da ubiquitous language e a DDD em posts futuros. No momento, basta sabermos que existe uma forma de melhorar a comunicação com o cliente.

Sem uma boa comunicação, é difícil conseguirmos um bom sistema. É comum em nossa área, termos profissionais com certa dificuldade para se expressar e para entender o que está sendo discutido. Esse problema é, normalmente, causado, pela timidez e dificuldade de concentração. Entretanto, existe uma luz no fim do túnel. Existem treinamentos para resolver essas dificuldades.

A timidez é oposta à segurança. Quanto mais seguro você está sobre um assunto, menos tímido você se sentirá para aborda-lo. Assim, alguns passos para acontecer a mágica da mudança de comportamento é:

Estude muito: quanto maior for o seu domínio sobre determinado assunto, maior será a sua segurança de falar sobre ele. Não estude apenas a teoria, mas também, crie cenários onde a teoria possa ser exercitada;

Não falar de algo que você não entenda bem: Esse é outro ponto importante. Se você está inseguro sobre determinado assunto, não fale nada. Escute e tente absorver o máximo de conceitos que está sendo debatido por outras pessoas. Se a sua idéia sobre determinado assunto não estiver completamente formada, não opine;

Aprenda a ser contrariado: quem nunca foi contrariado, nunca opinou. No nosso dia a dia, nos deparamos com situações que dependem da nossa avaliação e do nosso ponto de vista. Entretanto, outras pessoas podem ter um ponto de vista melhor devido a, por exemplo, ter mais experiência na área ou na empresa. Devemos nos preparar para sermos contrariados. Se não nos prepararmos quanto a isso, vamos correr o risco de gerar transtornos psicológicos que farão nos omitirmos cada vez mais.

Os pontos levantados ajudam na melhora da comunicação. Melhorando a comunicação, as reuniões com os clientes fluem com mais naturalidade e, consequentemente, mais fácil será o levantamento de requisitos.