engenhariadesoftwareagilscrumefddv4-100521231534-phpapp02

Prévia do material em texto

rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Engenharia 
de Software
Ágil
Versão 4
SCRUM e FDD
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
twitter: @rildosan
blog: http://rildosan.blogspot.com/
mailto:rildosan@uol.com.br?subject=Contato
mailto:rildosan@uol.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 2
Sobre o autor: Rildo F. Santos 
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, 
abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação 
(Métodos Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de 
Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia 
de Software pela Universidade Mackenzie. 
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM. 
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), 
RUP/UP - Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. 
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. 
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de 
Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI; 
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais 
frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999; 
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, 
Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, 
Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified 
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; 
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
http://twitter.com/rildosan
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 3
Comentário inicial:
Para desenvolver um software (ou produto), os métodos ágeis são altamente
recomendáveis, contudo, sempre existem muitas dúvidas na adoção dos 
métodos:
- Quais métodos devemos usar ?
- Posso usar mais de um método para desenvolver um software ?
- Quais são as práticas de engenharia de software que devemos utilizar ?
- A metodologia de desenvolvimento existente poderá ser utilizada junto com o 
SCRUM ?
- Poderei elaborar o “Product Backlog” a partir dos Casos de Uso ? 
- Como utilizar SCRUM e FDD juntos ?
Nesta apresentação responderemos algumas questões, mas focaremos na 
questão: Como utilizar SCRUM e FDD juntos ?
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 4
Método Ágil, Respostas: 
- Quais são as práticas de engenharia de software
que devemos utilizar ?
R: você poderá utilizar as práticas de engenharia que já 
são conhecidas da sua equipe ou utilizar as práticas de 
engenharia de software ágeis, tais como: FDD e XP.
- A minha metodologia de desenvolvimento será que
poderei utilizar junto com o SCRUM ?
R: Sim, o SCRUM é um framework para o 
Gerenciamento de Projetos, é possível usar uma 
metodologia de desenvolvimento de software junto com 
SCRUM (principalmente se ela for focada em práticas de 
engenharia de software)
- Poderei elaborar o “Product Backlog” a partir dos Casos 
de Uso ? 
R: Sim, é possível utilizar toda experiência, o 
conhecimento e cultura adquirida com o SCRUM. 
- Posso utilizar SCRUM e FDD juntos ?
R. Sim, vou responder de forma mais detalhada esta 
questão...
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 5
Como utilizar SCRUM e FDD juntos ?
FDDSCRUM
Eles são compatíveis ?
Qual é o papel de cada um no processo de desenvolvimento de software ?
Eles são complementares ?
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 6
O que é SCRUM ?
SCRUM é um processo iterativo e 
incremental para desenvolvimento de 
qualquer produto ou gerenciamento de 
qualquer trabalho...
SRUM é:
Processo empírico de gerenciamento e 
controle.
- Faz a inspeção e adaptação em loops 
de feedback
- Faz entrega de valor ao cliente em até 
30 dias;
- “Escalável” para suportar grandes 
projetos 
- Compatível com CMM3 e ISO9001
- Extremamente simples, mas muito 
resistente...
Valores do Scrum::
- Transparência 
-Integridade: assim que perceber 
algo, faça algo 
- Ser empírico 
- Auto-organização 
- Entrega de valor 
O que é o SCRUM ?
The New, New
Product 
Development
Game TimeBoxes
Iterative,
Incremental
Development
SmallTalk
Engineering Tools
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
O coração do SCRUM
artefatos
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
2-4 Semanas
24 horas
Revisão 
da Sprint
Retrospectiva
da Sprint
Visão
Cerimônias
Burndown
Produto
Backlog
• Product Owner (PO)
• ScrumMaster (SM)
• Equipe Scrum
• Planejamento da Sprint
• Reunião Diária
• Revisão da Sprint
• Retrospectiva da Sprint
• Product Backlog
• Sprint Backlog
• Burndown (gráfico)
Papéis Cerimônias Artefatos
Legenda:
7
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
ROAD MAP do SCRUM
Product 
Backlog
Selected Product
Backlog
Planejamento
da Sprint
Revisão da Sprint
Retrospectiva da Sprint
Produto
Reunião 
diária
SCRUM 
Master
Product
Onwer
Equipe
facilita
facilita
ajuda
facilita
Sprint 
Backlog
Execução da 
Sprint
Tarefas
da Sprint
Visão do 
Produto
8
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Papéis
Product Owner, responsável por:
- Definir a Visão do Produto 
- Elaborare manter o Product 
Backlog 
- Definir a prioridade e ROI;
- Representar o cliente 
- Aceitar ou rejeitar os entregáveis
Equipe SCRUM é responsável por:
- Fazer estimativa;
- Definir as tarefas; 
- Desenvolver o produto;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
Equipe: auto-gerenciável e multifuncional
SCRUM Master é responsável por:
- Ser um líder (servidor);
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (com Product Backlog); 
- Ser o facilitador da equipe;
- Garantir as práticas SCRUM.
O SCRUM tem somente três papéis: Product Onwer (PO), SCRUM Master (SM) 
e a equipe SCRUM.
9
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
A Equipe e Comprometimento:
Product Onwer
Equipe
SCRUM Master
ComprometidosEnvolvidos
Stakeholders
(clientes e usuários finais)
10
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Cerimônias:
Reunião de Planejamento da Sprint (8 horas)
Reunião Diária (15 minutos)
Revisão da Sprint (4 horas*)
Retrospectiva da Sprint (3 horas*)
Participantes: PO, Equipe e SCRUM MASTER
Participantes: Equipe e SCRUM MASTER
Participantes: PO, Equipe e SCRUM MASTER
Participantes: Equipe e SCRUM MASTER
Nesta reunião somente membros da equipe devem participar. A duração dela é de 15 minutos. As pessoas
fazem a reunião de pé. O objetivo desta reunião é fazer que as pessoas respondam 3 questões:
- O que eu fiz ontem ?
- O que vou fazer hoje ?
- Encontrei algum impedimento ?
Esta reunião acontece no final da Sprint, opcionalmente outras pessoas podem ser convidadas (se necessário).
O objetivo da reunião é apresentar o que a equipe fez durante a Sprint e fazer a entrega do produto (software 
funcionando) para o PO. (Normalmente é apresentado uma demo do software). 
Geralmente ela é feita em um auditório ou em uma sala de reunião
Esta reunião acontece logo após a Revisão da Sprint.
O objetivo dela é avaliar o que deu certo e que deu errado durante a Sprint, e fazer os ajustes possíveis para 
a próxima Sprint, ou seja, o ciclo de melhoria contínua.
Esta reunião é primeira reunião, seu objetivo é fazer
o planejamento da Sprint. Ela é dividida em duas partes.Na primeira parte o PO definirá prioridade, seleção dos 
itens do backlog e meta da Sprint. 
Na segunda parte a equipe definirá a Sprint Backlog (que são as tarefas necessárias para cumprir a meta).
11
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
O que é o FDD (Feature Driven Development) ?
Feature Driven Development (Desenvolvimento 
Guiado por Funcionalidades) é uma metodologia ágil 
para gerenciamento e desenvolvimento de software. 
Ela combina as melhores práticas do gerenciamento 
ágil de projetos com uma abordagem completa para 
Engenharia de Software orientada por objetos, 
conquistando os três principais públicos de um 
projeto de software: 
- Clientes, 
- Gerentes, 
-Desenvolvedores.
-
Seus princípios e práticas proporcionam um 
equilíbrio entre as filosofias tradicionais e as mais 
extremas, proporcionando uma transição mais suave 
para organizações mais conservadoras, e a 
retomada da responsabilidade para as organizações 
que se desiludiram com as propostas mais radicais.
O lema da FDD é: "Resultados freqüentes, 
tangíveis e funcionais."
O FDD foi criada em 1997 num grande 
projeto em Java para o United Overseas 
Bank, em Singapura.
Nasceu a partir da experiência de análise 
e modelagem orientadas por objetos de 
Peter Coad, e de gerenciamento de 
projetos de Jeff De Luca.
Foi inicialmente publicada em 1999, no 
capítulo 6 do livro "Java Modeling in 
Color with UML", de Peter Coad, Eric 
Lefebvre e Jeff De Luca.
Em 2002, Stephen Palmer (gerente de 
desenvolvimento do projeto em 
Singapura) e John Mac Felsing 
(arquiteto senior na TogetherSoft) 
publicaram o livro "A Practical Guide to 
Feature Driven Development", com a 
versão completa, atualizada e comentada 
da metodologia.
Em 2003, David Anderson, que foi o 
especialista em interface com o usuário, 
no projeto de Cingapura, publicou um 
marco na literatura Ágil, "Agile 
Management for Software Engineering: 
Using the Theory of Constraints for 
Business Results", onde oferece uma 
análise profunda sobre a FDD (entre 
outras metodologias), além de material 
inédito sobre a FDD.
12
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
FDD (Feature Driven Development)
13
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
A FDD chama a atenção por algumas características peculiares:
- Resultados úteis a cada duas semanas ou menos
- Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features"
- Planejamento detalhado e guia para medição
- Rastreabilidade e relatórios 
- Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e 
gerentes, tudo em termos de negócio
- Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a 
estimativa são sólidos
O que é o FDD (Feature Driven Development) ?
A FDD é uma metodologia muito objetiva. Possui apenas duas fases:
- Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 
semanas)
- Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas)
Os cinco processos são bem definidos e integrados:
DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
PPF (Planejar por Funcionalidade): Planejamento Incremental
DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos
14
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 15
A FDD é, classicamente, descrita por cinco processos:
DMA - Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, 
análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do 
domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, 
que guiará a equipe durante os ciclos de construção.
CLF - Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, 
em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da 
atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o 
produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
PPF - Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das 
funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O 
resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada 
para a construção.
DPF - Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os 
requisitos e outros artefatos para a codificaçãode cada funcionalidade, incluindo os testes. O 
projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais 
detalhado e os esqueletos de código prontos para serem preenchidos.
CPF - Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e 
inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, 
com qualidade e potencial para ser usado pelo cliente/usuário.
Os Processos
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 16
Visão da Arquitetura:
Apresentação
(Visões e Controladores de Interface)
Negócio
(Domínio do Problema)
Persistência
Interface com
outros sistemas
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 17
Sobre UML Color
UML Color é um conjunto de quatro cores associadas a UML (Unified Modeling Language). O sistema de 
coloração indica quais vários arquétipos se aplicam ao objeto UML. UML tipicamente identifica um estereótipo 
com um comentário entre parênteses, para cada objeto que identifica se é uma classe, interface, etc.
Estas cores foram pela primeira vez sugerida por Peter Coad , Eric Lefebvre e Jeff De Luca em 
uma série de artigos no The Letter Coad e posteriormente publicado em seu livro Java 
Modeling em cores com UML.
Ao longo de centenas de modelos de domínio, ficou claro que quatro grandes "tipos" de classes apareceu de 
novo e de novo - apenas um nome diferente para se adequar ao domínio. Estes eram chamados de arquétipos 
(depois de muita discussão), que serve para transmitir que as classes de um arquétipo dado seguem mais ou 
menos da mesma forma. 
Isto é, atributos , métodos , associações e interfaces são bastante semelhantes entre as classes de um 
determinado arquétipo. 
Ao tentar classificar um determinado domínio de classe, tipicamente uma pergunta sobre os padrões de cor, 
nesta ordem: 
Rosa: momento, intervalo - Será que representam um momento ou intervalo de tempo? Um exemplo
seria um objeto que armazena temporariamente as informações de login durante o processo de
Autenticação.
Azul - Descrição - É simplesmente uma descrição do catálogo-como a que classifica ou objeto 'rótulos„ Um ? 
Se os usuários do sistema são rotulados com base no departamento de uma empresa em que trabalham 
dentro e isso não muda a forma como o sistema se comporta, isso seria uma
descrição.
Amarelo - papéis - É uma maneira de participar de uma atividade (por qualquer pessoa, lugar ou coisa) ? 
Assinatura em um sistema como um administrador, que muda o comportamento do programa,
exigindo uma senha que contas de convidado não, é um exemplo.
Verde - parte, lugar ou coisa - algo tangível, unicamente identificável. Normalmente, se você passar a
três perguntas acima e acabam por aqui, sua classe é um verde ". O usuário do sistema e as
sub-seções do sistema são todos os que visitam PPTs.
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Exemplo: UML em cores:
18
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 19
As disciplinas envolvidas:
Fonte: Adail Muniz Retamal - www.heptagon.com
Gestão Ágil de Projetos
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 20
Juntando o SCRUM e o FDD:
Gerenciamento
de Projeto
Engenharia de 
Software
FDD
SCRUM
O SCRUM e o FDD são complementares em muitos aspectos:
-Podemos utilizar o SCRUM para o Gerenciamento 
- E o FDD para as práticas de Engenharia de Software
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 21
SCRUM FDD
Gestão de Projeto Engenharia de software
Gerenciamento (SCRUM) e Engenharia de Software (FDD, XP)
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 22
Juntando o SCRUM e o FDD:
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
FBS: Feature Breakdown Structure(FDD)
FBS (Feature BreakDown Structure) é uma prática para engenharia de requisito
FBS cria uma “estrutura analista de funcionalidades”, como estamos trabalhando com FDD, cada feature
deve representar um item do Product Backlog
23
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
O Que é Feature ? (Pela visão da FDD)
Fonte: Adail Muniz Retamal - www.heptagon.com
Funcionalidade (ou característica)
Pequena o suficiente para ser implementada no máximo em 01 iteração
Oferece valor para o cliente
Mapeia passos em uma atividade de negócio:
– Pode ser um passo de um Caso de Uso (ou user stories)
– Às vezes pode ser o próprio Caso de Uso (ou user stories)
Conceito muito próximo ao de um requisito funcional
Modelo: < ação> <resultado> <objeto >
- Liberar apartamento para locação
- Calcular o total de uma nota fiscal
- Autorizar uma transação com cartão
- Emitir uma nota fiscal 
- Calcular total da conta do cliente
- Imprimir o relatório para conferência
24
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Modelando Funcionalidades com Mind Map:
25
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Gerenciado ROI com Business Value
Business Value será uma moeda de troca durante o projeto e o cliente empresta 
um determinado valor dessa moeda para a equipe e esta por sua vez, terá que devolver 
o valor correspondente em forma de software, ou seja, é uma dívida que a equipe 
assume com o cliente e que deverá ser amortizada a cada ciclo(Sprint), até que a 
mesma seja totalmente liquidada (zerada).
Business 
Value 
Área de 
Negócio
Item
100 Reserva Os clientes poderão fazer reserva de apartamento
50 Reserva Os clientes poderão cancelar a reserva
50 Reserva Os clientes poderão fazer alterações de data da reserva
40 Reserva Os cliente poderão fazer consulta de reservas
100 Reserva Criação de o Book de Reserva
80 Pagamento O meio de pagamento da reserva serão por cartão de 
crédito
60 Apartamento Os apartamentos deverão ser cadastros
40 Apartamento Os apartamentos são classificados por categoria
60 Cliente Precisamos registrar os dados dos clientes
Exemplo de Product BackLog baseado no FDD:
26
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
eP
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
OK ?
Você já percebeu que utilizar o SCRUM e FDD juntos pode facilitar e potencializar o 
entendimento dos requisitos de software.
O SCRUM é excelente para o Gerenciamento de Projetos, contudo existe uma lacuna 
entre a Gestão de Projetos baseada em SCRUM e as práticas de engenharia de software.
Ao utilizarmos o FDD conseguimos reduzir esta lacuna e se aproximar da Engenharia de 
Software Ágil.
Devemos combinar, juntar as melhores práticas de cada método para termos um processo 
completo de Gestão de Projetos e de Engenharia de software Ágil
27
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Local: São Paulo
Gostou ?
28
Gostou...Que saber mais, conhecer mais os métodos ágeis, como SCRUM FDD e XP:
Participe do nosso treinamento: 
Formação de Engenharia de Software Ágil 
Entre em contato: 
- eventos@companyweb.com.br 
- rildo.santos@companyweb.com.br 
- rildo.santos@etecnologia.com.br 
Formação Engenharia de Software Ágil
As melhores práticas para o desenvolvimento de software ágil
Conteúdo Programático
Gestão de Projeto de desenvolvimento de 
Software com SCRUM (16 horas)
- Ciclo de Produto (8 horas) :
•Papel do Product Onwer 
•Visão do Produto 
•Roadmap do Produto 
•Plano de Release do Produto 
•Product Backlog 
•*Workshop do Produto e Requisitos
- Ciclo do Processo (8 horas)
Papel do SCRUM Master
Papel da Equipe SCRUM
Reunião de Planejamento: 
•Estimativa 
•Definição DoD 
•Sprint Backlog 
•Reuniões Diárias 
•Impedimentos 
- Engenharia de Software com as práticas 
FDD+BDD e XP (8 horas)
Ciclo do desenvolvimento da Sprint com 
práticas FDD, XP e BDD
Revisão da Sprint (Revisão do produto da 
Sprint) 
Retrospectiva (Revisão do processo - Lições 
aprendidas)
Implementação da Fábrica Ágil (8 horas)
Planejamento da implementação da Fábrica 
Ágil 
Fatores críticos de sucesso 
Ferramentas, pessoas e processos 
Capacitação da equipe 
Carga horária: 32 horas
http://www.companyweb.com.br/treinamento/programa_curso.cfm?id_categoria=1&id_subcategoria=16&id_curso=212&id_detalhe=1
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 29
Referências e Créditos:
FDD, Créditos:
Adail Muniz Retamal - www.heptagon.com
Manoel Pimentel Medeiros (Visão Ágil - http://www.visaoagil.com)
SCRUM Experience
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
SCRUM Product Owner
http://www.slideshare.net/Ridlo/scrum-product-owner
SCRUM:
http://www.heptagon.com/
http://www.visaoagil.com/
http://www.visaoagil.com/
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
http://www.slideshare.net/Ridlo/scrum-product-owner
http://www.slideshare.net/Ridlo/scrum-product-owner
http://www.slideshare.net/Ridlo/scrum-product-owner
http://www.slideshare.net/Ridlo/scrum-product-owner
http://www.slideshare.net/Ridlo/scrum-product-owner
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Quer Mais ?
http://etecnologia.ning.com/
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste 
material...
Envie um e-mail para com subject: “Quero entrar na comunidade” para rildo.santos@etecnologia.com.br 
que te enviaremos um convite para participar da nossa comunidade
30
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 31
Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de 
responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou 
fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes 
podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não 
visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema 
ou erro envie um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor 
envie um e-mail para nós. 
Rildo F dos Santos (rildo.santos@etecnologia.com.br)
Imagens:
Google, Flickr e Banco de Imagem.
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010 32
Licença:
rildo.santos@etecnologia.com.brVersão 4 | RFS
T
u
to
ri
a
l 
B
iz
A
g
i,
 M
o
d
e
la
g
e
m
 d
e
 P
ro
c
e
s
s
o
s
 d
e
 N
e
g
ó
c
io
s
 c
o
m
 B
P
M
N
Todos os direitos reservados e protegidos © 2006 e 2010
Engenharia 
de Software
Ágil
Versão 4
SCRUM e FDD
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
twitter: @rildosan
blog: http://rildosan.blogspot.com/
mailto:rildosan@uol.com.br?subject=Contato
mailto:rildosan@uol.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato
mailto:rildo.santos@companyweb.com.br?subject=Contato