[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
Engenharia
de Software
Ágil
Versão 4
SCRUM e FDD
Rildo F [email protected]
twitter: @rildosan
blog: http://rildosan.blogspot.com/
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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/
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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 ?
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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...
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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 ?
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
Papéis
Product Owner, responsável por:
- Definir a Visão do Produto
- Elaborar e 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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
A Equipe e Comprometimento:
Product Onwer
EquipeSCRUM Master
ComprometidosEnvolvidos
Stakeholders
(clientes e usuários finais)
10
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
FDD (Feature Driven Development)
13
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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ção de 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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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ênciaInterface com
outros sistemas
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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.
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
Exemplo: UML em cores:
18
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010 20
Juntando o SCRUM e o FDD:
Gerenciamento
de Projeto
Engenharia de
Software
FDDSCRUM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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)
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010 22
Juntando o SCRUM e o FDD:
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
Modelando Funcionalidades com Mind Map:
25
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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:
Formação Engenharia de Software ÁgilAs 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
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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 Experiencehttp://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum
SCRUM Product Owner
http://www.slideshare.net/Ridlo/scrum-product-owner
SCRUM:
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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 [email protected]
que te enviaremos um convite para participar da nossa comunidade
30
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
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 ([email protected])
Imagens:
Google, Flickr e Banco de Imagem.
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010 32
Licença:
[email protected]ão 4 | RFS
Tu
tori
al
Biz
Ag
i, M
od
ela
ge
m d
e P
roc
es
so
s d
e N
eg
óc
ios
co
m B
PM
N
Todos os direitos reservados e protegidos © 2006 e 2010
Engenharia
de Software
Ágil
Versão 4
SCRUM e FDD
Rildo F [email protected]
twitter: @rildosan
blog: http://rildosan.blogspot.com/
Top Related