Embed Size (px)
DESCRIPTION
É notável que a F.D.D. (Feature Driven-Development) é uma das metodologias ágeis que mais se aproxima do modelo tradicional, pois concentra uma boa parte da sua energia em etapas de planejamento, onde muitas outras não possuem um foco tão explicito. A ideia é mostrar a todos, como esta metodologia proporciona uma adaptação mais suave dos modelos tradicionais aos modelos agilistas.
Citation preview
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 – [email protected] - @javalex
Everton Lentez Email – [email protected]
Guilherme Pinter Email – [email protected]
