quarta-feira, dezembro 06, 2006

Avaliando o FDD Manager

Tenho que confessar que meu primeiro projeto utilizando FDD teve todos seus relatórios gerados no word e, principalmente, num quadro branco. Não, eu não sou mais um daqueles "tool killers" que pregam que "quem é bom mesmo não precisa de ferramenta", pelo contrário, sempre que possível procuro estar bem "armado" nos projetos que tenho que liderar, e por esse motivo, recentemente tive minha primeira experiência com o FDDManager. Procurarei então aqui passar minhas impressões finais sobre o produto.

Configuração
O produto permite que você defina os membros de sua equipe e seus respectivos papéis, os releases e iterações previstos. As Áreas e Atividades de Negócio e suas funcionalidades também podem ser configuradas e inclusas em determinado release e iteração. Um ponto fraco é que uma funcionalidade só pode ser atribuída a um
class-owner, o que dificulta a formação dos feature-team.

Gerenciamento
A parte gerencial do produto ainda deixa a desejar. Na verdade, se comparado ao uso de planilhas e documentos, o gerenciamento é até satisfatório, mas como sempre esperamos um "algo mais" de tudo, não perca seu tempo, pois aqui ele não existe.
O controle de tarefas e datas é realizado automaticamente, portanto, se uma determinada tarefa atrasar, a ferramenta gerencia isso e tornará esse atraso visível em todos os relatórios e consultas que possam ser gerados. Mas infelizmente o gerenciamento para por aí. Reagendar tarefas, transferir funcionalidades entre iterações e/ou releases, gerenciar utilização de recurso...tudo isso e muito mais continuará a ter que ser feito manualmente, e muitas vezes acaba dando mais trabalho do que fazer no quadro-branco.
















Relatórios
Esse é o ponto forte do produto, a ferramenta gera relatório para todos os gostos e necessidades. Seja você programador, analista, coordenador, gerente, diretor ou presidente...com certeza aqui terá um tipo de relatório que se adeque a sua visualização. Os tipos oferecidos são:

- Detalhes do Projeto
- Lista de Funcionalidades com anotações
- Detalhes de Estimativas
- Plan View
- Plan View por release
- Plan View por class-owner
- Atividades de negócio por release
- Funcionalidades atrasadas por desenvolvedor
- Parking Lot
- Cumulative Feature Status















Todos eles podem ser gerados em formato pdf e html, sendo que o Parking Lot possui ainda uma visualização à parte, sem a necessidade de gerar o relatório.

Resumindo
A utilidade da ferramenta vai depender unicamente da sua necessidade. Se a sua necessidade for sair das planilhas e documentos e ter algo mais prático para gerenciar seus projetos FDD, com certeza o FDD Manager será de grande valia para
você. Mas se você procura algo mais abrangente e integrado com outras ferramentas e atividades, e que possa lhe dar um desk mais amplo de gerenciamento, infelizmente o produto não lhe atenderá.
Por fim, o FDD Manager pode ainda ser utilizando para "vender" a FDD em sua empresa pois, pelo fato de ser bem focado na metodologia e automatizar a geração de resultados, ele acaba sendo um grande aliado para esta tarefa.

Link
www.fddmanager.com

quinta-feira, outubro 19, 2006

Supere o medo e viva, ou opte por "sobreviver"...

Pessoas são difíceis
Acho que há mais de 10 anos escuto repetidamente a frase "Pessoas são difíceis!", e isso todos nós sabemos, então por que temos que ficar repetindo? Para justificar nossos fracassos? A questão hoje deveria ser mais na linha de "O que me torna uma pessoa difícil?", ou, "O que posso fazer para ser uma pessoa mais fácil?". Não tenho aqui a pretensão de responder essas perguntas, mas através do que tenho observado em equipes com as quais trabalhei nos últimos anos, e mesmo em pessoas do meu convívio, acho que tenho pistas para o caminho de respondê-las, pelo menos para o lado profissional das pessoas.

Uma simples pergunta
Há poucos dias, em uma conversa de boteco, um colega me perguntou: -Alexandre, se você não fosse da área de software, o que você faria? Duas atividades que gosto muito de fazer passaram imediatamente pela minha cabeça, então respondi: - Lecionaria ou escreveria! Ele disse: -Tudo bem, mas em que área, sobre o que lecionaria ou escreveria? Fui tomado por uma sensação diferente, algumas coisas da adolescência me vieram à cabeça: seria um surfista profissional, um vocalista de uma banda de rock, um repórter do National Geographic, enfim...essas coisas que passam na nossa cabeça nessa fase da vida. Por fim, tive que me contentar em responder algo que não gostei nem um pouco de dizer: - Definitivamente, não sei!

Uma noite sem dormir
Como tenho trabalhado muito com pessoas nestes últimos anos, tenho procurado estudar e refletir muito sobre este polêmico tema. Aquela conversa de boteco não saía da minha cabeça, eu não conseguia mesmo imaginar o que eu poderia fazer fora da minha profissão...conseguia ver várias coisas que eu não gostaria de fazer e, o que não é novidade nenhuma para quem me conhece, a última coisa que eu gostaria de fazer seria trabalhar no funcionalismo público. Por fim, me contentei em ficar sem resposta, e agradecer a Deus por, logo aos meus 15 anos de idade, ter me colocado nesta área que, definitivamente, mudaria a minha vida, e então, meio sem querer, cheguei ao ponto: Quantas pessoas neste mundo tiveram a sorte que eu tive? De, desde novo, se identificar por inteiro com uma carreira? Definitivamente, são poucos!

Uma outra pergunta
"Como eu seria se, ao invés de atuar na minha carreira, atuasse em uma outra qualquer?" Bem, com certeza eu seria um profissional menos apaixonado, estudaria menos - ou como é na maioria desses casos - não estudaria, consequentemente seria menos competente - pois para mim estudo e competência estão diretamente ligados - enfim...seria com certeza uma pessoa mais difícil no meu ambiente de trabalho. Vale ressaltar que, quando eu digo pessoa difícil, não estou me referindo unicamente às típicas mal-humoradas e ranzinzas, mas também - e talvez principalmente – às pessoas que não conseguem desenvolver seu trabalho com competência, que estão sempre procurando algum "culpado" para algo que deu errado, atrapalhando a produtividade de um grupo. Por um momento me imaginei, sentado atrás de uma escrivaninha com plaquinha de metal escrita "Patrimônio do Estado", cheia de carimbos e almofadas, e papéis..muitos papéis, ao lado um grupinho de pessoas "conversando" sobre quando o governo iria dar um novo "reajuste salarial", aaarrgghhhhhh!! É, com certeza eu seria uma pessoa mais difícil.

A chave
Então, reunindo as idéias: "Pessoas são mais difíceis no trabalho quando atuam em algo que não lhes dá prazer". Levando o pensamento adiante, e esquecendo um pouco o foco, lembrei de quantas pessoas devem me achar louco quando digo que tenho prazer no meu trabalho, e é importante que se frise que quando digo trabalho não estou me referindo simplesmente a uma empresa, mas sim à carreira. É isso! Quantas pessoas eu conheço que concordam comigo quanto ao prazer em seu trabalho? Uma, duas...meia dúzia. Agora, quantas passam a semana inteira reclamando do seu trabalho? Dez, vinte, trinta...É isso! É por isso que nossos ambientes de trabalho estão infestados de crises, fofocas, reclamações, disputas, ego, etc.

A escolha
Bom, então o problema está na escolha da profissão. Pensei: -Como as pessoas escolhem sua profissão? Na maioria das vezes, influência. Nós, seres humanos, somos naturalmente influenciados, seja na música que ouvimos, no lugar que freqüentamos, no carro que compramos, enfim, quase sempre somos influenciados por algo ou por alguém. Isso pode ser bom, desde que saibamos avaliar até onde aquilo está sendo escolhido para atingir um objetivo próprio, e até onde para atender à expectativa de alguém. Ronald Gross citou com muita sabedoria em À maneira de Sócrates: "Tal como Sócrates, precisamos nos libertar das expectativas dos outros e descobrir por nós mesmos o que efetivamente viemos fazer no mundo".

O medo
Sabemos que nem sempre as influências são as melhores, ou feitas da forma correta, ou mesmo acontecerão. Então muitas pessoas acabam escolhendo uma profissão, carreira, por escolher, ou "porque dá dinheiro", ou sim, achando que é a escolha certa. No entanto, mais na frente, começa a sentir os sintomas da escolha errada, cadê o prazer? E aí já vimos o que acontece, a pessoa passa a se tornar, dia após dia, uma pessoa "mais" difícil. Aí vem a vontade de mudar...mas mudar para onde? para qual caminho? E agora?

Superando o medo
Seria muita pretensão de minha parte querer responder isso. Mas o que penso é que a pessoa, enquanto der - e vamos ser justos - nem sempre dá, não pode desistir de buscar o prazer no trabalho, seja buscando uma carreira em outra área, ou trocando de emprego, sei lá. Tem que superar esse medo de mudanças que nós, humanos, temos. Por quê? Raciocine comigo, um profissional trabalha em média 160 horas por mês, o que equivale a 1.920 horas por ano. Então, levando em consideração uma jornada de 8 horas diárias de trabalho, nós trabalhamos 240 dias por ano. Quer mais? Vamos lá, em 40 anos nós teremos que trabalhar 9.600 dias, isso dá mais de 26 anos de trabalho. Conclusão, um terço de sua vida (em média) será vivida sem prazer, com queixas e reclamações...e pior, esse terço está posicionado exatamente na fase intermediária da vida, que é a qual - teoricamente - estamos mais aptos a aproveitá-la.
Portanto, sugiro que descubra o que profissionalmente lhe dá prazer, se não der, tente descobrir como ter prazer com o que você faz, se não der..."sobreviva" por 26 anos da sua vida e fique rezando para chegar o dia da aposentadoria.

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.

terça-feira, agosto 29, 2006

FDD e requisitos

Em algumas listas/fóruns sobre FDD, nacionais e internacionais, vezes se tem perguntado sobre qual o tratamento dado pela FDD (Feature-Driven Development) aos requisitos de software. Para avaliarmos isso, vamos antes fazer uma rápida revisão sobre os conceitos das disciplinas relacionadas aos requisitos, que são definidas pela Engenharia de Requisitos. De acordo com o SEI, no CMMI for Development 1.2, o propósito do Desenvolvimento de Requisitos é produzir e analisar requisitos para clientes, produtos e componentes de produtos, enquanto o do Gerenciamento de Requisitos é gerenciar os requisitos de projetos e produtos e identificar inconsistências entres esses requisitos e os planos dos projetos. Dentro destas disciplinas temos os seguintes tipos de requisitos:
1. Requisitos de Negócio: Expressa "por que" estamos fazendo esse sistema.
2. Requisitos de Usuário: Expressa "quem" faz "o que" no sistema.
3. Requisitos Funcionais: Expressa "como" o sistema atende aos requisitos de usuário.
4. Requisitos Não-Funcionais: Expressa expectativas quanto a funcionalidade do sistema(performance, amigabilidade, escalabilidade, portabilidade, etc.)

Para quem conhece o conceito de features da FDD, percebe que elas são requisitos funcionais. Sendo assim podemos afirmar que tais requisitos emergem nas fases 01(Develop Overall Model) e 02(Build Feature List) e são detalhados(quando necessário) na fase 04(Design By Feature) do ciclo da FDD. Outros tipos de requisitos devem ser desenvolvidos (e gerenciados) fora do ciclo do FDD, servindo então de matéria-prima para as fases. Portanto, se você gosta de escrever use cases (ou outro formato de requisitos de usuário) e entende que seu uso é válido para o projeto em questão, vá em frente! No entanto não inclua esta tarefa em nenhuma das fases da FDD, o seu uso no ciclo será como documentação de estudo para a tarefa Study Documents, presente nas fases 01(Develop Overall Model) e 04(Design By Feature).