sexta-feira, setembro 29, 2006

Apresentando...FDD!

A FDD(Feature-Driven Development) é uma metodologia de desenvolvimento de software que, seguindo os princípios propostos pelo Manifesto Ágil, fornece processos para a distribuição repetível de software com valor para o cliente.

Com surgiu a FDD?
Ela surgiu no ano de 1997 quando Peter Coad e Jeff De Luca foram contratados para salvar um projeto bancário em Singapura. Reunindo experiências anteriores, eles chegaram ao que hoje é a FDD, esse mesmo projeto deu ainda origem à técnica de modelagem da UML em cores. Após pouco mais de um ano, o projeto estava salvo, tendo mais de 2.000 features (funcionalidades) desenvolvidas por uma equipe de 50 pessoas.

Identificando a FDD
A FDD possui características marcantes, entre elas podemos citar a importância que é dada para a qualidade das funcionalidades entregues ao cliente, através de práticas como a inspeção de modelo e de código. Outra característica não menos importante é a de priorizar a entrega de resultados frequentes, tangíveis e funcionais para os clientes, através do trabalho dividido em iterações, o que aliás é uma prática muito usada no mundo do desenvolvimento ágil. Relatórios de estado e progresso das atividades (como o famoso Parking Lot), adaptabilidade para projetos e equipes maiores ou menores, e um desenvolvimento partindo de um modelo abrangente são outras fortes características da FDD.

FDD significa Desenvolvimento Dirigido à Funcionalidades, mas...o que é uma funcionalidade?
É alguma característica do sistema que ofereça valor para o cliente e que possa ser desenvolvida em, no máximo, duas semanas. Para os mais experientes, uma funcionalidade pode ser comparada a um requisito funcional.
O template de uma funcionalidade é: [ação] [resultado] [objeto]
Alguns exemplos de funcionalidades: Calcular o desconto de uma venda, Validar o CPF de um cliente, Ordenar por Cidade e UF o relatório de clientes,...

Boas práticas da FDD
As principais práticas da FDD são as seguintes:
- Modelagem de objetos do domínio (negócio);
- Desenvolvimento por funcionalidade;
- Posse individual de classe (código);
- Time de funcionalidades;
- Inspeções de modelo e de código;
- Builds regulares;
- Gerenciamento de configuração;
- Relatório/visibilidade de resultados;

Os papéis da FDD
Os principais papéis que são definidos na FDD são os seguintes:
- Gerente de Projeto
- Gerente de Desenvolvimento
- Arquiteto-chefe
- Programadores-chefe
- Proprietários de código/classe (Desenvolvedores)
- Especialistas do domínio(negócio)
Em projetos maiores e que possuam tal necessidade, outros papéis podem ser incluidos no projeto, tais como:
- Gerente de Versão
- Guru da Linguagem
- Criador de Ferramentas
- Testadores
- Implantadores
- Redator Técnico
É importante ressaltar que é permitida, e comumente realizada, a atribuição de mais de um papel no projeto para a mesma pessoa.

Conhecendo os processos da FDD
A FDD é dividade em 5 processos que descrevo a seguir.

Processo 1: Desenvolvendo um Modelo Abrangente
Neste processo realizaremos um estudo dirigido sobre o escopo do projeto(e integrações) e seu contexto. Então, são realizados estudos mais detalhados sobre o domínio do negócio para cada área do produto(e integrações) a ser modelada. As atividades são realizadas em reuniões de domínio, executadas sequencialmente com a participação dos especialistas de negócio, programadores-chefes e arquiteo-chefe; eventualmente a participação do gerente do projeto pode ser considerada. Essas reuniões devem ser realizadas em ambiente isolado e confortável de forma a não torná-las excessivamente cansativas.

Processo 2: Construindo uma Lista de Funcionalidades
Processo realizado geralmente pelos programadores-chefes do processo nº 1, com o intuito de decompor funcionalmente o domínio(negócio) em áreas de negócio, atividades de negócio e funcionalidades.

Processo 3: Planejando por Funcionalidade
Este processo tem como finalidade produzir o plano de desenvolvimento. Gerente de projeto e programadores-chefes planejam, ordenam e estimam as funcionalidades que serão implementadas, baseando-se em dependências, carga de trabalho da equipe e complexidade.

Processo 4: Detalhando por Funcionalidade
Este processo é realizado uma vez para cada funcionalidade. O programador-chefe identifica os proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no desenvolvimento da funcionalidade que ele selecionou. Esta equipe produz o(s) diagrama(s) de sequência para a(s) funcionalidade(s) atribuída(s). O programador-chefe, então, refina o modelo de objetos, baseando-se no conteúdo do(s) digrama(s) de sequência. Os desenvolvedores escrevem os prefácios das classes e
métodos. Realiza-se uma inspeção no projeto.

Processo 5: Construindo por Funcionalidade
É uma atividade para cada funcionalidade, para produzir uma função com valor para o cliente (funcionalidade). Começando com o pacote de projeto (design), os proprietários de classes implementam os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção – a ordem aqui é determinada pelo programador-chefe. Após passar pela inspeção, o código é promovido à versão atual (build).

Então verificamos o seguinte, os processos de 1 a 3 serão realizados uma única vez por projeto, mas lembrando que não necessariamente UM projeto é UM produto, podemos dividir a construção de um produto em vários projetos ou termos um projeto para cada versão, por exemplo. Os processos 4 e 5 serão repetidos uma vez para cada funcionalidade, ou seja, se na fase 2 geramos uma lista com 50 funcionalidades, significa que passaremos 50 vezes pela fase 4 e 5.

O que está fora da FDD?
Vale lembrar que a FDD se propõe a ser uma metodologia para DESENVOLVIMENTO DE SOFTWARE, portanto ela prevê boas práticas apenas para esse fim, diferentemente de metodologias que sugerem padrões também para fora do processo de desenvolvimento. Necessidades tais como escolha de tecnologias e ferramentas, definição de interface de usuário, testes de sistema e de carga, obtenção de patrocínio para o projeto, gerenciamento de recursos, conversão de dados, etc. NÃO são cobertas pela FDD.

sexta-feira, setembro 01, 2006

Mostra-me tua equipe, e eu te direi quem és!

Empresas e projetos
O que significa o fracasso de um projeto para uma empresa? De uma forma simplificada poderíamos dizer que significa a perda de dinheiro, reputação e coragem. Dinheiro por motivos óbvios, reputação pelo desgaste que a equipe sofrerá com a queda, e coragem pelo fato de que a alta diretoria da empresa se sentirá apreensiva para investir em próximos projetos. Talvez, por este motivo pudemos perceber que nos últimos anos as companhias tem ficado mais atentas para a prática qualificada do gerenciamento de projetos. Na maioria das verticais de negócio, vemos um crescente investimento na capacitação e qualificação dos gerentes de projetos, mais ainda em ferramentas, metodologias, certificações e outros.
No entanto, no fim de cada projeto, continuamos a assistir o mesmo filme de sempre: “Caça às Bruxas'. Ou foi culpa do gerente, ou da diretoria, ou da falta de um maior investimento, ou dos programadores, ou da inexistência de treinamentos, ou – como é na maioria dos casos – a culpa foi do cliente(interno ou externo), que não sabia exatamente o que queria! (Esse assunto geraria facilmente um novo artigo, mas convido-os a visitar a lista agile-brasil, onde o tema já foi bastante debatido). Enfim, a temporada de caça está aberta, e a pergunta continua sendo a mesma: de quem é a culpa?

Ritual de fim de projeto
A resposta para essa pergunta pode ser obtida facilmente seguindo o seguinte ritual:
1.Convoque todos (exatamente todos) os envolvidos no projeto para uma reunião.
2.Quando todos estiverem presentes, solicite que se levantem e, após o uuumm...doooiss..trêêêss, repitam: A CULPA É NOSSA!
Pronto, a pergunta está respondida.

Onde está a equipe?
A resposta obtida no “ritual” que citei, dificilmente será aceita pela maioria dos participantes da reunião, afinal, se eles não foram uma equipe durante o projeto inteiro, não é agora – hora de encontrar culpados – que se tornarão uma. Mas será que se tivéssemos uma verdadeira equipe o resultado final seria seria diferente? Com certeza! Gerentes de projetos tem começado a perceber repetidamente algo em comum em projetos bem sucedidos: equipes de verdade, e – consequentemente - de alto desempenho. Mas o que é uma equipe de alto desempenho?

Equipes de alto desempenho
Um equipe de alto desempenho é aquela que possui um objetivo bem definido e compartilhado por todos os membros do projeto. É uma equipe onde todos estão entusiasmados com suas atividades, querem vencer juntos. Os membros dessas equipes são criativos e ousados na busca da qualidade, são dedicados, acordam na segunda-feira com vontade de ir para o projeto, pois se divertem no trabalho, e se divertem juntos, querem sempre fazer mais e melhor. Todos querem participar de uma equipe dessa, pois sabem que além de uma experiência profissional inigualável, isso será um divisor de águas na sua carreira.
Agora, quando isso não existe, o que você tem são clientes, diretores, gerentes, analistas, programadores e outros, cada um de um lado, com um “crachá” diferente.

Qual sua missão nesse projeto?
Tive uma experiência no passado, quando estava gerenciando um pequeno projeto que – para a diretoria – não estava gerando os resultados esperados. Quando menciono para a diretoria, é porque para nós – gerente, analistas e programadores – estava tudo aparentemente “nos trilhos”. Mas me frustou ouvir de meu diretor que não, que os resultados que eles precisavam não eram apenas cronograma afinado e resultados aparentes. Fui encorajado por ele a fazer um “acompanhamento” junto à nossa equipe para realizar a seguinte pergunta a todos: “Qual sua missão nesse projeto?”. Enquanto eu realizava esse trabalho pude perceber onde estava o problema e, ao finalizar, cheguei à mesa do diretor e disse: “Você estava certo, temos que mudar algo em nosso time”. O algo a mudar não eram pessoas, ferramentas, métricas ou metodologias, mas sim a forma com a qual a “equipe” enxergava o projeto. No acompanhamento, programadores responderam que sua missão no projeto era “programar”, analistas “analisar e modelar” e por ai vai. Ninguém mencionou palavras relacionadas ao sucesso do projeto, a resultados, ao objetivo maior, ao algo que se busca – aí sim – programando, modelando, gerenciando, etc. Portanto, o projeto estava fadado ao fracasso.

Como formar equipes de alto desempenho?
Uma série de fatores influenciam no sucesso ou fracasso dessas equipes, infelizmente não há uma receita, e é bom que tenhamos em mente que nem sempre isso será possível. Segue algumas atitudes que podem ajudar na formação dessas equipes:
- Siga os valores do manifesto ágil
- Tenha claro os objetivos do projeto. É extremamente importante que a expectativa de todos os envolvidos seja a mesma.
- Valorize a comunicação, montando inclusive um ambiente favorável às conversas espontâneas.
- Providencie recursos, principalmente econômicos, para que a atenção – e preocupação – da equipe esteja focada no projeto.
- Valorize a criação.
- Valorize as opiniões dos membros da equipe.
- Aceite falhas.
- Encoraje a ousadia.
- Torne o trabalho prazeroso e divertido.
- Prefira qualidade à quantidade, ou seja, desenvolver menos com qualidade é melhor que mais sem qualidade.
- Crie um nome, escudo, slogan...enfim, algo que identifique e diferencie a equipe.
- Encoraje os conflitos construtivos.
- Preocupe-se com o objetivo coletivo e não individual.