docs/Post_mortem.md
# Pontos Positivos
- Grupo proativo e sempre buscando o melhor para todo o projeto, com todos bem cientes sobre a situação atual do produto
- Comunicação efetiva desde as primeiras sprints até o final, sempre discernindo bem os momentos de descontração com os de seriedade tornando a equipe bem unida
- Testes de softwares desde o início da Release 1 permitiu uma cobertura de 100% no backend e de cerca de 91% no frontend
- O conhecimento conseguiu ser compartilhado por todo o grupo
- Todas as user stories necessárias do roadmap foram concluídas com sucesso
- Grupo esteve bem adiantado em relação à alguns temas da matéria e isso ajudou muito
- Processo de revisão de pull requests muito bem feito desde as sprints iniciais
- Pesquisar como seria feita a implementação de features futuras
- Constante refatoração de código
- Mudança dos pareamentos, o que ocasionou uma maior integração da equipe
- Concentração do recurso humano na área mais forte de cada um.
- Equipe bem confiante e aberta para o desenvolvimento de novas features no projeto.
- Grupo sempre disposto a ajudar em issues que não foram designadas a eles.
# Pontos Negativos
- Pouca ou nenhuma comunicação/documentação dos processos de desenvolvimento das issues
- Quase sempre tínhamos issues da semana atrasada e isso acabou virando uma bola de neve em algumas sprints
- Infelizmente não conseguimos implementar algumas user stories adicionais
- Muitas funcionalidades a serem implementadas num curto tempo
- Atraso de issues comprometeram o planejamento em algumas sprints
# Recomendações
- Pensem bem nas issues de backlog e em todo o escopo do projeto porque isso ajuda e muito no andamento do projeto
- Tentem sempre estarem adiantados em relação aos temas abordados na matéria, principalmente testes e DevOps, pois isso ajuda muito em um desenvolvimento eficaz do trabalho
- Tentem ao máximo criar um grupo comunicativo e unido porque além de diminuir o estresse da semana, facilita e muito no progresso do projeto
- Scrum masters, utilizem tecnologias como o zenhub para metrificação da equipe, TeamRetro ou Miro para as retrospectives e o planning poker para a pontuação das issues. Isso ajuda bastante a entender como está o desenvolvimento da equipe e como melhorar.
- Façam um protótipo o mais completo possível para evitar constantes refatorações
- A matéria é bem puxada então tome cuidado com o seu tempo e saúde mental.
- Não tenham medo de aprender tecnologias novas, Google sempre está aí para ajudar
- Tomem cuidado com o Vital porque issue na mão dele é certeza que alguma coisa vai quebrar
- Ter em mente um período da semana, fora o tempo de aula, para poder trabalhar nas responsabilidades da matéria.
- Discutir bem com a equipe qual dia é o ideal para o início da Sprint, o que pode mudar bastante a produtividade da equipe
- Iniciar as issues o quanto antes após a sprint review para não acumular.
# Frases
- `“Eu não fiz nada no final de semana” - Calixto em todas as dailies da segunda feira`
- `“Ele ta me dando erro 400” - Vital e seu docker bugado`
- `“Ontem tinha funcionado, hoje não” - Vital`
- `“Eae bora refatorar todo o back ?” - João`