Métodos Ágeis: FDD Guia

Métodos Ágeis: FDD
“Desenvolvimento de software é uma cadeia com diversos elos”
Kent Beck – Criador do eXtreme Programing (XP)
www.agilethink.com.br ©2017
Agile Think® - Todos os direitos reservados

André Vidal
Fundador e Sócio Diretor da Agile Think, com 20 anos de experiência na
área de Tecnologia. Atualmente trabalha como Gerente de Projetos e
Agile Coach. É pesquisador, ministra cursos técnicos e de
especialização nas áreas de Tecnologia da Informação. Articulista das
revistas Engenharia de Software e Java Magazine da Devmedia.
ESCRITOR
Autor do livro Agile
Think® Canvas,
Editora Brasport
AGILE COACH
Agile Coach e Gerente
de Projetos pela
empresa Abu
Consultoria
CONSULTOR
Gestão de Projetos,
Governança,
Processos, Negócios e
Quality Assurance
CERTIFICAÇÕES: MBA Gestão de Projetos,
PMI-ACP, CSM - Scrum Alliance, EXIN-ASF e
SAFe

O que é Desenvolvimento Lean
LEAN
É a aplicação em desenvolvimento de software do modelo “lean manufacturing”, cujos
princípios e práticas para o desenvolvimento de domínio de software foram adaptados do
Sistema Toyota de Produção – (http://en.wikipedia.org/wiki/Lean_software_development)
O Lean é uma subcultura da
comunidade Ágil, com foco na
criação e sustentação de sistemas
de produção de software.
Princípios Lean
1. Eliminar o desperdício no
desenvolvimento de sistemas
2. Amplificar aprendizagem dos envolvidos
no processo
3. Decidir o mais tarde possível!
4. Entregar o mais rápido possível!
5. Capacitar a equipe
6. Construir integridade agregando valores
pessoais e ativos de conhecimento

O que é Agile?
AGILE
Agile é realmente uma cultura que gera processos e não
apenas um processo. Isso deve afetar diretamente o nosso
modo de ensinar aos outros como adotar Agile.
Jeff Patton – (http://www.agileproductdesign.com/)
• O objetivo de uma metodologia ágil é minimizar riscos
inerentes ao desenvolvimento de software.
• A Agile Alliance define os seguintes princípios em
seu Manifesto Ágil, o qual é base para os demais
métodos:
1. Gerar satisfação no cliente pelo atendimento rápido e contínuo no fornecimento de software
2. Entregar software com freqüência semanal, ao invés de longas esperas
3. O software é a principal medida de progresso dos trabalhos
4. Mesmo que tardia, as mudanças nos requisitos são bem-vindas
5. Propiciar diariamente a cooperação entre desenvolvedores e clientes
6. Conversar face a face é a melhor forma de comunicação
7. Os projetos são construídos em torno de pessoas motivadas, confiáveis e que devem ter
atenção contínua, propiciando a excelência técnica e um bom design
8. Simplicidade
9. Auto-organizar equipes
10. Adaptar-se à evolução do negócio

Benefícios e Desafios
Desafios
Existe dificuldade ao
atendimento do que é
solicitado, até que o time
e gerência tenham
absorvido o conhecimento
necessário para resolver
o paradigma. Inicialmente
a performance da
ferramenta pode ter
resultados que
desapontam os
investidores.
Benefícios
Os requisitos iniciais de
produtividade e qualidade
são definidos para os time
boxes, propiciando o
entendimento das
necessidades do negócio,
fornecendo mais
visibilidade ao Líder de
Projeto e Time de
desenvolvimento.
Características do Uso de Lean, Agile, SCRUM e FDD
Curto Prazo
Baseado no artigo:
FREDDY BALLE & MICHAEL BALLE, "Lean or Six Sigma," www.lean.org/library/leanorsigma.pdf.

Desafios
O retorno de
investimento, até que
seja entendido, deve
passar por algumas
barreiras, que são
Implementar uma
mudança de programa
Vencer o cinismo de
empregados mais
experientes.
Benefícios
Time boxes
quantificáveis ou
projetados por classes
de negócio, que
podem ser executadas
paralelamente (“on the
side”).
Baseado no artigo:
Curto Médio Prazo

Baseado no artigo:
Desafios
Requer investimento
intelectual e constante
comprometimento com
resultados com o alto
gerenciamento. Para ter
sucesso na mudança de
modelo da empresa, o
alto gerenciamento tem
que estar comprometido
de forma mais incisiva,
sendo muito mais do que
apenas dar uma benção
distante e assinar o
cheque
Benefícios
Mudança de perspectiva,
que leva a uma
transformação de como
se enxerga o negócio,
sendo a análise uma
fonte fundamental de
vantagem competitiva.
Também aumenta as
barreiras para com os
concorrentes, pois o
modelo tem maior valor
agregado a ele.
Médio Prazo

Desafios
Romper com a falta de
sinergia entre os focos
de ação e ao que levou
à resultados
desapontadores.
Combater apatia e por
fim a falta de interesse
no programa.
Benefícios
Alguns benefícios de
longo prazo que levam
ao abandono do
programa anterior em
substituição por uma
versão mais
atualizada.
Baseado no artigo:
Longo Prazo

O que é FDD?
Feature Driven Development
É um processo de engenharia de software que tem por foco principal a entrega
freqüente de software funcional ao cliente.
• A FDD não foca a programação ou a definição de um modelo bem
definido, mas faz uso de um planejamento iterativo, que tem por
objetivo abstrair e atender as principais necessidades do negócio, que
determinará a forma de atuação da equipe de desenvolvimento.
• É uma metodologia ágil voltada ao
desenvolvimento de software.
• A FDD favorece de maneira incisiva o
envolvimento de clientes (internos ou externos) ao
processo de planejamento e desenvolvimento do
software.
• A FDD está baseada num processo de desenvolvimento de software iterativo
e incremental.

Como Funciona FDD
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver
Por
Funcionalidade
• Entendimento do
Negócio
• Construção de
Modelo Conceitual
Dedicar 1/6 do tempo do Projeto Iteração de Duas Semanas
• Construção da FBS
• Definição das User
Histories
• Atualização do Kanban
• Criação do Burndown
• Diagrama de Classes
• Diagrama de Seqüência
• Código
• Plano de Teste Unitário

Artefatos
Atividades
• FBS: Feature Breakdown
Structure
• Critérios de Aceitação
• Reunião de entendimento do problema,
contando com os membros efetivos do
Time e Cliente.
• Confecção das User Histories
• Analista de Negócios
• Arquiteto
• Analista de Sistemas
• Desenvolvedores
• Tester
Time
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver
Por
Funcionalidade

Artefatos
Atividades
• FBS: Feature Breakdown Structure
• User Histories (Negócios e Critérios de
Aceitação)
• Definir os responsáveis por cada um dos
modelos, agrupados por Features.
• Construir a Lista de Funcionalidades
• Arquiteto
• Desenvolvedores
• Testes
Time
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver Por
Funcionalidade

Artefatos
Atividades
• FBS: Feature
Breakdown Structure
• User Histories (Negocio)
• Definir Seqüência de Desenvolvimento.
• Atribuir Atividades de Negócio
• Atribuir Classes de Desenvolvimento por
Responsável
• Arquiteto
• Desenvolvedores
• Testes
Time
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver
Por
Funcionalidade

Artefatos
Atividades
• FBS: Feature
Breakdown Structure
• Diagrama de Classes e
Seqüência
• Storyboard
• Definir Seqüência de Desenvolvimento.
• Atribuir Atividades de Negócio
• Atribuir Classes de Desenvolvimento por
Responsável
• Arquiteto
• Desenvolvedores
Time
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver
Por
Funcionalidade

Artefatos
Atividades
• Código
• Diagrama de Seqüência
• Testes Unitários
• Implementar Classes e Métodos.
• Efetuar Revisão do Código
• Gerar Evidências de Testes Unitários
• Desenvolvedores
• Tester
Time
Desenvolver Modelo
Construir Lista
de
Funcionalidades
Planejar Por
Funcionalidade
Detalhar Por
Funcionalidade
Desenvolver
Por
Funcionalidade

Story-Writing Workshops
• São reuniões que incluem desenvolvedores,
usuários, cliente, product owner e qualquer
pessoa que possa contribuir no processo de
descoberta de stories;
• Durante este workshop os participantes
escrevem a quantidade de stories que
conseguirem;
• Prioridades não são associadas;
• Bons workshops combinam os melhores
elementos de brainstorming e prototipação de
desenho;
User Stories - Requisitos
• Quem
• O quê?
• Porque?
O que deve conter nas stories?
Como um <Perfil> eu posso /
devo / consigo <FUNÇÃO>
atender ao <VALOR DE NEGOCIO>
Como CLIENTE consigo
COMPRAR e pagar meu pedido
COM CARTÃO DE CRÉDITO.

Documentação inicial de Análise e Design
Criação de Features
Home-page
Pesquisar
Produtos
Selecionar
produto e por
no carrinho
Pagar pela
compra
Reservar
Produtos
Cadastrar
Clientes
Pagar com
cartão de
crédito
Pagar com
boleto
bancário
Efetuar a organização das user stories em features, facilita a
visualização do que deve ser feito pelo time!

Documentação de Análise e Design
Documentação do Processo
Pesquisar
Produtos
Reservar
Produtos

Documentação testes e qualidade
Testes de Aceitação
• Quem?
• O quê?
• Porque?
• Qual
o critério?
Como CLIENTE cadastrado
no site eu consigo EFETUAR
O PAGAMENTO do meu
pedido COM CARTÃO DE
CRÉDITO.
Aceitar
pagamento com
Visa e Mastercard
Verificar cartões
com prazo
expirado (falhar)
Aceitar
pagamento de
Pessoa Física e
Pessoa Jurídica

• Prevenindo defeitos com vários tipos de teste:
Testes de Histórias
Interesse de Negócio
(Design do Produto)
Testes de
Usabilidade
Testes Exploratórios
Testes de Unidade
Interesse do programador
(Design do Código)
Testes de
Propriedade
Segurança, Carga,
Combinatório
Perspectiva do Negócio
Perspectiva da Tecnologia
SuporteàProgramação
CríticaaoProduto
Qualidade de Testes
Documentação testes e qualidade

Sincronizando FDD ao SCRUM
Semana 1 Semana 2 Semana 3 Semana 4
Funcionalidade 1
Funcionalidade 2
Funcionalidade 3
Como sincronizar desenvolvimento novo à manutenção?
• Rotação de pessoas
• Alocar uma parte do dia para revisão de código
• Triagem agressiva + atendimento imediato a manutenções
urgentes
• Implantação semanal + tratar manutenção como funcionalidades
do release
Adotando Métodos Ágeis em Conjunto

FIM
Dúvidas!

Facilitando a vida...
... e priorização por parte do time
• Os participantes da reunião são:
Product Owner, Scrum Master e
todos os membros do time;
• Certifique-se que o Product
Backlog esteja priorizado;
• Certifique-se que há disponível
um conjunto de cartas para a
prática do Planning Poker;
• Certifique-se que há tempo
disponível – sem interrupções –
para a realização da reunião.
A priorização do Product Backlog
por parte do Product Owner...
• Sessões de Facilitação
• Brainstorm
• Mapas mentais
• Desenvolvimento de modelo visual
abrangente (FDD facilita ter esse tipo
de visão)
•Conhecer user stories profundamente
Apêndice 1

Facilitando a vida...
Daily Meeting
• Os participantes da reunião são:
Scrum Master e todos os membros do
time. Caso necessário, pode ser
solicitada a presença do Product
Owner;
• Certifique-se de que o local e
horário do Daily Meeting esteja claro
para todo o time;
• Certifique- se de que o quadro de
acompanhamento esteja visível no
ambiente físico em que será realizada
e reunião
• O que fiz desde a última reunião?
• O que pretendo fazer até a
próxima reunião?
• Estou tendo algum impedimento?
Se sim, adicione-o ao Impediments
Sprint Planning Meeting
• O Product Owner deve falar ao time
sobre a visão do produto;
• O Product Owner e o time devem
definir a meta da Sprint;
• O time deve realizar a estimativa dos
itens do backlog que não estejam
estimados;
• O Product Owner e o time, em
consenso, escolhem os itens que irão
fazer parte do próximo Sprint, estes
itens selecionados são chamados de
Selected Product Backlog.
Apêndice 2

Métodos Ágeis: FDD Guia

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Destaque

Destaque (19)

Semelhante a Métodos Ágeis: FDD Guia

Semelhante a Métodos Ágeis: FDD Guia (20)

Último

Último (20)

Métodos Ágeis: FDD Guia