Feature Driven Development - Artigo 2 de 2

Feature Driven Development – Artigo 2 de 2

Feature Driven Development - Artigo 2 de 2Passado o artigo inicial sobre Feature Driven Development, chegou a hora de nos aprofundarmos no assunto e fazer melhor uso da técnica.

Construir uma Lista de Funcionalidades

Os programadores líderes buscam no trabalho feito durante o processo de desenvolvimento de um modelo abrangente fontes para uma categorização em áreas do domínio do negócio, atividades, passos e regras, criando desta forma uma lista com todas as funcionalidades do sistema ou do modelo inicial, que pode ou não ser referente ao desenvolvimento de todo o produto e sim apenas de uma pequena porção do mesmo.

Promoção de Julho Site Campus

Critérios de Entrada

Especialistas do negócio, arquitetos líderes, programadores líderes e principais componentes da equipe de desenvolvimento.

Atividades

• Formar a Equipe da Lista de Funcionalidades

Equipe formada, principalmente, por programadores líderes da equipe de modelagem do processo de definição de um modelo abrangente. É uma atividade obrigatória e deve ser gerida pelo Gerente do Projeto em parceria com o Gerente de Desenvolvimento.

• Construir Lista de Funcionalidades

Por meio dos diversos estudos realizados durante o primeiro processo do Feature Driven Development, os programadores líderes e as equipes de lista de funcionalidades devem transformar cada um dos domínios estudados em passos para a realização de atividades que englobem a área de negócios em funções granulares, expressas em termos que possam ser interpretados pelo cliente. Cada funcionalidade não pode levar mais de duas semanas para ser desenvolvida. Os criadores da metodologia afirmam que duas semanas é o tempo limite, e na prática, maior parte das funcionalidades são entregues em muito menos tempo.

Verificação

Uma avaliação interna e externa é feita pela equipe que desenvolveu a lista de funcionalidades, juntamente com os principais representantes do negócio, sejam eles especialistas no domínio ou os próprios colaboradores da empresa.

Critérios de Saída

O processo resulta, justamente, em uma lista de funcionalidades composta por uma lista de áreas, atividades de negócio dentro de cada lista de áreas e, para cada passo da atividade de negócio, uma funcionalidade que satisfaça aquele passo.

Planejar por Funcionalidade

É através deste processo inicial que é produzido o plano de desenvolvimento. Os principais responsáveis pelo projeto definem a sequência na qual as funcionalidades serão concebidas/implementadas com base na dependência entre as mesmas. Além disso, são levadas em conta, também, a carga de trabalho da equipe de desenvolvimento e a complexidade de cada funcionalidade.

Muito comumente são levadas em conta as atribuições das atividades de negócio, que são direcionadas a equipe de desenvolvimento do projeto de acordo com a experiência de cada membro da mesma. Quando o equilíbrio entre funcionalidades, atividades do negócio e equipe de desenvolvimento é alcançado, então a distribuição das classes estará completa.

Critérios de Entrada

O processo Construir Lista de Funcionalidades deve ter sido finalizado.

Atividades

• Formar a Equipe de Planejamento

O gerente de desenvolvimento é definido e são indicados os programadores líderes. Esta é uma atividade de responsabilidade do gerente do projeto e é obrigatória.

• Determinar Sequência de Desenvolvimento

A equipe de planejamento deve compor as dependências entre as funcionalidades, a distribuição da carga de trabalho entre os proprietários das classes, a complexidade das funcionalidades, adiantamento de atividades de negócio de alto risco ou complexidade e definição de marcos do projeto.

• Atribuir Atividades de Negócio aos Programadores Líderes

A equipe de planejamento deve atribuir aos programadores líderes a sequência de desenvolvimento, dependências entre as funcionalidades, distribuição da carga de trabalho entre os proprietários de classes e a complexidade das funcionalidades a serem implementadas.

• Atribuir Classes aos Desenvolvedores

Cada desenvolvedor receberá uma determinada carga de trabalho em função de sua experiência. A distribuição de classes acontecerá da mesma forma, e a sequência de desenvolvimento se dará com base nesta distribuição de classes.

Verificação

A equipe de planejamento realiza uma auto-avaliação para definir o nível de participação no processo de todos os membros da mesma.

Critérios de Saída

Como resultado do processo, obtém-se o plano de desenvolvimento, que define as
atividades de negócios com datas de término, atribuição de atividades de negócio para membros da equipe de desenvolvimento, áreas com datas de término e listas de classes e seus proprietários.

Detalhar por Funcionalidade

É o processo que resulta no pacote de projeto (design) para cada funcionalidade. Um programador líder recebe um determinado número de funcionalidades para desenvolver. Logo, atribui classes para seus desenvolvedores que deverão ser a base para as funcionalidades a serem implementadas. Sua equipe produz, então, diagramas de sequência para as funcionalidades atribuídas a equipe. O programador líder refina o modelo de objetos e os desenvolvedores escrevem prefácios das classes e métodos.

Critérios de Entrada

O processo de planejamento deve ter sido finalizado.

Atividades

• Formar a Equipe de Funcionalidades

O programador líder identifica as classes que serão envolvidas no projeto deste conjunto de funcionalidades e, a partir disto, atualiza o banco de dados de funcionalidades. Da lista de proprietários de classes, o programador líder identifica os programadores necessários para formar a equipe de funcionalidades.

• Desenvolver os Diagramas de Sequência

Os Diagramas de Sequência, suas alterações e versões diferentes da versão oficial devem ser registrados para que o trabalho seja balizado a partir destes. Comentários e esclarecimentos também devem ser armazenados juntamente dos diagramas.

• Escrever Prefácios de Classes e Métodos

Cada proprietário de classe escreve o prefácio de classe e métodos para cada item definido pela funcionalidade e pelas classes as quais ficaram sob sua responsabilidade. Este prefácio inclui parâmetros, mensagens, exceções e tipos de retorno. O programador líder pode, então, gerar uma documentação completa com base em cada prefácio e disponibilizar para toda a equipe.

Verificação

Uma inspeção obrigatória deve ser realizada no projeto com todos os membros da equipe de funcionalidades e, inclusive, até mesmo outros componentes da equipe do projeto. O aceite deve ser dado pelo programador líder, que deverá gerar para cada uma das classes identificadas uma agenda de tarefas. Esta agenda refletirá diretamente no dia-a-dia do proprietário de cada classe e também no trabalho da equipe como um todo, já que haverá um diagrama de sequência de funcionalidades e um cronograma definido para o desenvolvimento de cada classe.

Feature Driven Development

Critérios de Saída

O resultado deste processo é um pacote de design revisado com sucesso, pronto para iniciar a próxima etapa do Feature Driven Development que é o desenvolvimento por funcionalidades. Existe documentação, sim. Este processo gera requisitos referenciados na forma de documentos de todos os memorandos de confirmação relacionados e documentação de apoio. Também são encontrados no pacote de projeto diagramas de sequência, alternativas de projeto, modelo de objetos com classes, métodos e atributos, lista de tarefas e agendamentos para itens na ação nas classes afetadas para cada membro da equipe.

Construir por Funcionalidade

É uma atividade direcionada para cada atividade. Desta forma, é possível produzir uma função com valor para o cliente, ou seja, uma funcionalidade.

Iniciando-se pelo projeto de design, cada proprietário de classes garante a implementação de itens necessário para que suas classes ofereçam a base para a construção de cada nova funcionalidade. Logo após esta estruturação, são realizados testes de unidade no código desenvolvido e por uma inspeção. Quem faz a determinação de como serão realizados os testes é o programador líder, ou então o gerente de projeto. Passando por todos os testes satisfatoriamente, o código é liberado como versão oficial de trabalho.

Critérios de Entrada

Tendo completado com sucesso o processo de Detalhar por Funcionalidade e completado o pacote de projeto (design) dentro dos requisitos estabelecidos e tendo o mesmo sido inspecionado e avalizado pela equipe, inicia-se o processo de Construir por Funcionalidade.

Atividades

• Implementar Classes e Métodos

Devem ser designados proprietários de classes dentro da modelagem de objetos realizada previamente ao trabalho de construir o software na prática. Cada responsável por cada classe devem garantir que as mesmas sejam implementadas para satisfazer os requisitos da funcionalidade em desenvolvimento. A atividade deve ser conduzida por toda a equipe de funcionalidades e é obrigatória.

• Inspecionar o Código

Podendo ser realizada antes ou após o teste de unidade, a inspeção deve ser realizada por toda a equipe de desenvolvimento de funcionalidades. É de caráter obrigatório.

• Teste de Unidade

Os testes de unidade devem ser realizados pelos proprietários de cada classe, dentro da equipe de desenvolvimento de funcionalidades. Os testes servem para garantir que todos os requisitos das classes determinadas foram atendidos, assim, as funcionalidades poderão ser implementadas sem riscos. Testes de unidade são obrigatórios.

• Promover à Versão Atual (Build)

É neste momento que a funcionalidade ganha vida. Após a inspeção do código e os testes unitários, o programador líder verifica as classes individualmente e por meio de informações de toda a equipe faz a promoção daquela funcionalidade ao cliente.

Verificação

A equipe de funcionalidades, assim como o programador líder, devem realizar testes de unidade (assim como os unit tests da metodologia XP) e inspecionar o código antes de liberar o que foi construído até então para uma versão atual utilizável pelo cliente. Estes testes são de caráter obrigatório.

Critérios de Saída

Métodos e classes devem ter sido inspecionadas e passado em todos os testes promovidos pela equipe de desenvolvimento, assim como os mesmos devem ter sido promovidos a versão oficial, ou seja, já utilizável pelo cliente. Finalmente, o que realmente importa ao fim da fase de Construir por Funcionalidade é entregar valor ao cliente, software que possa ser incorporado ao seu dia-a-dia.


#
Compartilhe!
Fale com o Site Campus

Tags: , , , ,