Abordagens Ágeis de Desenvolvimento de Software

Abordagens Ágeis De Desenvolvimento
de Software
Capítulo 1. Contexto Desenvolvimento de Software Ágil
Prof. Odivaney Ramos Pedro

Abordagens Ágeis de Desenvolvimento
de Software
Aula 1.1. Apresentação

Agenda
 Apresentação.
 Falando Sobre o Módulo.
 Próximas Aulas.
Abordagens Ágeis de
Desenvolvimento
de Software
Próximas Aulas
01. 03.
Contexto. Práticas Necessárias.
02. 04.
Manifesto Ágil. Mitos do Desenvolvimento.
Abordagens Ágeis de Desenvolvimento
de Software
Aula 1.2. Contexto

Agenda
 Contextualização.
 Métodos Tradicionais.
 Métodos Ágeis.
Contexto Ágil
1. Modelos Tradicionais.
2. Modelos Ágeis.
3. E o Desenvolvimento? Muda?
Tradicional X Ágil
https://www.inovalab.net.br/post/metodologia-%C3%A1gil-tudo-que-voc%C3%AA-precisa-saber-antes-de-come%C3%A7ar-a-usar
Tradicional X Ágil
https://www.inovalab.net.br/post/metodologia-%C3%A1gil-tudo-que-voc%C3%AA-precisa-saber-antes-de-come%C3%A7ar-a-usar
Desenvolvimento Ágil
1. Processo Cíclico.
2. Documentação Inteligente.
3. Comunicação Intensa.
4. Adaptabilidade.
Conclusão
• Desenvolvimento tradicional não dá suporte a

Agilidade/Adaptabilidade.
• Boas práticas do desenvolvimento tradicional não devem

ser abandonadas.
• Não existe bala de prata.
• Agilidade é EVOLUÇÃO
Próximas Aulas
01. 03.
Manifesto Ágil. Mitos do Desenvolvimento.
02. 04.
Práticas Necessárias. Papel do Desenvolvedor.
de Software
Aula 1.3. Manifesto Ágil

Agenda
 Evolução das Boas Práticas.
 Manifesto Ágil:
 Valores;
 Princípios.
Boas Práticas Anos 90
1. Crystal Methods
2. Refactoring
3. DSDM
4. Scrum & Programação em Pares
5. FDD
6. Adaptative SW (XP)
7. ...
8. 2001 (MANIFESTO ÁGIL)
Manifesto Ágil - Valores
Manifesto Ágil - Princípios
Conclusão
• Boas práticas permanecem.
• Complexidade dos sistemas tente a aumentar.
• Manifesto Ágil.
• Agilidade é ADAPTAÇÃO.
Próximas Aulas
01. 03.
Práticas Necessárias. Papel do Desenvolvedor.
02. 04.
Mitos do Desenvolvimento. ...
de Software
Aula 1.4. Práticas Necessárias

Agenda
 Características Desenvolvimento Ágil.
 Dificuldades técnicas.
 Práticas Necessárias.
Características Desenvolvimento Ágil
1. Entrega Frequente
2. Ciclos de Desenvolvimento curtos
3. Versões
4. Integração constante
5. ...
Dificuldades Técnicas
1. Como viabilizar integrações com frequência?
2. Como viabilizar implantações com frequência?
3. Como viabilizar entregas constantes com qualidade?
4. ...
Dívida Técnica
Deadlines apertados podem levar à: falta de

refatoração, menos testes do que o necessário, soluções
improvisadas...
A dívida técnica leva a regra custo da descoberta

de um problema do 1x10x100.
Dívida Técnica - Sinais
• Queda da produtividade da equipe ao longo das iterações.
• Uso de Versões defasadas de Frameworks e Bibliotecas.
• Código violando boas práticas (ferramentas automatizadas de análise de
código).
• Baixa cobertura de testes.
• Aumento do número de Defeitos em produção.
• Descoberta de defeitos tardios.
• Alterações em um componentes gerando alterações em outros componentes.
• ...
Práticas Necessárias
1. Processo de Qualidade
2. Integração Contínua
3. Boas práticas de qualidade

Processo de Qualidade
1. Verificação
2. Validação
3. Conhecimento técnico
4. Apoio Ferramental
5. Automatização
6. ...
Integração Contínua
1. Repositório Único de Código

2. Automatize o Build
3. Torne o Build Auto-testável
4. Commits Diários
5. Commits disparam um Build
6. Build rápido
7. Teste em clone do ambiente de produção
8. Último executável acessível a todos
9. Dê visibilidade a todos sobre os resultados do Build
10. Automatize a implantação
11. ...
Boas Práticas
1. Refatoração Constante
2. Desenhe Simples (dividir para conquistar)
3. Padrões de Projeto
4. Propriedade coletiva de código
5. Ritmo Sustentável
6. Padrão de Nomenclatura
7. Gestão de Equipes
8. ...
Conclusão
• Métodos Ágeis não é sinal de felicidade.
• Dívidas Técnicas são caras e os juros são pesados.
• São necessárias práticas a mais que o modelo tradicional.
• Testar, testar e testar.
• Integração Contínua.
Próximas Aulas
01. 03.
Mitos do Desenvolvimento. ...
02. 04.
... Papel do Desenvolvedor.
de Software
Aula 1.5. Mitos do Desenvolvimento Ágil

Agenda
 Falso Ágil.
 Ágil ou Caos?
 Adapte apenas o que você conhece.
 Pouco planejamento é ser Ágil.

Falso Ágil
“Implantação automática de práticas sem conhecer os valores.”
Check-list com os próprios valores do Manifesto ágil:

• Indivíduos e Interações ou Processo e Ferramentas?
• Software funcional ou Documentação Abrangente?
• Cliente amigo ou Divergências contratuais?
• Adaptabilidade ou Rigidez?
Ágil ou Caos
“Falta de planejamento não é Agilidade”
Check-list básico para verificação (PROJETOS ITERATIVOS E

INCREMENTAIS):
• Entregas SEMPRE são testadas e funcionais?

• A iteração se inicia sem a especificação estar completa?
• O Projeto tem iterações “timeboxed” menores que 30 dias?
Adapte apenas o que conhece
“Planeje bem a mudança do tradicional par

ao ágil”
Um dos maiores motivos de insucessos de métodos ágeis é a

adoção de métodos adaptados por empresas que não tentaram,
nem cogitaram, a sua adoção integral.
Pouco Planejamento
“Planeje muito, mas planeje para que possa

haver mudanças”
1. Não detalhe seu planejamento total no início do projeto.

2. Mudanças são boas (escopo variável).
3. Se precisar fixar, fixe o custo, prazo, orçamento, qualidade, mas não
fixe o escopo. Desenvolva em ordem de prioridade.
4. Tenha sempre em mente a VISÃO DO PROJETO.
Conclusão
• Ficar rápido não é ser Ágil.
• Ser ágil não significa NÃO ter regras.
• Processos são importantes.
• Adapte apenas o que você conhece.
• Em um projeto Ágil documentação é resultado

e não insumo.
Próximas Aulas
01. 03.
Papel do Desenvolvedor. Testes de Software.
02. 04.
Abordagens Ágeis. ...
de Software
Aula 1.6. Papel do Desenvolvedor

Agenda
 Desenvolvedor no Paradigma Tradicional.
 Funções do Desenvolvedor Ágil:

 Envolvimento;
 Colaboração;
 Times Ágeis;
 Escopo de Atuação.
Desenvolvimento Tradicional x Ágil
TRADICIONAL:
• Desenvolvedor apenas codifica requisitos.
• Atuação limitada.
• Sem liberdade.
ÁGIL:
• Mais que codificar.
• Dinamismo.
• Maior liberdade.
• Envolvimento.
• Qualidade.
• Times autogerenciáveis
Funções do Desenvolvedor Ágil
Colaboração e envolvimento!!!!
• Estimativas.
• Antecipação de problemas.
• Identificação de modelos ideais.
• Sugerir boas práticas de programação.
• Verificação e envolvimento quando necessário na validação.
• Implantação.
Conclusão
• Cultura Ágil tem que disseminada na equipe.
• Sentimento de pertencimento aumenta a

qualidade.
• Métodos ágeis o sucesso individual é

secundário.
• Os melhores codificadores, nem sempre são os

melhores desenvolvedores ágeis.
Próximas Aulas
01. 03.
Metodologias Ágeis. Testes de Software.
02. 04.
TDD. ...
de Software
Capítulo 2. TDD

de Software
Aula 2.1. Testes de Software

Agenda
 Definição:
 Critérios de Qualidade de Software.
 Classificação por estágio temporal.
 Classificação por características técnicas.
 Automação.
 Agile Testing.
Testes de Software
Processos de verificação e validação

para aumentar a qualidade no desenvolvimento
de software.
Qualidade
Atributos (ISO 9126 ):
• Funcionalidade
• Confiabilidade
• Usabilidade
• Eficiência
• Manutenibilidade
• Portabilidade
Foco de Teste
x
Estágio do Projeto
S
Engenharia de sistemas
Requisitos R
Projeto
D
Código C
Teste de unidade
U
I Teste de integração
Teste de validação
V
Teste de sistema
ST
Tipos de Testes
• Caixa Branca
• Caixa Preta
• Caixa Cinza
• Regressão
• Testes não funcionais
Importância da Automação
1. Agilidade
2. Custos
3. Simplicidade
4. Segurança
5. Antecipação dos erros
Agile Testing
https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
Agile Testing
Testes F.I.R.S.T
• FAST
• INDEPENDENT
• REPEATABLE
• SELF-VALIDATING
• TIMELY
Benefícios Agile Testing
• Software correto
• Alta Qualidade
• Prazos e Custos
• Alerta mais cedo
• Adaptação a Mudança
Conclusão
• Importância dos testes.
• Testes ao longo de todo o projeto.
• Tipos de testes.
• Regressão é importantíssima.
• Automação é essencial.
• ...
Próximas Aulas
01. 03.
TDD. REFACTORING.
02. 04.
TDD. BDD.
de Software
Aula 2.2.1. Conceitos Gerais TDD (Parte 1)

Agenda
 TDD (Test Driven Development):

 Fundamentos;
 Ciclo de Desenvolvimento;
 Vantagens;
 Limitações;
 Ferramentas;
 Leitura complementar.
TDD - Test Driven Development
TDD (Test Driven Development/Desenvolvimento Orientado por

testes) é uma técnica de desenvolvimento de softwares, amplamente utilizada
nos dias atuais.
O TDD tem enfoque no desenvolvimento de software amparado pela

criação/realização de testes ao longo de todo o desenvolvimento. Esta prática
auxilia o desenvolvimento de software com excelentes níveis de qualidade.
TDD - Fundamentos
• Regra 10/Dívida Técnica
• Qualidade no ciclo
• XP
• Definição de testes/Regras de Negócio
• Testes de Unidade
• Testes de Componentes
• Regressão
• Automação
TDD – Ciclo de Desenvolvimento
RED VERDE REFATORE
• TEST-FIRST
• "Keep It Simple, Stupid"

TDD – Ciclo de Desenvolvimento
TDD - Vantagens
• Qualidade
• Manutenção
• Regras de negócio
• Validação
• Custo
• Rapidez no Desenvolvimento
• Design/Projeto de Classes eficiente
• Modularização do código
• Testes como documentação

TDD - Limitações
• Controle de Versões
• Requisitos funcionais
• Fakes Mocks (Mundo externo)
• Suporte Gerencial
• Lacunas
• Falso senso de Segurança
• Visibilidade de código
• Testes de Integração podem ser parciais

TDD – Ferramentas
● Java – Junit
● C– Cunit
● .NET – NUnit
● PHP – PHPUnit
● Node ou Javascript – Jasmine
● Python – PyUnit
Leituras Complementares
• https://www.devmedia.com.br/testes-com-jasmine-melhore-a-qualidade-do-javascript/26957
• http://www.franciscosouza.com.br/2009/07/24/testes-unitarios-com-pyunit/
• https://www.devmedia.com.br/introducao-ao-desenvolvimento-guiado-por-teste-tdd-com-
junit/26559
• https://www.devmedia.com.br/test-driven-development-tdd-simples-e-pratico/18533
• https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
Conclusão
• TDD tem tudo a ver com agilidade.
• Melhora a qualidade de software.
• Nem tudo é um mar de rosas.

Próxima Aula...
01. 03.
TDD. BDD.
02. 04.
REFACTORING. ...
de Software
Aula 2.2.2. Conceitos Gerais TDD (Parte 2)

Agenda
 Testes de Unidade.
 Refactoring:
 Code Smell;
 Boas práticas.
 Dublês.
 Conclusão.
Testes de Unidade
• Unidade: menor parte testável de um

sistema.
• Testes de Unidade: testes de funções

simples e resultados constantes
Testes de Unidade
Características
• Rodam rápido: até 10 mins.
• Independência.
• Dados simples.
• Não precisam de configurações complexas.
• Não usam a rede.

• ...
Testes de Unidade
Como criar?
• Faça uma lista inicial, e alimente ao longo do
desenvolvimento.
• Teste todas as operações que você sabe que
serão implementadas.
• Nomenclatura de testes.
• Uma asserção lógica por testes.
• Planejamento de testes.
REFACTORING
“É uma técnica para reestruturação do
corpo de um código, alterando sua estrutura
interna sem modificar o seu comportamento
externo.” Martin Fowler
Simplicidade
Legibilidade
Performance
...
CODE SMELL
• Código duplicado.
• Rotinas muito longas.
• Interface sem bom nível de abstração.
• Mudanças em cadeia.
• Nomenclatura ruim.
• Dados públicos em classes.
• Necessidade de comentários explicativos.
• Variáveis Globais.
• ...
REFACTORING
1. Extrair Métodos.
2. Parametrizar Métodos
3. Extrair Classes.
4. Substituir comandos condicionais por polimorfismo.
5. Substituir Herança por Delegação.
6. Substituir Atributos por Objetos
7. Substituir Vetor por Objetos
8. Substituição de parâmetros (ex.: introdução de
objeto)
9. Substituir números mágicos por constantes
simbólicas.
10. Nomenclatura.
USO DE DUBLÊS
“É uma técnica que propõe a substituição do
código que define as funcionalidades por
implementações falsas que emulam o código real. “
• MOCK: cópia de um elemento externo, com
comportamento idêntico.
• STUB: simula um elemento externo, mas com um
comportamento fixo e previsível.
Conclusão
• Dividir para conquistar.
• Baby Steps.
• Facilidade de correção.
• Melhoria da Qualidade.
• Code Smell.
• Refatoração.
• ...
Próxima Aula
01. 03.
REFACTORING. ...
02. 04.
TDD. ...
de Software
Aula 2.3. REFACTORING

Agenda
 O Que É?
 Tipos.
 Conclusão.
 Próxima Aula.
REFACTORING
Técnica de reestruturar o corpo de

um código sem alterar seu comportamento.
São diversas técnicas, que sozinhas

modificam pouco de um código, mas em
grande quantidade produzem melhorias
significantes.
Refatoração Básica
Refatoração Encapsulamento
Refatoração
Movimentações de Código
Refatoração
Simplicidade de Lógica
Refatoração
Lidando com Herança
Conclusão
• Ferramenta prática.
• Dia a dia do programador.
• Check-lists Direcionados.
• Ferramentas Automatizadas.
Próxima Aula
01. 03.
BDD. ...
02. 04.
... ...
de Software
Aula 2.4. BDD (Behavior Driven Development)

Agenda
 Definição.
 Princípios.
 Como Funciona?
 User Stories.
 Vantagens.
 BDD e TDD.
 Conclusão.
BDD – Behavior Driven
Development
“Abordagem ágil de desenvolvimento de software que
encoraja colaboração entre as partes envolvidas no processo,
utilizando-se de técnicas de verificação e validação.”
“BDD é sobre implementar uma aplicação através da

descrição do seu comportamento pela perspectiva dos seus
stakeholders.”
* Resposta ao TDD
BDD - Princípios
• Linguagem Úbiqua (DSL).
• Participação dos Usuários/User Stories.
• Mais comportamento/Menos Código.
• Pontos fortes do TDD.
• TDD (caixa Branca)/BDD (caixa preta).
• Agilidade é qualidade.
• ...
Como funciona?
Necessidade de implantação
de uma funcionalidade do
Backlog
Definição dos testes
funcionais automatizados
como base nos exemplos.
Levantamento das User

Stories com os usuários
Levantamento dos exemplos
concretos como resultado
esperado das User Stories.
Descrição dos cenários de

comportamentos (features)
Levantamento das
User Stories
User Stories
User Story ou “história de usuário” é uma

descrição concisa de uma necessidade do usuário
do produto (ou seja, de um “requisito”) sob o ponto
de vista desse usuário.
User Stories são centradas no valor
entregue ao usuário do sistema.
User Stories
Componentes Críticos
CARTÃO
CONVERSAS
CRITÉRIOS DE ACEITAÇÃO
User Stories
Padrão INVEST
• Independente
• Negociável
• Valor
• Estimável
• Simples/Pequeno
• Testável
User Stories
Story Map
User Stories
Exemplo
REQUISITO:
O sistema permite pesquisar candidatos por função,
especialidade e região geográfica.
A função de um candidato pode ser uma entre
analista, responsável técnico, programador e web designer.
A especialidade de um candidato pode ser uma entre
SOX, Agile, UX e Microsoft.
A região geográfica de um candidato é a cidade e,
opcionalmente, num raio medido em kms da cidade indicada.
O raio é de 50 kms por omissão.
User Stories
Exemplo
USER STORY: quem, o quê e porquê
Título:
Pesquisa de candidatos por função.
Descrição:
Enquanto usuário, quero pesquisar candidatos
cadastrados por função, para poder analisar os perfis.
Critério de Aceitação:
A pesquisa retorna uma lista de candidatos ou uma
mensagem indicando que não há resultados.
User Stories
Notação Gherkin (DSL)
BDD - Vantagens
• Nivela o conhecimento entre as partes.
• Given-Then-When.
• Garante a regressão das funcionalidades.
• Acelera a criação dos testes.
• ...A
BDD x TDD
TDD: VERIFICAÇÃO, FOCO CÓDIGO NÃO VISÍVEL, JUNIT

BDD: VALIDAÇÃO, FOCO APROVAÇÃO DAS TELAS, JBEHAVE
BDD – Boas Práticas
• Envolvimento do testador
• Conhecimento da ferramenta
• Entregar o BDD na sprint
• User Stories padrão INVEST
• Ferramentas de Automação...
Conclusão
• BDD realidade com apoio ferramental.
• BDD & TDD se complementam.
• Testador tem papel chave.
• Estimula comportamento entre as partes (3

AMIGOS).
• Linguagem natural (DSL).
• Se possível testadores diferentes para BDD & TDD.
• Testes manuais são sempre necessários.
• INVEST.
• ...
Próxima Aula
01. 03.
Testando manualmente. ...
02. 04.
Apoio Ferramental. ...
de Software
Capítulo 3. FDD (Feature Driven Development)

de Software
Aula 3.1.1. Conceitos Gerais FDD (Parte 1)

Agenda
 FDD (Test Driven Development):

 HISTÓRICO;
 CARACTERÍSTICAS;
 PROCESSOS.
FDD - Feature Driven Development
• Anterior ao Manifesto Ágil.
• Singapura (98/99): grande projeto Java para um Bank.
• Baseado no método COAD (OO).
• Jeff de Luca (Projetos).
• Derivado processos iterativos e Lean.

FDD - Feature Driven Development
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.
O FDD busca o desenvolvimento por funcionalidade, ou seja, por um

requisito funcional do sistema.
LEMA: RESULTADOS FREQUENTES TANGÍVEIS E FUNCIONAIS!!!!!!!!!!!

FDD - Características
• Ágil, Adaptativo e Iterativo;
• Foco no Desenho e Construção;
• Interação com outras metodologias;
• Uso de diversos Modelos para documentar;
• Foca em qualidade no processo;
• Contempla gerenciamento de projetos ágeis;
• Abordagem de Eng. Software orientada por objetos;
• Adequado a problemas complexos;
• Modelagem orientada a objetos do Domínio...

FDD - Características
• Entregas úteis a cada 2 semanas, ou menos.
• Uso de Feautures/Construções Regulares.
• Adequado a grandes equipes:
• Propriedade individual da Classes;
• Equipes de funcionalidades (3 a 6 programadores).
• Planejamento detalhado e guia para execução.
• Rastreabilidade e relatórios com precisão.
• Relatórios Gerais.
• Administração da Configuração/Controle de Versões.
• Avalia-se o plano e as estimativas aos 10% do projeto.

FDD – Processos Principais
Develop and overall
model
Build a feature List
Design by feature Build by feature
Plan by Feature
• Ciclos de 2 semanas
FDD – PADRÃO EVTX
• ENTRY: critérios para entrada da fase.
• TASK: lista de tarefas da fase.
• VERIFICATION: especificação dos tipos de

avaliações e inspeções de projeto e códigos teste.
• EXIT: específica os critérios de aceitação para fase

concluída.
FDD – Definição de
funcionalidades/Features
<AÇÃO> <RESULTADO> <OBJETO>
• EXEMPLOS:
• Cadastrar dados do usuário.
• Realizar compra de livro.
• Solicitar aluguel do veículo.
• Calcular desconto de uma venda.
• Concepção e Planejamento:
• Desenvolver um modelo abrangente: Análise Orientada a Objetos;
• Construir a lista de funcionalidades: Decomposição Funcional;
• Planejar por funcionalidade: Planejamento Incremental.
• Construção:
• Detalhar por funcionalidade: Design/Projeto OO;
• Construir por funcionalidades: Implementação e Testes.
FDD – (1) Desenvolvendo um Modelo
Abrangente
• O que é?
Modelagem completa e abrangente do projeto.
• Quem participa?
Especialistas de negócio, programadores experientes, arquitetos...
• Como?
• São realizadas pequenas reuniões, onde os especialistas de negócio
apresentam as funcionalidades que o sistema deve ter (DOMAIN Walkthrough).
• Após a reunião são formados pequenos grupos, que constroem um modelo
provável.
• Os modelos são avaliados, e é escolhido o melhor, ou uma junção entre as
propostas.
• Processo se repete, até que todo o escopo dos requisitos esteja modelado.
FDD – (1) Desenvolvendo um Modelo
Abrangente
Camadas do Modelo:
1. ÁREA DE NEGÓCIO
2. ATIVIDADE DE NEGÓCIO
3. AUTOMATIZAÇÃO DA ATIVIDADE (funcionalidade)
EX: SISTEMA COMERCIAL.

FDD – (2) Construir a lista de
Funcionalidades
• O que é?
Transformar os requisitos da fase anterior em funcionalidades a serem
desenvolvidas.
• Quem participa?
Equipe da LISTA DE FUNCIONALIDADES, composta pelos
programadores líderes que participaram da fase anterior.
• Como?
Fazendo a decomposição funcional de cada um dos requisitos da fase
anterior.
Categorização da lista por Área, Atividades de Negócio e Funcionalidades.
FDD – (3) Planejar por Funcionalidades
• O que é?
Plano de Desenvolvimento do Software.
• Quem participa?
Equipe de Planejamento: Gerente do Projeto, Gerente do
Desenvolvimento e os Programadores Chefes.
• Como?
Avaliando as funcionalidades e definindo a ordem baseado em critérios.
PLANO DE DESENVOLVIMENTO
CRONOGRAMA DE IMPLEMENTAÇÃO DE FUNCIONALIDADES
PROGRAMADORES CHEFES ATRÍBUIDOS AS FUNCIONALIDADES
LISTA DE CLASSES E SEUS PROPRIETÁRIOS
FDD – (4) Detalhar por Funcionalidades
• O que é?
Detalhamento do processo de implantação de cada funcionalidade.
• Quem participa?
Programador Chefe e programadores.
• Como?
Atribuição das classes a seus responsáveis.
Construção do Diagrama de Sequência.
Refino do Modelo de Classes.
Inspeção final da modelagem.
PACOTE DE TRABALHO
MODELO DE CLASSES
DIAGRAMAS DE SEQUÊNCIA
REQUISITOS DE IMPLEMENTAÇÃO
FDD – (5) Construir por Funcionalidades
• O que é?
Implementação do modelo.
• Quem participa?
Equipe de desenvolvimento.
• Como?
Base no Pacote de Trabalho.
Após a construção do código o mesmo deve ser testado e inspecionado.
Se os testes obtiverem sucesso, o pacote vira uma release.
FUNCIONALIDADE COM VALOR PARA O CLIENTE LIBERADA

EM UM CURTO ESPAÇO DE TEMPO.
Conclusão
• Possibilidade de uso com o Scrum.
• Aplicável a vários tipos de contextos.
• Geração de valor.
• Mais formal que outros métodos ágeis.
• Ideal para empresas tradicionais migrando para Agilidade.
• Eficiente na gestão de grandes equipes.

Próxima Aula...
01. 03.
FDD. DDD.
02. 04.
PRIORIZANDO REQUISITOS. DAD.
de Software
Aula 3.1.2. Conceitos Gerais FDD (Parte 2)

Agenda
 FDD (Test Driven Development):

 CARGOS E RESPONSABILIDADES;
 BOAS PRÁTICAS;
 CONCLUSÃO;
 LEITURAS COMPLEMENTARES.
Develop and overall
model
Build a feature List
Design by feature Build by feature
Plan by Feature
FDD – Cargos e Responsabilidades
• Gerente de Projeto (Project Manager)
• Arquiteto Líder (Chief Arquitect)
• Gerente de desenvolvimento (Development Manager)
• Programador líder (Chief programmer)
• Proprietário de classe (Class owner)
• Especialista do domínio (Domain experts)
• Gerente do domínio (Domain manager)
• ...
FDD – Cargos e Responsabilidades
• Gerente de versão (Release manager)
• Guru de linguagem (Language lawyer/language guru)
• Engenheiro de construção (Build engineer)
• “Ferramenteiro” (Toolsmith)
• Administrador de sistemas (System Administrator)
• Técnicos:
• Testatores (Testers)
• Instaladores (Deployers)
• Escritores técnicos (Technical Writers)

FDD – Equipes
• EQUIPE DE MODELAGEM (#1)
• EQUIPE DA LISTA DE FUNCIONALIDADES (#2)
• EQUIPE DE PLANEJAMENTO (#3)
• EQUIPE DA FUNCIONALIDADE (#4)

FDD – Boas Práticas
• Modelagem de Objetos de Domínio (Domain Object Modeling)
• Exploração e explicação do problema de domínio
• Resulta em um arcabouço
• Desenvolver por Funcionalidade (Developyng By Feature)
• Proprietários de Classes Individuais (Individual Class OwnerShip)

FDD – Boas Práticas
• Equipe de Funcionalidades
• Equipes pequenas e dinâmicas
• Inspeção por equipes
• Métodos de correção
• Construções Frequentes (Regular Builds)
• Administração da Configuração (Configuration Manager)

Leituras Complementares
• http://www.featuredrivendevelopment.com/files/CSCIE275_CP_G
uide.pdf
• http://www.featuredrivendevelopment.com/files/FeatureDrivenDev
elopment_0.pdf
Conclusão
• Possibilidade de uso com o Scrum.
• Aplicável a vários tipos de contextos.
• Geração de valor.
• Mais formal que outros métodos ágeis.
• Ideal para empresas tradicionais migrando para Agilidade.
• Eficiente na gestão de grandes equipes.

Próxima Aula...
01. 03.
Priorizando requisitos. DDD.
02. 04.
UML. DAD.
de Software
Aula 3.2. Priorizando Requisitos

Agenda
 Priorizar requisitos?
 Práticas para Priorização:

 Product Backlog (1)
 Work List Item (2)
 Option Pool (3)
 Conclusão.
 Próximas Aulas.
FDD – Priorizar requisitos?
Contexto de Desenvolvimento Ágil:
• Entrega de valor incremental
• Alta Qualidade
• Envolvimento do Cliente
Como Conseguir?
• Avalie os requisitos indispensáveis.
• Avalie os requisitos de maior valor observado.
• Avalie restrições técnicas.
• Considere as possíveis mudanças.
“Entregue valor de forma gradativa e incremental para seu cliente,

através da entrega das melhores funcionalidades de forma gradativa.”
FDD – Product Backlog (1)
• Preencha uma lista Inicial de requisitos com base nas reuniões iniciais.
• Novos Requisitos podem ser adicionados pelas partes interessadas a

qualquer momento.
• Alterações de prioridades, ou exclusão/adaptação de requisitos é possível

sempre.
FDD – Product Backlog (1)
• Uma pessoa tem que ter a palavra final sobre a priorização de requisitos
(Product Owner/Especialista do domínio).
• A cada iteração, ao menos um valor é retirado da lista/pilha e entregue.
• O responsável pela última palavra a respeito da lista/pilha de requisitos,

assume um função similar ao dono do produto (disponível, comprometido,
envolvido...).
• A priorização de itens não relacionados a requisitos são negociadas com os

stake holders, podendo ser descritas na lista ou como tempo ocioso.
FDD – Item Work List (2)
• Vá além dos requisitos funcionais.
• Análise o valor do risco relacionado ao item.
• Modele um pouco a frente.

FDD – Pool Options (3)
• Opções.
• Piscina.
• Opção são classificadas em classes de serviço.
• O Objetivo é limitar o trabalho em progresso (WIP).
• Eliminação de Itens antigos.
FDD – Qual estratégia utilizar?
ESTRATÉGIA VANTAGENS DESVANTAGENS
1)Sobrecarga de manter a pilha atualizada, conforme

mudam as prioridades.
PRODUCT BACKLOG 1)Simplicidade
2)Casos complexos podem requerer várias pilhas.
3)Fator de trabalho próximo a 30% a cada iteração.
1)Sobrecarga de manter a pilha atualizada, conforme

1)Suporta diferentes itens de trabalho.
mudam as prioridades.
WORK ITEM LIST

2)Menos "Overhead Fudge Factor", devido aos itens
2)Casos complexos podem requerer várias pilhas.
serem mais coesos e menos acoplados.
1)Funciona em métodos ágeis e tradicionais.
POOL OPTIONS 1)Just In time

2)Sem necessidade de gerenciar a fila de
prioridades.
Conclusão
• Entrega de valor é essencial.
• Priorização deve ser definida de forma inteligente.
• Existem várias práticas para gerir a sua lista de trabalho a

ser feito.
Próxima Aula...
01. 03.
DDD. ...
02. 04.
DAD. ...
de Software
Capítulo 4. DDD (Domain Driven Development)

de Software
Aula 4.1.1. DDD (Domain Driven Development) (Parte 1)

Agenda
 Definição.
 Princípios.
 MDD.
 Elementos.
 Conclusão.
 Próxima Aula.
DDD – Domain Driven
Development
DOMÍNIO: é o Core Business do sistema. Baseado
em ideias, conhecimento e processos de negócio.
“RAZÃO DO SOFTWARE EXISTIR”.
O pilar chave do DDD é conceituar, através

de modelos, o seu domínio e usar essa
conceituação como base para o desenvolvimento.
Eric Evans 2003 (Livro sobre padrões)

DDD – Princípios
• O.O. superficial
• Alinhamento do código com o

negócio
• Mínimo de acoplamento
• Independência de Tecnologia
DDD – Princípios
• Linguagem Ubíqua.
Se durante uma conversa com um cliente do
sistema de cobrança, por exemplo, ele disser:
“Temos que emitir a fatura para o cliente antes da
data limite”, vamos ter no nosso código alguma coisa do
tipo:
• Uma classe para a entidade Cliente;
• Uma classe para a entidade Fatura;
• Algum serviço que tenha um método emitir;
• Algum atributo com o nome de data limite.
DDD – Princípios
• Uso de modelagem conceitual (MDD).
• Participação de todos (dev e users)
• Ideal para sistemas com regras de negócios

complexas.
• Hands On Modelers.
• Modelo com melhorias contínuas
• ...
DDD – Princípios
• MODEL DRIVEN DESIGN
DDD – Elementos do Modelo
• Entidades
• Objetos de Valor
• Factories
• Serviços
• Repositórios
Conclusão
• Fácil de entender, difícil de aplicar.
• Alinhamento do código com o negócio.
• Participação de todos.
• Criação de um modelo representativo inicial.

Próxima Aula
01. 03.
DDD. ...
02. 04.
DAD. ...
de Software
Aula 4.1.2. DDD (Domain Driven Development) (Parte 2)

Agenda
 Dificuldades DDD.
 Bounded Contexts.
 Contexts Maps.
 Conclusão.
 Próxima Aula.
DDD – Domain Driven
Development
• Sistemas complexos
• Regras de negócio contraditórias
• Como fazer a divisão de trabalho?
• ...
• CONTEXTOS DELIMITADOS
DDD – Bounded Contexts
• Delimita os contextos da aplicação.

• Cada contexto possui suas responsabilidades
claramente definidas (ex.: funcionalidades
agrupadas).
• Linguagem Ubíqua por contexto (cuidado com
entidades com mesmo nomes em contextos
diferentes).
• Contextos são gerados a partir das histórias
produzidas juntos aos Domain Experts.
• ...
DDD – Context Maps
• Caminhos separados
• Núcleo Compartilhado
• ...
NÚCLEO DO DOMÍNIO
Conclusão
• Fácil de entender, difícil de aplicar.
• Uso de Padrões.
• Busca o Core do Negócio.
• Produz software escalável.
• Mínimo Acoplamento.
• Desenvolvimento em paralelo.
Próxima Aula
01. 03.
DAD. ...
02. 04.
... ...
de Software
Capítulo 5. Disciplined Agile Delivery

de Software
Aula 5.1.1. Disciplined Agile Delivery (Parte 1)

Agenda
 Contexto Ágil.
 Definição.
 Características.
 Camadas.
 Princípios.
 Fluxo de Trabalho Devops.
 Papéis.
 Conclusão.
DAD – Disciplined Agile Delivery
Qual o melhor método?
• Equipes heterogêneas.
• Sistemas distintos.
• Projetos diferentes.
• Cases de Sucesso/Insucesso.
• Dificuldade de mudança de paradigma.
• DAD – 2009 – Scott Ambler (TI/IBM).

Características:
• Eliminar indecisões.
• Aspectos críticos de outros modelos.
• Abordagem híbrida.
• Interativo e Incremental.
• Agile Toolkit PMI.

Características:
• Eliminar indecisões.
• Aspectos críticos de outros modelos.
• Abordagem híbrida
• Interativo e Incremental
• Agile Toolkit PMI

4 CAMADAS - PMI
Princípios
DevOps Tradicional Workflow
Disciplined WorkFlow
DAD – Papéis Primários
• Team Lead
• Product Owner
• Team Member
• Architecture Owner
• Stake Holder
DAD – Papéis Primários
• Specialist
• Independent Tester
• Domain Expert
• Technical Expert
• Integrator
Conclusão
• Governança.
• Empresas resilientes.
• Processo definido.
Próxima Aula
01. 03.
DAD. ...
02. 04.
... CONCLUSÃO GERAL.
de Software
Aula 5.1.2. Disciplined Agile Delivery (Parte 2)

Agenda
 Ciclos de Vida.
 Certificação.
 Leituras Complementares.
 Conclusão.
CICLO DE VIDA
• Inception
• Construction
• Transition
Leitura Complementar
• CHOOSE YOUR WOW.
Certificações
Conclusão
• Abordagem prática.
• Melhoria continua.
• Grandes empresas.
• Visão menos técnica.
• Adaptabilidade do Software.
• Adaptabilidade do processo.
Próxima Aula
01.
Conclusão Geral.
de Software
Capítulo 6. Revisão Teórica

de Software
Aula 6.1. Revisão Teórica

Agenda
 Contexto Ágil.
 Manifesto Ágil.
 TDD.
 FDD.
 DDD.
 DAD.
 Conclusão.
Contexto Ágil
• Aumento da Complexidade dos sistemas
• Evolução tecnológica
• Ineficácia dos métodos tradicionais
• Empresas bancando P&D

Manifesto Ágil
TDD - Test Driven Development
ATDD
BDD
FDD – Feature Driven Development
DDD – Design Driven Development
Conclusão
• Manifesto ágil.
Próxima Aula
01. 03.
Atividades práticas. Atividades práticas.
02. 04.
Atividades práticas. Atividades práticas.

Abordagens Ágeis de Desenvolvimento de Software

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Abordagens Ágeis de Desenvolvimento de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Abordagens Ágeis De Desenvolvimento

Prof. Odivaney Ramos Pedro

Prof. Odivaney Ramos Pedro

 Falando Sobre o Módulo.

Prof. Odivaney Ramos Pedro

• Desenvolvimento tradicional não dá suporte a

• Boas práticas do desenvolvimento tradicional não devem

• Não existe bala de prata.

Prof. Odivaney Ramos Pedro

 Evolução das Boas Práticas.

• Boas práticas permanecem.

• Complexidade dos sistemas tente a aumentar.

Prof. Odivaney Ramos Pedro

 Características Desenvolvimento Ágil.

2. Ciclos de Desenvolvimento curtos

1. Como viabilizar integrações com frequência?

2. Como viabilizar implantações com frequência?

3. Como viabilizar entregas constantes com qualidade?

Deadlines apertados podem levar à: falta de

A dívida técnica leva a regra custo da descoberta

3. Boas práticas de qualidade

1. Repositório Único de Código

2. Desenhe Simples (dividir para conquistar)

4. Propriedade coletiva de código

• Dívidas Técnicas são caras e os juros são pesados.

• São necessárias práticas a mais que o modelo tradicional.

• Testar, testar e testar.

Prof. Odivaney Ramos Pedro

 Adapte apenas o que você conhece.

 Pouco planejamento é ser Ágil.

“Implantação automática de práticas sem conhecer os valores.”

Check-list com os próprios valores do Manifesto ágil:

Check-list básico para verificação (PROJETOS ITERATIVOS E

• Entregas SEMPRE são testadas e funcionais?

“Planeje bem a mudança do tradicional par

Um dos maiores motivos de insucessos de métodos ágeis é a

“Planeje muito, mas planeje para que possa

1. Não detalhe seu planejamento total no início do projeto.

• Ficar rápido não é ser Ágil.

• Ser ágil não significa NÃO ter regras.

• Processos são importantes.

• Adapte apenas o que você conhece.

• Em um projeto Ágil documentação é resultado

Prof. Odivaney Ramos Pedro

 Desenvolvedor no Paradigma Tradicional.

 Funções do Desenvolvedor Ágil:

• Cultura Ágil tem que disseminada na equipe.

• Sentimento de pertencimento aumenta a

• Métodos ágeis o sucesso individual é

• Os melhores codificadores, nem sempre são os

Prof. Odivaney Ramos Pedro

Prof. Odivaney Ramos Pedro

 Classificação por estágio temporal.

 Classificação por características técnicas.

Processos de verificação e validação

• Alerta mais cedo

• Importância dos testes.

• Testes ao longo de todo o projeto.

Prof. Odivaney Ramos Pedro

 TDD (Test Driven Development):

TDD (Test Driven Development/Desenvolvimento Orientado por

O TDD tem enfoque no desenvolvimento de software amparado pela