Descrição:

Política de issues, commits e pull requests.

Tarefas:

• Adicionar template de issues, commits e pull requests.

Critério de aceitação:

• Todos os membros deverão seguir o formato deste template.
• Criar template de issues, commit e PR, e adicionar no diretório de documentos.

Descrição

Adicionar nome e Logo do projeto, e organizar e linkar novo repositório para o front-end.

Tarefas

• Adicionar o nome e logo do projeto no repositório
• Criação do repositório para o front-end do projeto.
• Atualização inicial do readme

Critérios de aceitação

• Todos devem estar de acordo com o nome e logo escolhidos.

Descrição:

Para uma evolução do projeto, discutiremos o backlog do produto.

Tarefas:

• Discutir e organizar o backlog do produto.
• Publicar o backlog do produto.

Critério de aceitação:

• Seguir os padrões propostos pelo tema da professora;
• Time estar de acordo com o Product Backlog.

Descrição:

Atualizações dos docs no GitHub Pages e aprofundamento dos tópicos dentro do documento de Arquitetura.

Tarefas:

• Aprimoração do documento de arquitetura.
• Atualização do GitHub Pages.

Critério de aceitação:

• Documentos estarem corretos.

• Criar uma pasta "docs" para as documentações do projeto.

• Adicionar o documento de planning e review da sprint 0.

Descrição:

Estudar Docsify e implementar ele na nossa pagina do GitHub.

Tarefas:

• Estudar Docsify

• Implementar no GitHub Page.

• Atualiza-lo com os documentos do projeto.

Critérios de aceitação:

• O Docsify deve estar bem implementado.
• GitHub Page deve estar atualizado com as novas informações.

Descrição:

Criação e documentação das metodologias trabalhadas pelo grupo.

Tarefas:

• Estudo e elaboração das metodologias

• Documentação

Critérios de Aceitação:

A issue só será aceita caso a documentação esteja na github pages sem erros ortográficos

Descrição:

Estudo das tecnologias de desenolvimento do front-end.

Tarefas:

• Estudar javascript e react.js
• Implementação inicial da home.

Critério de aceitação:

• Compartilhamento de aprendizagem, podendo ser via: disponibilização de materiais úteis ou rachando algum curso.
• Treinamento dos que possuem mais conhecimento em programação web com os integrantes que nunca tiveram contato com a mesma.

Descrição:

Atualização geral, documentos, github pages, escopo do projeto etc.

Tarefas:

• Documento de Visão

• Documento de Arquitetura

• Product Backlog

• GitHub Pages

Critério de aceitação:

Atualização dos documentos de acordo com o escopo atualizados na github pages

Feedback Geral

Olá pessoal, estou aqui para dar uma ajudinha no andamento do projeto de vocês!
De modo geral, quero dar os parabéns a vocês! Estão bem empenhados, presentes em todas as reuniões, se organizando e estudando bastante, isso é ótimo! Continuem nesse bom ritmo que é sucesso.
Gostei bastante de como fizeram o planning da sprint 1 e que incluíram o quadro de conhecimentos.
Gostei também dos templates de issues e commits (outro exemplo de commit se tiverem interesse).

Práticas

• Quantidade mínima de issues está de acordo com o esperado (pelo menos 1 issue por membro por sprint)
• As issues estão bem escritas (alguém que não faz parte da equipe é capaz de entender e implementar a solução)
• Os commits estão atômicos (uma tarefa por commit)
• Os commits estão bem comentados
• O repositório está organizado
• O ritmo do projeto está de acordo com o esperado
• Estão comentando nas issues

Sugestões de Melhorias

• Criem menos issues por sprints (de acordo com o que vocês darão conta)
• Não sobrecarreguem apenas um membro (dividam as tarefas igualmente)
• Comentem nas issues, abram discussões sobre o assunto e registrem o que está sendo feito (toda a equipe deve comentar, para que a professora veja a atividade de cada aluno)
• Coloquem o template de issues e PRs dentro da aba Insights / Community para facilitar e automatizar suas criações

Descrição:

Criar o documento da sprint 2.

Tarefas:

• Criação do planning da sprint 2.
• Criação do review da sprint 2.

Critérios de aceitação:

• O planning deve ter boa descrição do que deve ser seguido ao longo da sprint.
• A review deve ser fidedigna ao andamento da sprint, detalhando pontos positivos e negativos encontrados na mesma.

Descrição:

Estudar e escolher um modelo inicial para elaboração inicial do RoadMaps do projeto.

Tarefas:

• Estudar e escolher uma estrutura de RoadMap para ScrumMaster/ProductOwner/DevOps/DevTeam

• Criação do documento RoadMap ScrumMaster.

• Criação do documento RoadMap ProductOwner.

• Criação do documento RoadMap DevOps.

• Criação do documento RoadMap DevTeam.

Critérios de aceitação:

• Cada um deve preencher o documento conforme sua função no projeto, todos devem contribuir.
• Revisão ortográfica do documento.

Descrição:

Determinar quais serão as ferramentas de comunicação utilizadas pelo grupo.

Tarefas:

• Criar um documento indicando quais são as ferramentas escolhidas.

Critério de aceitação:

• Todos membros devem saber utilizar as ferramentas propostas.

Descrição:

Inicialização do protótipo de alta fidelidade.

Tarefas:

• Aprimoração do modelo da aplicação web a partir do protótipo de baixa fidelidade.
• Adição do protótipo no projeto.

Critério de aceitação:

• estar coerente com o escopo do projeto.

Descrição:

Elaboração do Canvas do Produto

Tarefas:

• Estudo e Aperfeiçoamento da ferramenta

• Criação do Canvas

Critérios de aceitação:

• Aprovação da equipe
• Atualizada no GitHub Pages

ESTUDO/RESUMO

• Estudar a metodologia Open Source através do link da professora

• Documentar e resumir a ferramenta para os outros colegas.

Descrição:

Criar o documento da sprint 3.

Tarefas:

• Criação do planning da sprint 3.
• Criação do review da sprint 3.

Critérios de aceitação:

• O planning deve ter boa descrição do que deve ser seguido ao longo da sprint.
• A review deve ter o relato do ScrumMaster e BurnDown Chart

• Escolha de 3 temas para a elaboração do projeto

Descrição:

Estudo dos protótipos, e a importância deles para o avanço do projeto.

Tarefas:

• Estudar e entender a funcionalidade de cada um dos

• Disponibilizar para a equipe um pequeno resumo completo, contendo links para aprofundar o conteúdo.

Critérios de aceitação:

• Todos os membros devem ter entendido o funcionamento do mesmo.

Essa issue tem o intuito de introduzir aos integrantes as boas práticas de planejamento e desenvolvimento de um projeto no github, baseando-se em projetos anteriores de MDS.

• Selecionar projetos, que possuam: documetação clara, estrutura organizacional concisa e um bom gerenciamento de escopo.

• Filtrar o projeto que é mais similar com o tema do grupo.

Descrição:
Elaborar uma ATA para controlar as reuniões diárias do grupo, inserindo data, horário, participantes e meio de comunicação.

Tarefas:

• Criar uma ATA para as reuniões.

• Preenchê-la com as informações de cada reunião.

Critérios de aceitação:

• Dados das reuniões devem estar corretos.

Descrição:

Começando a implementação do banco de dados, começando no estudo e aplicação das tabela

Tarefas:

• Estudo da funcionalidade do Banco de Dados
• Pensar e Aplicar as tabelas.

Critério de aceitação:

Treinamento de Banco de Dados, e o aprendizado de suas aplicações

• Assistir aula da quinta-feira com os monitores.

• Pesquisar matérias complementares e informações para o aprendizado do GitHub.

• Entender os Conceitos e ferramentas básicas do GitHub para o trabalho em conjunto do grupo.

Descrição:

Elaboração do documento de arquitetura do projeto, para definir quais softwares serão utilizados no desenvolvimento do projeto,

Tarefas:

• Estudar sobre o assunto e escolher uma estrutura (template) a ser seguida.

• Preencher o documento.

Critério de aceitação:

• Pareamento dos integrantes para o desenvolvimento do documento.

• Deve ser submetida a uma revisão de ortografia.

• Deve estar no github pages.

Feedback Geral

Oii, pessoal, meu nome é @Giuulob89 e agora também sou monitora de vocês! Eu e a @gabrielapivetta estivemos um pouco enroladas essas últimas semanas, mas voltamos aqui para dar uma atualizada sobre como está a avaliação do projeto.
Ficamos felizes em observar que não estão tendo dificuldades em se organizar e fazer o que se propõem, a documentação está muito bem feita e o repositório organizado e intuitivo, com arquivos e pastas bem explicados, além de issues bem comentadas com discussões pertinentes. No próximo tópico, observamos algumas coisinhas a mais, que achamos importante que deem uma olhada, mas saibam que estão fazendo um excelente trabalho!

Pontos Observados

• É importante que deixem mais claro no fluxo do usuário como será a interação do paciente com o sistema (inclusive, gostaríamos que nos explicassem para que possamos avaliar melhor e ver se a documentação está feita de forma correta);

• Vimos o documento de casos de uso de vocês e cremos que a explicação dele está um pouco rasa e que faltam alguns elementos consideráveis nesse tipo de documentação. Por exemplo, se o paciente também tem interação com o sistema é necessário que isso seja explicado no diagrama e também é importante que façam as indicações de uma forma mais explicativa (existem relações diferentes entre as setas, ex: extend e include) e as relações são explicadas dentro de uma caixa que representa o sistema. Sugestão: Estudem essas relações.

• Lembrem que o projeto está com o escopo bem grande, então focar apenas nas features de prioridade alta, no primeiro momento, é essencial;

• Gostamos de ver que fizeram todas as documentações que se propuseram e que já iniciaram a primeira feature do projeto, pois, assim, sobra bastante tempo para revisões antes da R1;

• A identidade visual de vocês também está muito bem trabalhada(um arraso), parabéns!

Descrição:

Criação da pasta .github para templates de issues e PR's. #20

Tarefas:

• Procurar bons modelo e adaptar para o uso do nosso projeto.
• Criação dos templates na pasta .github

Critério de aceitação:

• O template de issues deve ter uma pasta com os tipos de issues essenciais que serão usados ao longo do projeto.

Descrição:

Elaborar o documento de Termo de Abertura do Projeto (TAP).

Tarefas:

• Estudar e escolher uma estrutura(template) de TAP a ser seguido.

• Preencher o documento.

Critérios de aceitação:

• Documento deve ser revisado por outra pessoa que não está responsável pelo mesmo.

• Deve estar no github pages.

Descrição:

Complementar os riscos do TAP, criar um documento com mais detalhes sobre os riscos.

Tarefas:

• Criação do documento de riscos.

Critério de aceitação:

O documento deve está de acordo com pré-elaborada no TAP, e com toda sua complementação.

Descrição:

Delegar aos membros as funções que cada um vai desenvolver, e escolher as tecnologias para elaborar o projeto.

Tarefas:

• Definir tecnlogoias do back/front.

• Divisão das funções do projeto: ProductOwner/ScrumMaster/DevOps/Front/Back.

Critérios de aceitação:

• Afinidade ou vontade de aprender a tecnologia/função proposta.

Descrição:

Atualização de todos os documentos do repositório.

Tarefas:

• Atualizar RoadMaps.
• Atualizar gh-pages.
• Atualizar TAP, e Documento de Visão e outros.

Critério de aceitação:

Todos os membros devem contribuir nesses consertos.

Descrição

Criação da ATA de reuniões da Sprint 3, com os dados das respectivas reuniões.

Tarefas

• Criação da ATA de reuniões.
• Atualização da ATA.

Critérios de aceitação

• Dados corretos de cada reunião.
• Ortografia correta.

Descrição:

Estudo das tecnologias de desenolvimento do back-end.

Tarefas:

• Estudar Python e Django
• Implementar classe psicólogo.

Critério de aceitação:

• Compartilhamento de aprendizagem, podendo ser via: disponibilização de materiais úteis ou rachando algum curso.
• Treinamento dos que possuem mais conhecimento em python com os integrantes que nunca tiveram contato com a linguagem.

Descrição:

Criação do documento de visão do projeto, para definir escopo e finalidade do projeto.

Tarefas:

• Estudar sobre o assunto e escolher uma estrutura (template) a ser seguida.

• Preencher o documento.

Critério de aceitação:

• Professora deve estar de acordo com o escopo proposto, definindo se é algo tangível em 15 sprint's.

• Todos os integrantes devem ser responsáveis por ao menos um tópico do documento.

• Deve ser submetida a uma revisão de ortografia.

• Deve estar no github pages.

Descrição:

Atualização do documento de arquitetura com adição de conteúdo.

Tarefas:

• Estudar sobre a visão.
• Adição de conteúdo.

Critério de aceitação:

A issue será confirmada caso o conteúdo adicionado estiver bem contextualizado com o que a atualização do documento indicar.

Descrição:

Elaboração do RoadMap do Projeto, Product Owner, Scrum Master, DevOps, Arquiteto.

Tarefas:

• Estudar sobre o assunto e escolher uma estrutura (template) a ser seguida.

Critérios de aceitação:

• Cada integrante montar a estrutura do documento de acordo com sua escolha/função no projeto. (Adiante, a função dos membros será flexível, existindo a possibilidade de trocas).

Descrição

Eu, como psicólogo, gostaria de me cadastrar no site para utilizar a plataforma.

Critérios de Aceitação ?

• O cadastro deve pedir:

1. Nome e cpf.
2. Número de CRP
3. Senha
   Estrutura dos campos de cadastro levada em consideração foi essa:
   

Comportamento esperado

• Criação do endpoint de cadastro de psicólogo.

• Criação da tela de front-end, com o formulário de cadastro do psicólogo.

• Envio do formulário do front para o back.

• Comunicação responsiva front-end, back-end e usuário.

• Criar Open source license

• Atualizar O README

• Criar Contributing guidelines

• Criar Code of conduct

Descrição:

Criar o documento da sprint 1.

Tarefas:

• Criação do planning da sprint 1.
• Criação do review da sprint 1.

Critérios de aceitação:

• O planning deve ter um quadro com os conhecimentos dos membros e a função que cada um escolheu.

ATA

Pontos planejado

Assuntos pendentes

• Atraso de funcionalidade X, resolvido.

Tasks e responsáveis

• [] Issue x, @assignerY

Descrição:

Descobrir o que é backlog de produto é qual a sua importância para o desenrolar da equipe.

Tarefas:

• Aprender sobre como funciona o Backlog de produto.
• Resumir de forma sucinta em comentários.

Critério de aceitação:

Resumo qualificado para o final da issue.

Descrição:

Estudo do que é o docker, e como ele funciona.

Tarefas:

• Disponibilizar links/tutorial simples e prático para todos os integrantes do grupo.

• Implementar configuração inicial do docker no projeto.

Critérios de aceitação:

• Todos os membros devem ter entendido o funcionamento do mesmo.

Descrição:

Tarefas

• Continuação do estudo e da config. inicial (#15)
• Implementação do Docker no projeto

Critérios de aceitação

• Implementação revisada e aceitada pelo grupo.

Descrição:

Criar documentação da Sprint 04.

Tarefas:

• Adicionar o planning da sprint.
• Adicionar a review da sprint.

Critério de aceitação:

• O planning deve ter boa descrição do que deve ser seguido ao longo da sprint.
• A review deve ter o relato do ScrumMaster e BurnDown Chart

Descrição:

Estudo e resumo da plataforma em nuvem Heroku para os colegas

Tarefas:

• Estudo da plataforma
• Resumo e documentação.

Critério de aceitação:

Todos os integrantes entenderem o funcionamento e a importância para o projeto

• Estudar Agile em geral

• Estudar mais aprofundado o SCRUM

• Documentar e Resumir para os colegas

Descrição

Criação da Estrutura Análitica do Projeto.

Tarefas

• Estudar e definir modelo de EAP do projeto.
• Criação do modelo.

Critérios de aceitação

• Diagrama do fluxograma das releases.
• Correção de ortografia.

• Adicionar uma licença para o projeto open source.

Descrição:

Elaboração da estrutura de documentos do projeto a partir do GitHubPages.

Tarefas:

• Estudo do funcionamento da ferramenta / aulas com os monitores sobre o assunto.

• Criação do GitHubPages para o projeto.

Critério de aceitação:

• Manual para todos integrantes conseguirem informação de fácil acesso.
• O link tem que ser acessível através do github io.

Descrição

realizar estudo sobre a implementação do banco de dados em django para que possam ser possivel realizar o cadastro de psicólogos no futuro

Tarefas:

• Estudar os modúlos de banco de dados e django.
• implementar os módulos no projeto na branch develop

Critério de aceitação:

A issue será aceita se o pulll request for devidamente aceito.

Descrição:

Criação do protótipo de baixa fidelidade.

Tarefas:

• Estudar e definir protótipo de baixa fidelidade do projeto
• Criação do documento

Critério de aceitação:

• estar coerente com modelos passados de outros projetos