FDD Em Uma Casca de Banana

FDD em uma casca de banana

Um guia de rpido aprendizado para aFeature-Driven Development

mar.2007

aXmagnow w w . a x m a g n o . c o m

O que FDD?O que FDD?

O que no FDD?O que no FDD?

Feature-Driven Development (FDD) uma metodologia gil para o processo de engenharia de software, que foi elaborada com foco na entrega frequente de software funcionando para os clientes e na utilizao de boas prticas durante o ciclo de seu desenvolvimento.

Uma caracterstica marcante da FDD o fato dela favorecer fortemente o envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software.

Feature-Driven Development (FDD) um processo de desenvolvimento de software iterativo e incremental.

Diferentemente de outras metodologias, a FDD no extremamente focada na programao ou no modelo, mas sim

utiliza o bom senso para abstrair o melhor dos dois mundos.

A FDD no uma metodologia descrita em uma coleo com 30(trinta) volumes de livros. Portanto, ela no uma bblia a ser seguida por sua equipe de desenvolvimento.

A FDD no uma metodologia de gerenciamento de projetos de software. Apesar de, em suas prticas, existirem

atividades relacionadas a esse fim, a FDD tem como principal foco cobrir o processo da engenharia de software, e no do

gerenciamento.

A FDD no uma bala de prata, portanto, ela no resolver todos os problemas do mundo, ou mesmo os da sua

empresa. No entanto, a FDD o auxiliar a tornar o processo de engenharia de software da sua empresa mais eficiente, e a criar em sua equipe uma cultura voltada rpida entrega de software

para o cliente.

Por que devo Por que devo usar FDD?usar FDD?

Porque em projetos de software precisamosmais do que apenas cdigo escrito e funcionando.

Porque os processos da FDD favorecem a aproximao de especialistas de negcio, gerentes e desenvolvedores.

Porque decompondo o produto em funcionalidadesestou mais prximo de estar sempre entregando algode valor para o meu cliente.

Porque FDD gil, e nos permite realizar entregasfrequentes aos nossos clientes.

Porque utilizando a prtica de proprietrios de classes,garanto a responsabilidade, especialidade e familiaridade dos

desenvolvedores com determinado pedao de cdigo.Com isso, tenho sempre manuteno rpida e de qualidade

em qualquer parte do meu sistema.

Porque os mecanismos de visualizao deprogresso da FDD, tais como o Parking Lot,nos permitem ter, a qualquer momento, umavisualizao exata de onde estamos.

Porque as prticas da FDD contribuem paraum grande envolvimento do cliente no projeto, fazendo

com que, rapidamente, este passe a chamar o seuprojeto de NOSSO PROJETO.

Porque FDD funciona!

Porque a FDD oferece planejamento e modelo namedida certa! Sem exageros, mas tambm sem ausncia.

Porque a inspeo de cdigo e de design, que uma dasprticas da FDD, nos garante qualidade no produto final.

Quem quem?Quem quem?

Como Especialista do negcio uso meu conhecimento no negcio para apresentar equipe do projeto as necessidades para que o software possua valor real para ns. Estou sempre disponvel para fornecer aos desenvolvedores maior detalhamento sobre determinada funcionalidade. Sou um membro fixo da equipe e sempre estou fornecendo feedback das entregas para todos os envolvidos.

Ol! Eu sou a Gerente do Projeto, e como tal sou responsvel por todos os assuntos administrativos do projeto, o que inclui o gerenciamento de recursos, oramento, equipamentos e outros. Minha principal meta fornecer subsdios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto.

Por possuir bastante experincia tcnica em modelagem orientada a objetos, e habilidade para atuar como facilitador na absoro das regras de negcio, fui escolhido para ser Arquiteto deste projeto. Serei, portanto, responsvel pela ltima palavra em toda arquitetura do sistema.

Sou um dos Programadores-chefes da nossa equipe e sou responsvel por liderar pequenos grupos de desenvolvedores durante a construo das funcionalidades do produto. Tambm atuo como desenvolvedor e, normalmente, atribuda a mim a propriedade das classes mais complexas do sistema. Possuo, ainda, papel fundamental nas fases de absoro do conhecimento de negcio e no planejamento das funcionalidades.

Como Gerente de Desenvolvimento, sou responsvel por liderar o dia-a-dia do desenvolvimento do produto. Por ser o responsvel por resolver qualquer conflito tcnico que exista entre programadores-chefes, preciso possuir boa experincia no desenvolvimento de software e nas tecnologias que estaro sendo utilizadas no projeto.

Eu sou programadora (class-owner) e sempre estou compondo pequenas equipes de funcionalidades nas quais programo, diagramo, testo e documento as funcionalidades a mim atribudas pelo Programador-chefe da equipe.

A FDD fo rnece, a inda , para aqueles pro je tos ma iores e /ou mais complexos, papis auxiliares, ta is como: Gerente de Release , Testadores, Escrito res

tcnicos, Guru da linguagem, Administrador de Sistema, Implantadores e outros.

O que feature?O que feature?

Features(funcionalidades) so expresses granulares que representem algum valor para o cliente.

Funcionalidades so nomeadas atravs do uso do template

Alguns exemplos de funcionalidades: Calcular o desconto de uma venda

Listar os clientes ativos de uma empresaDestacar os clientes devedores de uma empresa

Imprimir a nota fiscal de uma vendaValidar a senha de um usurio

Enviar e-mail com os resultados mensais de uma empresa

Uma funcionalidade deve ter uma granularidade que noultrapasse o tamanho de sua iterao. Por exemplo,se foi definido que o projeto ter iteraes de2(duas) semanas, voc no deve possuirfuncionalidades que ultrapassem esse tamanho(tempo).Quando isso acontecer, voc deve procurardecomp-la em mais features.

um conjunto de funcionalidades quevoc entregar para seu cliente ao final de

uma iterao(ou release), portanto, noeconomize tempo, ateno e criatividade

no processo de definio das mesmas.

O ciclo de vidaO ciclo de vida da FDDda FDDO ciclo de vida da FDD composto de 05(cinco) prticas. So elas:

1. Desenvolver um modelo abrangenteEste processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time de modelagem: este time normalmente composto por especialistas de negcio e programadores, sendo facilitados por um arquiteto com experincia em modelagem.

Conduzir o Domain Walkthrough(Estudo dirigido sobre o domnio): os especialistas de negcio apresentaro ao restante da equipe uma viso do produto. Aps isso, realizaro apresentaes focadas em pequenas partes do negcio.

Estudar documentao: Dependendo da complexidade da rea de negcio apresentada, a equipe pode solicitar um intervalo para estudar a documentao fornecida pelo especialista de negcio.

Desenvolver modelos de pequenos grupos: aps cada apresentao(ou estudo), a equipe dividida em pequenos grupos, que elaboraro uma proposta de modelo(sem detalhamento) para aquela parte especfica do negcio que foi apresentada.

Desenvolver o modelo da equipe: as propostas so apresentadas e uma delas, ou uma combinao delas, escolhida por consenso para ser o modelo para aquela parte do negcio apresentada.

Refinar o modelo abrangente: o modelo escolhido incluso no modelo abrangente do produto. Este modelo abrangente o resultado da juno de todos os modelos escolhidos para cada parte do negcio apresentada.

Escrever notas: notas e observaes so includas no modelo abrangente.

As atividades vo se repetindo at que tenhamos um modelo abrangente que cubra todas as partes de negcio previstas para o produto(ou release).

2. Construir a lista de funcionalidadesEste processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time da lista de funcionalidades: normalmente, este time composto unicamente pelos programadores-chefes que participaram do processo anterior.

Construir a lista de funcionalidades: as partes do produto, que foram identificadas e modeladas no processo anterior, so aqui identificadas como reas de negcio. Dentro de cada rea de

negcio, o time deve conseguir identificar as atividades de negcio daquela rea especfica e, dentro destas atividades, as funcionalidades que a compem.

3. Planejar por funcionalidadesEste processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time de planejamento: normalmente este time composto pelo gerente de projeto, gerente de desenvolvimento e programadores-chefes.

Determinar a sequncia do desenvolvimento: o time determina a seqncia do desenvolvimento baseando-se nas dependncias entre elas, na carga de trabalho da equipe de desenvolvimento e tambm na complexidade das funcionalidades a serem implementadas.

Atribuir atividades de negcio aos programadores-chefes: cada programador-chefe fica responsvel por um conjunto de atividades de negcio. Ele ser o programador-chefe de todas as funcionalidades que compem suas atividades.

Atribuir classes aos desenvolvedores: cada classe passar a ter um dono. Este dono, que um programador, ser o responsvel por qualquer manuteno necessria naquela classe. As classes so distribudas pelo time levando em considerao a experincia, carga e sequncia de trabalho de cada desenvolvedor.

4. Detalhar por funcionalidadeEste processo ser executado uma vez para cada funcionalidade.

Formar a(s) equipe(s) de funcionalidades: sabendo quais as classes que sero envolvidas no desenvolvimento de determinada funcionalidade, o programador-chefe convoca os desenvolvedores responsveis por cada classe envolvida para fazer parte da equipe.

Conduzir Domain Walkthrough(Estudo dirigido sobre o domnio): dependendo do nvel de complexidade da funcionalidade e de quo clara ela est para a equipe, o programador-chefe pode convocar um especialista de negcio para promover uma apresentao detalhada daquela funcionalidade para a equipe.

Estudar documentao relacionada: ainda dependendo do nvel de entendimento do time, pode ser reservado um perodo para ser estudada documentao de negcio e anotaes relacionadas quela funcionalidade.

Desenvolver diagrama(s) de sequncia: o time desenvolve o(s) diagrama(s) de sequncia relacionado(s) quela funcionalidade.

Refinar o modelo abrangente: j com um maior entendimento do negcio, o time se sente seguro em refinar o modelo abrangente, incluindo mtodos e atributos nas classes envolvidas no desenvolvimento da funcionalidade.

Escrever prlogo de mtodos e classes: Com as informaes geradas pelo(s) diagrama(s) de sequncia, cada programador responsvel por criar os prlogos de suas classes. Isto inclui cabealhos de mtodos com tipagem de parmetros, atributos e outros. Vale lembrar que apenas os prlogos so criados aqui, nada de implementao deve ser realizado.

Inspeo de design: o programador-chefe da funcionalidade deve convidar algum outro membro do time do projeto para avaliar o que foi feito em sua classe durante este processo.

5. Desenvolver por funcionalidadeEste processo ser executado uma vez para cada funcionalidade.

Implementar classes e mtodos: cada desenvolvedor implementa suas classes e mtodos de acordo com a viso abrangente e detalhamento realizados nos processos anteriores.

Inspecionar cdigo: cada desenvolvedor deve convidar algum outro membro do time(da funcionalidade ou do projeto) para avaliar o que foi feito em sua classe durante este processo.

Teste unitrio: cada desenvolvedor responsvel por executar os testes de unidade nos mtodos de suas classes para garantir o alcance das necessidades do negcio.

Promover a build: estando a classe inspecionada e testada, ela ento pode ser promovida a build.

Um projetoUm projeto

A Equipe de Tecnologia da UNITY EVENTOS precisa iniciarum projeto para o desenvolvimento de um sistema quegerencie o processo de realizao e inscrio em eventosrealizados pela empresa.A equipe optou por utilizar a FDD como metodologia,juntamente com o ferramental de desenvolvimento jutilizado pela empresa: Delphi, Together e SQL Server.

A empresa, o projeto.

O time.

unitYeventos

Paulo MartinsGERENTE DE DESENV.

/ PROG. CHEFE

unitYeventos

Carlos JniorPROG. CHEFE

unitYeventos

Paula PimentaPROGRAMADORA

unitYeventos

Mnica SilvaGERENTE DE PROJETO

unitYeventos

Joo MarcosESPECIALISTA DE

NEGCIO

unitYeventos

Thomz BinARQUITETO

unitYeventos

Raimunda LinsESPECIALISTA DE

NEGCIO

unitYeventos

Jos PintadoPROGRAMADOR

unitYeventos

Thiago PiresPROGRAMADOR

Formar o time de modelagem

Conduzir o Domain Walkthrough

Estudar documentao

Processo 1: Desenvolver um modelo abrangente


Como nossa equipe pequena, acredito que possa ser interessante que nosso time de modelagem seja composto por todos os membros do projeto.


NEGCIO

O processo de organizao de um evento sobre o qual explanarei aqui basicamente composto das seguintes etapas: primeiramente definimos o tema e perodo do evento, aps isso realizamos uma tomada de preo em centro de convenes e hotis que possuam auditrio com a capacidade necessria para o evento. A lista de auditrios candidatos realizada a partir de contatos anteriores e lista de pginas amarelas...

>

Thomz BinARQUITETO

Pessoal, como todos decidimos que a equipe necessita de um maior aprofundamento no assunto explanado pela Raimunda, realizaremos uma pausa de 45 minutos para estudarmos a documentao por ela entregue. Vocs podem realizar este estudo aqui mesmo ou em suas mesas, como preferirem. Portanto, s 15:45 retornaremos para iniciarmos o desenvolvimento do modelo.

Desenvolver modelos de pequenos grupos

Agora, com um conhecimento mais abrangente sobre a organizao de um evento, vamos nos dividir em grupos para a elaborao de propostas para um modelo do que foi exposto, seguindo o uso da UML em cores. Para isto importante que cada equipe possua programador(es) e especialistas de negcio.


/ PROG. CHEFE



Joo MarcosESPECIALISTA DE

NEGCIO


NEGCIO

Jos PintadoPROGRAMADORThiago PiresPROGRAMADOR

Equipe A Equipe B

Esta a nossa proposta de modelo para a rea de organizao de eventos...


/ PROG. CHEFE


Vejamos agora o nosso modelo...

Bom pessoal, olhando o que cada um dos modelos tinha de bom, e com algumas sugestes minhas, temos aqui o nosso modelo para o processo de organizao de eventos da Unity.

Thomz BinARQUITETO

Refinar o modelo abrangenteAps a explanao de outras reas de negcio, tais como inscrio de congressistas no evento e recrutamento de palestrantes, o modelo abrangente final foi o seguinte:

Formar o time da lista de funcionalidades

Processo 2: Construir a lista de funcionalidades


O time da Lista de Funcionalidades sercomposto pelos dois Programadores-Chefes presentes no primeiro processo.


/ PROG. CHEFE

Construir a lista de funcionalidades

Formar o time de planejamento


Paulo, nessa fase precisaremos identificar o conjunto de funcionalidades usando o conhecimento adquirido na Fase 1. Precisaremos identificar as reas de Negcio apresentadas. Depois estas reas sero decompostas em reas de atividades de negcio, que, por sua vez, sero decompostas em funcionalidade. Estas funcionalidades so granulares e criadas a partir do template:


/ PROG. CHEFE


/ PROG. CHEFE

O time de Planejamento ser formado pelo gerente de desenvolvimento, pelos programadores-chefes e pelo cliente (interno ou externo).

Processo 3: Planejar por funcionalidades

Determinar a sequncia do desenvolvimentoEsta sequncia baseada em:

- Dependncia entre as funcionalidades em termos de classes envolvidas;- Distribuio de carga de trabalho entre os proprietrios das classes;- Complexidade das funcionalidades a serem implementadas;- Adiantamento das atividades de negcio de alto risco ou complexidades;- Prioridade do cliente;

Eu preciso que a parte de organizao do evento esteja disponvel o quanto antes, sendo que a montagem da grade de palestras pode ficar mais para frente. Outra atividade que tambm de extrema importncia a de inscrio dos congressistas, pois assim que a organizao do evento tiver sido finalizada, iniciaremos as inscries.

Ok! Baseando-se ento nesta sua priorizao, analisaremos a dependncia das classes, carga de trabalho e complexidade, para definirmos a sequncia de desenvolvimento.



NEGCIO

Atribuir atividades de negcio aos programadores-chefes

Atribuir classes aos programadores

Formar o time da funcionalidade

Como Carlos chegou a esses nomes para o time desta funcionalidade? Simples! Verificando as classes que seriam envolvidas na funcionalidade e verificando seus respectivos proprietrios.

Conduzir o Domain WalkthroughO Especialista do Negcio apresenta ao time da funcionalidade, uma viso mais detalhada da rea de domnio a ser projetada.

Processo 4: Detalhar por funcionalidade


O time da funcionalidade Registra informaes de um auditrio ser composto por:




NEGCIO



>

Estudar documentao relacionadaA equipe da funcionalidade estuda o(s) documento(s) de referncia. Desenhos de telas, memorandos, especificaes de interface, e qualquer outra documentao considerada importante para um bom planejamento da funcionalidade.

Desenvolver diagrama(s) de sequncia(s)

Refinar o modelo abrangente

Escrever prlogo de mtodos e classes

Inspeo de design

O time da funcionalidade mantido para agora, aps detalhar e planejar o seu desenvolvimento, partir para a sua codificao.

Implementar classes e mtodosOs proprietrios de classes implementam os tens necessrios para satisfazer os requisitos de suas classes para esta funcionalidade.


Paula, voc poderia por favor realizar a inspeo de design

da feature Registrar Informaes de um

Auditrio?Carlos JniorPROG. CHEFE

Processo 5: Desenvolver por funcionalidade


Teste de unidadeUtilizando recurso da prpria ferramenta de desenvolvimento adotada, o time realiza teste de unidade em todos os mtodos implementados para esta funcionalidade. A poltica de teste de unidade, ou seja, por quem ser realizado e em que exato momento, deve ser definida pelo programador-chefe da funcionalidade.

Inspecionar cdigo Seguindo o mesmo mecanismo utilizado na inspeo de design, o programador-chefe solicita que um outro programador, ou mesmo um outro programador-chefe, inspecione todo o cdigo implementado para esta funcionalidade.

Promover a build



Este o momento de integrar todas as classes e mtodos desenvolvidos para esta funcionalidade.



DONE!

Aps a promoo a build de uma funcionalidade(ou pacote de funcionalidades), os processos 4 e 5 vo sendo repetidos para cada nova funcionalidade(ou pacote) prevista para a iterao corrente.Ao final de cada iterao, a lista de funcionalidades(backlog) deve ser revisada, quando ento podero ser adicionadas ou removidas novas funcionalidades na lista.

Visibilidade gerencial


Durante todos os releases e iteraes do projeto, eu, como gerente de projeto, tenho que possuir mecanismos para visualizar o andamento das atividades, ou melhor, das funcionalidades. Consigo isto atravs do Parking Lot, um dos principais grficos gerenciais da FDD.

Seqncia do projeto

Dvidas freqentesDvidas freqentesExistem ferramentas disponveis para FDD?Sim, existem vrias ferramentas especficas para o uso dos processos da FDD, dentre elas podemos citar: FDDTracker(www.fddtracker.com) e FDDTools(fddtools.sourceforge.net) como as principais, sendo que a primeira ideal para quem precisa de uma ferramenta mais abrangente, e a segunda para quem quer apenas controlar as funcionalidades do projeto e visualiz-las atravs do Parking Lot. Ferramentas de grandes fornecedores, como o Caliber da Borland e o RequisitePro da IBM/Rational, tambm suportam as funcionalidades da FDD, mas sem seus recursos especficos. J o Visual Studio Team System, da Microsoft, possui um plug-in especfico para FDD que foi desenvolvido por uma empresa indiana chamada Cognizant (www.cognizant.com).Vale ainda frisar que, com simples planilhas eletrnicas ou mesmo post-its, voc consegue sem muitas complicaes montar um ambiente para completo acompanhamento de projetos FDD.

Posso utilizar FDD em conjunto com outra metodologia?O uso da FDD em conjunto com alguma metodologia de gerenciamento de projeto muito comum. Como exemplo podemos citar a dobrinha Scrum/FDD que, sendo bem planejada, pode ser de grande valia para seus projetos de software.

Na FDD, como tratado o processo de levantamento de requisitos?A FDD pressupe que, ao entrar na fase de desenvolvimento do modelo abrangente, voc j tenha em mos os requisitos do seu projeto, sejam eles use-cases, storys ou qualquer outra coisa. Portanto, a FDD considera que o processo de levantamento de requisitos deva ser executado antes de voc entrar nas prticas de engenharia, ou seja, antes de entrar na FDD. No post FDD e requisitos (www.axmagno.com) comento mais sobre este assunto.

Posso utilizar FDD em projetos relacionais, ou seja, sem nenhum uso de orientao a objetos?Apesar da documentao da FDD ser sempre recheada das palavras classes, objetos e diagramas, nada nos impede de utiliz-la em projetos relacionais/procedurais. Uma vez que voc considere o modelo abrangente da Fase 1 como um MER ao invs de um diagrama de classes, todas as prticas seguintes sero aplicadas a ele. David Anderson fala sobre um projeto relacional onde aplicou FDD no post FDD in non-OO projects em www.agilemanagement.net. Em breve devo estar escrevendo algo sobre a minha experincia neste tipo de projeto aqui mesmo em www.axmagno.com.

Como est sendo o uso da FDD pelo mundo?A Trail Ridge Consulting realizou uma pesquisa sobre o uso de prticas geis em projetos de software pelo mundo. Nela podemos perceber que a FDD, juntamente com a Extreme Programming so as duas metodologias geis para a engenharia de software de maior destaque. A Heptagon disponibilizou em uma verso em portugus desta pesquisa em seu site www.heptagon.com.br, Vale a pena dar uma conferida nos resultados.

Como fao estimativas em FDD?A FDD no define uma prtica oficial para estimativas. No livro Agile Management for Software Engineer, David Anderson sugere uma tabela de medidas no-lineares, baseadas em um certo grau de dificuldade para serem utilizadas em projetos FDD que faam uso dos arqutipos de Peter Coad, mas apenas uma sugesto.Com o uso do Scrum em conjunto com a FDD, a prtica do Planning Poker para definir o tamanho das funcionalidades pode ser uma boa opo, sendo esta a minha prtica preferida.

Ao utilizar FDD sou obrigado a utilizar UML em cores?No. O modelo abrangente da FDD pode ser tranquilamente desenvolvido fazendo o uso da UML padro, ou como j citei anteriormente do modelo entidade/relacionamento. No entanto, no podemos deixar de frisar que os arqutipos da UML em cores funcionam muito bem para projetos FDD e, na minha opinio, sempre que possvel devem ser utilizados.

Onde consigo mais informaes sobre FDD?aXmagno: www.axmagno.comHeptagon: www.heptagon.com.brNebulon Jeff De Luca: www.nebulon.comFDD Oficial Site: www.featuredrivendevelopment.comDavid Anderson: www.agilemanagement.netStephen Palmer: www.step-10.comGrupo de Usurios da FDD: http://br.groups.yahoo.com/group/gufdd

Sobre o autorSobre o autor

Alexandre Magno Figueiredo vive em So Paulo -SP, onde trabalha como consultor em liderana e gerenciamento de projetos de software atravs do uso de metodologias e processos geis, principalmente FDD e Scrum. Atua na rea de software h mais de 14 anos, j tendo participado de projetos de variadas dimenses de lead time, escopo e investimento. Certified Scrum Master, possuindo ainda certificaes dos fornecedores IBM e Borland, e dos grupos OMG e PMI. Pode ser encontrado em [email protected] ou no Palestra Itlia assistindo aos jogos do Palmeiras.

Documents

FDD Em Uma Casca de Banana