Your SlideShare is downloading. ×
Feature driven development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Feature driven development

513
views

Published on

Artigo produzido no curso de pós-graduação em Engenharia de Software Centrada em Métodos Ágeis da UNA - BH

Artigo produzido no curso de pós-graduação em Engenharia de Software Centrada em Métodos Ágeis da UNA - BH


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
513
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Feature Driven Development Davi Busanello, Izabel Rodrigues, Kleber Sales, Mateus Alves, Priscilla Aguiar Centro Universitário UNA Caixa Postal 30140-071 – Belo Horizonte – MG – Brasil Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis davibusanello@gmail.com, izabel.castro.rodrigues@gmail.com, kleberhermsdorff@gmail.com, snap.mateus@gmail.com, pricaguiar@gmail.com Abstract The goal of this article is introduce the FDD, an agile methodology for managing software development. It`ll be described in this article topics like the history of FDD, its principles, values, practices and processes. This is an article presented at Agile Software Engineering discipline. Resumo O objetivo deste artigo é apresentar a FDD, uma metodologia ágil para gerenciamento de desenvolvimento de software. Será descrito neste artigo tópicos como a história do FDD, seus princípios, valores, práticas e processos. Este é um artigo apresentado na disciplina Engenharia de Software Ágil.
  • 2. 1. Introdução Softwares estão presentes em vários setores. Não é incomum ouvir-se falar que projetos de software fracassam por não resolverem os problemas pelos quais eles foram motivados. Muitos deles estouram orçamento, planejamento e em alguns outros cenários, são entregues com muito menos funcionalidades do que inicialmente foram planejados. Isso quando não são interrompidos sem entregar nenhum valor ao cliente. No processo de desenvolvimento, temos dois modelos o iterativo e o em cascata. O modelo em cascata tem como essência dividir o projeto com base nas atividades necessárias para se concluir o projeto. Já no modelo iterativo, o projeto é divido em um conjunto de funcionalidades e dentro de intervalos de tempo executamos todas as atividades necessárias para desenvolver determinada funcionalidade. [FOWLER 2005] Os projetos que mais fracassam utilizam o modelo de desenvolvimento em cascata, onde passam se intervalos de tempo muito grandes (meses, anos) no entendimento do sistema e quando de fato começam a ser construídos já perderam seu valor, pois deixam de entregar aquilo que era importante, tinham valor. Essa situação cria abertura para o negócio mudar e/ou as tecnologias ficarem obsoletas tornando assim um risco para o projeto com tempos muito extensos. [COAD 1999] Desenvolver produtos de software de forma a agregar valor cada vez mais eficaz a quem os solicita, requer o uso de metodologias que têm como base os quatro fundamentos de valorização: “Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano.” [Agile Manifesto 2001] Todas as metodologias tais como XP (Extreme Programming), Scrum, FDD (Feature Driven Development), Crystal Clear, DSDM (Dynamic Systems Development Method), AMDD (Agile Model Driven Development), Lean Software Development, entre outros tem em sua essência os fundamentos acima. Nesse artigo iremos falar sobre a FDD, que se constitui de uma metodologia de desenvolvimento de software guiada por funcionalidades e que valoriza a parte de modelagem como ponto essencial para se ter sucesso. O ponto aqui é realizar muito desenho para que o problema seja entendido de forma bastante eficaz e mais condizente com a realidade. Na FDD as funcionalidades são denominadas Features que é uma funcionalidade que agrega valor ao cliente e que pode ser implementada em duas semanas ou menos [COAD 1999]. Nesse artigo iremos apresentar sua história, as principais práticas, princípios, valores, papéis e processos que a caracterizam. 2. História e Evolução A FDD surgiu entre 1997 e 1999 a partir da experiência de análise e modelagem orientada por objetos de Peter Coad e das técnicas de gerenciamento de projetos de Jeff de Luca durante o desenvolvimento de software em um projeto Java para o United Overseas Bank em Singapura. 1
  • 3. Em 1999, a primeira versão oficial dos processos foi divulgada no capítulo 6 do livro “Java Modeling in Color with UML” de Peter Coad, Eric Lefebvre e Jeff De Luca. No ano de 2002, Stephen Palmer e John Mac Felsing, publicaram “A Pratical Guide to Feature Driven Development.” Esse livro trouxe uma abordagem completa e atualizada da metodologia tornando-se a literatura de referência. Em 2003, a metodologia foi analisada por David Anderson em sua obra “Agile Management for Software Engineering: Using the Theory of Constraints for Business Results”. 3. Princípios e Valores Apesar de a FDD ter surgido antes mesmo do manifesto ágil ser escrito, a mesma pode ser considerada uma metodologia ágil por seus princípios. A metodologia tem em sua essência resultados frequentes, tangíveis e funcionais [COAD 1999]. Abaixo a fala de Peter Coad em sua obra: “Feature-driven development is a process for helping teams produce frequent, tangible working results.” [COAD 1999] 3.1 Prioriza o cliente Dentro de um pequeno intervalo de tempo, duas semanas em geral, um conjunto de características que possuem valor para o cliente é estudado e desenvolvido sendo entregue funcionando ao cliente. Isso garante estabilidade e entrega contínua de novas funcionalidades. [BARKER 2003] “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” [Agile Manifesto 2001] 3.2 Adaptável a mudanças A FDD possui natureza iterativa. Se na fase de modelagem uma área de risco é identificada, onde os requisitos ainda não estão bem fundamentados ou até mesmo que estejam previstos para mudar, a FDD permite que o isolamento dessa área seja feito para garantir que o menor impacto ocorra quando a mudança acontecer. [BARKER 2003] “Mudanças nos requisitos são bem-vindas, mesmo que tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.” [Agile Manifesto 2001] 3.3 Priorizar a menor escala de tempo A FDD utiliza um prazo de duas semanas. Em geral, a cada uma semana uma release é entregue para a realização dos testes de sistema. [BARKER 2003] “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.” [Agile Manifesto 2001] 3.4 Pessoas do Negócio e Desenvolvedores trabalham juntas A FDD não obriga a presença diária do cliente. No entanto, prevê como obrigatória a presença dos especialistas de domínio do cliente no processo de desenvolvimento do modelo abrangente e da lista de features. Durante o processo de detalhamento e 2
  • 4. construção, a presença do cliente se dá através de testes de sistema, feedback de usabilidade, testes de performance, relatório de erros, etc. [BARKER 2003] “Pessoas do negócio e desenvolvedores devem trabalhar diariamente juntos durante todo o projeto.” [Agile Manifesto 2001] 3.5 Indivíduos Motivados A FDD enfatiza a necessidade de utilização de ferramentas de suporte para garantir que o ambiente de trabalho e a infraestrutura tenha todas as condições para se obter o sucesso.O mecanismo da FDD proporciona desenvolvedores motivados pois, a cada duas semanas eles tem coisas novas para se fazer. Pessoas de gestão sempre tem a possibilidade de planejar faturamento do que foi feito. Clientes tem uma melhor visibilidade do que está sendo realizado, onde o projeto está e de uma maneira que eles entendem. “Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho” [Agile Manifesto 2001] 3.6 Comunicação Face a Face Conforme já dito anteriormente a FDD proporciona momentos que enfatizam a comunicação aberta. “O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face” [Agile Manifesto 2001] 3.7 Medida do progresso O fluxo de trabalhos dos times garante entrega ideal de funcionalidades. A FDD possui ferramentas embutidas para permitir monitoração, medição eficaz e geração de relatórios para acompanhamento do progresso pela gestão. “Software funcionando é a medida primária do progresso” [Agile Manifesto 2001] 3.8 Desenvolvimento Sustentável Os aspectos de ritmo de trabalho, contato com o cliente, entrega ideal continuamente já citados garantem um desenvolvimento sustentável. “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.” [Agile Manifesto 2001] 3.9 Excelência Técnica A FDD oferece grande ênfase à modelagem e ao desenho até uma qualidade essencial. A excelência técnica é incentivada em todos os níveis. “Contínua atenção a excelência técnica e bom design aumenta a agilidade.” [Agile Manifesto 2001] 3.10 Simplicidade Ao invés de incentivar um ciclo constante de refatoração, a FDD apóia a ideia de se fazer bastante desenho de modo que a construção seja otimizada quando for iniciada. “Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.” [Agile Manifesto 2001] 3
  • 5. 3.11 Equipes Auto-Organizáveis As equipes de features tem provado ser altamente eficazes de várias maneiras. Elas mantêm canais de comunicação a um nível mínimo, diminuindo elevados custos. É centrada em uma pequena equipe ágil centrada em um conjunto de funcionalidades relacionadas. Promove orientação para acelerar o aprendizado e otimiza seu fluxo de trabalho. Está concentrada em oferecer qualidade através da requisição de inspeção de desenho e de código. “As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis” [Agile Manifesto 2001] 3.12 Melhoria Contínua Os checkpoints regulares garantem que o progresso e o desempenho são revisados. Monitoração embutida identifica áreas de risco rapidamente e permitem que os mesmos sejam mitigados de uma melhor maneira. “Em intervalos regulares, o time reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento em conseqüência disso.” [Agile Manifesto 2001] 4. Práticas 4.1 Modelagem de Objetos de Domínio com cores Essa prática fundamenta-se no desenho de diagrama de classes representando os objetos significativos para o problema do domínio e suas relações [Palmer, Felsing 2002]. A FDD utiliza a técnica de modelar usando as cores amarelo, rosa, azul e verde descrita em Java modeling in Color with UML. [COAD 1999] A modelagem de domínio permite que os membros da equipe compartilhem uma visão comum sobre o sistema. [PALMER 2002] O modelo deve ser baseado na visão de especialistas de domínio de forma que o conhecimento necessário seja documentado e disseminado na equipe e sirva de base para que novas funcionalidades possam ser acrescentadas a ele. [PALMER 2002] 4.2 Desenvolvimento por Features Nessa prática temos a ação de dividir funcionalidades do sistema em pequenas partes que podem ser implementadas em até duas semanas. Essas são escritas no seguinte formato: <ação><resultado><objeto>. [PALMER 2002] 4.3 Propriedade de Código A FDD utiliza propriedade única de código. A propriedade única garante a integridade conceitual do modelo, velocidade na implementação de novas funcionalidades (o desenvolvedor autor do código está mais familiarizado com aquele pedaço de código) [PALMER 2002]. 4.5 Times organizados por Features Embora as classes não tenham propriedade coletiva, para desenvolver uma funcionalidade normalmente existirá mais de uma classe envolvida e possivelmente mais de um desenvolvedor. Em virtude disso, os times são formados conforme a 4
  • 6. atribuição de propriedade das classes envolvidas na sua implementação [PALMER 2002]. 4.5 Inspeções A inspeção é feita visando eliminar erros e pode ser feita baseada em métricas de código. Essa prática traz benefício uma vez que o desenvolvedor se sente motivado a adotar boas práticas e padrões de codificação determinados pela empresa. [PALMER 2002]. 4.6 Agendamento de Builds Regulares Em intervalos regulares de tempo, o código das funcionalidades concluídas deve ser integrado e realizado o build. 4.7 Relatar Progresso A FDD possui mecanismos de gerar relatórios para reportar progresso à gestão e ao cliente. 4.7 Gerenciamento de Configuração O gerenciamento de configuração serve para controlar as versões e rastrear artefatos [GOYAL 2008]. 5. Papéis A FDD possui seis papéis principais envolvidos no processo. São eles: Gerente de Projetos, Arquiteto Chefe, Gerente de Desenvolvimento, Programador Chefe, Dono de Classe e Especialistas de domínio. [GOYAL 2008] O Gerente de projetos tem como atribuições relatar progresso, gerenciar recursos, orçamento, etc. É um papel de caráter administrativo. O Arquiteto chefe é responsável por desenhar um modelo geral do problema de domínio e conduzir sessões de modelagem. O Gerente de Desenvolvimento possui a tarefa de liderar de forma geral as atividades de desenvolvimento e resolver conflitos entre programadores chefes. Esse papel requer que a pessoa que o desempenhe tenha boas habilidades técnicas. O Programador Chefe é um programador mais experiente que participa de atividades relacionadas à modelagem e desenvolvimento da solução. Em geral lidera outros programadores. Dono de Classe: São membros do time de desenvolvimento que atuam sob a liderança de programadores chefe que tem por funções modelar, codificar, testar e documentar as funcionalidades para o novo sistema de software. Especialistas de domínio: São usuários chaves, analistas de negócios, patrocinadores ou profissionais com mais de uma função das já citadas. Profissionais que ocupam esse papel são a principal fonte de conhecimento na qual os desenvolvedores recorrem para melhor entendimento do problema a fim de realizar a entrega correta do sistema solicitado. Esses são profundos conhecedores do negocio e são indispensáveis para o sucesso do projeto. [GOYAL 2008] 5
  • 7. Além dos papéis principais [GOYAL 2008] cita que durante a adoção da FDD podemos nos deparar com outros sete papéis. Language Guru que se caracteriza por ser especialista em uma linguagem ou tecnologia e estará mais evidente nos projetos onde essa tecnologia ou linguagem for utilizada pela primeira vez. Build Engineer é responsável por rodar, configurar e dar manutenção no processo de build. Toolsmith: responsável por criar pequenas ferramentas de desenvolvimento para as equipes de testes e conversão de dados. System Administrator: Responsável por configurar, gerenciar, solucionar problemas de todos os servidores e estações de trabalho específicas da equipe do projeto. 6. Processos Segundo a descrição oficial [COAD 1999], podemos utilizar o seguinte template para escrever uma Feature: <ação> o <resultado> <de|para|por> um|a <objeto>. Exemplo: Calcular o total de uma venda. A FDD possui cinco processos que fazem parte de duas fases. A figura 1 ilustra esse cenário.[Nebulon 2012] Figura 1. Processos FDD Para um melhor entendimento dos processos [Nebulon 2012], organizamos as tarefas correspondentes aos processos nas tabelas 1, 2, 3, 4 e 5. Tabela 1. Tarefas do Processo 1 - Desenvolver um Modelo Abrangente Tarefa Formar a equipe modelagem de Conduzir um passo a passo do domínio Estudar documentos Detalhamento Forma - se a equipe por especialistas de domínio e alguns desenvolvedores Um especialista de domínio realiza uma explicação, visão geral do que será modelado Estudo opcional de documentos de requisitos funcionais que 6 Responsável Gerente de Projetos Tipo Obrigatório Gerente de Projetos Obrigatório Equipe de Modelagem Opcional
  • 8. Desenvolver modelos em pequenos grupos Desenvolver um modelo do time Refinar o modelo geral de objetos Escrever modelo anotações no podem estar no formato de casos de uso, modelo de dados, guias de usuário, quaisquer outros documentos que estejam disponíveis e que auxiliem no entendimento do problema São formados grupos de até 3 componentes que geraram modelos. Fica a cargo do Arquiteto chefe propor ou não um modelo base e modelos alternativos Da etapa anterior surge um modelo do time As iterações das tarefas anteriores geram modelos para atualizar o modelo geral Anotações para referências futuras são realizadas Equipe de Modelagem em pequenos grupos Obrigatório Equipe de Modelagem Obrigatório Arquiteto Chefe e Equipe de Modelagem Obrigatório Arquiteto Chefe e Programador Chefe Obrigatório Tabela 2. Tarefas do Processo 2 - Construir a Lista de Features Tarefa Formar a equipe da Lista de Features Construir a lista de Features Detalhamento Os principais programadores do processo 1 compõe a equipe da Lista de Features. A lista é construída extraindo as funcionalidades encontradas no processo anterior e colocadas no formato. <ação><resultado><objeto> Responsável Gerente de Projetos e Gerente de Desenvolvimento Equipe da lista de Features Tipo Obrigatório Obrigatório Tabela 3. Tarefas do Processo 3 - Planejar por Feature Tarefa Formar a equipe de planejamento Determinar a sequencia de desenvolvimento Atribuir um conjunto de Features a programadores chefes Atribuir classes desenvolvedores Detalhamento Gerente de desenvolvimentos + principais programadores Levando – se em conta dependência, risco e complexidade a ordem de execução é determinada. Analisando dependência de classes, complexidade, sequencia a lista é atribuída aos programadores chefes. Tipo Obrigatório Equipe de Planejamento Obrigatório Equipe de Planejamento Obrigatório Equipe de Planejamento a Responsável Gerente de Projetos Obrigatório Tabela 4. Tarefas do Processo 4 - Detalhar por Feature Tarefa Formar a equipe de Feature Conduzir um estudo sobre o domínio de negocio Detalhamento O Programador chefe identifica as classes envolvidas em sua lista e seus respectivos programadores responsáveis e forma sua equipe O especialista de domínio conduz um estudo sobre o que vai ser implementado 7 Responsável Programador Chefe Tipo Obrigatório Especialista de Domínio Opcional
  • 9. Estudar documentos de referência Refinar o modelo de objetos Escrever classes e métodos iniciais Fazer o projeto de inspeção A equipe estuda a documentação de apoio O programador chefe refina o modelo para adicionar classes, métodos, atributos e cria diagramas que são submetidos ao controle de versão. Usando o modelo refinado da etapa anterior, o desenvolvedor grava suas classes, métodos, atributos iniciais e o programador chefe gera a documentação da API e submete a publicação na intranet do projeto. É realizada a inspeção e as alterações são submetidas a um controle de mudanças. Equipe de Feature Opcional Programador Chefe Obrigatório Equipe de Feature Obrigatório Equipe de Feature Obrigatório Tabela 5. Tarefas do Processo 5 - Construir por Feature Tarefa Implementar classes métodos e Conduzir uma inspeção de código Fazer Testes Unitários Promover versão para build Detalhamento O desenvolvedor implementa o que é necessário para sua feature. Realiza-se uma nova inspeção. Responsável Equipe de Feature Tipo Obrigatório Equipe de Feature Obrigatório O dono da classe realiza testes unitários. Depois de inspecionado e testado o código é promovido para o build. Equipe de Feature Obrigatório Equipe de Feature e Programador Chefe Obrigatório 7. Conclusão Após a análise e levantamento dos principais pontos da metodologia Feature Driven Development, pode-se dizer que a mesma é aplicável para projetos de pequeno, médio e grande porte. Demonstra ser uma solução viável para aquelas organizações que não dispõe de facilidade de se manter o cliente sempre por perto como requer, por exemplo, o XP. A FDD parece amenizar ou resolver impasses entre desenvolvedores e gerentes e também entre cliente e equipe contratada para desenvolvimento de algum produto. A natureza iterativa, com momentos que incentivam a transparência e a comunicação levam a um melhor relacionamento entre os envolvidos em todo o processo. Pode-se dizer que parece ser bastante razoável de ser implementada naquelas organizações onde se percebe um caráter bastante conservador, com papéis e responsabilidades bastante definidas. O motivo pelo qual leva ainda muitos projetos serem desenvolvidos utilizando o modelo cascata que é tentar ter-se uma melhor previsibilidade do andamento das atividades pode ser resolvido com todos os recursos que a FDD propõe de relatórios de fácil entendimento para a gestão e para o cliente. Esses recursos deixam muito transparentes os pontos onde se tem “gaps” ou onde tudo ocorre conforme esperado. 8
  • 10. Um ponto que parece ser negativo em algum dado momento é o fato da propriedade única de código. Essa questão se utilizada com muito rigor não se permitindo a quebra dessa regra, pode levar até a paralisia nas atividades impactando o bom andamento do projeto. Para concluir a FDD é uma boa opção para se introduzir metodologias ágeis por todos os seus aspectos que não levam nenhuma questão ao extremo e ainda garante um alto nível de qualidade na entrega de novos produtos de software. Referências COAD, Peter, LEFEBVRE, Eric, DE LUCCA, Jeff. “Java modeling in Color with UML”, Prentice Hall PTR, 1999 Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software. Disponível em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 14 de abril de 2013. Nebulon PTy Ltd (2012). Consultoria de Jeff De Luca. Disponível em: <http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf>. Acesso em: 28 de abril de 2013 BARKER, Gavin(2003). The Agile Umbrella. Feature Driven Development. Disponível em: <http://www.featuredrivendevelopment.com/node/531>. Acesso em: 14 abril 2013. PALMER , Stephen R.; FELSING, John M. “A Practical Guide to Feature-Driven Development”, Prentice-Hall, 2002, p.35-54. GOYAL, Sadhna. Major Seminar On Feature Driven Development Agile Techniques for Project Management and Software Engineering. Munich, 2008. Disponível em: <http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf>. Acesso em: 22 abril 2013 FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005 9

×