Definição

O tipo Feature é:

Uma ação específica sobre um objeto que entregue valor ao usuário.

Uma outra forma rápida de imaginar uma feature é pensar em um VERBO sobre um objeto.

Cada verbo é uma feature. Talvez a forma mais fácil de entender isso é considerar um objeto qualquer, por exemplo, uma "Nota Fiscal". Que coisas você pode fazer com uma nota fiscal? Vejamos:

• Preencher o Cabeçalho da Nota Fiscal
• Imprimir a Nota Fiscal
• Emitira 2a Via da Nota Fiscal
• Cancelar a Nota Fiscal
• Emitir a Nota Fiscal
• Alterar Item na Nota Fiscal
• Alterar Itens na Nota Fiscal
• Remover Item da Nota Fiscal
• Remover Itens da Nota Fiscal
• Pesquisar uma Nota Fiscal por Número
• Pesquisar uma Nota Fiscal por Data de Emissão
• Etc.

Observe os inúmeros verbos associados à Nota Fiscal, como Preencher, Imprimir, Emitir, Alterar, etc. Cada um desses verbos representa uma ação que traz valor para o usuário. Ou seja, o sistema, a coisa acontece apenas se as features existirem. Só faz sentido existir uma Nota Fiscal se o usuário puder realizar ações (features) sobre ela.

E a Nota Fiscal neste exemplo? A Nota Fiscal é justamente o objeto, ou seja, o Épico !

Olhando de uma forma estruturada, o Épico é a coisa, o objeto, e a Feature é a ação sobre este objeto.

É por este motivo que se diz que as features existem dentro do épico. E o épico é composto de features.

Quanto mais features existirem sobre um épico, maior ele é. E possivelmente, quanto mais features existirem sobre o épico, mais crítico e complexo ele se torna, justamente devido a interação entre estas features dentro do épico.

Para que se possam definir boas features, é importante homogenizar algumas regras sobre elas. Vejamos isso abaixo.

Princípios das Features

Algumas considerações são importantes para que as features sejam algo útil, algo controlado, algo que realmente permita a construção de sistemas e projetos de forma organizada.

Esta seção destaca algumas regras para isso.

 Utilize verbos específicos

Você só deve utilizar verbos muito específicos e assertivos para nomear uma feature.

Por exemplo, a palavra "incluir" é diferente de "criar". O verbo "incluir" parte do princípio que já existe algo a ser incluído em outra coisa. Isso é diferente de "criar", que parte do princípio a coisa ainda não existe e por isso será criada. Logo, "incluir" e "criar" são features diferentes. Você precisa manter essa distinção.

É fundamental ter este cuidado, caso contrário, o sistema se deforma, com features que não representam exatamente o que a ação se propõe a fazer.

 Aplique adjetivos quando necessário 

Devido a natureza da linguagem humana, muitos verbos implicam obrigatoriamente em um ADJETIVO associado. Para entender isso melhor, vamos considerar o mesmo exemplo da "Nota Fiscal" acima.

Vejamos a expressão "Pesquisar Nota Fiscal". Ela faz sentido ?

Em um primeiro momento parece que sim, afinal é intenção do usuário pesquisar uma nota fiscal. Mas aí o leitor mais atendo faz a perguna: "Pesquisar pelo número ou pela data de emissão dela?"

Podemos pesquisar notas fiscais por inúmeros parâmetros (guarde este conceito), como por exemplo: Pelo número, pelo emitente, pelo destinatário, pela data de emissão, por um produto específico que ela contenha, pelo valor total, pelo tipo ou qualquer outra característica.

Logo, o verbo "Pesquisar" pressupõe um adjetivo associado, no caso, um campo, uma característica em específico da nota fiscal.

Assim, ao invés de você criar uma feature "Pesquisar nota fiscal", o correto é sempre complementar isso com um adjetivo, como:

• Pesquisar uma nota fiscal pelo número
• Pesquisar uma nota fiscal pela data de emissão
• Pesquisar uma nota fiscal pelo emitiente emissor
• Pesquisar uma nota fiscal pelo valor total
• Pesquisar uma nota fiscal pelo tipo
• Pesquisar uma nota fiscal pela unidade federativa
• Pesquisar uma nota fiscal pelo destinatário
• Pesquisa uma nota fiscal por produto contido

O intuito do uso dos adjetivos é dar sentido à feature, evitando que ela seja algo genérico que pode ser interpretado de muitas formas pelo usuário.

Da mesma forma, cria um escopo definido, que permite a quem construa o sistema delimite o que de fato será entregue.

Imagine que a feature fosse apenas "Pesquisar nota fiscal" em um sistema de logísica de algance global. Simplesmente a feature de pesquisa de notas fiscais se tornaria um módulo inteiro de possibilidades, nunca sendo entregue e tendo que crescer a cada nova característica que uma nota fiscal tivesse!

Logo, os adjetivos funcionam como PARÂMETROS para o verbo, delimitando o seu espectro de atuação.

O formato ideal para adicionar os adjetivos nas features é sempre DEPOIS do objeto, usando preposições como de, da, do, dos, das ou por, pelo ou pela. Ou similares.

Mantenha a divisão entre o unitário e o coletivo

Fundamental distinção deve ser feita sobre features que atingem um único objetivo ou resultado , ou das que atingem múltiplos objetos ou resultados.

Por exemplo, "Pesquisar uma Nota Fiscal por Número" é diferente de "Pesquisa Pesquisar Notas Fiscais por Número", concorda?

Noutro exemplo, "Pesquisar uma Nota Fiscal por Data" é diferente de "Pesquisar uma Nota Fiscal por Datas", certo?

E mesmo, poderiamos poderíamos ter features como "Pesquisar Notas Fiscais por Intervalo de Datas" ou "Pesquisar Notas Fiscais com Números Maiores Que", sim ?

Nesses exemplos acima mostra-se a sutileza de estarmos falando de singular e plural, e cada Exemplo da pesquisa unica e varios acimacada feature ali é - espero que você concorde! - uma coisa difente. 

Logo, é fundamental ter muito cuidado na escrita da feature sob a ótica de estar falando sobre algo individual ou algo coletivo. E isso se aplica tando sobre o objeto e o resultado.

De forma geral, você sempre pode ter 4 possibilidades neste sentido:

• Uma feature que age sobre um único objeto e tem como saída um único resultado. Isso é geralmente o padrão e mais comum.
• Uma feature que age sobre um único objeto e tem como saída múltiplos resultados. Geralmente os resultados são uma lista.
• Uma feature que age sobre múltiplos objetos e tem como saída um único resultado. Geralmente a entrada é uma lista.
• Uma feature que age sobre múltiplos objetos e tem como saída múltiplos resultados. A entrada é uma lista e a saída também é uma lista.

Mas não se preocupe, como tempo você pega o jeito e será natural essas construções.

Mantenha a coerência de nomenclatura ao longo do sistema

De igual importância sobre o assundo do singular e plural anteriormente discutido, fundamental é manter a coerência de escrita das features ao longo do projeto.

Por exmeplo, se você optar por escrever "Pesquisar", use este verbo no sistema inteiro. Não caia na armadilha de permitir que um colega ou você mesmo tenha uma feature chamada "Buscar" se a ide

Evite Verbos Genéricos

Esta recomendação é o complemento sobre a lógica dos verbos específicos.

Verbos genéricos não devem ser utilizados para features. Mas o que é um verbo genérico? É todo verbo que representa, dentro dele, uma série de possibilidades.

Exemplos comuns de verbos genéricos são: Cadastrar, Manter, Gerir, Controlar, Pesquisar, Buscar, etc.

O que estes verbos significam? Verbos genéricos significam que dentro deles uma série de outros verbos existe. Vamos explorar o verbo genérico "Cadastrar". O que é cadastrar? Cadatrar pode ser criar um novo registro, incluir um novo registro, editar um registro existente ou qualquer outra coisa relativa ao conceito de "cadastro". Logo, "cadastrar" não é algo específico.

Por exemplo, o uso de verbos genéricos ou abertos não é correto para criar features. S

•   
•  Marcelo Mrack | Sócio reescrever daqui para baixo pois isso foi simplesmente copiado do Tipo Epic

Linkar/relacionar, por exemplo, o PowerShell que inclusive padronizada os nomes de metodos https://learn.microsoft.com/en-us/powershell/scripting/learn/ps101/09-functions?view=powershell-7.4#naming

Um épico é um processo de negócio, contendo o ciclo de vida e regras completas de um objeto do sistema.

Em outras palavras, um épico também pode ser visto como uma funcionalidade, ou seja, um conjunto de funções (conjunto de features) que se interrelacionam fortemente, formando o ciclo de vida de um objeto.

Outra forma de pensar em épicos é pensar em um objeto e todas as coisas (verbos, ações) que você pode fazer com ele. Isso é um épico.

Por exemplo, uma reunião de pessoas; ela é um épico. Isso porque você pode (ações) solicitar a reunião, agendar a reunião, convidar participantes para reunião, confirmar a reunião, realizar a reunião, documentar a reunião, etc. A reunião então, é o épico, e as ações sobre ela serão suas features.

Fazendo uma analogia ao mundo do desenvolvimento Java EE, cada épico (ou processo de negócio) pode ser implementado por um EJB de Negócio. E, se estendendo essa definição, se percebe que isso está em concordância com a JSR 299. Isso porque (conforme a JSR), os WebBeans possuem um ciclo de vida: o ciclo de vida de um objeto, ou seja, o seu processo.

Falando em metodologias, os épicos (funcionalidades) possuem relação um-para-um com os épicos do Scrum ou as FeatureSets da FDD.

Em nível de gerenciamento de projeto, os épicos (funcionalidades) são pontos perfeitos para trabalharmos a questão do Earned Value do PMBOK para se fazer a gestão de custos e andamento de cronograma. Pense bem: de que adianta entregar ao cliente meio processo de negócio, ou seja, meia funcionalidade? Assim, ao se pensar em gerenciamento de entregáveis e controle de progresso, as funcionalidades (épicos) são o denominador comum e lógico para o gerenciamento de entregas. Mas claro, essas entregas são evolutivas, e assim, cada ciclo (sprint?!) você vai entregando mais e mais features (verbos) ao seu objeto (o épico).

Outra forma de visualizar um épico (funcionalidade) é pensar no conjunto de features operando em grupo. Por exemplo, o conjunto das features "incluir", "editar", "deletar", "pesquisar", "exportar" (...) de uma Nota Fiscal formam o épico "Manter Notas Fiscais". Bom, já falamos da "reunião", acima. Começa a fazer sentido para você?

Finalmente, fazendo uma analogia a um banco de dados, cada tabela no banco de dados pode ser representada como um épico, como Tabela "Cliente" → Épico "Manter Clientes".

Quer saber uma forma fácil de reconhecer um épico ? Use este algoritmo:

1. Pense em um objeto do seu dia-a-dia (uma reunião, um fluxo de trabalho, um documento) ou parte de um sistema (uma tela, um relatório, etc.). Por exemplo: Relatório de Vendas Mensais.
2. Esse objeto pode ser decomposto em outros? Se sim, para cada objeto dentro dele, volte ao passo #1, pois talvez ele seja então um Tema ou um Set. Agora, se ele for um objeto final, avance para #3.
3. Agora, coloque um verbo genérico na frente, como "Manter". Por exemplo: Manter Relatório de Vendas Mensais.
4. Pronto. você tem um épico. E dentro dele você terá as features com seus verbos específicos (descritas no padrão AARON* na seção 2.1.3, item "0 - Desejada" da página Features):
   1. Filtrar vendas de licença por dia do mês no Relatório de Vendas Mensais.
   2. Filtrar vendas de consultoria por dia da semana no Relatório de Vendas Mensais.
   3. Filtrar vendas de licença do tipo Atlassian por semana no Relatório de Vendas Mensais.
   4. Filtrar vendas de gestão compartilhada por intervalo de dias no Relatório de Vendas Mensais.
   5. Imprimir listagem de registros em PDF no Relatório de Vendas Mensais.
   6. Imprimir listagem de vendas em PDF no Relatório de Vendas Mensais.
   7. Exportar listagem de registros em CSV no Relatório de Vendas Mensais.
   8. Etc, etc, etc.

Para mais detalhes, vide o post https://goo.gl/nPyHW que carateriza toda a relação estrutural de temas, sets, épicos e features em um sistema.

* Nos exemplos do item #4 acima, optamos por suprimir o ator (o primeiro "A") e o objetivo de negócio ("N") a fim de torná-los de mais fácil leitura aqui. Assim, o item #4.a, no padrão AARON completo deveria ser: Vendedor filtrar vendas de licença por dia da semana no relatório de vendas para obter dados diários de vendas de licenciamento.