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:
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?
agilementoring 