engenharia de software Ágil (scrum e fdd)

33
[email protected] Versão 4 | RFS Tutorial BizAgi, Modelagem de Processos de Negócios com BPMN Todos os direitos reservados e protegidos © 2006 e 2010 Engenharia de Software Ágil Versão 4 SCRUM e FDD Rildo F Santos r[email protected] [email protected]r twitter: @rildosan blog: http://rildosan.blogspot.com/

Upload: rildo-rildosan-santos

Post on 05-Dec-2014

15.589 views

Category:

Technology


9 download

DESCRIPTION

SCRUM e o FDD são Métodos Ágeis que são utilizados para desenvolvimento de software Fizemos uma pequena demonstração de como utilizar o SCRUM e FDD (Featured Driven Development – Desenvolvimento Guiada por Funcionalidade) juntos. O SCRUM é utilizado para o Gerenciamento e o FDD como parte das práticas de Engenharia de Software. Ambos se complementam.

TRANSCRIPT

Page 1: Engenharia de Software Ágil (Scrum e 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

Engenharia

de Software

Ágil

Versão 4

SCRUM e FDD

Rildo F [email protected]

[email protected]

twitter: @rildosan

blog: http://rildosan.blogspot.com/

Page 2: Engenharia de Software Ágil (Scrum e 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 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/

Page 3: Engenharia de Software Ágil (Scrum e 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 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 ?

Page 4: Engenharia de Software Ágil (Scrum e 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 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...

Page 5: Engenharia de Software Ágil (Scrum e 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 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 ?

Page 6: Engenharia de Software Ágil (Scrum e 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 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

Page 7: Engenharia de Software Ágil (Scrum e 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

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

Page 8: Engenharia de Software Ágil (Scrum e 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

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

Page 9: Engenharia de Software Ágil (Scrum e 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

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

Page 10: Engenharia de Software Ágil (Scrum e 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

A Equipe e Comprometimento:

Product Onwer

EquipeSCRUM Master

ComprometidosEnvolvidos

Stakeholders

(clientes e usuários finais)

10

Page 11: Engenharia de Software Ágil (Scrum e 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

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

Page 12: Engenharia de Software Ágil (Scrum e 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

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

Page 13: Engenharia de Software Ágil (Scrum e 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

FDD (Feature Driven Development)

13

Page 14: Engenharia de Software Ágil (Scrum e 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

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

Page 15: Engenharia de Software Ágil (Scrum e 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 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

Page 16: Engenharia de Software Ágil (Scrum e 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 16

Visão da Arquitetura:

Apresentação

(Visões e Controladores de Interface)

Negócio

(Domínio do Problema)

PersistênciaInterface com

outros sistemas

Page 17: Engenharia de Software Ágil (Scrum e 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 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.

Page 18: Engenharia de Software Ágil (Scrum e 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

Exemplo: UML em cores:

18

Page 19: Engenharia de Software Ágil (Scrum e 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 19

As disciplinas envolvidas:

Fonte: Adail Muniz Retamal - www.heptagon.com

Gestão Ágil de Projetos

Page 20: Engenharia de Software Ágil (Scrum e 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 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

Page 21: Engenharia de Software Ágil (Scrum e 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 21

SCRUM FDD

Gestão de Projeto Engenharia de software

Gerenciamento (SCRUM) e Engenharia de Software (FDD, XP)

Page 22: Engenharia de Software Ágil (Scrum e 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 22

Juntando o SCRUM e o FDD:

Page 23: Engenharia de Software Ágil (Scrum e 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

Page 24: Engenharia de Software Ágil (Scrum e 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

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

Page 25: Engenharia de Software Ágil (Scrum e 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

Modelando Funcionalidades com Mind Map:

25

Page 26: Engenharia de Software Ágil (Scrum e 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

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

Page 27: Engenharia de Software Ágil (Scrum e 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

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

Page 28: Engenharia de Software Ágil (Scrum e 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

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:

- [email protected]

- [email protected]

- [email protected]

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

Page 30: Engenharia de Software Ágil (Scrum e 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

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

Page 31: Engenharia de Software Ágil (Scrum e 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 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.

Page 32: Engenharia de Software Ágil (Scrum e 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 32

Licença:

Page 33: Engenharia de Software Ágil (Scrum e 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

Engenharia

de Software

Ágil

Versão 4

SCRUM e FDD

Rildo F [email protected]

[email protected]

twitter: @rildosan

blog: http://rildosan.blogspot.com/