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

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.

“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