Ubiquitous Language

Sempre que encontro com meus amigos guitarristas é uma festa... O assunto principal, como não poderia deixar de ser, é sempre sobre guitarras e tudo que essas preciosidades podem fazer. Falamos sobre as pickups que nossos ídolos utilizam, se vamos colocar jumbo frets em nossos necks para obter maior sustain, comentamos sobre os tipos de bridge que mais gostamos, entre outros assuntos.

Não está entendendo nada desse assunto? Não esquenta, somente nós guitarristas (malucos) entendemos. Essa é a nossa linguagem, a que usamos normalmente para comunicar nossas ideias e nossa paixão pela música.

Imagine uma situação hipotética, na qual esse grupo de amigos tivesse encomendado a uma equipe de programadores um sistema de controle de guitarras, um software no qual pudéssemos encontrar e colocar todo o tipo de informação pertinente da nossa área de atuação. De que modo você pensaria em modelar esse sistema? Qual seria um design apropriado para esse problema?

Um programador com linguagem puramente técnica tentaria explicar como desenvolveria o sistema usando DAOs, controladores, queries, Design Patterns e outras coisas que nada tem a ver com a área (apenas me deixando preocupado se ele realmente teria entendido) o negócio que gostaríamos de ver solucionado.

De outra forma, um programador poderia aproveitar o nosso vocabulário para modelar uma solução que usasse a nossa linguagem como apoio para o design. Nesse modelo, ele me mostraria como criaria guitarras, pickups, tremolos e repositórios diretamente na solução. Deixaria bem claro como esses elementos estão associados usando a mesma linguagem que nós utilizamos normalmente. A essa linguagem damos o nome de ubiquitous language.


Repare onde a ubiquitous language naturalmente se encontra, um meio-termo que une especialistas em domínio com especialistas em tecnologia:

A ubiquitous language é fundamental para o Domain Driven Design, metodologia que foca na construção de sistemas a partir do desenvolvimento (e isolamento) de um rico domain model, capaz de resolver problemas com eficiência e apoiado na linguagem que os usuários utilizam no dia a dia.

Eric Evans nos dá a direção:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communications within the team and in the code. Use the same language in diagrams, writing, and especially speech. Recognize that a change in the ubiquitous language is a change to the model."

Nós devemos ser capazes de desenvolver sistemas que comuniquem bem seu design para os usuários que realmente o utilizarão. Mantenha apenas o modelo, código e testes como artefatos permanentes do desenvolvimento. Use a linguagem no dia a dia e a incorpore em todo o lugar, dos diagramas de classe aos códigos Java e C#. Isole o domain model e deixe o aparato técnico para ser discutido apenas por especialistas em tecnologia.

Próximos posts veremos como a arquitetura DDD é feita de forma a permitir o isolamento desse domain model.

Curso agile pronto

Fala pessoal!
Tudo bem?

O curso agile ficou pronto e já saiu do forno... Montei um compacto das melhores práticas de engenharia do XP com as práticas de gestão de projetos do Scrum.

Modéstia à parte, ficou bem bacana. hehehe

Quem quiser conferir clique aqui.

Abração e qualquer dúvida é só postar que eu respondo. :)

Formação Agile

Fala pessoal!

Ando meio sem tempo para postar por conta da formação agile que estou criando em parceria com o Infnet.

Será um mix de Scrum e XP com muita informação legal para desenvolvedores e gestores.

Aguardem notícias muito em breve aqui no blog!

Abraços.

Agile Project Management

Debates fervorosos acontecem, atualmente, na comunidade de gestão de projetos de sotware. O grande centro das discussões encontra-se na questão sobre qual seria a melhor metodologia a ser aplicada no gerenciamento desses projetos. Devemos seguir as boas práticas do PMBOK ou aplicar uma abordagem ágil, utilizando métodos como Scrum e XP? Minha resposta: devemos sempre adotar o que for melhor para cada projeto em particular.

Não devemos gerenciar projetos no estilo "by the book". Procurar por cartilhas que nos digam exatamente o que fazer é um caminho perigoso e que tem poder de levar um projeto ao fracasso. Um profissional sério deve se aprofundar no conhecimento dos frameworks e metodologias existentes no mercado para, como um médico, diagnosticar um quadro geral e indicar o tratamento mais adequado. É preciso entender a situação primeiro para depois poder traçar uma estratégia coerente, um plano de ação que seja eficaz para o case específico.

E por que não mesclar as técnicas para preencher as lacunas que cada método possui?

Podemos estar gerenciando com foco no PMBOK e mesmo assim aplicar técnicas ágeis como abordagem iterativa, cliente-onsite e reuniões de retrospectivas. Analogamente, podemos utilizar Scrum e aplicar técnicas como gestão de riscos e construção de uma visão para o produto. Conhecer mais ferramentas dá maior poder de escolha para o gestor, evitando vícios como a incessante procura pela "bala de prata" das metodologias, comportamento que engessa a atuação de qualquer profissional (não apenas de gestão).

Sendo assim, independente do método utilizado, há sempre dois pontos que são os mais importantes em qualquer projeto (especialmente os de software): pessoas e comunicação. Qualquer abordagem que priorize os complexos relacionamentos que existem entre os interessados de um projeto, facilitando a comunicação entre os envolvidos e buscando dar mais autonomia e responsabilidade às pessoas tem muito mais chance de terminar com sucesso.