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]
Recommended
