FDD, User Stories e Boards na Engenharia de Requisitos

Olá caros, tudo bom?

Hoje vou falar sobre junções de técnicas de diferentes métodos que auxiliam na Engenharia de Requisitos. Venho usando essa junção há algum tempo e obtendo bons resultados.

Vamos começar por FDD.

Feature Driven Development é uma metodologia ágil criada por Peter Coad e Jeff de Luca em 1997, utilizada em um projeto de um grande banco em Singapura.

O FDD oferece uma estrutura interessante:

  • DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
  • CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
  • PPF (Planejar por Funcionalidade): Planejamento Incremental
  • DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  • CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos

No passo CLF, eu uso a estratégia criada do modelo ARO para escrever nos Products Backlogs. Vamos conhecer mais sobre o modelo:

<ação> <resultado> <objeto>

Exemplos:

  • <calcular> o <total> de uma <venda>
  • <calcular> a <quantidade total vendida por um varejista> para uma <descrição de produto>.

As funcionalidades são granulares, de acordo com a regra de que uma funcionalidade não levará mais do que duas semanas para ser completada, mas não tão granulares ao nível de “getters” e “setters” (os métodos de acesso aos atributos de uma classe). Duas semanas são um limite superior; a maioria das funcionalidades levam muito menos tempo do que isso. Quando um passo de uma atividade de negócio parece maior do que duas semanas, o passo é quebrado em passos menores, que então tornam-se funcionalidades. by Heptagon

Nos últimos projetos que atuei, construi meu Product Backlog, escrevendo as funcionalidades seguindo a descrição ARO. Interessante informar que, descrevendo deste modo, a percepção inicial sobre a funcionalidade é mais fácil de ser “sacada” pelo Time e também mais fácil de ser descrita pelo P.O (ou o Time do P.O).

Tendo como base que o Product Backlog é uma lista de desejos, acho interessante escrever o desejo no modelo ARO. Quando faço entrevistas com os clientes e usuários, vejo que eles tem uma visão interessante do objetivo que desejam alcançar. O que faço é quebrar estes objetivos em ações menores, e vai ficando fácil enquadar isto numa descrição no modelo ARO.

Em projetos que necessitam de um Pré Planning/Pré Game, popular o Product Backlog desta maneira é interessante pois facilita na explicação para o Time e ajuda-os a estimar. Pensando em Agile, não devemos nos alongar em coisas que não serão feitas agora (foco no ROI). Usando o modelo ARO para compor a lista inicial do Product Backlog ajuda, pois não necessita da mesma profundidade de análise e tempo que uma User Story.

O modelo ARO se mostra indiferente ao tamanho. Você pode usa-lo para descrever Funcionalidades menores (inferiores a duas semanas) ou Épicos. Os exemplos abaixo ilustram isso:

  • calcular o total de uma venda
  • calcular a quantidade total vendida por um varejista para uma descrição de produto.

O primeiro exemplo cai bem num Épico, pois é mais vago, está mais aberto para discussão e entendimento. O segundo exemplo cai bem para uma funcionalidade que está em vias de entrar em uma Sprint, pois já define um papel interessado, um cálculo definido e um objeto mais conciso.

Do FDD, eu também gosto de usar a Feature Breakdown Structure. A FBS é um modelo de estruturação de funcionalidades, igual a WBS.

A FBS é uma forma visual e interessante de modelar suas funcionalidades de acordo com a Modelagem de Negócios do Produto/Empresa.

A utilização dos conceitos de Funcionalidade do FDD e a FBS são de grande ajuda para fases iniciais do Projeto e para auxiliar em estimativas.

Para saber mais, dou a dica de dois posts: Um da VersionOne explicando mais sobre a FBS e estimativas e outro da Flylib explicando mais sobre uma fase de Pré Game, utilizando FBS e Funcionalidades.

Para o topo do Backlog, eu geralmente quebro as Funcionalidades, usando o modelo de User Stories:

As a [type of user]

I want to [perform some task]

so that I can [reach some goal]

Isso me facilita muito evoluir no entendimento da funcionalidade, reconhecer os reais usuários, as necessidades e o valor de negócio de uma User Story. Mantendo o padrão Agile, geralmente eu crio as User Stories apenas quando necessário. Em alguns projetos isto quis dizer:

  • No decorrer da Sprint
  • Uma Sprint de antecedência
  • Duas Sprints de antecedência

E vou atualizando minha FBS:

Pra quem utiliza Story Mapping, a FBS é uma mão na massa. Você pode montar suas Releases, Sprints, pinçar as funcionalidades e User Stories necessárias para atingir os objetivos e exibi-las no Map:

by Agile Product Design 

Pra quem usa Boards (ou mesmo o Método Kanban), pinçar as Funcionalidades e/ou as User Stories fica bem interessante, exibindo a decomposição, o avanço do entendimento e a evolução do desenvolvimento.

Eu submeti uma proposta de palestra sobre este tema para o Agile Brazil, vou torcer para entrar.

E você, o que acha desta miscelânia?

Anúncios

7 comentários sobre “FDD, User Stories e Boards na Engenharia de Requisitos

  1. Estou fazendo a FBS de um produto existente que será evoluido. Gostaria de saber se coloca na FBS as funcionalidades que dão suporte (cadastros básicos) as funcionalidades principais do negócio.

    Grata,

    Sheila

    • Olá Sheila.

      Eu gosto de ajustar minha FBS de acordo com o Negócio.

      Essas funcionalidades de Suporte serão alteradas? Elas tem ROI? Fazem parte da análise?

      Caso sim, acredito que agrega e você possa adicionar elas na sua FBS.

      Elas podem ser de menor importância, mas se estão mapeadas no Backlog e tem ROI para serem alteradas, provavelmente chegará a hora de evoluir e começar a criar as User Stories sobre elas. Então acho válido adiciona-las.

      []s.

  2. Olá Rafael, excelente post… Acompanhei na infoq a palestra sobre esse assunto no Agile Brazil… Bem, tenho pesquisado a respeito da FBS com um intuito de entender melhor a sua aplicação na prática. Você poderia me dar exemplos práticos do uso das Áreas de Atividades ??
    Imagino que as Áreas de Negócio sejam Contábil ou Financeiro por exemplo… mas a área de atividade está um pouco nebuloso para mim…

    Desde já muito obrigado Rafael o/

    • Olá CordShell. Muito obrigado pelo elogio e pelo comentário.

      A área de atividade é um dos tipos possíveis que você pode para estruturar sua FBS. Não necessariamente precisa usa-las.

      No caso uma área de atividade, seguindo seu exemplo, poderia ser:

      Financeiro (Área de negócio)
      – Controladoria (área de atividade)
      – Contabilidade (área de atividade)
      – Tesouraria (área de atividade)

      E você, se achar viável, ainda pode segmentar mais:

      Financeiro
      – Contabilidade
      – Bens
      – Direitos
      – Obrigações

      O mais importante é que a FBS represente sua estrutura de negócio, como o pessoal de negócio a ve ou como faça sentido. Não crie burocracia ou níveis subjetivos na sua FBS.

      Um bom modo de se validar se está seguindo num caminho correto é montar um Story Mapping, se você tiver usando User Story ou mesmo UCs, e bater sua FBS com o entendimento das Stories ou UC no Mapa. Se fizer sentido a segmentação do negócio, OK.

      ´[]s.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s