Estudo e levantamento de tecnologia/Front-end

Descrição:

Para fazer um bom projeto, é necessário estudar e levantar tecnologias que melhor se encaixam no projeto.

Tarefas:

• Estudar tecnologias que podem ser usadas no Front-end.

• Conversar com monitor e outras pessoas sobre qual tecnologia foi escolhida em projetos passados.

Critérios de aceitação:

• Listar ao menos 2 tecnologias por parte da arquitetura.

• Debater as tecnologias levantadas na reunião de quarta, 20h (#43).

Descrição:
Conversar sobre as dúvidas sobre ferramentas como pullrequest, issue, sprint, gitflow e mais.

Critério de Aceitação:

• Todos terem assistido a live sobre git no canal Projeto BOSS.

Reunião de debate sobre as tecnologias levantadas

Descrição:

Issue destinada a reunião de debate de todas as tecnologias levantadas para uma aplicação web.

Tarefas:

• Comentar sobre as tecnologias levantadas - Back-end; Bruno e Enzo (#42);
• Comentar sobre as tecnologias levantadas - Banco de dados: Daniel P. e Bruno (#44);
• Comentar sobre as tecnologias levantadas - Front-end: Denys e Danie P. (#39);
• Comentar sobre as tecnologias levantadas - Docker: Emily e Daniel B. (#40);
• Comentar sobre o Product Backlog pensado (#46);
• Comentar sobre o Documento de Visão (#41).
• Reunião será realizada quarta(19/09) as 20h.

Critérios de aceitação:

• Debater as tecnologias levantadas na reunião;
• Destacar aquelas que potencialmente serão usadas no desenvolvimento do produto;
• Debater Product Backlog e possíveis melhoras;
• Debater Documento de Visão e possíveis melhoras;
• Comentar nessa issue tudo que foi debatido e concordado na reunião.

Desenvolver documento de Product Backlog

Descrição:

Issue destinada a criação e desenvolvimento do documento Product Backlog.

Tarefas:

• Reavaliar o Backlog levantado na issue #46;
• Inserir histórias ainda restantes, seguindo os requisitos levantados #38 ;
• Criar documento na pasta docs ou na nova branch criada para a gh pages #55;
• Definir pontuação para as histórias de usuário.

Critérios de aceitação:

• Considerar o Backlog condizente com as necessidades do produto;
• Considerar o Product Backlog condizente com os requisitos levantados.
• Conversar com o grupo sobre as histórias levantadas.
• Pontuação das histórias devidamente levantadas;
• Documento estar devidamente inserido na pasta docs ou na gh pages.

Descrição:
Criar pasta /docs para inserir documentos futuramente.

Tarefa:

• Inserir pasta Docs.

Critério de Avaliação:

• Pasta /docs estar no repositório remoto.

Finalizar Desenvolvimento do Documento de Visão

Descrição:

Issue destinada a finalizar e aprimorar os tópicos do Documento de Visão.

Tarefas:

• Revisar todos os tópicos já levantados;
• Aprimorar os tópicos que necessitam de mais detalhamento.
• Desenvolver os tópicos que ainda restam.

Critérios de aceitação:

• Considerar todos os tópicos levantados bem desenvolvidos;
• Considerar o documento bem fixado e alinhado a nossa visão de projeto e produto.

Estudo da estrutura de uma aplicação web

Descrição:

Como as tecnologias trabalham para fazer app web funcionar, como o back-end se comunicará com o front-end e com o banco de dados

Tarefas:

• Verificar como que as tecnologias trabalham juntas

Critérios de aceitação:

• Todos os membros do grupo devem concordar

Criar discord

Descrição:

Criação de discord para uma maior facilitação de comunicação

Tarefas:

• Criar os canais de texto e de voz no discord

Critérios de aceitação:

• Todos os membros entrarem

Treinamento sobre documento de arquitetura

Descrição:

Os batedores de #12 deverão fazer um breve treinamento com os demais integrantes baseados nas fontes compartilhadas.

Tarefas:

• Definir quando será realizado o treinamento.

• Dividir os tópicos de treinamento entre os batedores.

Critérios de aceitação:

• Treinamento ser concluído.

Descrição:

Dia 20/08, as 16h tivemos uma reunião com 2 prováveis clientes.

---

Reunião

Avisos:

• Questões entre parentes são pontos questionados pelos alunos de MDS, não expressa a opinião das outras pessoas envolvidas na reunião;
• Em alguns momentos, fomos colocados como os seus representantes no quis diz respeito ao que a matéria é como seria o desenvolvimento do produto nela. Por favor reforce esses pontos numa proxima reunião;

Grupo 1 - Ganhadores do hackathon

Projeto: Postagens de assuntos relacionados a UnB.

Aplicativo/Site que pudessem ajudar a UnB. alunos e servidores fazem postagens sobre problemas que enfrentam da faculdade e os gestores podem visualizar e tomar medidas para resolver esse problema reportado.

Aluno:

• Postagem em tempo real e já aparecer no cliente;
• Notícias gerais e das postagens(status e atualizações).
• Fácil participação;
• Linguagem fácil e intuitiva;
• Colaboração de forma simples.

Login:

• Postagem sem login;
• Cadastro simples e rápido, Integração com o cadastro da UnB.

Gestor:

• Dashboard de gerenciamento dos posts cadastrados:
  • Dados gerados pelas postagens (Parte um pouco vaga, como essas postagens serão trabalhadas para gerar dados e a complexidade desses dados é algo a se trabalhar)
  • Coleta de dados objetiva e eficiente;
  • Visualização dos posts e aceitar resolver-lo:
  • Gerar status e feedbacks da resolução da postagem.

Recompensas para o usuário colaborar (Gamificação):

• Ganha moedas, para engajar mais a participação das pessoas;
• Ponto em aberto:
  • Exemplo: Poderia ser desconto no RU, Benefícios em empresas parceiras;
  • O projeto foi pensado para cada postagem gerar moedas, mas pode acontecer de pessoas postarem só pelas moedas e não focar no ponto que é ajudar a faculdade (talvez só ganha moedas caso post seja resolvido pelo gestor?! Ou outra maneira de recompensar)

Ponto levantado pelo cliente que tem que ser melhor discutido:

• Como será a participação deles no processo de desenvolvimento?
• (Como eles tem uma empresa, e serem pessoas de TI, talvez queiram participar mais de perto do produto)

Desenvolver README

Descrição:

Issue destinada a desenvolver README básico do projeto.

Tarefas:

• Desenvolver antes o Documento de Visão para ter melhor entendimento do projeto;
• Ver recomendações compartilhadas na issue de padrão #5;
• Produzir um bom readme;
• Ver READMEs de grupo anteriores anteriores #3.

Critérios de aceitação:

• Readme estar de acordo com as recomendações;
• README estar bem estruturado, clean e focado na apresentação do projeto.

Reunião com grupo Dashboard

Descrição:

Issue destinada a reunião com o grupo responsável pela parte do Dashboard da aplicação.

Tarefas:

• Alinhar a visão de produto que cada grupo tem;
• Debater questões de requisitos, feactures e backlog do produto;
• Conversar sobre questões de arquitetura e troca de dados;
• Conversar sobre questões de identidade visual;
• Debater a necessidade de reuniões a cada x sprints.

Critérios de aceitação:

• Dois grupos alinharem suas visões sobre o que deve ser o produto.
• Dois grupos alinharem ordem de prioridade e funcionalidades do produto;
• Dois grupos chegarem a uma data interessante para reuniões.

Descrição:
Realizar estudos sobre o Documento de Visão.

Tarefas:

• Pesquisar o significado de um Documento de Visão no projeto;
• Entender todas as partes do Arquivo;
• Compartilhar as melhores referencias para estudo.

Critério de Aceitação:

• Integrantes responsáveis precisam concordar que as referencias compartilhadas são suficiente para a produção do documento.

Estudo e inserção do template de Roadmap

Descrição:

Issue feita para estudar o conceito de Roadmap e para a inserção do template de Roadmap

Tarefas:

• Estudo do conceito de Roadmap;
• Inserção do template de Roadmap.

Critérios de aceitação:

• Conclusão dos estudos de Roadmap;
• Conclusão e inserção do documento de Roadmap.

Desenvolver Identidade Visual

Descrição:

Desenvolver Identidade Visual da plataforma.

Tarefas:

• Desenvolver ideias de logomarcas.

• Sugerir paletas de cores.

• Guia de cores, fontes e botões

Critérios de aceitação:

• Realizar reunião para discutir as tarefas.

• Definir o conjunto completo de estilo do projeto.

---

Paleta de cores:

Logomaraca:

Wordmark:

Fontes: Montserrat e Revue BT (Apenas na Wordmark).

Planejamento de Riscos

Descrição:

Colocar o planejamento de risco que pode ocorrer durante o projeto, como imprevistos que podem atrapalhar no desenvolvimento da equipe em um todo.

Tarefas:

• Estudar e desenvolver planejamento de risco

Critérios de aceitação:

• Ver em grupo anteriores

Revisar Contributing e Políticas de Contribuição

Descrição:

Issue destinada a revisão do Contributing.

Tarefas:

• Visualização de grupos anteriores;
• Colocar a opção de documentos no template de Pull Request.

Critérios de aceitação:

• Opção de Documentos adicionado ao template de Pull Request;
• Ter visto o Contributing de grupos anteriores.

Elaboração para o desenvolvimento do Product Backlog

Descrição:

Issue destinada a elaboração e desenvolvimento do Product Backlog do projeto.

Tarefas:

• Revisão dos requisitos levantados #38;
• Analisar e definir a lista de estórias com base em sua prioridade e necessidade #34 #38;
• Inserir e desenvolver documento de Product Backlog.

Critérios de aceitação:

• Documento Product Backlog estar devidamente desenvolvido; COMENTÁRIO
• Todos os integrantes concordarem com o Product Backlog levantado.

---

Épico

Épico	Descrição
E1	Cadastro e Login do Usuário
E2	Criação, vizualização e manipulação de postagens
E3	Feedback e estágio de resolução das postagens
E4	Engajamento e interação do usuário com as postagens

Histórias de Usuários

Épico	História de Usuário	Descrição
E1	US01	Eu, como usuário, desejo criar uma conta
E1	US02	Eu, como usuário, desejo fazer e desfazer login de minha conta
E2	US03	Eu, como usuário logado, desejo realizar uma postagem
E2	US04	Eu, como usuário, desejo vizualizar a lista de todas as postagens realizadas
E2	US05	Eu, como usuário, desejo vizualizar todas as informações de uma determinada postagem
E3	US06	Eu, como usuário, desejo vizualizar estágio de resolução de uma determinada postagem
E2	US07	Eu, como usuário logado, desejo editar minhas postagens realizadas
E2	US08	Eu, como usuário logado, desejo excluir minhas postagens realizadas
E1	US09	Eu, como usuário logado, desejo editar minha conta
E1	US10	Eu, como usuário logado, desejo excluir minha conta
E4	US11	Eu, como usuário logado, desejo comentar em uma determinada postagem
E4	US12	Eu, como usuário logado, desejo reagir(positivamente ou negativamente) a uma determinada postagem
E4	US13	Eu, como usuário, desejo compatilhar uma determinada página
E4	US14	Eu, como usuário logado, desejo denúnciar uma postagem
E3	US15	Eu, como sistema, desejo enviar ao usuário uma notificação caso sua postagem tenha sido resolvida
E3	US16	Eu, como usuário, desejo ter uma área direcionada às posicionamentos, notificações, relatórios e atualizações gerais, da universidade, sobre as postagens
E4	US17	Eu, como usuário, desejo ter uma área de ajuda de uso da aplicação

Treinamento sobre documento de visão

Descrição:

Apoś a #6 de estudo do documento de visão, essa issue servirá para a apresentação do documento para o grupo, a explicação de seus pontos e para o primeiro debate sobre desenvolvimento do tema e do projeto.

Tarefas:

• Marcar reunião;
• Explicar todos os pontos do documento;
• Debate inicial do documento;
• Tentar realizar a issue #29 antes dessa;

Critérios de aceitação:

• Todos os integrantes deverão entender bem todos os pontos do documento de visão;
• Todos os integrantes deverão fazer um proveitoso debate inicial sobre o inicio de desenvolvimento do documento e do projeto;
• Criar issue de devolvimento do documento de visão.

Assistir ao vídeo da reunião com o cliente

Descrição:

Todos os integrantes devem estar bem instruídos quanto ao tema do projeto que será desenvolvido.

Tarefas:

• Assistir ao vídeo da reunião.

• Ler a ata da reunião.

Critérios de aceitação:

• Todos os integrantes leram a ata e assistiram ao vídeo.

Treinamento de GitFlow e git

Descrição:

Dar um treinamento, na pratica, de Gitflow e dar dicas de commit e de contribuição.

Tarefas:

• Demostrar na pratica o uso do gitflow;
• Passar dicas e boas praticas de git e commits.

Critérios de aceitação:

• Todos os integrantes entenderem e serem capazes de aplicar o gitflow no desenvolvimento do projeto;
• Os integrantes entenderem as boas práticas de uso do git.

Reunião com clientes, grupo aliado e membros representantes da universidade

Descrição:

Continuação da Issue #29, interrompida na Sprint passada.

Issue destinada ao detalhamento da primeira reunião entre todos os envolvidos no projeto.

Tarefas:

• Criar um roteiro de perguntas e dúvidas sobre o projeto;
• Questionar como será o trabalho paralelo dos 2 grupos envolvidos no projeto;
• Participar da reunião marcada para o dia 10/09, as 14h.

Critérios de aceitação:

• Grupo tirar todas as dúvidas e ter um entendimento sólido do que será o projeto;
• Grupo entender como será o pareamento de trabalho dos 2 grupos envolvidos.
• Grupo entender como será a relação do projeto e a universidade.

Descrição:
Todos os integrantes personalizarem seus perfis e entrarem no repositório do grupo.

Tarefas:

• Verificar no email o convite, feito pela @emysdias, para o repositório do grupo;
• Todos terem fotos e informações em seus perfis;
• Adicionarem extensão ZenHub;
• Dá um fork no projeto.

Critério de Aceitação:

• Todos os integrantes aceitar o convite;
• Todos os integrantes personalizarem seus perfis;
• Todos terem o ZenHub instalado;
• Todos terem dado um fork no projeto.

Estudo e levantamento de sistemas/Banco de dados

Descrição:

Issue destinada ao estudo e levantamento de sistemas de gerenciamento de banco de dados mais usadas em aplicações.

Tarefas:

• Estudar sistemas de banco de dados que podem ser usados em nossa aplicação;
• Conversar com monitor e outras pessoas sobre qual sistema foi escolhido em projetos passados.

Critérios de aceitação:

• Listar ao menos 2 sistemas;
• Debater os sistemas levantados na reunião de quarta, 20h (#43).

Estudo da tecnologia: Docker

Descrição:

Estudar o funcionamento do docker, e como será aplicar no projeto.

Tarefas:

• Estudar como o docker funciona para Web

Critérios de aceitação:

• Debater sobre o uso do docker na reunião de quarta, 20h (#43).

Descrição

Gestão e planejamento de Sprint.

Tarefas

• Estudar o framework Scrum;

• Ler o Guia do Scrum;

• Definir na próxima reunião o timebox das sprints;

• Definir horário da Daily;

• Difundir para o grupo, na próxima reunião, tudo o que foi aprendido de forma sintetizada;

Critério de aceitação

• Difundir para o grupo como será a gestão das sprints;

Descrição:
Realizar estudo sobre Arquitetura de Software.

Tarefas:

• Estudar os modelos de arquiteturas.

• Entender a documentação de arquitetura.

Critérios de Aceitação:

• Compartilhar as melhores referencias para estudo.

• Deverá ser compartilhada por essa issue.

Descrição
Issue focada no estudo do documento Product Backlog.

Tarefas

• Encontrar boas referencias de Product Backlog;
• Estudar a função e os pontos do documento.

Critério de Avaliação

• Compartilhar boas referencias para o estudo.
• Entender, de forma concreta, a função e os pontos do documento Product Backlog;

Estudo e levantamento de requisitos

Descrição:

Para auxiliar um melhor entendimento e aprofundamento dos aspectos do projeto, os integrante devem se inteirar sobre levantamento de requisitos visto possível contato com cliente.

Tarefas:

• Estudar sobre levantamento de requisitos.

• levantar requisitos dos projeto com o que temos até agora. (para efeito de treino)

• Realizar reunião dia 05/09 19 horas.

Critérios de aceitação:

• Debater todos os requisitos pensados pelos integrantes.

• Criar issue para desenvolvimento do documento de arquitetura.

• Criar issue do desenvolvimento do Product Backlog.

Requisitos

Identificador	Requisito
RF01	Permitir que usuários da comunidade acadêmica realize postagens sobre problemas da universidade
RF02	Permitir o usuário editar e excluir suas postagens
RF03	Permitir que o usuário crie, edite e apaga sua conta
RF04	Permitir o usuário fazer e desfazer login de sua conta
RF05	Exibir a listagem de todas as postagens feitas
RF06	Permitir a visualização de todas informações de uma postagem
RF07	Permitir que o usuário visualize suas postagens feitas
RF08	Permitir a visualização do estágio de resolução da postagem
RF09	Permitir que a listagem das postagens seja feita por filtros
RF10	Permitir os usuários engajarem com uma postagem, através de comentários e apoio(positivo ou negativo)
RF11	Permitir o usuário compartilhar uma postagem
RF12	Permitir o reporte de uma postagem
RF13	Exibir ao usuário uma notificação caso uma postagem sua tenha sido resolvida com sucesso
RF14	Exibir uma página direcionada às notificações e atualizações da universidade sobre as postagens
RF15	Exibir uma aba de ajuda de uso da aplicação
RNF16	A aplicação deve fazer a verificação de conta com dados da universidade
RNF17	O sistema deve se tratar de uma PWA (Progressive web app)
RNF18	A aplicação deve ter uma experiencia de uso simples e familiar, de linguagem fácil e intuitiva
RNF19	Assegurar a segurança de dados dos usuários
RNF20	Pode ter suporte para gamificação

Estudo da função Product Owner

Descrição:

O integrante deve estudar as funções a ser desempenhada no projeto

Tarefas:

• Estudar funções e atribuições do Product Owner

Critérios de aceitação:

• O integrante deve entender a função a ser exercida

---

Pápeis

Product Owner

O Product Owner é o representante do produto dentro do time de desenvolvimento. Tem como objetivo maximar o valor do produto que está sendo desenvolvido e garantir que o produto será o melhor possível para a problemática do cliente.

Stakeholders

Skateholders são todas as pessoas afetadas pelo produto. Pode ser o usuário final, os contratantes, terceiros que fazem parte do processo de uso do produto (como um provedor de serviço) e etc.

Dev Team

Time de desenvolvimento do produto.

Fundamentos do Product Owner

1. Conhecer o usuário, entender pra quem esse produto que será feito. Ter empatia com o usuário final, saber o nicho que será focado, quais são suas características e o mais importante, saber com clareza os problemas dele e como você e seu time de devs irá resolve-los com seu produto;

2. Ter um bom gerenciamento do Product Backlog. Gerenciar bem a pilha de tudo aquilo que espera ser feito em relação ao produto;

3. Ser orientado por fatos e dados. Fazer testes para entender o funcionamento prático do produto é muito importante para saber que rumo ir com o Product Backlog, se alguma funcionalidade foi efetiva ou não e pensar em possíveis mudanças no planejamento.

Fundamentos do Product Backlog

1. Deixar muito claro os itens do backlog. Todos devem entender o que precisa ser feito;

2. Priorizar os itens do backlog. Dizer em que ordem as estórias tem que ser feitas para ter um bom fluxo do projeto. Estórias pequenas e claras > grandes e vagas;

3. Deixa-lo transparente e visível para todo mundo.

Inserir o template do documento de arquitetura

Descrição:

Deve ser criado e inserido um documento de arquitetura com o template que será usado e editado ao longo de todo o projeto.

Tarefas:

• Inserir um documento de arquitetura.

Critérios de aceitação:

• Todos os integrantes devem concordar em usar o arquivo inserido.

Descrição
Analisar padrão de trabalho de semestres anteriores.

Sugestão de grupos

• Acacia;
• Ada;
• Dulce;
• Dr-Down.

Tarefas

• Os integrantes usarem projetos de sucesso como exemplo para documentação e desenvolvimento do nosso projeto.

Critério de Aceitação

• Introduzir aos integrantes que, projetos anteriores, são uma excelente fonte de pesquisa no desenrolar do nosso projeto.

Descrição:
Visualizar todos os requisitos de trabalho open source.

Tarefas:

• Modificar nome do repositório após termos nosso tema;
• Inserir descrição;
• Inserir README;
• Inserir código de conduta;
• Inserir Contributing;
• Inserir Issue e Pull request templates.

Critérios de Aceitação:

• Todos os documentos tem que estar na língua portuguesa.
• Todos os membros concordarem com os documentos criados e mudanças feitas;

Refatorar o documento de arquitetura

Descrição:

Issue destinada a correção e revisão do documento de arquitetura.

Tarefas:

• Corrigir a titulação;

• Remover tópicos fora do padrão (sumário, 5 e 7);

• Refatorar a Representação da arquitetura;

• Refatorar as metas e restrições de arquitetura;

• Refatorar a visão dos casos de uso.

Critérios de aceitação:

• Revisão do documento;
• Documento estar completo.

Estudo da função Scrum Master

Descrição:

O integrante deve estudar as funções a ser desempenhada durante o projeto

Tarefas:

• Estudar funções e atribuições do Scrum Master

Critérios de aceitação:

• O integrante deve entender a função a ser exercida

---

Scrum Master

O Scrum Master é responsável por promover e suportar o Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas e as regras do Scrum, ou seja, ele é responsável por transmitir os valores da metodologia ágil e, por possuir esses conhecimentos, deve garantir que todos da equipe respeitem e sigam essas práticas de valores.

O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão
fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais
não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.

O Scrum Master trabalhando para o Product Owner

O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor
possível por todos do Time Scrum
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter itens de Backlog do Produto
claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximar
valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.

O Scrum Master trabalhando para o Time de Desenvolvimento

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Transmitir os valores da metodologia ágil garantindo que todos da equipe respeitem e sigam essas práticas de valores.
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum
não é totalmente adotado e compreendido.

Criar página para documentação - GitHub Page

Descrição:

Criar e organizar em uma branch, uma GitHub Page para a disponibilização da documentação do projeto.

Tarefas:

• Criar uma branch para ser a fonte da página.

• Mover a pasta docs para a nova branch.

• Atualizar o repositório.

Critérios de aceitação:

• A página deve estar acessível de forma funcional.

Treinamento sobre templates para a contribuição com o projeto

Descrição:

Os batedores da issue #4 treinarão os outros membros acerca dos templates, com base em seus estudos.

Tarefas:

• Divisão dos tópicos entre os batedores.
• Definir data para a realização dos treinamentos.

Critérios de aceitação:

• Conclusão do treinamento.

Estudo e planejamento da nossa GitHub Pages

Descrição:

Estudar sobre criação de GitHub Pages e elaborar os tópicos que terão em nossa página.

Tarefas:

• Entender como se cria e como funciona uma página do GitHub;
• Visualizar os principais tópicos que serão necessário na nossa GitHub page.

Critérios de aceitação:

• Compartilhar as melhores referencias para estudo;
• Ter a lista dos principais tópicos que estarão na nossa GitHub page;

• Deverá ser compartilhada por essa issue.;

• Integrantes responsáveis concordam que as referências compartilhadas são suficiente;
• Integrantes responsáveis concordam com a lista de tópicos estarão na nossa GitHub page.

Título da issue

Descrição:

Deve ser inserido o documento de visão com o template que será usado e editado ao longo de todo o projeto.

Tarefas:

• Inserir o template do documento de visão.

Critérios de aceitação:

• Todos os integrantes responsáveis devem concordar com o template inserido.

Conversar com Clientes

Descrição:

Conversar com o pessoal do Hackathon que proveram a ideia do projeto e tentar entender, de maneira mais profunda, o tema.

Tarefas:

Script:

• Conversar sobre a faculdade deles, como se reuniram e quiseram participar do evento;
• Saber o contexto e o ambiente do Hackathon; (Associar com o evento nacional Prêmio Mini Empresa 2014 que participei aonde fiquei em 3º);
• Saber tema do Hackathon e entender a ideia tida;
• Conversar sobre a problemática que eles combateram;
• Entender o processo do evento e o desenvolvimento da aplicação (Aprenderam muito?, Tiveram problemas);
• Expectativa sobre o resultado; (Tinham a sensação que podiam vencer?)
• Como foi ser campeão?
• Conversar sobre o desenvolvimento do projeto (ideias, sugestões e dicas);
• Conseguir a apresentação deles;
• Conversar sobre a logo e as imagens usadas.

Critérios de aceitação:

• Entender melhor como foi o Hackathon e a experiencia do cliente no projeto;
• Entender melhor o tema e suas premissas;

Estudo e levantamento de tecnologias/Back-end

Descrição

Issue destinada ao estudo e levantamento de tecnologias mais usadas no Back-end de uma aplicação web.

Tarefas

• Estudar tecnologias que podem ser usadas no Back-end;
• #224

Critérios de aceitação:

• Listar ao menos 2 tecnologias;
• Debater as tecnologias levantadas na reunião de quarta, 20h (#43).

Criar ambiente de desenvolvimento

Descrição:

Descrever de maneira clara e objetiva o propósito da issue.

Tarefas:

Checklist de ações que devem ser realizadas.

• Criar arquivo Dockerfile front-end;
• Criar arquivo Dockerfile back-end;
• Configurar Docker-compose com node;
• Configurar Docker-compose com mongo;
• Criar projeto Node;
• Criar novo respositório.

Critérios de aceitação:

Descrever os requisitos necessários para que a issue possa ser finalizada.

• Ambiente dockerizado estar funcionando corretamente

Descrição:

Definir os padrões de commit, de criação de issues, e como será a gestão das sprints

Tarefas:

• Gestão de Sprint (documentação sprint + rituais + boas praticas); (issue #14)
• Padrão de commit;
• Padrão de issues;
• Processo de contribuição;
• Padrão de branch #20;
• Obter referencias, exemplos e dicas de um bom README.

Critérios de Aceitação:

• Todos os integrantes concordarem com os padrões elaborados;
• Demonstrar como será a gestão das sprints. (issue #14)

---

Padrões no Projeto

Padrão de Commit

• Sempre verificar se sua alteração está sendo feita na branch correta, seguindo o design de fluxo do Gitflow;
• Em português;
• No gerúndio;
• Sempre com o número da issue que esse commit está relacionado;
• Melhor 10 commits sobre coisas específicas do que 1 genérica com muitas coisas;
• Tentar usar o máximo possível de infos no nome do commit(Dica: usar nomes de variável, arquivo ou tela no commit);
• Ex.: #999 Criando botão informacoesUsuario na página - visualizarPostagem
  (Aqui fica bem claro que existe uma página chamada visualizarPostagem.html e nela foi implementada um botão chamado informacoesUsuario)

Padrão de Issues #4

• A issue deve especifica o suficiente para abordar sua descrição
• Se ler e perceber que alguma tarefa ou critério não casa com a descrição da issue, talvez seja a hora de pensar em criar uma nova issue para abordar essa tal tarefa ou critério.
• Issue, como já dito pela professora, é prova do seu trabalho e participação

Descrição
Clara e objetiva descrição da issue.

Tarefas

• Ponto a ser considerado no issue;
• Ação a ser feita na issue;

Critério de Avaliação

• Ponto a avaliado na issue;
• Ação a ser verificada na issue;

Em caso de Estudo de Documento:

• Integrantes responsáveis precisam concordar que as referencias compartilhadas são suficiente para a produção do documento.

Em caso de Produção de Documento:

• Todos os integrantes precisam concordar com o Documento Criado.

Processo de Contribuição #4

1. Fazer fork do projeto #2
2. Clonar seu repositório remoto;
3. Fazer as mudanças necessárias e as funcionalidades planejadas;
4. Verificar se o repositório não tem mudanças no repositório principal do projeto;
5. Subir tudo feito para seu repositório remoto;
6. Dá pull request direto pelo GitHub;
   6.1 Explicar na descrição do pull request o que ele aborda e as mudanças/implementações foram feitas;
7. Seu pull request ser aceito repositório principal do projeto.

Referencias de um bom README

• awesome-readme: repositório
• README-ecoleta: repositório

Documentação do planejamento e resultado das Sprints

Descrição:

Documentação do planejamento e resultado de todas as sprints até então.

Tarefas:

• Criar documentação do planejamento e resultado de todas as sprints.

Critérios de aceitação:

• Documentar o planejamento e resultado das sprints

E1: Autenticação

Features

Épico	ID	Descrição
E1	FT01	Cadastro e Login do usuário

Histórias de Usuário

Épico	Feacture	História de Usuário	Descrição	Pontos	Feito
E1	FT01	US05	Eu, como usuário, desejo fazer um cadastro	2	Sim
E1	FT01	US06	Eu, como usuário, desejo fazer e desfazer login em minha conta	2	Sim
E1	FT01	US13	Eu, como usuário logado, desejo editar minha conta	2	Sim
E1	FT01	US14	Eu, como usuário logado, desejo excluir minha	2	Sim

Pontos

Estimativa: 8 pontos;

Feitos: 8 pontos.

Descrição:
Realizar estudo sobre protótipos.

Tarefas:

• Pesquisar sobre realização de protótipos.

• Entender as diferenças entre os tipos de protótipos.

Critério de Aceitação:

• Compartilhar as melhores referencias para estudo

• Deverá ser compartilhada por essa issue.

• Integrantes responsáveis concordam que as referencias compartilhadas são suficiente para a produção do documento.

Desenvolver protótipo de baixa fidelidade

Descrição:

Criar um protótipo de baixa fidelidade da plataforma.

Tarefas:

• Criar telas para perfil do usuário.

• Criar telas para o feed.

• Criar telas para notícias.

• Criar telas para postagem.

• Criar telas para login.

Critérios de aceitação:

• Todos os requisitos funcionais devem ser contemplados no protótipo.

• Realizar reuniões para discutir as tarefas e analisar os resultados.

• Mobile first!

• Criar issue de Desenvolver protótipo de alta fidelidade

Desenvolvimento do documento de visão

Descrição:

Issue destinada para a desenvolvimento do documento de visão.

Como não temos uma visão fixa e detralhada do projeto devido a consecutivos adiamentos de reuniões com clientes, somente os 3 primeiros tópicos do documento serão desenvolvidos.

Tarefas:

• Desenvolver Tópico 1 - @DenysRogeres e @emysdias;
• Desenvolver Tópico 2 - @Bruno-Felix e @daniel-bm;
• Desenvolver Tópico 3 - @DanielPortods e @enzoggqs;
• Comentar prováveis alterações do documento;

Critérios de aceitação:

• Todos devem aceitar o Tópico 1 desenvolvido;
• Todos devem aceitar o Tópico 2 desenvolvido;
• Todos devem aceitar o Tópico 3 desenvolvido;
• Prováveis alterações comentadas devem ser discutidas.

Descrição
Issue direcionada no estudo do Design de Fluxo Gitflow.

Tarefas

• Pesquisar a essência e o uso do Gitflow;
• Compartilhar as melhores referencias para estudo.

Critério de Aceitação

• Integrantes responsáveis precisam concordar que as referencias compartilhadas são suficiente para o uso do Gitflow.

E2: Postagens

Features

Épico	ID	Descrição
E2	FT02	Criação e Gerencia das postagens
E2	FT03	Listagem das postagens
E2	FT04	Visualizar detalhes da postagem
E2	FT05	Feedback e Progresso de resolução das postagens

Histórias de Usuário

Épico	Feacture	História de Usuário	Descrição	Pontos	Feito
E2	FT02	US01	Eu, como usuário logado, desejo realizar uma postagem	2	Sim
E2	FT03	US02	Eu, como usuário, desejo visualizar a lista de todas as postagens realizadas	3	Sim
E2	FT04	US03	Eu, como usuário, desejo visualizar todos os detalhes de uma determinada postagem	3	Sim
E2	FT05	US04	Eu, como usuário, desejo visualizar o estágio de solução de uma determinada postagem	5	Sim
E2	FT02	US07	Eu, como usuário logado, desejo realizar uma postagem não anônima	3	Sim
E2	FT02	US11	Eu, como usuário logado, desejo editar minhas postagens realizadas	3	Sim
E2	FT02	US12	Eu, como usuário logado, desejo excluir minhas postagens realizadas	2	Sim
E2	FT03	US15	Eu, como usuário, desejo filtrar a lista de postagens por categoria	3	Sim
E2	FT05	US16	Eu, como usuário, desejo receber uma notificação caso minha postagem tenha sido resolvida	3	Não

Pontos

Estimativa: 27 pontos;

Feitos: 24 pontos.