Priorização e Backlog do Produto

1. Introdução:

Este documento contém a priorização dos documentos elicitados e, a partir deles, a criação do backlog do produto com base na prioridade dos requisitos. Além disso, dividimos em 3 níveis de elicitação: User stories, requisitos e tarefas, que serão explicados individualmente. Esse documento será a base para todo desenvolvimento, indicando qual a ordem adequada para o desenvolvimento da aplicação.

1.2. Abreviaçãoes e acrônimos:

Abreviação	Significado
RF	Requisito funcional
RNF	Requisito não funcional
US	User storie
T	Tarefa

2. Níveis:

Para a criação do backlog do produto, optamos por dividi-lo em 3 níveis diferentes visando uma melhor compreensão e análise. Em nosso primeiro momento, elicitamos os requisitos e, a partir deles, vamos agrupar em User stories, para dar uma visão do usuário acerca dos requisitos, e em tarefas menores, para devida atribuição em issues.

2.1. User Stories:

Segundo 1 , User story é uma descrição das necessidades do usuário sobre um ponto de vista do usuário, sendo esse um dos seus principais princípios: representar integralmente o produto sobre o ponto de vista do usuário.

2.2. Requisitos:

O site DevMedia tem a seguinte definição para requisitos: "Requisitos são, além de funções, objetivos, propriedades, restrições que o sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s). De forma mais geral um requisito é uma condição necessária para satisfazer um objetivo." [2]

Como a user story é uma descrição baseada na visão do usuário e vários requisitos podem fazer parte da mesma user story, os requisitos serão abordados nesse documento como uma subdivisão das US's.

Dentro de requisitos, temos duas principais classificações:

2.2.1. Requisitos funcionais:

Se refere a o que o sistema faz, como funções e informações [2].

2.2.2. Requisitos não funcionais:

Se refere a como o sistema faz, geralmente atribuído a métricas de qualidade, como usabilidade e confiabilidade[2].

2.3. Tarefas:

É um meio de "quebrar" tanto os requisitos quanto as Histórias de usuário de forma que seja de tamanho pequeno e que tenha um escopo bem definido, sendo essas as tarefas que serão realizadas pela equipe.

3. Priorização dos requisitos por meio do MoSCoW

Esta técnica consiste em dividir os requisitos em quatro níveis de prioridade definidos de acordo com as letras que compõem o MoSCoW, sendo eles:

Must: Nesta categoria são atribuídos os itens que devem necessariamente ser realizados. São considerados obrigatórios, vitais, essenciais e inegociáveis;
Should: Nesta categoria estão os itens necessários, importantes e valorosos porém não obrigatórios e negociáveis. São itens de segunda prioridade que podem ser realizados num segundo momento;
Could: Nesta categoria estão inseridos os itens desejados, mas com menor impacto ou menor valor para o objetivo estratégico. São itens de terceira prioridade que não apresentam problemas caso não sejam realizados;
Would: São os itens de menor prioridade. Podem ser reconsiderados no futuro, mas não ocuparão os recursos da organização no momento atual.

4. Product Backlog:

4.1 Tabela User Stories

US	Descrição	Prioridade
US01	Eu como usuário desejo encontrar um estabelecimento com o procedimento estético que eu queira	Must
US02	Eu como usuário desejo ver as informações do estabelecimento.	Must
US03	Eu como usuário desejo que o sistema obedeça critérios de portabilidade e usabilidade	Should

4.2 Tabela Requisitos

Requisito	Descrição	Prioridade
RF01	Criar feed de serviços.	Must
RF02	Criar um feed de estabelecimentos.	Must
RF03	Criar um mapa interativo.	Should
RF04	Criar um filtro para o feed de serviços.	Must
RF05	O sistema deverá ser capaz de calcular a distância entre o usuário e um estabelecimento.	Must
RF06	O sistema deverá permitir que o usuário admin cadastre os estabelecimentos.	Must
RF07	O sistema deverá ser capaz de coletar a localização do usuário.	Must
RF08	O sistema deverá fornecer um link para que o usuário possa acessar a localização do estabelecimento.	Must
RF09	O sistema deverá ter um perfil do estabelecimento com informações básicas de contato, funcionamento e localização.	Must
RF10	O sistema deverá listar dentro do perfil do estabelecimento, os serviços que ele oferece.	Must
RNF01	Avaliar a usabilidade por meio do tempo necessário para a realização das principais tarefas.	Should
RNF02	O sistema deverá ter portabilidade para uso em mobile e desktop.	Should

4.3 Tabela Tarefas

US	Requisito	Prioridade	Tarefa
			US01	RF01	Must	T01: Criar página de apresentação de serviços no front
						T02: Criar componente que mostre um serviço no feed
T03: Desenvolver endpoint para consumo dos dados dos serviços
T04: Desenvolver estabelecimentos no backend
RF02	Would	T05: Criar página para apresentar os estabelecimentos
RF02	Would	T06: Consumir dados dos estabelecimentos no backend
RF03	Could	T07: Integrar um mapa do site
		T08: Permitir interação do usuário com o mapa
		T09: Alimentar o mapa com os dados dos estabelecimentos
		T10: Identificar os estabelecimentos no mapa
		T11: Poder acessar o perfil de um estabelecimento no mapa
RF04	Must	T12: Criar componente para abrigar os filtros
		T13: Criar endpoint que recebe os filtros e retorna os dados equivalentes
		T14: Exibir dados filtrados
RF05	Must	T15: Criar endpoint que receba a localização do usuário e calcule a distância
RF06	Must	T16: Criar um CRUD de estabelecimentos no backend
RF06	Must	T17: Criar uma página para cadastro dos estabelecimentos no front
RF07	Must	T18: Solicitar localização exata
RF07	Must	T19: Conseguir localização aproximada (caso o usuário não forneça a localização)
US02	RF08	Must	T20: Gerar link do mapa com a localização do estabelecimento
	RF09	Must	T21: Criar página de perfil no frontend
			T22: Criar endpoint no backend para consumo desses dados
			T23: Exibir os dados corretamente no frontend
	RF10	Must	T24: Consumir a lista de serviços no backend
			T25: Exibir os dados no frontend
			T26: Possibilitar melhor visualização (aproximação) das fotos
US03	RNF01	Should	T27: Elaborar método de avaliação da usabilidade com relação ao tempo (inspeção, observação, investigação)
	RNF01	Should	T28: Aplicar método escolhido para a avaliação
	RNF02	Should	T29: Elaborar método de avaliação da portabilidade
			T30: Aplicar método escolhido para a avaliação

Apesar de termos um escopo que aparenta ser pequeno, muitos requisitos são vitais ao sistema para que ele seja concluído.

5. Referências:

[1] - https://k21.global/tudo-sobre/agilidade/user-stories/o-que-e-user-story#:~:text=User%20Story%20ou%20%E2%80%9Chist%C3%B3ria%20de,ponto%20de%20vista%20desse%20usu%C3%A1rio.
[2] - https://www.devmedia.com.br/introducao-a-requisitos-de-software/29580
[3] - https://www.pluralsight.com/guides/break-down-agile-user-stories-into-tasks-and-estimate-level-of-effort

6. Versionamento:

Data	Nome	Descrição	Versão
01/03/2021	João Pedro Silva de Carvalho	Documentando Brainstorm	0.1
01/03/2021	Nícalo Ribeiro	Complementando a documentação	0.2
02/03/2021	Nícalo Ribeiro	Adição de tarefas para o backlog	0.3
02/03/2021	Nícalo Ribeiro	Ajustes na tabela de tarefas e adição de novas	0.4
07/03/2021	Nícalo Ribeiro	Refatoração do documento; Adição da priorização e tarefas do backlog	0.5
07/03/2021	João Pedro Silva de Carvalho	Adicionando definições de termos	0.6
08/03/2021	João Pedro Silva de Carvalho	Dividindo requisitos em tarefas	0.7
08/03/2021	Nícalo Ribeiro	Revisão e ajustes	0.8
18/03/2021	João Luis Baraky e João Pedro Silva	Substitui tabela do Backlog para 3 tabelas melhores organizadas e coerentes	0.9
18/03/2020	João Pedro Silva e João Luis Baraky	Adicionando priorização nos requisitos	1.0
19/03/2020	João Pedro Silva e Gustavo Nogueira	Adicionando revisão do PR	1.1