Essay:

Essay details:

  • Subject area(s): Marketing
  • Price: Free download
  • Published on: 14th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

Introdução

Surgiram várias metodologias ágeis após o manifesto para desenvolvimento de software, as quais procuram seguir os princípios formulados no manifesto: indivíduos e iterações em vez de processos e ferramentas, software funcional a documentação detalhada, colaboração do cliente mais que negociações contratuais, responder às mudanças e não seguir um plano. As metodologias ágeis tem a finalidade de entregar ao usuário um produto de qualidade em pouco tempo.

É passiva de tarefa árdua, a junção de metodologias distintas a fim de mesclar boas práticas de engenharia de software e de gestão de projetos, de forma harmoniosa, eficaz e eficiente. Porém, essa intenção desde o princípio, aliada à experiência e ao talento das pessoas envolvidas, propicia um resultado altamente satisfatório, a qual agrada os clientes, gestores e desenvolvedores. A FDD (Desenvolvimento Dirigido por Funcionalidades) é um excelente exemplo disso.

FDD – História

Em 1997, a partir da experiência de analise e modelagem orientada por objetos nascia a Feature Driven Development, o FDD (Desenvolvimento Dirigido por Funcionalidades). Foi inicialmente publicada no livro “Java Modeling in Color with UML”, de Peter Coad, Eric Lefebvre e Jeff de Luca. Já em 2002 fora publicada aversão completa e atualizada da metodologia no livro “A Pratical Guide to Feature Driven Development”.

O surgimento desta metodologia é mérito de Peter Coade de Jeff De Luca que, em um grande projeto em Java para o United Overseas Bank usou os seus conhecimentos em análise e modelagem orientadas por objetos e o conhecimento de Jeff De Luca em gerenciamento de projetos. O UOB precisava de uma completa reengenharia da sua plataforma de empréstimos, um complexo e gigantesco projeto que aproximadamente dois anos e 3.500 páginas de casos de usos documentados, porém quase nada de software executando, Jeff De Luca convenceu a diretoria do banco a tentar mais uma vez, agora sob a sua liderança. Para modelar a arquitetura Jeff De Luca contratou o exímio projetista de sistemas Peter Coad, houve também a contribuição do gerente de desenvolvimento Stephen Palmer com muitas ideias.

Após 15 meses e cerca de 2.000 funcionalidades entregues, o projeto foi concluído com a contribuição de 50 pessoas, com sucesso e com o orçamento abaixo do esperado. O sistema desenvolvido foi denominado de “Power Lender” e está funcionando atualmente.

A ligação da FDD com o manifesto ágil se deu quando Peter Coad foi convidado à famosa reunião dos metodologistas ágeis em 2001, ele não pôde comparecer e enviou Jon Kern, diretor de serviços da Together Soft, em seu lugar. Portanto a FDD, desde o inicio é uma metodologia “oficial” do movimento ágil.

Figura 1 Criadores do FDD

{

https://sitecampus.com.br/feature-driven-development-artigo-1-de-2/

Métodos Ágeis para Desenvolvimento de Software

Por Rafael Prikladnicki, Renato Willi, Fabiano Milani – Porto Alegre:Bookman, 2014

}

Conceito de Feature Driven Development (FDD)

Metodologia criada por Jeff De Luca e Peter Coad, a Feature-Driven Development – FDD (Desenvolvimento Dirigido por Funcionalidades) é uma abordagem direta a fim de desenvolver softwares com o uso das principais vantagens de outras abordagens ágeis utilizando técnicas centradas no modelo, as quais pode matender equipes e projetos maiores. A ênfase na qualidade por todo o processo e o monitoramento de progresso direto preciso e com baixa ocupação são características da FDD. Seu ciclo inicia-se na criação de um modelo de objetos do domínio do problema em colaboração com os especialistas no domínio. Usando a informação vinda da atividade de modelagem e de quaisquer outras atividades de coleta de requisitos que já possam ter ocorrido, os desenvolvedores prosseguem para a criação da lista de funcionalidades. A seguir é elaborado um plano para cada funcionalidade e são atribuídas responsabilidades. Então, equipes pequenas e formadas dinamicamente desenvolvem as funcionalidades, realizando repetidamente iterações de projeto (design) e construção, que duram não mais do que duas semanas e, geralmente, são muito mais curtas.

De acordo com Stephen Palmer (2002), tais funcionalidades da FDD são expressões granulares que representam algum valor para o cliente. Estas devem ter granularidades que não ultrapassem o tamanho de suas iterações, como por exemplo, se for definido que um projeto terá iterações de duas semanas, não se devem possuir funcionalidades que ultrapassem este tempo e caso ocorra, deve-se decompô-la em mais funcionalidades. Destacam-se dentre as práticas sugeridas durante o ciclo de vida da FDD e definidas por Stephen Palmer:

O Desenvolvimento por funcionalidade –O qual consiste em desenvolver as funcionalidades separadamente, tratando cada uma de forma única. Nesta prática, divide-se a funcionalidade de forma que cada membro da equipe se torna dono de uma classe e ficando dessa forma ele, responsável por refinar o modelo abrangente gerado no início do ciclo, codificar e testar a funcionalidade que lhe foi atribuída;

O Planejamento por Funcionalidade - Este consiste em gerar uma equipe de funcionalidades, que irá analisar o modelo abrangente gerado na fase anterior e criar uma lista com as funcionalidades do sistema, com base neste modelo e juntamente com os requisitos coletados antes do ciclo.

Conceito de Feature (Funcionalidades)

Trata-se de uma funcionalidade pequena, a qual tem um valor claro para o cliente quanto ao seu domínio de negócio. Já para a equipe de projeto deve ocupar apenas uma iteração para ser desenvolvido, que ocupa menos de duas semanas de trabalho, tipicamente. A implementação da maioria das funcionalidades requer apenas algumas horas de trabalho.

Segundo Prikladnickiet al (2014), Para entendermos bem onde a funcionalidade se encaixa precisamos recorrer à Teoria dos Processos. Um domínio de negócio pode ser decomposto em macroprocessos ou macro áreas de processos, como Compras, Vendas, Marketing, Operações, entre outras, também conhecidas como Áreas de Negócio. Dentro de cada Área de Negócios podemos identificar diversos processos ou Atividades de Negócio, que são desempenhadas por essa área, total ou parcialmente. Cada atividade, por sua vez, é composta por tarefas ou Passos, que podem ser manuais ou automatizados por sistemas (software, hardware etc.). Os Passos que precisarem de auxilio do sistema tornam-se as funcionalidades para o projeto FDD.

{

Palmer, S. R.andFelsing, J. M. (2002). A practicalguidetoFeature-DrivenDevelopment, Prentice Hall.

Métodos Ágeis para Desenvolvimento de Software

Por Rafael Prikladnicki, Renato Willi, Fabiano Milani – Porto Alegre:Bookman, 2014

}

Atores do FDD

FDD exibe uma notável característica social, refletida em sua proposta de estrutura da equipe de projeto, isso é em função do reconhecimento da interdependência sistêmica e o fator humano com a sua alta importância.

Figura 3 Interdependência dos componentes organizacionais

Quando se trata de metodologias ágeis há forte tendência na valorização do profissional, pois a influência da qualificação e do desempenho pessoal que a equipe possui em métodos adaptativos de desenvolvimento de software é muito expressiva. Nessa metodologia um profissional pode desempenhar mais de um papel e o próprio papel pode ser conter mais de um profissional.Os papeis principais que definem a estrutura fundamental de equipe FDD são:

o Gerente de projeto –É o gerente geral administrativo do projeto, responsável pela coordenação e alavancagem das ações da equipe, interlocutor da gerência, cliente e demais interessados quanto ao progresso.  É também o líder financeiro e tem a palavra final para escopo, cronograma, e recursos do projeto. Possivelmente tem um assistente administrativo que o ajuda a fim de alcançar a eficiência e eficácia de sua atuação.

o Gerente de desenvolvimento –Operacionaliza as instruções recebidas do gerente de projeto utilizando suas habilidades técnicas, gerenciais e de liderança através da orquestra das ações da equipe de desenvolvimento. Ele é responsável por resolver quaisquer possíveis conflitos dentre a equipe. Em pequenas equipes esse papel pode ser assumido pelo gerente de projeto.

o Especialistas no domínio do negócio –Os especialistas do domínio podem ser usuários, clientes, patrocinadores ou analistas de negócio. São responsáveis por transmitir e explicar o que deve ser feito a fim da adequação do sistema às necessidades usuais.

o Arquiteto líder –É responsável pela análise e modelagem do projeto, lidera a equipe no desenvolvimento do modelo que será construído e implementa as funcionalidades identificadas. Deve conduzir as sessões de modelagem de forma que a equipe de desenvolvedores possa contribuir na construção do sistema. Em pequenas equipes, esse papel pode ser assumido por desenvolvedores mais experientes desde que tenha visão sistêmica e, ainda pode ser assumido por um consultor externo a fim de trazer experiência e fornecer novas ideias.

o Programadores líderes – São os líderes dos pequenos times de análise, são desenvolvedores mais experientes reconhecidos como líderes pela equipe. Coordenama modelagem e desenvolvimento de novas funcionalidades, montam as equipes destas funcionalidades e participam das definições técnicas e, também são proprietários de classes. Cada programador líder geralmente tem sua subequipe de 2 a 5 profissionais, a qual é adaptável a cada contexto.

o Proprietários da classe –Os “Donos” de classe trabalham orientados pelo programador líder executando as tarefas de modelar, codificar, testar e documentar. São os demais desenvolvedores da equipe que assumem certas classes do modelo. O proprietário de classes sempre será escalado para participar de uma equipe de funcionalidades quando a classe em sua custodia precisar ser usada em uma funcionalidade.

Figura 3 Estrutura de equipe fundamental da FDD

{

Métodos Ágeis para Desenvolvimento de Software

Por Rafael Prikladnicki, Renato Willi, Fabiano Milani – Porto Alegre: Bookman, 2014

http://www.leandromtr.com/gestao/metodologia-agil-fdd/

}

Além dos papeis principais há também outros papeis importantes denominados papeis de apoio. Eles precisam ser desempenhados pelos profissionais que atuam no papeis principais ou por outros que se dedicam a ele. Não há necessidade que o apoio faça parte da estrutura principal, porém a ausência dele pode fazer com que tudo venha abaixo. Os agentes destes papéis são:

Gestor de Actividade, Guru da Linguagem, Engenheiro de Builds e Administrador de Sistema.

o Assistente de projeto –Dá assistência ao gerente de projeto cuidando dos detalhes do dia a dia do projeto. Pode atuar na promoção de eventos de integração e motivação da equipe, administrar reuniões, documentação, finanças, comunicação entre a equipe e o restante da organização etc.

o Testadores –Integrantes do controle da qualidade do produto durante o desenvolvimento, os quais atuam nos teste de integração, aprovação e reprovação.

o Gerente de versão ou de produto –Define o ciclo de vida do produto e quais funcionalidades que serão incluídas em cada versão etc.

o Gerente de configuração –Garante a segurança e integridade dos repositórios de artefatos, geralmente assume a responsabilidade pela compilação e montagem geral do produto.

o Guru da linguagem/ plataforma/ tecnologia –A partir de intervenções e mentorias rápidas aos demais desenvolvedores, permite o fluxo de programação sem pausa por falta de experiência ou conhecimento.

o Produtor de ferramentas, utilitários e bibliotecas –Fornece aos proprietários de classes, produtos de consumo interno que aceleram o desenvolvimento, promovendo então a padronização e o reuso.

o Administrador de sistemas –Responsável pelo ambiente de rede, e-mail, internet, servidores, instalação e manutenção de aplicativos, antivírus, ambientes de desenvolvimento, de teste e de produção etc.

o Implantadores –Encarregados da instalação e garantia de funcionamento adequado do produto no ambiente de produção do cliente, incluindo treinamento aos usuários se necessário.

o Escritores técnicos – Assumem a produção dos documentos e manuais do produto e até criar o material do treinamento com possível auxilio de profissionais do ramo.

{

Métodos Ágeis para Desenvolvimento de Software

Por Rafael Prikladnicki, Renato Willi, Fabiano Milani – Porto Alegre: Bookman, 2014

http://www.leandromtr.com/gestao/metodologia-agil-fdd/

}

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/marketing/2018-10-25-1540476218.php > [Accessed 18.11.19].