04telefone_lata Hoje vamos mudar um pouco nossas conversas, não vamos falar nem mostrar uma linha de código se quer. Bem, não sei nem por onde começar esta discussão, mas vou tentar colocar da melhor forma possível e depois deixo minha opinião e espero que vocês possam contribuir deixando a opinião de vocês. Aliás, para os menos avisados, NÃO EXISTE o Design Pattern TSF, na verdade estou chamando assim porque muitos, assim como eu, já brincaram de telefone sem fio quando criança e é exatamente isso que encontramos na maior parte das empresas quando se fala em desenvolvimento de software.

Você deve ter ficado meio confuso com isso não é? Como uma brincadeira de criança pode estar presente numa empresa que desenvolve software? “O Luciano ficou maluco? Telefone sem fio pra desenvolver sistemas? É, realmente ele pirou de vez!!”. O que posso dizer é, esse modelo de desenvolvimento existe e é amplamente utilizado!

Bom, antes de começarmos, gostaria de dizer os motivos que me levaram a escrever sobre esse assunto. O primeiro deles é porque estou estudando metodologias de desenvolvimento, o segundo é que percebi que terei mais uma vez que quebrar o paradigma para a construção de um software e o terceiro e último motivo é pelo simples prazer em compartilhar um pouco da minha experiência.

Para tentar explicar o que acabei de citar acima vamos ver um exemplo, qualquer coincidência é mera realidade (rsrs), para que vocês possam entender melhor o que estou dizendo.

Suponhamos que você seja o analista de uma fabrica de software e que seu mais novo projeto seja desenvolver um sistema para uma empresa de investimentos, uma corretora de valores.

Tudo começa quando você  vai até o cliente e discute com ele tudo que ele precisa no novo software (Home Broker). A par do projeto e das necessidades do cliente, você irá discutir com o Analista de Negócios, pois ele, mais do que ninguém,  possui o conhecimento de todo o funcionamento de um Home Broker. De posse de toda informação e de anotações feitas durante a discussão com o Analista de Negócio e com o cliente, você dá inicio ao processo de documentação, seguindo ou não algum padrão (isso vai de empresa para empresa, de analista para analista).

Findado este processo de documentação você irá validar estes documentos junto ao Analista de Negócio. Dada tal aprovação, o próximo passo é passar tudo para o Coordenador da equipe de desenvolvimento para que o mesmo possa repassar para os programadores e DBA´s suas tarefas para que os mesmos coloquem o desenvolvimento do projeto em prática.

A maioria dos projetos que trabalhei e que trabalho seguem essa linha de raciocínio, e isso não é exclusividade de uma ou outra empresa, esta forma de trabalho é geral, encontrada também em grandes empresas, posso citar dentre as quais trabalhei CEF e FGV.

Até ai tudo bem, não vimos nada demais só que como todo bom projeto, começam a surgir algumas dúvidas (digamos que sejam as regras de negócio, e olha que você documentou tudo heim!!) e logo um dos programadores irá até seu Coordenador tentar sanar a dúvida. Qual será a reação do Coordenador? Isso mesmo, ele irá até você (Analista de Sistemas) e, assim como ele, você irá até o Analista de Negócios tentar da melhor forma possível captar informações suficientes para sanar a dúvida do Coordenador que por sua vez irá repassar para o programador. Algo soa familiar a alguma brincadeira da sua infância? Alguma mera semelhança com o “Telefone sem Fio”? Não né!

E um dos problemas que vejo nessa forma de trabalho é quando as informações começam a sofrer distorção, ou seja, nem tudo é passado de forma correta para o pessoal de desenvolvimento gerando pequenas falhas no software e quando for enviado para a equipe de testes, muitos erros serão detectados fazendo com que o software volte para ser refeito gerando atrasos não planejados e consequentemente insatisfação por parte do cliente.

Os padrões de desenvolvimento de software são bons, mas como tudo que diz respeito à tecnologia, metodologias, conceitos e padrões, também precisam evoluir, e talvez um pouco mais de flexibilidade nestas comunicações seja uma forma de adicionar flexibilidade e minimizar os ruídos de comunicação.