Sprint 1

Os entregaveis esperados para está Sprint estão descritos abaixo.

1. Entendimento do Negócio

Elaborar uma apresentação para o parceiro contendo a análise do cenário com as seguintes partes.

1.1 Padrão de entrega

1. Matriz de avaliação de valor Oceano Azul - deve ser feita considerando o projeto que o grupo está criando. O grupo precisa definir 8 atributos que são importantes para o parceiro e diferenciá-los da concorrência por meio das ações de Reduzir, Eliminar, Aumentar e Criar. Para construir a Matriz, utilize o template disponibilizado. Os valores escolhidos para comparar sua solução com as dos competidores são ilustrativos. Por exemplo, se a sua solução é a mais barata com relação aos competidores você pode considerar o valor 5 para ela, 10 para o concorrente A e 8 para o concorrente B. Indica-se que a pontuação máxima seja 10 e a mínima 0. Justifique suas decisões.

   1. Reduzir: Quais atributos podem ser reduzidos com relação a competição? Por exemplo, seu "Preço" pode ser o mais baixo.
   2. Eliminar: Os atributos existentes em função de competição, podem ser eliminados, sem afetar o valor que o cliente percebe? Por exemplo, sua solução pode eliminar os "Descontos".
   3. Aumentar: Quais atributos o segmento de negócio oferece, discretamente e que podem ser elevados? Por exemplo, sua solução pode aumentar o "Conforto".
   4. Criar: Quais atributos o segmento de negócio não oferece e que podemos criar para gerar valor? Por exemplo, sua solução pode criar o atributo "Praticidade".

2. Matriz de Risco - deve ser feita considerando o projeto que o grupo está criando. Deve ser entregue no template disponível no drive da turma. O grupo deve enumerar pelo menos 10 riscos, distribuí-los na matriz e justificar suas decisões.

3. Canvas Proposta de Valor - deve ser feito considerando a solução que o grupo está desenvolvendo. (Usar o template disponível no drive da turma)

4. Análise financeira do projeto - informar o quanto o parceiro planejou investir no projeto e quais são as projeções de custos e de receitas oriundas para o projeto no período de um ano. Ressalta-se que é uma estimativa. Caso o projeto seja interno, não existindo receita, não é necessário informar a receita estimada. Para que a entrega seja realizada, basta informar esses dados e a lógica que o parceiro forneceu para alcançá-los.

Link para os templates: link.

O envio deve ser disponibilizado na documentação do projeto no GitHub da equipe.

1.2 Padrão de avaliação

1. Matriz de avaliação de valor Oceano Azul - identificação de 8 atributos que são importantes para o parceiro e diferenciá-los da concorrência por meio das ações de Reduzir, Eliminar, Aumentar e Criar. (2,5 peso)
2. Matriz de Risco - identificação de pelo menos 10 riscos que ameaçam ou alavacam o projeto no tocante à equipe, domínio tecnológico, complexidade etc. (2,5 peso)
3. Canvas Proposta de Valor - apresentação gráfica das dores e potenciais da soluções, bem como os ganhos proporcionados por ela. (2,5 peso)
4. Análise financeira do projeto - informar o quanto o parceiro planejou investir no projeto e quais são as projeções de custos e de receitas oriundas para o projeto no período de um ano. Ressalta-se que é uma estimativa. Caso o projeto seja interno, não existindo receita, não é necessário informar a receita estimada. Para que a entrega seja realizada, basta informar esses dados e a lógica que o parceiro forneceu para alcançá-los. (2,5 peso)

2. UX Research

2.1 Padrão de entrega

Segundo Susan Farrell, para o [NNGroup](Fonte: https://www.nngroup.com/articles/ux-research-cheat-sheet/), métodos de pesquisa da experiência do usuário são ótimos para produzir dados e insights. Acompanhados pelo processo de iterações criativas e testes, estes levantamentos de dados nos ajudam a tomar decisões corretas sobre o direcionamento do projeto. Em todas as fases do processo de design, diferentes métodos de UX podem manter os esforços de desenvolvimento de produto no caminho certo, de acordo com as necessidades reais do usuário e não com aquelas que idealizamos com base numa pré-concepção do que este quer ou como pensamos que ele se comporta. # Padrão de entrega:

1. Imersão Preliminar
2. Definição das Personas
3. Jornada do Usuário
4. User Stories

Para informações detalhadas das requisições deste artefato, acesse: link.

2.2 Padrão de qualidade

Para informações detalhadas dos critérios de qualidade deste artefato, acesse: link.

3. Proposta de Arquitetura do Sistema

A proposta de arquitetura do sistema deve ser apresentada neste artefato. Quando estamos avaliando a proposta de arquitetura do sistema, espera-se encontrar informações o bastante para que possa ser possível compreender a solução que será construída, a dor que ela pretende atender, a forma como os elementos que vão resolver está dor estão interligados e como eles vão trocar informações entre si.

É importante observar que está proposta de arquitetura, em um primeiro momento, não precisa estar fortemente ligada as tecnologias que serão utilizadas para implementar o sistema. O grupo deve se preocupar em apresentar uma proposta de arquitetura que seja capaz de resolver a dor do parceiro, que seja escalável e que possa ser implementada utilizando as tecnologias que o grupo julgar mais adequadas para o projeto. Vale destacar também que a proposta de arquitetura deve ser capaz de atender os requisitos funcionais e não funcionais do sistema.

O levantamento de requisitos funcionais e não funcionais do sistema deve ser realizado com base nas informações que o grupo obteve durante a imersão no negócio. É importante que o grupo tenha em mente que os requisitos funcionais e não funcionais do sistema devem ser capazes de atender as necessidades do parceiro, bem como as necessidades dos usuários do sistema. Vale destacar também que o grupo deve ser capaz de evidenciar como esses requisitos funcionais e não funcionais serão atendidos pela proposta de arquitetura do sistema.

Para saber mais sobre requisitos funcionais e não funcionais: link.

3.1 Padrão de entrega

Ela deve contemplar o diagrama de blocos do sistema, quais serão os elementos utilizados e a forma como eles devem trocar dados. Os requisitos funcionais e não funcionais do sistema deverão ser listados neste artefato também. O grupo deve deixar claro no diagrama de blocos, qual a funcionalidade de cada um dos blocos propostos. Além disso, deve ser possível expandir e modificar as funcionalidades do sistema, sem que essas modificações tragam como impacto reimplementar todo o projeto. Essa proposta deve ser entregue na documentação do projeto, como uma seção no Docusaurus no GitHub da equipe.

3.2 Padrão de qualidade

1. Descrever os requisitos funcionais do sistema (até 2.0 pontos);
2. Descrever os requisitos não funcionais do sistema (até 2.0 pontos);
3. Diagrama de blocos da arquitetura do sistema (até 2.0 pontos);
4. Descrição da forma como os componentes propostos no sistema estão interligados e trocam informações (até 2.0 pontos);
5. Proposta com baixo acoplamento e facilidade de realizar as modificações necessárias no sistema (até 2.0 pontos).

4. Documentação

Este artefato deve ser responsável por apresentar toda a documentação realizada ao longo da Sprint.

4.1 Padrão de entrega

Ela deve conter a descrição e documentação dos demais artefatos, bem como apresentações, vídeos de demonstrações e instruções para executar o projeto até o momento desta entrega. Deve ser realizada também um "RELEASE" do repositório, destacando a documentação que foi entregue referente a sprint que passou.

É importante destacar que na documentação deve existir um log com o registro da evolução das tarefas do projeto, bem como a quantidade de tempo que foi investido em cada tarefa que foi desenvolvida durante a sprint. Todos os artefatos de documentação devem ser elaborados utilizando o Docusaurus (https://docusaurus.io/). Ela deve estar disponível no GitHub Pages da equipe e deve seguir os padrões definidos na orientação. Espera-se também neste artefato que os estudantes construam o pipeline de automação do GitHub para que a documentação construída com o Docusaurus possa ser visualizada no GitHub Pages do repositório da equipe.

4.2 Padrão de qualidade

1. A documentação traz os passos necessários para executar a versão atual da sprint (até 3.0 pontos);
2. A documentação contém todos os arquivos de mídia utilizados pela equipe (apresentações e vídeos) (até 2.0 pontos);
3. A documentação atende os requisitos apresentados pelo escritório de projetos para entrega ao parceiro (até 2.0 pontos);
4. Pipeline de entrega utilizando o GitHub Pages e o Docusaurus (até 3.0 pontos).