Processos Ágeis II - FDD - Feature Driven Development - Desenvolvimento Dirigido a Funcionalidades

Olá sejam bem-vindos ao canal engenheria de software com ênfase em uml Eu sou professor gilian Guedes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar segmento ao tema de processos de desenvolvimento de software enfocando o os processos eh ágeis eh Então hoje eu vou falar sobre o processo fdd que é abreviatura de feature driving development ou desenvolvimento dirigido a funcionalidades que

é um tipo de processo ágil voltado para projetos grandes e com certo grau de complexidade Então vamos iniciar a nossa aula Então essa é a é a segunda aula sobre processos de desenvolvimento ágeis na primeira aula eu dei uma introdução aos conceitos em princípios ágeis e também sobre os problemas de se implantar processos ágeis e hoje eu vou iniciar a falar sobre um processo ágil específico que é o fdd que como eu falei é abreviatura de feature Drive development ou desenvolvimento dirigido a funcionalidades Como eu disse anteriormente esse processo iria voltado principalmente para projetos grandes

com um uma quantidade de funcionalidades maior do que o normal e com certo grau de complexidade Então esse tipo de processo ele apesar de ser um processo ágil ele gera bastante documentação e ele trabalha muito com modelagem orientada a objetos Então como já tinha falado anteriormente não é que por ser um processo ágil nós não vamos fazer modelagem nós não vamos gerar documentação nós não vamos produzir modelos nós vamos fazer engen de requisitos Não vamos não vamos fazer projeto Isso é uma falácia isso tem pessoas que afirmam Ah eu sou ágil então eu não produzo

documentação eu não faço modelagem eu não faço projeto não faço engenharia de requisito e parto direto por código isso não é ser ágil isso é desenvolver da forma clássica de basicamente codificar e testar certo então vocês podem ver que existem processos ágeis que geram bastante documentação e produzem muita modelagem Ah é importante falar que muito do material dessa aula foi retirado foi baseado no livro do professor Raul o vs slavic sobre engenharia de software bom então vamos começar a falar sobre o processo fdd então o processo fdd tem duas fases principais a primeira fase é

a de concepção e planejamento e a segunda é a de construção a fase de concepção e planejamento ela trabalha principalmente mas não somente a engenharia de requisitos enquanto que a fase de construção trabalha mais projeto e codificação desenvolvimento e é também na fase de construção que ocorrem as iterações ã então a fase de concepção e planejamento ela tem como entrada principalmente os requisitos e ela possui eh quatro aliás três subfases três estágios que são o desenvolver modelo abrangente o dma ou também por alguns autores desenvolver modelo geral o depois disso é produzido é executada a

o estágio de construir lista de funcionalidades e depois o estágio de planejar por funcionalidade isso gera entre outros artefatos um modelo de classes ou mais de um e um plano de desenvolvimento na fase construção ela possui dois está ou duas subfases que são a detalhar por funcionalidade ou projetar por funcionalidade ou modelar por funcionalidade tem algumas variações e construir por funcionalidade que é a codificação priamente dita enquanto que a o detalhar por funcionalidade é o Projeto principalmente o projeto bom então falar um pouquinho sobre os membros da equipe da fdd tem a fdd trabalha com

equipes grandes com vários papéis então alguns membros são o gerente de projeto que como o nome já diz né ele responsável pelos aspectos administrativos do projeto ah gestão de tarefas e de prazos garantir que o cronograma está sendo cumprido que as tarefas estão sendo cumpridas dentro do que foi planejado ã operação do Centro de Controle contato com o cliente e comp ento do status do projeto o a divulgação de como o projeto se encontra um outro papel é o do arquiteto chefe que ele é responsável por estruturar o sistema ou seja principalmente desenvolver a a

arquitetura do software que é o esqueleto a partir do Qual o software vai ser desenvolvido que estabelece como os módulos vão vão estar eh estruturados dentro do sistema eh também ele é responsável por grande parte da modelagem do projeto e ele gerencia os demais arquitetos nós temos o papel de programador Líder que como o nome já diz ele lidera a equipe de programadores eventualmente pode haver mais de um programador Líder eh nós temos o papel de gerente de desenvolvimento que ele como o nome já diz ele gerencia a equipe de desenvolvedores H ele tenta gerenciar

os prazos de sprints um Sprint é basicamente uma iteração eh coordena entregas e os relatórios junt eh junto ao arquiteto chefe eh o programador Líder a Ainda temos também o papel de proprietário de classe que ele é basicamente um desenvolvedor que eh a ele são atribuídos uma ou mais classes em que ele deve se responsabilizar por desenvolver eh ele tem Ah um prazo relativamente rápido para executar as suas tarefas cerca de duas semanas e nós temos o especialista em domínio o especialista de domínio eh são os usuários Chaves Eh Ou seja é uma pessoa que

tem bastante conhecimento sobre como funciona um um determinado departamento determinado setor um determinado processo da empresa ele tem bastante experiência sobre uma determinada área do negócio então ele entende bastante do contexto do projeto e deve contribuir para a otimização desse projeto então especialista em domínio é um uma das pessoas que mais fornece eh insumos para a elicitação de requisitos e para a compreensão desses requisitos outros membros da equipe podem ser testadores escritores técnicos que podem escrever a especificação de requisitos e outros documentos por exemplo administradores de sistema responsáveis pela configuração de hardware software de apoio

eh gestores de ferramentas que também tem mais ou menos essa função bom vamos falar sobre a de concepção e planejamento Então ela se baseia na premissa que se deve pensar antes de começar a construir Como já foi falado ela tem três subfases que são a dma a clf e a PPF dma significa desenvolver modelo abrangente alguns autores falam de desenvolver modelo geral em que basicamente se produz uma modelagem orientada a objetos Principalmente uma relativa a engenharia de requisitos Mas já tem um pouco de projeto nisso ah depois tem a subfase de construir lista de funcionalidades

que basicamente identifica as funcionalidades do software ou seja as funções serviços que o software deve oferecer aos seus usuários nessa fase eventualmente pode se aplicar decomposição funcional com objetivo de dividir o projeto em Pates menores e mais fáceis de gerenciar e nós temos a fase de PPF que significa planejar por funcionalidade em que se faz um planejamento dos diversos ciclos iterativos para desenvolver determinadas funcionalidades bom vou falar sobre as atividades do processo dma então primeira atividade formar a equipe de modelagem é uma atividade obrigatória sob responsabilidade do gerente de projeto então Eh o gerente ele

deve formar uma a equipe de modelagem eh utilizando eh convocando especialistas de domínio ou especialistas de negócio ou seja usuário Chaves que tem conhecimento sobre um determinado domínio um determinado setor do negócio da empresa para o qual se destina o software clientes e desenvolvedores a a segunda atividade é o estudo dirigido sobre domínio é uma atividade obrigatória sob responsabilidade da equipe de modelagem nessa nessa atividade é realizado um domain Walkthrough ou estudo dirigido de domínio basicamente os usuários Chaves os especialistas de domínio eles apresentam a sua área de domínio os seu conhecimento o conhecimento que

eles possuem sobre a sua área sobre o processo ã que eles dominam eles apresentam esse conhecimento esse domínio paraa equipe ã principalmente dando ênfase aos aspectos conceituais como falei aqui Ness no dma se trabalha principalmente emeria de requisitos Então os aspectos conceituais são muito são muito importantes para essa fase Ah então os especialistas de domínio ou especialist de negócio eles podem também apresentar uma visão do produto uma visão Inicial H estabelecendo um escopo inicial do que se pretende alcançar com o produto aí depois nós temos a atividade de estudo de documentação que é opcional que

também é responsabilidade da equipe de modelagem se for necessário a equipe Ela estuda documentos disponíveis relativos ao domínio do problema e isso pode incluir o estudo de possíveis sistemas legados um sistema legado é um software que já existe na empresa e que muitas vezes não possui documentação é um software antigo que ainda está em uso e muitas vezes ele vai ser sub vai ser substituído pelo novo software e nós temos a atividade de desenvolver o modelo que é atividade obrigatória é responsabilidade de equipes de modelagem específicas ou equipes de modelagem menores eh a equipe de

modelagem ela é dividida em diversos grupos contendo Não mais do que três pessoas e esses eh grupos eles vão criar diversos modelos candidatos para as suas áreas de domínio Ah o arquiteto Líder ele pode eh fornecer um modelo base para as equipes eh tomarem como exemplo para criar os seus próprios modelos e as equipes elas apresentam os seus modelos ao final dessa atividade esse modelos eles são refinados corrigidos consolidados e Unidos em um modelo único H em algumas alguns autores também falam que às vezes o melhor modelo é escurido com o modelo que vai ser

eh utilizado como modelo único depois nós temos a atividade de refinar o modelo de objetos abrangentes é uma atividade obrigatória Mas pode acontecer ou não ah em termos de Que bom Primeiro ela é responsabilidade do arquiteto líder e da equipe de modelagem e pode ocorrer que as decisões que foram tomadas durante o desenvolvimento dos modelos específicos elas podem afetar a o modelo Geral de negócio então se isso ocorrer o modelo deve deve ser refinado Quais são as saídas do processo de desenvolver modelo geral ou modelo abrangente é produzido o modelo conceitual O que é o

modelo conceitual o modelo conceitual é basicamente um diagrama de classes que ele identifica os conceitos relacionados ao domínio do problema na forma de classes então eh essas classes são basicamente classes de Entidade que estão relacionadas diretamente ao domínio do problema que se tenta solucionar então o modelo conceitual ele é frequentemente produzido por pela engenharia de requisitos e ele não contém métodos porque são métodos já já são fazem parte da solução porém além do modelo conceitual a saída do dma pode também produzir métodos e atributos nesse caso já seria um início de modelo de domínio que

é um modelo conceitual Enrique com detalhes de solução Mas isso pode acontecer eventualmente principalmente atributos é mais comum os métodos em geral São detalhados em outras fases mas nesse caso eles precisarão ser refinados e revistos podem ser produzidos diagramas de sequência ou de máquinas estados Se isso for considerado necessário para compreender melhor o problema também são produzidos sobre modelo que definem porque determinadas decisões de projeto foram escolhidas em detrimento de outras ah bom ah agora vou falar sobre a atividade de construir lista de funcionalidades eh atividade não subprocesso eh basicamente ela possui uma única atividade

que é justamente construir a lista de funcionalidades essa é uma atividade obrigatória que é a responsabilidade da equipe da lista de funcionalidades essa equipe Ela é formada por pelos programadores líder do processo anterior de definir modelo abrangente se utiliza de se utiliza as partes do produto que foram identificadas no processo dma que são adas áreas de negócio e a partir dessas áreas de negócio o grupo precisa identificar as atividades dessas áreas e a partir dessas atividades Quais são as funcionalidades que compõem cada atividade então Aqui nós temos uma figura para demonstrar a estrutura da lista

de funcionalidades nós temos uma área de negócio mais geral ela é composta diversas atividades de negócio que por sua vez é composta por diversos passos de negócio isto aqui é uma associação de agregação significa que esta classe ela precisa ser complementada por informações dessas desta classe e como Aqui nós temos uma associação de agregação esta classe também precisa ser complementada pelas informações contidas dos Passos de negócio bom as saídas do processo de construir lista de funcionalidades são a lista de áreas de negócio Ah uma lista de atividades de negócio para cada área de negócio e

para cada lista para cada uma das atividades identificadas também é produzido uma lista de passos de atividade ou funcionalidades que permitiriam realizar a atividade em questão bom eh agora eu vou falar sobre o subprocesso de PPF que significa planejar por funcionalidade Então a primeira delas é formar a equipe de planejamento é uma atividade obrigatória sob responsabilidade do gerente de do projeto e ele forma uma equipe formada que vai ser composta pelo gerente de desenvolvimento e pelos programadores Líder depois se determina a sequência de desenvolvimento também é uma atividade obrigatória é responsabilidade da equipe de planejamento

essa equipe ela precisa determinar o Prazo de Conclusão do desenvolvimento de cada uma das atividades de negócio o que pode não ser uma tarefa fácil Em algumas situações E para isso eles se baseiam nas dependências e na complexidade das funcionalidades na própria equipe de desenvolvimento e na carga horária disponível Ahã depois outra atividade eh aliás ainda continuando Continuando a atividade determinar sequência de desenvolvimento essa essa atividade é precisa procurar eh tentar priorizar as atividades com funcionalidades mais complexas ou com risco considerado alto eu sou um grande defensor da priorização de atividades priorização de requisitos aqui

se pode trabalhar com alguma técnica como a moscou para priorizar Quais as atividades ou Quais as funcionalidades mais importantes ã alocar jun depois além disso a a sequência de desenvolvimento ela deve juntas atividades ou funcionalidades que têm dependência uma das outras eh deve-se considerar Marcos externos quando isso for necessário para determinar a as entregas e também eh deve-se pensar na possibilidade de distribuir o trabalho entre os proprietários das classes outra atividade se atribuem as atividades negócio aos programadores líderes é uma atividade obrigatória sob responsabilidade da equipe de planejamento e essa atividade ela determina quais programadores

Líder vão ser proprietários de quais atividades de negócio em uma em um segundo momento esses programadores líderes vão hã delegar algumas funções para as as equipes de desenvolvimento Ahã ainda dentro dessa atividade essa atribuição de propriedade ela considera a dependência entre as funcionalidades e as classes que os programadores líderes já são proprietários a sequência de desenvolvimento que foi produzida na atividade anterior a complexidade das funcionalidades levando em consideração também a carga de trabalho que foi alocada aos programadores líderes atividade seguinte atribuir classe aos desenvolvedores é uma aidade obrigatória sob responsabilidade da equipe de planejamento ela

deve atribuir a propriedade das classes aos desenvolvedores eles se baseiam nisso eles se baseiam para isso eles se baseiam na distribuição da carga de trabalho que os desenvolvedores eh possuem a complexidade das das classes novamente deve-se priorizar as classes de maior complexidade de maior risco isso é útil para enfocar Quais são as as as classes que deverão ser desenvolvidas primeiro Ah também a intensidade do uso das classes quais classes são mais utilizadas ou serão mais utilizadas O sistema também deve se priorizar esse tipo de classe e também eh ele se baseia na sequência de desenvolvimento

as saídas do processo de planejar por funcionalidade são os prazos para a conclusão de desenvolvimento que se refere a cada uma das atividades de negócio a atribuição dos programadores líderes a cada uma das atividades de negócio os prazos para a conclusão do desenvolvimento eh referentes a cada uma das áreas de negócio e a lista dos desenvolvedores e das classes que eles são proprietários e as classes que foram atribuídas a eles agora vou falar sobre os processos da fase de construção e é uma fase iterativa ou seja esse ciclo pode se repetir várias vezes cada ciclo

eh em geral ocupa de uma a duas semanas e tem dois processos ou dois subprocessos principais que são o dpf que é o detalhar ou modelar ou projetar com funcionalidade onde o projeto orientado a objeto será eh efetivamente desenvolvido embora ele já tenha sido iniciado na fase nas fases anteriores e a outra o outro subprocesso é o CPF que é o construir por funcionalidade que é a codificação propriamente D Então as atividades do detalhar por funcionalidade ou eh projetar por funcionalidade o a primeira delas é formar equipe de funcionalidades é uma atividade obrigatória sob responsabilidade

do programador Líder então cria um um pacote de funcionalidades que precisaram ser trabalhados naquele ciclo naquela iteração ã baseado nessas nas classes envolvidas eh com essas funcionalidades se estabelece a equipe de funcionalidades que é composta pelos proprietários dessas classes e se atualiza o controle de andamento de projeto determinando que o pacote de funcionalidades atual que o pacote de funcionalidades que foi produzido agora nessa atividade eh está sendo trabalhado correntemente então basicamente essa atividade essa etapa Escolhe um conjunto de funcionalidades que serão desenvolvidas nesse ciclo nessa interação depois se faz um estudo de dirigido de domínio

isto é uma atividade opcional responsabilidade do especialista de domínio Ela será realizada se ah as alguma funcionalidade se demonstrar eh muito complexa então o especialista domínio ele vai novamente conduzir um estudo dirigido sobre domínio com um pouco mais detalhe para tentar detalhar melhor aquela funcionalidade em questão ou o conjunto de funcionalidades eh antes que o projeto seja eh efetivamente iniciado para basicamente tornar a compreensão daquela funcionalidade eh mais fácil de entender atividade seguinte é o estudo da documentação de referência também é opcional responsabilidade da equipe de funcionalidades então se a complexidade da funcionalidade for maior

do que a o esperado então a equipe pode ter que estudar outros documentos disponíveis e eventualmente estudar eh softwares legados em seguida se passa paraa atividade de desenvolver os diagramas de sequência os diagramas de sequência são diagramas comportamentais da uml muito úteis para detalhar um determinado processo uma determinada funcionalidade descobrir a ordem das mensagens que serão disparadas entre os objetos que comporão aquele processo e que métodos deverão ser disparados entre eles é uma atividade opcional sob responsabilidade da equipe de funcionalidades e eles modelam os diagramas de sequência que são necessários para descrever eh cada funcionalidade

a ser desenvolvida Ah o modelo abrangente que foi eh desenvolvido na dma na fase no no subprocesso dma ele é refinado dessa vez incluindo métodos ou seja os modelos conceituais que haviam sido produzidos na fase anterior passam a se tornar modelos de domínio depois se refina o modelo de objetos ou modelo de domínio é uma atividade obrigatória responsabilidade do programador líder então utilizando o sistema de controle de versões o programador Líder ele cria uma área de trabalho ã utilizando uma cópia das classes necessárias para o modelo e essa cópia Ela é disponibilizada para equipe de

funcionalidades ainda dentro dessa atividade a equipe de funcionalidade vai ter um acesso compartilhado essa cópia mas o restante da da das pessoas dos H profissionais que participam do projeto não terão acesso a essa cópia Enquanto essa cópia não for salva com uma nova versão H das classes no Sistema de Controle de versões a equipe de funcionalidades ela adiciona métodos atributos associações e novas classes que forem consideradas necessárias ao modelo então vai se refinando o modelo de domínio ah a sexta atividade é a escrita das interfaces e das assinaturas das classes e métodos é uma atividade

obrigatória sobre responsabilidade da equipe de funcionalidades então o proprietário de cada classe ele escreve as interfaces das classes isso também inclui os a definição a escrita dos atributos e dos seus tipos h a a Declaração dos métodos e a assinatura desses métodos que inclui os parâmetros que recebem e os valores que eles Retornam H também se definem possíveis exceções e mensagens necessárias as saídas do processo detalhar por funcionalidad são uma capa com comentários que descreve o pacote de funcionalidades de uma forma ã razoavelmente Clara os requisitos que estão sendo abordadas na por aquele pacote naquela

interação eh os diagramas de sequência produzidos os possíveis projetos alternativos Se isso for considerado necessário h o modelo de classes atualizado ou seja modelo de domínio as interfaces de classe que foram geradas e a lista de tarefas que vão ser atribuídas aos desenvolvedores que foi gerada em função dessas atividades e agora nós vamos trabalhar com o subprocesso de construir por funcionalidade a primeira atividade é implementar classe métodos ela é obrigatória so responsabilidade da equipe de funcionalidades basicamente os proprietários das classes vão codificar as classes e os métodos colaborando entre si para concluir essa atividade depois

o código vai ser inspecionado Isso é uma atividade muito importante ela é obrigatória sob responsabilidade da equipe de funcionalidades ela é coordenada pelo programador Líder ela pode ser feita antes ou depois dos Testes de unidade e basicamente as inspeções como o nome já diz elas inspecionam analisam esquadram o código para determinar se os padrões de codificação estão sendo seguidos se o código está limpo fácil de entender se ele é flexível a mudanças se ele não possui maus cheiros de código se o código é elegante e foi devidamente refatorado as as inspeções elas podem ser feitas

por analistas externos O que é o mais recomendável mas eventualmente ela pode ser feita pela própria equipe de funcionalidades depois se passa ao teste de unidade que é uma atividade obrigatória sob responsabilidade da equipe de funcionalidades onde os proprietários das classes vão estabelecer vão Criar e vão executar os testes de unidade sobre as suas classes procurando por defeitos anomalias ou inadequação aos requisitos então o programador Líder ele pode determinar também teste de integração para verificar se as classes conseguem se comunicar quando ele julgar isso necessário depois eh se passa a atividade de promover a versão

atual chamada build que é uma atividade obrigatória sob responsabilidade do programador Líder Então à medida que os desenvolvedores eles vão eh afirmando declarando que os testes de unidade Eles foram bem sucedidos o programador Líder então promove a versão atual de cada classe A build mas antes é necessário que essas classes passem pelos testes de integração ou seja verificar se elas estão eh se comunicando trabalhando juntos as saídas do processo de construir por funcionalidade são as classes promovidas a versão atual depois que foram aprovadas nos testes de unidade de integração Ah e um conjunto de funcionalidades

um valor agregado para o cliente que ele já pode começar a utilizar Lembrando que essa é uma das interações outras iterações poderão ser realizadas se o software ainda não tiver sido concluído então volta-se a detal a etapa de detalhar funcionalidade cria-se um novo pacote funcionalidades se executam todas as atividades da fase anterior e depois passe novamente a fase de construir por funcionalidade até que o software seja concluído a o processo de fdd ele pratica algumas algumas boas práticas de desenvolvimento que são A modelagem orientada a objetos do domínio eh o desenvolvimento por funcionalidade ele estabelece

classes proprietárias individualmente então isso com isso se tenta evitar conflitos na equipe existem equipes de recurso que são pequenas equipes que tentam auxiliar na no desenvolvimento e fornecer suporte para para o projeto isso em todas as fases do projeto do fdd inspeções constantes O que é muito importante para garantir a qualidade do código gerenciamento e configuração para determinar quais são os componentes necessários para produzir uma versão de uma determinada versão da daquele software quais são os componentes que compõem Quais são as classes necessárias e possíveis outros ã softwares outros arquivos de apoio eh com bibliotecas

arquivos de ajuda arquivos de configuração etc integração contínua de forma que o cliente consiga H visualizar a evolução do desenvolvimento do do software e também a visibilidade dos Progressos e resultados do desenvolvimento além disso esse processo ele tem várias vantagens ele é bastante adequado para equipes grandes e projetos grandes ele é útil para produzir projetos bem atados desde o início desde a primeira fase permite que muitas equipes trabalhem simultaneamente isso reduz o tempo de execução do projeto o processo ele produz muita documentação o que permite que ele seja muito rastreável a rastreabilidade eh permite determinar

a origem de requisito que é a rastreabilidade para trás determinando quem pediu porque pediu quando pediu e a rastreabilidade para a frente determina que fat serão alterados pela mudança num requisito numa funcionalidade Ah esse essa grande documentação ela torna mais fácil identificar lacunas e corrigi-las eh é importante destacar que isso ã derruba o mito Que métodos ágeis não possuem não produzem documentação Eles produzem documentação fdd produz bastante documentação a diferença com relação aos processos prescritivos é que eles não gostam não aceitam produzir documentação burocrática ou inútil que não ajuda a solucionar o problema ou a

compreender o problema mas fdd é um método ágil que produz muita documentação Outra vantagem é que as equipes trabalham com as etapas de desenvolvimento com bastante agilidade agora tem as desvantagens Ah esse processo ele não funciona bem com equipes pequenas H porque o projeto fdd ele tem muitas tarefas muitas atividades e muitos papéis eh pode não necessariamente é uma desvantagem Na minha opinião não não necessariamente é uma desvantagem mas ã ele gera uma grande documentação escrita nas primeiras fases do projeto e por isso novamente é necessário uma equipe grande e uma outra possível desvantagem é

que o projeto depende muito das decisões dos programadores líderes eles precisam ter bastante experiência para desempenhar esse papel e nós terminamos mais essa aula nós vimos então o processo ágil de desenvolvimento dirigido a funcionalidades o fdd feature driving development eu espero que vocês tenham gostado dessa aula Espero que ela tenha sido útil se vocês gostaram dessa aula eu peço então que vocês curtam esse vídeo compartilhem com quem possa se interessar e se ainda não estão inscritos eu peço que você se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas Y