o que possivelmente também resultará em gargalos e sobrecarga.
Código Coletivo é uma boa vacina contra ilhas de conhecimento, e reduz o risco
se alguém, por alguma razão, deixar o projeto.
77
4.5. Linguagem ubíqua
Casa do Código
Nessa abordagem de propriedade de código, se um desenvolvedor encontrar um
código pouco claro, sem testes, ou fora dos padrões e qualidade, não importa quem
o escreveu, esse código poderá e deverá ser melhorado.
4.5
Linguagem ubíqua
Desenvolvedor: - Nós estamos com um problema no NFBusinessDelegate quando
enviamos o objeto para o Service, parece que a transação não é iniciada e o DAO e,
então, não funciona bem.
Cliente: - ?
Desenvolvedores devem falar a linguagem de negócio [66].
Um dos grandes desafios do desenvolvimento de software é, muitas vezes, a co-
municação entre desenvolvedores que não são experts no domínio (áreas de
negócio) do software com os experts do negócio. [66].
Em seu livro Domain-driven design (DDD), Eric Evans cunhou o termo Lingua-
gem Ubíqua que diz respeito à criação de uma linguagem comum entre experts no
negócio e o time de desenvolvimento de software. Dessa forma, essa mesma lingua-
gem de negócio é utilizada no próprio código fonte do software, na hora dar nomes
a parâmetros, métodos, variáveis, classes, testes, etc.
É importante que o time compreenda cada um dos termos utilizados por clien-
tes. É comum que os experts do negócio tenham seus próprios jargões, assim como
desenvolvedores e testadores também têm seus próprios. Em um projeto sem uma
linguagem comum, o tempo todo, desenvolvedores precisam traduzir seus termos
para o expert de negócio, assim como esse também têm que traduzir seus termos
para os desenvolvedores, e isso prejudica a comunicação [23].
Com uma linguagem comum, tanto a linguagem das discussões quanto a do pla-
nejamento será a mesma utilizada no código. Se, em um sistema de logística, por
exemplo, o cliente se refere a cargas, os desenvolvedores, no código fonte, utilizarão, precisamente, o mesmo o termo cargas, e não mercadorias, ou produtos, ou
lote, por exemplo.
O primeiro passo para melhorar a comunicação é reconhecer a sua fragilidade,
e a linguagem ubíqua é uma excelente ferramenta para ajudar você e sua equipe a se
comunicarem melhor com as pessoas de negócio envolvidas em seu projeto.
78
Casa do Código
Capítulo 4. Entregando Valor
4.6
Design Ágil é Design Iterativo
Um dos maiores erros do desenvolvimento em cascata é achar que o conhecimento
existe apenas na forma de requisitos levantados antes do início da implementação e
separados do desenvolvimento.
Em uma perspectiva ágil, o desenvolvimento de software é um processo de cria-
ção de conhecimento, e que na prática, o design detalhado de um software ocorre so-
mente na codificação. Um design prematuro, ou seja realizado antes da codificação,
não pode prever a complexidade encontrada durante a implementação, e tampouco
pode utilizar-se do feedback que só pode ser recebido ao longo do desenvolvimento.
O design de um software deve evoluir ao longo de seu desenvolvimento. Tentar
fixá-lo prematuramente resultará em desperdício.
Em se tratando de requisitos, deve-se seguir
a mesma linha de pensamento, de
forma que os requisitos devem ser detalhados apenas quando estiverem perto da
hora de desenvolvê-los. É importante também estar preparado para as prováveis
mudanças neles, uma vez que o cliente também está aprendendo e evoluindo suas
ideias a respeito da solução que está sendo desenvolvida.
As abordagens prematuras de levantamento de requisitos e de design são chama-
das, respectivamente, de Big Requirements Up Front (BRUP) e Big Design Up Front
(BDUF), e têm sido amplamente abordadas na comunidade ágil como práticas a se-
rem evitadas, pois o conhecimento não é gerado por antecipação, mas sim através
de experimentação, codificação e releases frequentes que permitem receber feedback
dos clientes. O desenvolvimento de software iterativo e incremental encaixa-se per-
feitamente nessa linha de pensamento.
79
4.7. Definindo o significado de Pronto
Casa do Código
YAGNI: Você não vai precisar disso...
Não pague o preço da complexidade a menos que você realmente precise.
Neal Ford
O princípio YAGNI (You Aint Gonna Need It ou Você não vai precisar
disso) muito disseminado na comunidade ágil, defende a ideia de que
você deve evitar especulações no desenvolvimento de software [25].
Isso ocorre naquelas situações em que se pensa Eu acho que vamos
precisar disso no futuro, então, vou aproveitar e já fazer. Dessa forma,
adiciona-se complexidade desnecessariamente no projeto, e, quando
mais complexidade, mais difícil de se alterar torna-se o software.
Procure fazer apenas aquilo que realmente é preciso agora!
4.7
Definindo o significado de Pronto
A Definição de Pronto (em inglês Definition of Done, referenciado com o acrônimo
DoD), é, basicamente, um checklist do que deve ser feito antes que uma história possa ser considerada potencialmente entregável.