Abordagens Ágeis de Desenvolvimento de Software

Bootcamp: Engenheiro de Software Ágil

Odivaney Ramos Pedro

2021
Abordagens Ágeis em Engenharia de Software
Bootcamp: Engenheiro de Software Ágil
Odivaney Ramos Pedro
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.

Abordagens Ágeis em Engenharia de Software – Página 2 de 29

Sumário

Capítulo 1. TDD – Introdução ..................................................................................... 4

1.1 Contextualização .............................................................................................. 4

1.2 Práticas ágeis necessárias ao desenvolvimento ágil ........................................ 8

Capítulo 2. TDD – Test Driven Development ........................................................... 10

2.1 TDD – Método................................................................................................. 10

2.2 TDD – Ciclo de Desenvolvimento ................................................................... 11

2.3 BDD – Behavior Driven Development ............................................................. 13

2.4 BDD – Ciclo de Desenvolvimento ................................................................... 14

Capítulo 3. FDD – Feature Driven Development ...................................................... 17

3.1 FDD – O método ............................................................................................. 18

3.2 FDD – Ciclo de Vida ....................................................................................... 18

Capítulo 4. DDD – Domain Driven Development ...................................................... 22

4.1 DDD – Bounded Contexts e Contexts Maps ................................................... 23

Capítulo 5. DAD – Disciplined Agile Delivery ........................................................... 25

5.1 Ciclo de Vida ................................................................................................... 26

Capítulo 6. Conclusões ............................................................................................ 28

Referências............ .................................................................................................. 29

Abordagens Ágeis em Engenharia de Software – Página 3 de 29

Capítulo 1. TDD – Introdução

Esta apostila irá auxiliar na compreensão de todos os assuntos relativos às

abordagens de desenvolvimento de software ágil.

Primeiramente, vale ressaltar que não estamos falando aqui de modelos ou

metodologias ágeis, mas de abordagens de desenvolvimento ágil. Abordagem, no
nosso contexto, pode ser interpretada como modo de compreender e lidar com algo.
No nosso caso, trata-se de como compreender e lidar com o desenvolvimento de
software ágil. Entender o significado da palavra abordagem é de suma importância.

Para auxiliar na compreensão desse significado, faça um exercício mental:

imagine com qual abordagem você leva sua vida. Você vê o copo meio cheio ou meio
vazio?

Consegue entender agora qual o motivo deste capítulo? Ele mostrará formas
de direcionar o desenvolvimento, mas não exatamente modelos com processos
definidos e que devam ser seguidos de forma metódica.

1.1. Contextualização

Para entendermos as abordagens de desenvolvimento e as ideias que essas

defendem, precisamos primeiro entender as dores que elas vieram curar, ou seja, os
problemas que elas vieram resolver.

A abordagem de desenvolvimento de software tradicional trabalha

fundamentalmente com a ideia de que os requisitos (as funcionalidades, em outras
palavras) que um software deve ter já estão definidos logo no início do processo. Por
esse motivo, os modelos que são alinhados com a abordagem tradicional de
desenvolvimento (ex.: Cascata/Waterfall) normalmente definem fases iniciais onde
todos os requisitos são especificados e modelados. E os materiais
(especificação/modelagem) dessa fase direcionam todo o restante do
desenvolvimento do software até a entrega ao cliente.

Abordagens Ágeis em Engenharia de Software – Página 4 de 29

 A abordagem tradicional seria excelente para todos os contextos, se não
fosse o fato de que sabemos que diversos imprevistos em relação aos requisitos
podem acontecer. Por exemplo:

▪ Requisitos mudam. Um cadastro de dados especificado 12 meses atrás pode

ter que ser diferente de hoje devido à LGPD (Lei Geral de Proteção de Dados).

▪ Requisitos deixam de existir. O cliente tinha solicitado uma funcionalidade

para marcação de mesas em seu restaurante, mas devido à pandemia de
Covid, ele mudou completamente o foco de seu negócio para entregas.

▪ Tecnogia evolui. Surgimento do PIX para realização de pagamentos

bancários.

Outra limitação às abordagens tradicionais de forma geral é o fato de que,

nessas abordagens, o cliente tem que esperar até a entrega do deploy final para ver
o software funcionando.

Imagine só, você comprar uma casa na planta e só poder ver ela no dia de
pegar as chaves. E aí quando você tentar entrar na casa, vê que a porta é muito
baixa, ou que alguns cômodos não têm janela, ou ainda que a pintura é de uma cor
diferente da abordada.

Podemos afirmar que até a década de 80 a maior parte esmagadora dos

softwares eram desenvolvidos utilizando as abordagens tradicionais. Com o passar
dos anos, veio o aumento do número de computadores e dos tipos de usuários –
devido a isso e a outros fatores (ex.: empresas globalizadas), as demandas de
desenvolvimento também mudaram (softwares se tornaram mais complexos). Essas
mudanças fizeram com que diversos projetos de desenvolvimento de software (em
especial na década de 90), usando a abordagem tradicional, fracassassem.

Nesse contexto, especialistas da área de desenvolvimento de software

começaram a estudar, propor e utilizar modelos de desenvolvimento com abordagens
diferentes para desenvolver softwares. Essas novas abordagens tinham diversos
pontos em comum, mas podemos citar especialmente:

Abordagens Ágeis em Engenharia de Software – Página 5 de 29

 1. Processo cíclico: fazer pequenas partes do sistema por vez (iteração), fazendo
o planejamento detalhado apenas da próxima fase.

2. Documentação inteligente: ao invés de se preocupar em entregar

especificação de requisitos detalhados, com uso de padrões formais de
comunicação e com uma grande quantidade de páginas, os novos modelos
focaram na utilização de modelos de representação mais fáceis para
entendimento dos usuários e clientes. Assim, todos falavam uma língua
compreensível por todos.

3. Comunicação intensa: nos processos tradicionais, o cliente (stakeholders,

usuários e domains experts) estava presente apenas nas fases iniciais da
construção do software. As novas abordagens, por sua vez, estimulavam a
participação intensa do cliente ao longo das diversas fases do projeto.

4. Adaptabilidade: nos modelos tradicionais, uma mudança de requisito ao longo

do projeto seria um grande problema que, em alguns casos, poderia inviabilizar
o projeto, mas os modelos que utilizam a abordagem ágil focam em processos
que aceitam mudanças em diversos momentos.

A Figura 1, a seguir, evidencia muito bem a diferença entre modelos nas

diferentes abordagens:

Abordagens Ágeis em Engenharia de Software – Página 6 de 29

 Figura 1 – Comparativo Cascata x Ágil.

Fonte: https://www.inovalab.net.br/post/metodologia-%C3%A1gil-tudo-que-
voc%C3%AA-precisa-saber-antes-de-come%C3%A7ar-a-usar.

O tempo e os casos de sucesso têm mostrado que os modelos que utilizam

a abordagem ágil são mais eficazes e adequados a uma gama muito grande de
contextos de desenvolvimento. Em especial os contextos de desenvolvimento de
software, nos quais todas as informações não são conhecidas no início do
desenvolvimento.

A ideia desse módulo é mostrar algumas das boas abordagens ágeis de

desenvolvimento. Em alguns casos, essas abordagens têm também o modelo
definido – neles, exploraremos o modelo. Contudo, antes de iniciarmos, algo precisa
ficar claro para todos: não podemos falar que as abordagens ágeis são perfeitas e
melhores que a abordagem tradicional.

As abordagens ágeis não são uma estratégia “bala de prata”, ou seja, que
mata todos os monstros. O que podemos afirmar categoricamente é que em alguns
contextos elas são o melhor caminho a ser seguido.

Abordagens Ágeis em Engenharia de Software – Página 7 de 29

1.2. Práticas ágeis necessárias ao desenvolvimento ágil

Nem tudo são flores. Conforme já falamos um pouco, o contexto de

desenvolvimento ágil de software tem algumas características peculiares. Por
exemplo:

▪ Ciclos curtos de desenvolvimento;

▪ Diversas versões do software sendo entregues e desenvolvidas aos clientes;

▪ Software sendo entregue por partes;

▪ Equipes de desenvolvimento distintas trabalhando juntas;

▪ Deadlines apertados;

▪ ...

Essas características exigem de qualquer abordagem de desenvolvimento

ágil algumas práticas para que tudo corra bem, e podemos citar dentre essas práticas:

1. Processos de qualidade mais eficientes.

Um processo de desenvolvimento de software de qualidade deve ter, no

mínimo, as seguintes características:

1.1. Verificação: análise do código em busca de erros.

1.2. Validação: analisar se o resultado é exatamente o que era esperado.

1.3. Uso de ferramentas de apoio: códigos muito complexos, extensos, ou

atualizados constantemente precisam de outros modos de verificação,
além do modo manual. Existem diversas ferramentas no mercado para
auxiliar esse processo.

1.4. Automatização: como o processo de testes deve ser abrangente, fica

muito pesado para o desenvolvedor ou testador realizar todos os testes.
Então, no caso do desenvolvimento de grandes sistemas, para realizar

Abordagens Ágeis em Engenharia de Software – Página 8 de 29

 todos os testes necessários é preciso de ferramentas para automatizar
esse processo.

2. Integração Contínua

Integração contínua: em alguns casos, os softwares são desenvolvidos por

grandes equipes que acessam o mesmo repositório de código. Esse contexto de
trabalho pode gerar problemas, como um programador depender de desenvolver uma
classe X, mas para fazer bem o seu trabalho ele precisa ter acesso à especificação
da classe Y, tudo isso ao mesmo tempo. Como fazer isso? Através da integração
contínua.

3. Boas práticas de programação.

O desenvolvimento de software ágil implica na construção de sistemas

compostos por diversas componentes, que devem ser coesos e com acoplamento
mínimo. Para se alcançar essas características no produto, é importante que o
processo tenha: componentes bem especificados, código refatorado, utilização de
padrões (ex.: Design Patterns), padrão de nomenclatura de classes e variáveis e
funções que sejam compartilhadas por todos.

Por tudo que foi falado neste capítulo inicial, podemos concluir que o
desenvolvimento de software ágil é uma importante alternativa para diversos
contextos, como sistemas nos quais os requisitos não estão previamente
determinados. No entanto, as abordagens ágeis não se aplicam em todos os
contextos, e nem sempre serão as melhores opções de desenvolvimento. Assim
como outras abordagens, a abordagem ágil tem suas limitações e as cautelas
necessárias para sua utilização. Para finalizar este capítulo, vou parafrasear uma
afirmação de autoria desconhecida, mas muita utilizada no nosso meio:

“NÃO EXISTE ABORDAGEM QUE SEJA BALA DE PRATA”

Abordagens Ágeis em Engenharia de Software – Página 9 de 29

Capítulo 2. TDD – Test Driven Development

Neste capítulo, falaremos sobre a abordagem de desenvolvimento orientado

por testes (TDD). De forma básica, essa abordagem consiste na ideia de que se você
dividir o seu sistema em pequenas partes (unidades e componentes) e testá-las bem
(testes de unidades e componentes), assim como a integração entre essas partes
(teste de regressão), isso já vai ser um grande indicativo de que o software produzido
será de grande qualidade.

Para explicar a abordagem orientada por testes, explicaremos em detalhes o

método de desenvolvimento que tem o mesmo nome: TDD (Test Driven
Development). Esse método foi a base para o desenvolvimento e a disseminação da
abordagem orientada por testes, que atualmente é muito utilizada por diversas
empresas. Para simplificar, de agora em diante, sempre que referenciarmos o termo
TDD, estaremos referenciando ao método, mas os conceitos explicados são
extensíveis a ele.

2.1. TDD – Método

Método de desenvolvimento de software criado por Kent Beck em 2003, que

basicamente fez um compilado de boas práticas que já existiam em diversos métodos
ágeis, como o XP (Extreme Programming). O método TDD tem como base alguns
fundamentos. Dentre eles, podemos evidenciar:

▪ Especificação inicial do sistema. Essa especificação deve ser abrangente e

não entrar em níveis de detalhes.

▪ Definição de quais partes do todo serão desenvolvidas em cada iteração.

Devem ser priorizadas as partes do sistema que entregam mais valor ao
cliente.

▪ No início de cada iteração, primeiro deve-se especificar os testes (verificação

e validação) que serão realizados para unidade do sistema, para apenas
depois codificar-se as unidades.

Abordagens Ágeis em Engenharia de Software – Página 10 de 29

 ▪ Após o desenvolvimento, a unidade desenvolvida só é entregue ao cliente se
passar nos testes que foram previamente definidos.

2.2. TDD – Ciclo de Desenvolvimento

A Figura 2 demonstra de forma básica o processo (ciclo de desenvolvimento)

que ocorre a cada iteração do TDD.

De forma básica, a primeira obrigação que o método determina é a

especificação de um ou mais testes que irão validar a funcionalidade no final. Este é
o grande diferencial do TDD em relação a outros métodos: essa especificação dos
testes deve ser validada pelo usuário, e nesse processo de especificação e validação
novas regras do negócio acabam sendo descobertas. Isso auxilia ainda mais para
que seja produzido um software de qualidade.

Figura 2 – Ciclo básico de desenvolvimento TDD.

Fonte: http://www.agiledata.org/essays/tdd.html.

Abordagens Ágeis em Engenharia de Software – Página 11 de 29

 Explicando em linhas gerais, o ciclo de vida do TDD pode ser resumido da
seguinte forma:

1. Especifique e codifique um teste que não passe.

2. Implemente a funcionalidade com o código mais básico possível; apenas o

necessário para passar no teste.

3. Teste a funcionalidade:

‒ Se o teste passar, siga para o passo 4.

‒ Se o teste não passar, volte ao passo 2.

4. Refatore o código que passou no teste, deixando ele melhor e mais eficiente.

5. Teste o código refatorado com o mesmo teste do passo 1.

‒ Se o teste passar, a unidade foi produzida, e agora você deve iniciar do

passo 1 com uma nova funcionalidade.

‒ Se o teste não passar, volte ao passo 4.

Muitos desenvolvedores têm dificuldade de aplicar o TDD por entenderem

que gerar um caso de teste primeiro é perda de tempo. Contudo, a criação de casos
de teste antes da implementação auxilia o desenvolvedor a conhecer melhor o
problema do cliente e auxilia na validação do que deve ser feito. Além disso, quando
o desenvolvedor codifica já sabendo qual o teste que será feito, automaticamente já
produz um código de maior qualidade para ser aprovado no teste. E caso esse código
não seja bom o suficiente, poderá ser refatorado depois.

O método TDD tem sido amplamente utilizado por muitos desenvolvedores,

e é reconhecidamente um bom método para desenvolver softwares de qualidade. Por
ser um método derivado do XP, muitas empresas utilizam ambos em conjunto. O TDD
tem excelentes diferenciais, podemos evidenciar dois: criação de testes antes do
desenvolvimento e a refatoração do código. Esses diferenciais têm auxiliado a

Abordagens Ágeis em Engenharia de Software – Página 12 de 29

produção de software com altos níveis de qualidade, conformidade dos requisitos e
software modularizado.

Vale ressaltar que o TDD sugere a participação de um profissional específico

para auxiliar no processo de criação de testes. Também é altamente estimulado o uso
de ferramentas para auxiliar tanto na criação e na execução dos testes de unidade
quanto na criação e na execução dos testes de integração. Por ser um método
amplamente utilizado, praticamente todas as linguagens têm ferramentas de apoio
para dar suporte a ele.

Dentre as diversas ferramentas existentes no mercado, podemos citar:

Linguagem/Plataforma – Ferramenta – Link

▪ Java – Junit - https://junit.org/junit5/

▪ C– Cunit- http://cunit.sourceforge.net/

▪ .NET– Nunit- https://nunit.org/

▪ PHP – PHPUnit- https://phpunit.de/

▪ Javascript – Jasmine- https://jasmine.github.io/

▪ Python – PyUnit- http://pyunit.sourceforge.net/

2.3 BDD – Behavior Driven Development

Apesar das inúmeras vantagens do BDD, existia-se uma visão de que este
era muito técnico e que ainda existia uma lacuna na forma em que o cliente/usuário
poderia validar o que estava sendo feito. Isso porque alguns usuários poderiam não
ter a capacidade de validar um caso de teste por não ter conhecimento técnico
suficiente. Dessa forma, apesar do TDD produzir um software resiliente a erros de
programação, os erros de especificação continuariam existindo. Como alternativa

Abordagens Ágeis em Engenharia de Software – Página 13 de 29

complementar ao TDD, surgiu o BDD (Behavior Driven Development), idealizado por
Dan North em 2003.

Essa metodologia de desenvolvimento, que também se enquadra na

abordagem orientada a testes, foca mais na interação entre todas as partes
envolvidas no processo, mas mantendo as características técnicas do TDD.

2.4 BDD – Ciclo de Desenvolvimento

A Figura 3 demonstra de forma básica o processo (ciclo de desenvolvimento)

do BDD.

Figura 3 – Ciclo básico de desenvolvimento BDD.

O clico de vida acima pode ser explicado pela sequência de passos abaixo:

Abordagens Ágeis em Engenharia de Software – Página 14 de 29

 ▪ Passo 1:

O ciclo representado na Figura 3 deve se iniciar no passo de

“NECESSIDADE DE IMPLANTAÇÃO DE UMA FUNCIONALIDADE DE
BACKLOG”.

▪ Passo 2:

A partir desse momento, diversas reuniões são realizadas com os

stakeholders e domain experts, visando criar User Stories (Figura 4) que retratem a
funcionalidade a ser desenvolvida por completo. O modelo de User Stories foi
escolhido, pois dessa forma é mais fácil compreender o que o stakeholder quer, assim
como é mais fácil para este validar após a especificação. Além das User Stories,
nessas reuniões é utilizada uma linguagem ubíqua de entendimento de todos, assim,
existe a garantia que todos estão falando a mesma língua.

▪ Passo 3:

Ainda nas reuniões com usuários, as User Stories são refinadas, verificando
o que realmente deve ser produzido (feature).

▪ Passo 4:

Uma vez definidas quais funcionalidades devem ser feitas, é definido quais
os testes de validação que serão realizados após o desenvolvimento para verificar se
a funcionalidade foi desenvolvida corretamente.

▪ Passo 5:

Com os testes já definidos de forma geral, são definidas as ferramentas

técnicas e detalhes do processo de testes.

Após a realização dos cinco passos, a funcionalidade é desenvolvida

utilizando-se a metodologia TDD. A Figura 4 na sequência dá uma visão geral da
aplicação do BDD.

Abordagens Ágeis em Engenharia de Software – Página 15 de 29

 Figura 4 – BDD & TDD.

Fonte: https://blog.testlodge.com/tdd-vs-bdd/.

A Figura 5 demonstra a simplicidade de uma User Story, e, por sua forma

simples, conseguimos entender o porquê de ser melhor compreendida por um usuário
do que a especificação formal e detalhada como é feito no TDD.

Figura 5 – User Stories.

Fonte: https://www.productplan.com/glossary/user-story/.

Tanto o TDD quanto o BDD são métodos que utilizam a abordagem orientada
a testes. O primeiro mais focado na correção do código, enquanto o segundo é mais
focado na validação do que é esperado pelo usuário.

Abordagens Ágeis em Engenharia de Software – Página 16 de 29

Capítulo 3. FDD – Feature Driven Development

Neste capítulo, falaremos de uma abordagem de desenvolvimento ágil muito

interessante. Diversas empresas que têm migrado do universo tradicional para o
universo ágil vêm optando por esta abordagem por ela ser muito intuitiva.

De forma básica, essa abordagem guia o desenvolvimento por

funcionalidades (features). Pelos requisitos funcionais, primeiro deve-se levantar os
requisitos funcionais que precisam ser desenvolvidos, modelá-los de forma detalhada
conceitualmente e, então, produzir as features de forma iterativa.

Antes de seguir para o restante do capítulo, peço que você veja o vídeo de
onde retirei a Figura 6. Basta copiar o link na fonte abaixo do vídeo e abrir no seu
navegador.

Observação: o vídeo está em espanhol, mas é plenamente compreensível

devido ao uso das figuras e legendas. Achei o vídeo fantástico e queria compartilhar
com vocês; além disso, vou usar o exemplo contado no vídeo ao longo deste capítulo
e nas aulas para explicar os conceitos. O vídeo tem três minutos e conta a história
real do surgimento da abordagem FDD.

Figura 6 – Metologia FDD.

Fonte: https://www.youtube.com/watch?v=iEDFgXX-WcA.

Abordagens Ágeis em Engenharia de Software – Página 17 de 29

3.1 FDD – O método

Feature-driven development (FDD), ou Desenvolvimento Dirigido por

Funcionalidades, é um método leve e iterativo para desenvolvimento de software.
Criado por Jeff de Luca e Peter Coad, combina gestão de projetos com boas práticas
de engenharia de software. Vale também ressaltar que essa é uma das metodologias
ágeis anteriores ao Manifesto Ágil. O método FDD representa muito bem a
abordagem de desenvolvimento orientada por funcionalidade, e, em nosso contexto,
trataremos as duas coisas como sinônimas.

O FDD surgiu como solução em um caso de atraso de entrega de software.

No caso em questão (assim como mostra no vídeo), tratava-se de um software
bancário, grande e complexo, que, após 18 meses da assinatura do contrato para
realização, ainda estava nas etapas de especificação e modelagem. De forma
emergencial, a equipe, através de Jeff de Luca e Peter Coad, que sabia que para
desenvolver todas as funcionalidades (cerca de 2000) iria demorar muito, criou uma
proposta para o cliente: a de que a equipe iria refazer a modelagem conceitual, com
a participação de diversos stakeholders e, após isso, uma quantidade grande de
funcionalidades seriam entregues de 14 em 14 dias. O cliente aceitou a proposta e,
em aproximadamente 15 meses, 2.000 funcionalidades foram desenvolvidas e
entregues por uma equipe de aproximadamente 50 pessoas.

Vamos entender um pouco mais dessa abordagem vendo o seu ciclo de vida.

3.2 FDD – Ciclo de Vida

De forma básica, o FDD usa o conceito de gastar um tempo inicial para fazer
a modelagem conceitual do sistema e depois, de forma iterativa, entregar
funcionalidades em ciclos curtos (14 dias). A Figura 7 demonstra o ciclo de vida do
FDD:

Abordagens Ágeis em Engenharia de Software – Página 18 de 29

 Figura 7 – Ciclo de Vida do FDD.

Os passos do modelo acima podem ser entendidos da seguinte forma:

1) Desenvolvendo um modelo abrangente.

Essa etapa tem como foco construir um modelo geral e abrangente do

software a ser desenvolvido.

Nessa fase, são realizadas reuniões com a presença de diversos

stakeholders, do Product Owner e de profissionais relacionados ao desenvolvimento
(arquiteto chefe, programador chefe etc.). A ideia é que nessas reuniões seja
discutido e definido um modelo conceitual que demonstre o sistema como um todo
(domain walkthrough). Com esse modelo, já se começa a ter uma ideia das
funcionalidades que o software deverá ter.

Resultado da fase 1: modelo conceitual.

2) Construir a lista de funcionalidades.

Nesta fase, uma equipe técnica composta por programadores avalia o modelo
conceitual gerado na fase 1 e cria uma lista de todas as funcionalidades que o
software deverá ter. Essa fase gera um dos principais benefícios do FDD, visto que a

Abordagens Ágeis em Engenharia de Software – Página 19 de 29

decomposição do modelo em funcionalidade é feita através do método COAD, que é
um método de análise orientada a objetos criado pelo Peter Coad.

As funcionalidades (features) são descritas da seguinte forma:

< AÇÃO> < RESULTADO > <OBJETO>

• EXEMPLOS:
• Cadastrar dados do usuário.
• Realizar compra de livro.
• Solicitar aluguel do veículo.
• Calcular desconto de uma venda.

Com base na descrição da features nesse padrão, é possível identificar os

comportamentos (AÇÃO), classes (OBJETOS) e os resultados esperados dos
comportamentos sobre as classes. Assim, Peter estabeleceu uma forma simples de
modelar orientado a objetos.

Resultado da fase 2: lista geral de funcionalidades (features).

3) Planejar por funcionalidades.

Nesta fase, são realizadas reuniões entre os principais papéis da equipe de

desenvolvimento e eventualmente o Product Owner para definir questões
relacionadas ao planejamento.

Resultado da fase 3: a sequência de realização das funcionalidades, qual

equipe será a responsável por desenvolver cada funcionalidade, lista detalhada das
classes e comportamentos.

4) Modelagem detalhada da funcionalidade.

Nesta fase, a modelagem orientada a objetos de cada elemento da feature a

ser desenvolvida é aprofundada, com definição total sobre classes, visibilidade,
herança e polimorfismo.

Abordagens Ágeis em Engenharia de Software – Página 20 de 29

 Resultado: modelagem orientada a objetos completa com riqueza de detalhes
sobre cada elemento relacionado à feature a ser desenvolvida. Também é feita a
atribuição de cada classe a programadores que ficarão responsáveis por elas.

5) Desenvolvimento da funcionalidade.

Nesta fase, a feature é construída com base na modelagem detalhada da

geração pela fase anterior. Tem que ter respeito à atribuição de responsabilidades da
fase anterior e ao modelo orientado a objetos gerado.

Resultado: funcionalidade com valor para o cliente.

Sobre o modelo de processo acima, é importante frisar que as três primeiras

fases são realizadas uma única vez, e o tempo de realização depende do contexto do
problema e da disponibilidade de todos os participantes. Esse prazo normalmente fica
em torno de 2 meses. Já as fases 4 e 5 são as iterações deste modelo, iterações que
duram cerca de 14 dias, e sempre ao final das mesmas o cliente recebe features de
implementação funcional e valor agregado.

A abordagem orientada a features tem a grande vantagem de produzir

softwares modulares e escaláveis, sendo muito aconselhada a sua utilização no
contexto de microsserviços. Essas características do software produzidos têm relação
com aplicação do método do Peter Coad. Além disso, é importante lembrar que essa
abordagem é muito utilizada com Scrum, devido ao seu processo iterativo e
incremental.

Abordagens Ágeis em Engenharia de Software – Página 21 de 29

Capítulo 4. DDD – Domain Driven Development

Neste capítulo, falaremos sobre a abordagem de desenvolvimento orientado

por domínios (DDD). Essa abordagem é mais conceitual que as anteriores, sendo
muito utilizada quando é necessário a compreensão de contextos de softwares
complexos. Ex.: imagine que sua equipe irá desenvolver um software gerencial
completo para uma empresa que vende foguetes, que também tem um módulo
educacional voltado a pessoas carentes e ainda tem um app para dar suporte para
investidores da bolsa de valores. Ou seja, são vários sistemas dentro deste contexto,
e, para desenvolver, você deve compreender cada um desses sistemas e quais as
suas relações/dependências.

O DDD surgiu devido ao grande sucesso de um livro (Domain Driven Design

– atacando a complexidade no coração do software) de Eric Evans no ano de 2003.
Neste livro, Evans mostra uma série de padrões a serem utilizados para resolver
problemas no desenvolvimento. Esse livro trouxe a ideia de domínio e essa ideia teve
muita aceitação no meio do desenvolvimento de software.

O primeiro e fundamental conceito para compreender a abordagem orientada

a domínios é o conceito de domínio. Devemos compreender Domínio como o Core
Business da empresa, podemos usar a expressão “Razão da empresa existir”. No
exemplo anterior, é como se a empresa tivesse três domínios: comércio de foguete,
módulo educacional e suporte para investidores.

O pilar conceitual chave do DDD é este, compreender quais os domínios da

empresa e direcionar o desenvolvimento através desses domínios. Fazendo a
modelagem conceitual desta forma, tende-se a gerar softwares modulares e com
adequação para aplicação de orientação a objetos. Uma outra importante vantagem
é que desenvolvendo o código por domínios, você gera componentes modulares e
com baixo acoplamento.

Para ser possível a correta definição dos domínios, é importante a definição

de uma linguagem ubíqua (universal), que será utilizada entre os domains experts e
a equipe de desenvolvimento (hands on modeler) em eventuais reuniões, onde são

Abordagens Ágeis em Engenharia de Software – Página 22 de 29

levantadas as questões para entendimento dos domínios. O uso da linguagem ubíqua
é de extrema necessidade, pois existem algumas palavras que têm sentidos
diferentes em domínios diferentes. No exemplo do início do capítulo, a palavra cliente
teria significados um pouco diferente em cada um dos domínios, pois um cliente de
compra de foguete tem atributos diferentes de um cliente de módulo educacional.

Uma das grandes dificuldades de aplicação deste método é a de alcançar a

compreensão dos domínios e de suas relações/dependências.

4.1 DDD – Bounded Contexts e Contexts Maps

No DDD, os domínios do software são modelados através da figura dos

Bounded Contexts. Os bounded contexts delimitam as funcionalidades, classes e
dados manipulados dentro de cada domínio. Eventualmente, os domínios podem ter
dados ou funcionalidades compartilhadas entre si, essa característica é uma das
maiores dificuldades de aplicação desta abordagem.

Esses domínios são desenhados pela equipe de desenvolvimento com base

nas histórias geradas pelos domains experts, nas reuniões de levantamento de
informações. Caso seja necessário, utiliza-se uma linguagem ubíqua para cada um
dos domínios (bounded contexts). A Figura 8, logo abaixo, demonstra dois domínios
(bounded contexts) e as classes compartilhadas entre eles. O conjunto de dois ou
mais domínios é chamado de Context Maps.

Abordagens Ágeis em Engenharia de Software – Página 23 de 29

 Figura 8 – Bounded Contexts.

Fonte: https://martinfowler.com/bliki/BoundedContext.html.

Entre as diversas vantagens do DDD, podemos evidenciar o seu auxílio na

plena compreensão do contexto de desenvolvimento do software. Por outro lado, se
precisássemos ressaltar dificuldades ou limitações, poderíamos citar o caso de
inviabilidade de aplicação em empresa com muitos domínios e com alta dependência
entre os mesmos.

Abordagens Ágeis em Engenharia de Software – Página 24 de 29

Capítulo 5. DAD – Disciplined Agile Delivery

Conforme já falado, não existe metodologia “Bala de Prata”: a metodologia

que é adequada para um determinado contexto de desenvolvimento pode ser
completamente inviável em outro, até mesmo as metodologias e abordagens ágeis.
A DAD (Disciplined Agile Delivery) surgiu como conceito de uma abordagem híbrida
por Scott Ambler por volta do ano de 2009. Nessa época, Ambler era chefe de
metodologia de TI e procurava descobrir qual a melhor metodologia. Para isso, fez
diversas pesquisas.

Para sua surpresa, o que descobriu é que grande parte das organizações
falava que usava Scrum, XP ou Kanban, mas quando o Ambler ia levantar detalhes,
o que ele via era que as organizações usam metodologias híbridas, como o Scrum
com programação em pares e conceitos de RUP para entrega de features.

Nesse contexto, Ambler tentou propor um framework de ferramentas que

deixaria a possibilidade do engenheiro de software “montar” a sua própria
metodologia, utilizando as melhores práticas e estratégias ágeis das metodologias já
existentes. Conforme pode ser visto na Figura 9.

Figura 9 – DAD – Disciplined Agile Delivery.

Fonte: https://www.objective.com.br/disciplined-agile-delivery/.

Abordagens Ágeis em Engenharia de Software – Página 25 de 29

5.1 Ciclo de Vida

O DAD utiliza um ciclo de vida voltado para a construção de funcionalidades

de forma iterativa e incremental, com possibilidade do desenvolvedor usar as
ferramentas que melhor entender para dirigir a escolha de qual funcionalidade será
desenvolvida.

O ciclo de vida do DAD é composto por três fases:

1) INCEPTION:

Assim como as outras abordagens, o processo se inicia por uma fase onde
são levantadas informações necessárias para o desenvolvimento do software. Ex.:
levantamento de funcionalidades, mapeamento conceitual, escrita de User Stories. O
DAD não define quais informações devem ser levantadas ou quais ferramentas
podem ser utilizadas, ele apenas disponibiliza uma lista de ferramentas e dá
sugestões conforme o caso. Essa fase normalmente tem o prazo aproximado de 30
dias.

2) CONSTRUCTION:

Durante essa fase, uma equipe DAD produzirá uma solução potencialmente
consumível em uma base incremental. Eles podem fazê-lo por meio de um conjunto
de iterações ou por meio de uma abordagem de fluxo contínuo e enxuto. A equipe
pode aplicar aqui um híbrido de práticas do Scrum, XP, Agile Modeling, Agile Data e
outros métodos para fornecer a solução.

3) TRANSITION:

O DAD reconhece que, para projetos ágeis em grandes empresas, a

implantação da solução para os stakeholders geralmente não é um exercício trivial.
Por isso, é importante que as equipes procurem simplificar seus processos de
implantação para que, com o passar do tempo, essa fase dure cada vez menos tempo
– até que, idealmente, desapareça.

Abordagens Ágeis em Engenharia de Software – Página 26 de 29

 As três fases acima são realizadas de forma iterativa e incremental, com a
flexibilidade para escolher a metodologia por parte do responsável pelo
desenvolvimento, podendo optar por um método definido ou por um híbrido entre
esses. A figura abaixo mostra o conceito do ciclo de vida do DAD:

Figura 10 – Ciclo de vida DAD.

Fonte: https://www.objective.com.br/disciplined-agile-delivery/.

No ano de 2019, o PMI (Project Management Institute) teve os direitos sobre

esta metodologia e a incluiu em um arcabouço de soluções empresariais.

Essa metodologia, que também pode ser considerada uma abordagem, tem se
mostrado uma boa ferramenta e tem tido grande aceitação por empresas que têm
altos índices de governança e não possuem o desenvolvimento de software como
núcleo principal de seu negócio. Essa metodologia vem se mostrado muito eficiente
para empresas que estão buscando transitar do tradicional para o ágil.

Abordagens Ágeis em Engenharia de Software – Página 27 de 29

Capítulo 6. Conclusões

Apenas destacando aqui alguns pontos que nos auxiliam a compreender esse
módulo de forma geral:

▪ Não existe método ágil e nem tradicional Bala de Prata.

▪ TDD melhora a qualidade do processo de desenvolvimento de software.

▪ BDD é uma evolução do TDD e auxilia na compreensão do domínio.

▪ FDD é uma excelente metodologia, de fácil compreensão e aplicação junto

com Scrum.

▪ DDD nos auxilia na compreensão do contexto geral do desenvolvimento.

▪ DAD é uma framework de trabalho que tem como uma das principais
característica a flexibilidade, se adequando a vários contextos.

▪ Ser ágil é mais ser adaptável do que ser rápido.

▪ Método iterativos propiciam entrega de valor incremental.

Abordagens Ágeis em Engenharia de Software – Página 28 de 29

Referências

AGILE MODELING. Home. Disponível em: http://agilemodeling.com/style/. Acesso

em: 24 maio 2021.

CASTRO, Artur de. Disciplined Agile Delivery: o que é e como funciona?. Disponível
em: https://www.objective.com.br/disciplined-agile-delivery/. Acesso em: 24 maio
2021.

CUKRIER, Daniel. DDD – Introdução a Domain Driven Design. 2010. Disponível em:
www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/. Acesso
em: 24 maio 2020.

MARTIN FOWLE. Domain Driven Design. Disponível em:

https://martinfowler.com/tags/domain%20driven%20design.html. Acesso em: 24 maio
2021.

PACHECO, Diego. FDD: Um Método Ágil e Eficiente. 2009. Disponível em: diego-
pacheco.blogspot.com/2009/06/fdd-um-metodo-agil-e-eficiente.html. Acesso em: 24
maio 2021.

PIRES, Eduardo. DDD, TDD, BDD, Afinal o que são essas siglas?. 2012. Disponível
em: https://www.eduardopires.net.br/2012/06/ddd-tdd-bdd/. Acesso em: 24 maio
2021.

PMI – PROJECT MANAGEMENT INSTITUTE. The Disciplined Agile Mindset.

Disponível em: https://www.pmi.org/disciplined-agile/mindset. Acesso em: 24 maio
2021.

Abordagens Ágeis em Engenharia de Software – Página 29 de 29