Argumentações

Versionamento

Versão	Argumentação
Versão 1	É necessário colocar concorrentes no Rich Picture?, Deve ser feito um Rich Picture próprio para feed e conversas?, Deve ser feito um Rich Picture que aborde os requisitos não-funcionais?, O limite de likes deve entrar na história de usuário de dar like?

Introdução

  A argumentação é uma forma utilizada para que um conjunto de pessoas que discordam cheguem a um consenso, buscando como resultado uma conclusão racional. Ela é usada na pré-rastreabilidade para garantir o rastro nas decisões, assim é possível visualizar quais conflitos ocorreram, porque ocorreram, quem os provocou e qual proposição venceu.

Argumentação 01

É necessário colocar concorrentes no Rich Picture?

• p1 - É necessário colocar os concorrentes no Rich Picture para mostrar como o O usuário escolhe qual aplicativo usar - Arthur

• p2 - Não é necessário colocá-los, porque não se sabe se é possível encaixar os concorrentes no Rich Picture - Vítor

• p3 - Não é necessário, porque no Rich Picture é necessário descrever o conceito da aplicação escolhida. Sendo assim, os concorrentes não se encaixam - Luciana

• A conclusão dessa argumentação foi para não adicionar os concorrentes no rich picture conceitual.

Argumentação 02

Deve ser feito um Rich Picture próprio para feed e conversas?

• p1 - não é necessário fazer um rich picture separado, pois esse fluxo já está incluso no rich picture de match - Amanda

• p2 - não é necessário já que é um fluxo bem pequeno - Vítor

• p3 - seria interessante ter um próprio, pois se a equipe estivesse criando o aplicativo do zero traria uma visão nova para o desenvolvimento que não seria óbvio - Luciana

• p4 - é necessário já que pode trazer uma visão não funcional dessa parte da aplicação - Arthur

• p5 - é bom para trazer informações do que deve aparecer no feed - Vítor

• A conclusão dessa argumentação foi que o rich picture sobre o feed e conversas deveriam ser feitos.

Argumentação 03

Deve ser feito um Rich Picture que aborde os requisitos não-funcionais?

• p1 - é válido optar por adiar o rich picture de requisitos não funcionais - Luciana

• p2 - é importante se preocupar com os requisitos não funcionais para garantir que eles vão estar documentados desde a pré-rastreabilidade - Arthur

• p3 - fazer a pesquisa não significa que os requisitos não funcionais estão sendo deixados de lado, mas sim que estão sendo feitas pesquisas para entendê-los melhor - Vítor

• p4 - é melhor pesquisar e garantir uma representação mínima dos interesses dos usuários - Amanda

• p5 - se feito agora seria sem embasamento nenhum - Waysman

• p6 - todos os documentos são evolutivos. Então mesmo feito com menos conhecimento, eles seriam evoluídos e amadurecidos - Arthur

• p7 - existe um embasamento porque os integrantes do grupo são usuários do tinder. O que cada indivíduo do grupo pensa do Tinder acaba sendo um pensamento de usuário, e isso ajudaria na elaboração do rich picture - Arthur

• p8 - apesar dos integrantes serem usuários não é significativo, já que é um número extremamente pequeno de indivíduos e muitos não estão usando o Tinder de forma real. É muito difícil que seis pessoas representem todos os usuários. Por isso um documento validaria os requisitos não funcionais - Luciana

• A conclusão dessa argumentação foi que o rich picture de visão social seria feito depois que o formulário fosse lançado para receber respostas. Sendo assim, um questionário precisaria ser criado e para isso os integrantes levantaram perguntas que não poderiam faltar. Foi decidido que o questionário teria perguntas para usuários e não-usuários, perguntas sobre concorrentes e sobre os motivos de utilizar ou não o Tinder.

Argumentação 04

O limite de likes deve entrar na história de usuário de dar like?

• p1 - O limite de likes não deveria entrar nessa user storie, pois é uma funcionalidade que não faz muito sentido para a história. É possível realizar a história sem esse limite. Essa funcionalidade vem dos serviços pagos. - Arthur

• p2 - O limite deve entrar porque seria um tipo de validação, como um critério de aceitação da história. - Luciana

• p3 - Concordo que limitar os likes seria um critério de aceitação, já que só verificaria se tem likes disponíveis sendo um usuário free. - Waysman

• p4 - Eu não acho que seria um critério de aceitação, pois não agrega valor na user storie de dar like. O valor dessa história é um usuário avaliar outro e o limite de likes agrega valor no épico de serviços pagos. - Arthur

• p5 - Não acho que agrega valor no épico de serviços pagos, já que seria como adicionar um IF/ELSE de um método da história de dar likes e isso não tem relação com a história de serviços pagos. - Luciana

• p6 - O limite de likes deveria entrar na história de dar likes porque a maioria dos usuários não são pagos. E os usuários pagos herdam as características de usuário. - Vítor

• p7 - Acho que isso não faz sentido, uma vez que a visão ágil acredita em entregar pequenos produtos funcionais e um produto com esse limite não agrega valor. Isso acaba quebrando a usabilidade e alguns requisitos funcionais. Se você não dá outra opção para usuário não faz sentido limitar os likes, enquanto não existir a opção de compra. - Arthur

• p8 - Eu não acho que a limitação do like ‘estraga’ o produto. Acho que essa limitação do like, mesmo antes de colocar os serviços pagos da um gostinho a mais e instiga o usuário a voltar quando tiver like disponível. - Waysman

• p9 - Discordo, porque o Tinder não fez isso. Eles disponibilizaram tudo e somente depois colocaram a limitação de likes. - Arthur

• A conclusão dessa argumentacao foi que a funcionalidade de limitar likes devieria se encontrar no épico de serviços pagos.