FDD para equipes não tão ágeis

Para equipes não tão ágeis

AGENDA

• Introdução• FDD Overview• Estudo de caso• Referências• Contatos

Introdução

Vamos começar....

Sua empresa é assim ?

Cheia de burocracia

A comunicação é ineficiente entre equipes

Mudanças organizacionais são sempre complicadas

Algumas acham que fazer software é como uma linha de montagem

Foco no planejamento antecipado do projeto

Projetos com documentações excessivas

Acabam ficando pesados e custosos para se manter

A qualidade e as boas práticas de desenvolvimento acabam ficando esquecidas.

Aumentando o risco do projeto e o seu insucesso

Você até pensa em mudar, mas acaba esbarrando no modelo de gestão da empresa.

Você até gostaria de fazer diferente

Mas mudanças são sempre complicadas

E acaba se sentindo preso a uma estrutura engessada

Como mudar, qual caminho escolher ?

Feature Driven-Developement (F.D.D)

Combina as melhores práticas do gerenciamento ágil de projetos, mas com nível mínimo de processo definido para modelagem de software.

Lema: Resultados freqüentes, tangíveis e funcionais.

Um pouco da história

• Criada em 1997 num grande projeto em Java para o United Overseas Bank, em Singapura.

• Seus criadores eram Peter Coad e Jeff De Luca.

• Foi publicada em 1999, no livro Java “Modeling in Color with UML”, de Peter Coad, Eric Lefebvre e Jeff De Luca.

• Em 2002, Stephen Palmer e John Mac Felsing publicaram o livro “A Pratical Guide to Feature Driven Development”, com a versão completa, atualizada e comentada da metodologia.

Principais características

Resultados úteis a cada duas semanas ou menos

Desenvolvimento orientado a Features

Blocos bem pequenos de funcionalidades valorizadas pelo cliente, chamados de Features

Planejamento detalhado na etapa inicial e guiado para medição

Jeff De LucaPrincipais características

Principais características

Parking Lot Chart

Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes.

Principais características

Principais características

Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos.

1. D.M.A2. C.L.F.3. P.P.F.

Fases do F.D.D.

4. D.P.F.5. C.P.F.

Desenvolver Modelo Abrangente

Conjunto de técnicas para entendimento do domínio de negócio em questão. Seu resultado é um modelo de objetos de alto nível, que guiará a equipe durante os ciclos de construção.

Modelo de classes

Decomposição funcional do modelo de domínio, em três camadas típicas: áreas de negócio, atividades de negócio e funcionalidades.

Construir Lista de Funcionalidades

Planejar por Feature

Nesta fase realiza-se a estimativa das funcionalidades, assim como suas dependências. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.

Detalhar por Feature

Nesta fase a equipe detalha os requisitos e outros artefatos para codificação de cada funcionalidade, incluindo testes e inspeção de design.O resultado é o modelo de domínio mais detalhado e classes stubs prontas para codificar.

Construir por Feature

Nesta fase cada classe stub (Esqueleto) é preenchida, testada e inspecionada, gerando como resultado um incremento do produto ou uma feature pronta.

Visão geral do ciclo da F.D.D.

Estudo de Caso

Cenário em 2008:• Complexidade alta;• Iniciou o desenvolvimento em 2008;• Levou cerca de 4 meses para ser feita a análise inicial;• Desenvolvimento executado por equipe terceirizada;• Problemas encontrados:

– Nenhuma entrega para o usuário;– Documentação não foi respeitada pelo fornecedor;– Conhecimento com equipe externa (terceirizada);

Estudo de Caso – Projeto X

Estudo de Caso – Projeto X

Cenário em 2009:• Projeto teve seu desenvolvimento

internalizado;• Sem metodologia de desenvolvimento;• Problemas encontrados:– Comunicação ineficiente;– Sem entrega parcial para o usuário;– Conhecimento do negócio com equipe externa

(terceirizada);

Estudo de Caso – Projeto X

Cenário em 2010:• Necessidades de mudanças• Ampliação da equipe de desenvolvimento

interna;• Absorver o conhecimento técnico;• Implementação de grandes features, porém

com entregas freqüentes;• Criar/utilizar uma metodologia adequada a

empresa;

Estudo de Caso – Projeto X

RUP FDD XP

Quero Controle

Equipes grandesRigor Obrigatório

Quero apenas o ProcessoSuficiente.

Escalável para Equipes Médias e Pequenas

Quero Liberdade

Equipes Pequenas

Estudo de Caso – Projeto X

Alguns resultados da FDD na equipe:• Integração da equipe – Formação dos times• Entendimento do projeto – Criação do Modelo

Abrangente• Analise de negócio e requisitos – Adaptação da WBS

para FBS• Mudança da visão tradicional para o ágil dos

envolvidos no projeto.• Entregas freqüentes de features para o cliente.• Entrega da primeira release

Resultados obtidos no projeto:• Maior segurança para empresa, acostumada

com o modelo tradicional;• Documentação necessária feita pela equipe;• Entendimento do negócio por todos os

envolvidos no projeto;• Aceitação da cultura Ágil, dando abertura para

outras metodologias;

Estudo de Caso – Projeto X

+

+=

Referências

Alguns links:• FDD – www.featuredrivendevelopment.com• Heptagon – www.heptagon.com.br• Visão ágil – visaoagil.wordpress.com• GUFDD – http://br.groups.yahoo.com/group/gufdd/• FDD em uma casca de banana -

http://amagno.blogspot.com/2007/04/fdd-em-uma-casca-de-bananas.html

• Blog do Abu – http://blogdoabu.blogspot.com

Contatos

Alexandre Rosa Email – alexrosa@gmail.comTwitter - @javalex

Everton Lentez Email – lentez@gmail.com

Guilherme Pinter Email – guilhermepinter@gmail.com