FDD: Um Método Ágil e Eficiente
Neste post vim falar um pouco mais de FDD, que além de ser um método ágil tem uma grande eficiência e aderência a requisitos. Vou dar uma visão geral de como o método funciona e como podemos mixar o método com outro método ágil chamado de Scrum.
Se você quiser saber mais sobre Scrum, pode ler outros posts que tenho sobre o assunto a baixo:
O FDD foi criado por Jeff De Lucca em 1997. FDD é um método que prega a visibilidade do estado projeto de forma consistente e honesta. Você consegue saber quantas funcionalidades já foram desenvolvidas e quantas faltam ser desenvolvidas por que tudo é orientado as funcionalidade.
O FDD ajuda muito a você organizar as suas entregas, o FDD funciona muito bem por que ajuda usando as boas práticas de gerência de configuração como plano de release, plano de deploy e outras práticas ágeis como build continuo e foco em testes.
Visão Geral
Visão Geral do FDD
Nota: Quando falo de deploy freqüente ou diário em produção, me refiro a quando isso é possível, não estou dizendo para você pular testes nem bypassar seu SQA. Mas se você puder fazer um deploy todo o dia melhor, isso será bom para todo mundo.
Medindo Progresso com o FDD
Essa medição se dá através de um cartão que representa a funcionalidade, você pode fazer isso com um post-it semelhante ao da figura a baixo, essa não é um funcionalidade pura e já fiz uma mix com o Scrum:
Tracking de Funcionalidades com o FDD
Na figura a cima existem as funcionalidades tradicionais do FDD, mas existe um mix que fiz com o Scrum também. Vamos por parte primeira ao FDD e as modificações que fiz. A cor amarela significa que a Feature está em andamento, em verde significa que já foi concluída e rosa significa que a funcionalidade está atrasada. Usei essas cores por que são as cores básicas dos post-its em se quiser você fazer tudo isso com post-its.
Outro mix válido é mixar o FDD com o Kanban, assim as atividades de planejamento, revisão, design, revisão, construção, revisão e deploy do FDD podem ser colocadas em um pipeline. Para facilitar a sua vida com post-it você pode deixar só para desenhar a barra de progresso ou então considere que a funcionalidade é o item do scrum e continuar quebrando a feature em tarefas, mas vá movendo o progresso só da feature e use o Tasks/W.I.P/Done do Scrum Tradicional.
Os números dos cartões de funcionalidades são o seguinte, vou explicar da esquerda para a direita de cima para baixo. O primeiro número é o identificador único da funcionalidade, esse pode ser o mesmo número que você tem no backlog do Scrum ou até mesmo o número de um ticket da sua ferramenta de tracking.
O número do meio é a pontuação do Scrum, onde está pontuado a complexidade de desenvolver essa funcionalidade. E o terceiro número bem a direita é a prioridade da feature que é dada pelo dono do produto. Você pode jogar o post-it fora para mudar a cor ou pode pintá-lo,outra abordagem para quem não usa um dashboard seria fazer isso em uma planilha excel, é uma boa mas eu prefiro as coisas feitas a mão por que elas favorecem a colaboração.
Quando atualizar o progresso?
Para mim o momento ideal é quando estamos fazendo as reuniões de pé. Todo o dia você pode atualizar o progresso de todas as funcionalidades em desenvolvimento no dashboard ou em sua planilha, assim todos vão saber do andamento das funcionalidades, esse mix com o Scrum é muito benéfico pois o scrum dá um framework geral e com o FDD colocamos algumas coisas especificas.
As Revisões
O FDD enfatiza a prática de revisão tanto de código como de projeto, isso é muito bom e contribui para a evolução da qualidade do produto. Aqui o FDD pode se juntar com diversas práticas da Garantia da Qualidade de Software.
O FDD é um método que prove muitas cosias legais em torno de funcionalidades, mas isso não elimina outras necessidades, em um projeto é muito saudável misturar FDD com outros métodos como Scrum, XP, RUP e OpenUP. Misturas com Kanban também são bem vindas e podem melhorar mais ainda a visibilidade e facilitar a visualização do status do projeto.
Se vocês quiserem mais informações sobre o FDD confiram neste site aqui, aqui e aqui.
Abraços e até a próxima.
Se você quiser saber mais sobre Scrum, pode ler outros posts que tenho sobre o assunto a baixo:
- Scrum
- O que faz a diferença usando XP, Rup, Scrum ?
- Scrum não substitui gerenciamento de projetos
- Estimando com Scrum
- Gerenciamento de Níveis com Scrum e RUP parte 1
- Gerenciamento de Níveis com Scrum e RUP parte 2
- O Melhor do Scrum
O FDD foi criado por Jeff De Lucca em 1997. FDD é um método que prega a visibilidade do estado projeto de forma consistente e honesta. Você consegue saber quantas funcionalidades já foram desenvolvidas e quantas faltam ser desenvolvidas por que tudo é orientado as funcionalidade.
O FDD ajuda muito a você organizar as suas entregas, o FDD funciona muito bem por que ajuda usando as boas práticas de gerência de configuração como plano de release, plano de deploy e outras práticas ágeis como build continuo e foco em testes.
Visão Geral
Visão Geral do FDDO FDD tem duas fases basicamente a fase de Concepção e Planejamento e a fase de Construção, por ser simples e objetivo o FDD pode ser uma excelente solução para projetos de manutenção.
Na fase concepção acontece a triagem de requisitos, você ainda pode usar as técnicas tradicionais da Engenharia de Requisitos mas focando em funcionalidades, é perfeitamente viável essa abordagem. De inicio você tem que desenvolver um modelo abrangente isso é legal por que nesse ponto começar a se mixar o FDD com as práticas de OOAD e UML em Cores.
No modelo abrangente o foco está mais na forma do que no conteúdo, isso é bom por vários motivos, primeiro que é um incentivo para que você não faça um big design up to front e também não comece a querer fazer toda a arquitetura de uma vez só, esse é um bom ponto de interação do design com a arquitetura também.
Com isso você tem insumos para a geração da lista de features, que pode ser o seu backlog que você usa Scrum, logo você pode manter isso em uma boa planilha excel. Esse trabalho permite que você faça um planejamento por features que pode ocorrer em uma reunião de planejamento do Scrum, com as práticas do Scrum logo você consegue saber quantas funcionalidades por sprint você é capaz de desenvolver.
Na fase de construção existe um detalhamento por funcionalidade, nesse ponto que você vai especificar mais o que deve ser feito, acho plausível se você sentir necessidade, usar estórias do usuário do XP.
Neste ponto você constrói por funcionalidade, e o progresso é medido por funcionalidade, a cada funcionalidade feia se você quiser pode coloca-la em produção, eu recomendo, o Flckr por exemplo tem deploys em produção diariamente, deploy mais freqüentes são melhores para o negócio, quanto mais melhor.
Na fase concepção acontece a triagem de requisitos, você ainda pode usar as técnicas tradicionais da Engenharia de Requisitos mas focando em funcionalidades, é perfeitamente viável essa abordagem. De inicio você tem que desenvolver um modelo abrangente isso é legal por que nesse ponto começar a se mixar o FDD com as práticas de OOAD e UML em Cores.
No modelo abrangente o foco está mais na forma do que no conteúdo, isso é bom por vários motivos, primeiro que é um incentivo para que você não faça um big design up to front e também não comece a querer fazer toda a arquitetura de uma vez só, esse é um bom ponto de interação do design com a arquitetura também.
Com isso você tem insumos para a geração da lista de features, que pode ser o seu backlog que você usa Scrum, logo você pode manter isso em uma boa planilha excel. Esse trabalho permite que você faça um planejamento por features que pode ocorrer em uma reunião de planejamento do Scrum, com as práticas do Scrum logo você consegue saber quantas funcionalidades por sprint você é capaz de desenvolver.
Na fase de construção existe um detalhamento por funcionalidade, nesse ponto que você vai especificar mais o que deve ser feito, acho plausível se você sentir necessidade, usar estórias do usuário do XP.
Neste ponto você constrói por funcionalidade, e o progresso é medido por funcionalidade, a cada funcionalidade feia se você quiser pode coloca-la em produção, eu recomendo, o Flckr por exemplo tem deploys em produção diariamente, deploy mais freqüentes são melhores para o negócio, quanto mais melhor.
Nota: Quando falo de deploy freqüente ou diário em produção, me refiro a quando isso é possível, não estou dizendo para você pular testes nem bypassar seu SQA. Mas se você puder fazer um deploy todo o dia melhor, isso será bom para todo mundo.
Medindo Progresso com o FDD
Essa medição se dá através de um cartão que representa a funcionalidade, você pode fazer isso com um post-it semelhante ao da figura a baixo, essa não é um funcionalidade pura e já fiz uma mix com o Scrum:
Tracking de Funcionalidades com o FDDNa figura a cima existem as funcionalidades tradicionais do FDD, mas existe um mix que fiz com o Scrum também. Vamos por parte primeira ao FDD e as modificações que fiz. A cor amarela significa que a Feature está em andamento, em verde significa que já foi concluída e rosa significa que a funcionalidade está atrasada. Usei essas cores por que são as cores básicas dos post-its em se quiser você fazer tudo isso com post-its.
Outro mix válido é mixar o FDD com o Kanban, assim as atividades de planejamento, revisão, design, revisão, construção, revisão e deploy do FDD podem ser colocadas em um pipeline. Para facilitar a sua vida com post-it você pode deixar só para desenhar a barra de progresso ou então considere que a funcionalidade é o item do scrum e continuar quebrando a feature em tarefas, mas vá movendo o progresso só da feature e use o Tasks/W.I.P/Done do Scrum Tradicional.
Os números dos cartões de funcionalidades são o seguinte, vou explicar da esquerda para a direita de cima para baixo. O primeiro número é o identificador único da funcionalidade, esse pode ser o mesmo número que você tem no backlog do Scrum ou até mesmo o número de um ticket da sua ferramenta de tracking.
O número do meio é a pontuação do Scrum, onde está pontuado a complexidade de desenvolver essa funcionalidade. E o terceiro número bem a direita é a prioridade da feature que é dada pelo dono do produto. Você pode jogar o post-it fora para mudar a cor ou pode pintá-lo,outra abordagem para quem não usa um dashboard seria fazer isso em uma planilha excel, é uma boa mas eu prefiro as coisas feitas a mão por que elas favorecem a colaboração.
Quando atualizar o progresso?
As Revisões
O FDD enfatiza a prática de revisão tanto de código como de projeto, isso é muito bom e contribui para a evolução da qualidade do produto. Aqui o FDD pode se juntar com diversas práticas da Garantia da Qualidade de Software.
O FDD é um método que prove muitas cosias legais em torno de funcionalidades, mas isso não elimina outras necessidades, em um projeto é muito saudável misturar FDD com outros métodos como Scrum, XP, RUP e OpenUP. Misturas com Kanban também são bem vindas e podem melhorar mais ainda a visibilidade e facilitar a visualização do status do projeto.
Se vocês quiserem mais informações sobre o FDD confiram neste site aqui, aqui e aqui.
Abraços e até a próxima.
