Mudanças entre as edições de "FEATURE"
De Wiki CTI
(→Conteúdo) |
m (Protegido "FEATURE" ([Editar=Permitir apenas usuários autoconfirmados] (indefinidamente) [Mover=Permitir apenas usuários autoconfirmados] (indefinidamente))) |
(Sem diferença)
|
Edição atual tal como às 12h57min de 26 de junho de 2019
![]() |
|
---|---|
Artefato: | Feature |
Utilizado para: | Descrever uma Funcionalidade |
Utilizado em: | Ambiente Ágil |
"A descrição de um interação ou ação com o sistema é o que chamamos de feature. Por exemplo, escrever uma mensagem pra compatilhar uma ideia, pensamento ou conteúdo relevante
dentro do Twitter é um feature que chamamos de tweet."
Item de trabalho, em nível de portfólio do produto, usado para descrever uma funcionalidade. O cadastro pode ser oriundo de um Epic ou não.
Para que essa funcionalidade seja atendida deve haver o cadastro de ao menos uma User Story ou mais. O conjunto dessas FEATURES é a formação do
Backlog.
Índice
Fluxo para se construir uma feature
Consulte o manual de como criar esse artefato no ALM
Modelo de Feature
Artefato de Referência Feature 27066
Conteúdo
Quando a necessidade de nova funcionalidade é identificada, é de extrema importância que ao descreve-la na ferramenta alguns pontos sejam observados, esses pontos são obrigatórios para que uma feature alcance e contribua com o entendimento de todos do time e para que a funcionalidade seja entregue com qualidade, atendendo efetivamente o que foi levantado e estimado.
Prioridade Valor para o negócio Risco Perspectiva de conclusão.
Quem cria
- Analistas
- Gestão Estratégica ( nos casos em que a feature nasce de uma ISSUE)
Quem Gerencia e fecha a feature?
- O controlador de projetos, podendo ser o analista também.
O Ringue
No nosso cenário a diferença mais marcante desses dois artefatos esta em que a FEATURE descreve uma funcionalidade e USER STORY descreve um pedido do cliente e como ele quer que esse
pedido contribua para a funcionalidade ser entregue.
Onde e como usar
Não é obrigatório a FEATURE nascer de um EPIC, esse funcionalidade pode nascer de um pedido do cliente que não seja a nível de um Epic.
Então monta-se o backlog e prioriza-o de acordo com o valor e importância para o cliente. Porém é importante lembrarmos que para que uma funcionalidade seja entregue
obrigatoriamente ao menos 1 User Story deve ser cadastrada, podendo conter na feature uma ou mais user stories cadastradas.
- Vindo de um Epic
- De um pedido
Ainda temos a possibilidade dessa Feature nascer da demanda do BUG Zero, através do cadastro de uma ISSUE que é analisada pela Gestão estratégica e caso seja necessário a Feature é cadastrada.
- De uma Issue
Referências
http://blog.caelum.com.br/como-levantar-e-priorizar-features-com-seu-time/