Post Mortem

Introdução

Este documento tem por finalidade fornecer uma avaliação crítica quanto ao projeto, realizado na etapa final, é de suma importância sua leitura, pois ele contém informações cruciais para auxiliar no desenvolvimento de projetos futuros.

Pontos do Projeto

Positivos

Nossa equipe sempre esteve muito engajada no projeto, todos se empenharam muito durante o seu desenvolvimento, o que realmente facilitou todo o processo.
Nossa equipe não tinha muita experiência, então tudo era novo, o que nos permitiu aprender muito. Aprendemos muito sobre metodologias ágeis como o scrum, e sobre como trabalhar em equipe, utilizamos as funções de Scrum master, Product Owner, Devops …, não tínhamos muita noção de trabalho em equipe, mas todos nos demos bem e conseguimos fazer funcionar.
Por não termos EPS nos tornamos muito mais independentes, mesmo o monitor que foi designado para nos ajudar não esteve muito presente, então sempre tínhamos que descobrir tudo por nós mesmos, parece algo negativo, mas na verdade contribuiu bastante para criarmos uma visão mais crítica de todo o projeto.
Tivemos a oportunidade de utilizar diversas tecnologias que nem sabíamos que existiam como React, Flask, docker, heroku??,o que foi bem assustador de início, mas deu tudo certo.
Projetos Open Source eram um mistério, mas agora entendemos melhor como funcionam. LINUX é bacana, no começo é um susto, mas todos se comprometeram em utilizá-lo, saber se virar com linux é bem importante para um programador.
Nós conseguimos desenvolver muito vocabulário de programador na disciplina, sempre aparecia algum nome diferente que nunca tínhamos visto, mas depois de vê-lo, era só pesquisar e descobrir o que era.
Agora temos mais direcionamento em relação à carreira que podemos construir, tem o front-end, back-end, devops, todo mundo começa como programador padrão, mas agora somos capazes de pelo menos tentar a sorte em algum estágio.
Github é MUITO importante para qualquer programador, finalmente tivemos a oportunidade de utilizá-la á fundo e continuaremos a usá-la por um bom tempo.

Negativos

O escopo do projeto foi mal definido, tivemos que refatorar algumas vezes durante o projeto, o que acabou gastando um tempo que poderia ser melhor utilizado caso o escopo fosse bem definido.
Normalmente os PR’s demoravam muito para serem avaliados, isso devido ao fato de termos ciência da importância de uma boa avaliação causou um sentimento de “deixa pra depois que avalio melhor” no pessoal e atrasou bastante algumas issues e métricas.
Um fator importante do nosso escopo que era a responsividade do app poder ser usado de dispositivos mobiles foi focada só no final do projeto, o que prejudicou sua visualização pois teria que refatorar um “pouco” de código para poder implementar da melhor maneira.
Essa disciplina demanda muito tempo e dedicação, muito mais do que os créditos pré-estabelecidos, o ideal seria pegar menos matérias do que o fluxo oferece, pois se não fica bem pesado.

Conselhos para projetos futuros

A comunicação é um fator extremamente importante, então investir em uma boa comunicação integra bem mais o time, fornecendo um espírito de equipe e união que funciona como base para ânimo durante o projeto.
Explorar os repositórios antigos foi a atividade mais importante para o início do projeto, pois eles são uma boa base para se apoiar no momento de desespero inicial da disciplina haha.
Tivemos muita dor de cabeça na implementação de testes de qualidade de códigos estáticos (codeclimate, sonarcloud) e o lint, foram muitos problemas para consertar, então utilizar o lint desde o começo é uma excelente prática.
Explore ao máximo a utilização de batedores(membros que estudam determinado assunto e passam pro resto da equipe ) em pareamento no início do projeto, isso facilita a integração do time…
Ter uma boa definição do escopo com o que é possível de ser feito é extremamente importante para o projeto como um todo, então na hora de definir funcionalidades pega leve para conseguir entregar tudo, foquem mais nos pontos principais do produto.
Não tenham medo de mudanças, mudar é importante em alguns cenários, principalmente quando se refere a produtividade da equipe (Ínicio de sprints, rotação de pareamento).
Cuidem da saúde mental de vocês, promover alguma atividade extra como jogos pode ser interessante em um cenário remoto, se tiver possibilidade de se encontrar, se encontrem, lanchem, conversem sobre a vida, busquem conhecer melhor uns aos outros, pois ter uma equipe unida facilita muito.
Se possível não pegue muitas disciplinas, MDS oferece muito conhecimento, porém é necessário ter tempo para estudar.

Feeling individual

Rafael Ramos (Scrum Master)

Sempre escutei frases do tipo “MDS é muito pesado e demanda tempo”, “O curso de software é separado em pré-MDS e pós-MDS” e realmente todas essas frases parecem ter um pouco de sentido, senti que vivi toda essa experiência com muito tempo dedicado e muito conhecimento adquirido, porém o mais importante que molda essa experiência é ter uma boa equipe que esteja interessada em aprender e se desenvolver juntos.

Pensei que desempenhar o papel de Scrum Master não seria algo muito difícil de ser cumprido pois já conhecia alguns membros da equipe e saberia lidar um pouco com cada, porém foi algo extremamente desafiador pois manter viva as práticas ágeis em um semestre tão pesado pra todos não é uma tarefa fácil, sinto que aprendi muito melhor como me organizar, como me comunicar de maneira mais clara, além analisar melhor algumas métricas importantes para uma equipe de software.

O único ponto negativo que penso da minha experiência foi que além do tempo dedicado a documentação e análise de métricas, “pulei muito de galho em galho” para promover uma melhora na equipe como um todo, e acabei perdendo algumas partes importantes como desenvolvedor, por exemplo, enquanto eu sentia que todo mundo estava aprendendo e se especializando mais em alguma tecnologia específica, eu me sentia um pouco atrás, sabendo um pouco de tudo mas não sabendo nada kkk, porém desempenhar algumas atividades de devops como testes e automatização, além de realizar algumas issues no front-end me trouxeram ânimo de aprendizado novamente, então ao final de tudo com muito esforço, sinto que valeu a pena.

A mensagem que fica da minha experiência como um todo é gratidão, muita gratidão ao meu time, sério, são pessoas que tenho hoje como família ! Nos divertimos muito com as gameplays de gartic ao final das sprints, sinto que posso contar com cada membro, após vivenciar e ouvir algumas experiências com trabalhos em grupo na faculdade sinto que essa foi minha melhor experiência. Além de me sentir parte de algo que realmente tem valor,a todas pessoas que apresento o produto acham a ideia bacana, principalmente os universitários haha !

Rodrigo Balbino (Product Owner)

Essa foi a primeira disciplina que senti que estava desenvolvendo algo real que tivesse algum tipo de valor como engenheiro de software, claro que deu aquela ansiedade por estar pegando essa matéria, já havia ouvido sobre a matéria e sabia que não seria algo simples. Por acaso dei a ideia sobre o tema do nosso projeto e acabei virando o product owner, não entendia muito do que estava acontecendo mas sempre tentei ajudar como podia. Inicialmente senti um pouco de dificuldade em relação ao github e as documentações que precisavam ser feitas, não tinha tido muita experiência em relação a nada disso, e todos pareciam estar se saindo muito bem.

A primeira parte do projeto foi mais voltada à documentação, o que foi frustrante pois não tínhamos EPS, eles que fariam essa parte, iniciei a matéria achando que aprenderia muita programação e estava com todo gás pra trabalhar. Infelizmente o gás passou, depois da release 1 foi que iniciamos a programação, fiquei responsável pelo back-end usando Python e Flask, infelizmente nesse período todas as matérias começaram a requisitar muita atenção, até PI1 que estava tranquilo acabei assumindo liderança. Mesmo estudando todos os dias, apenas liberando sábado ou domingo no final de semana, estive sempre atrasado em relação a MDS, tudo era pra ontem, me faltava tempo.

Estive sempre correndo pra tentar entender o que estava acontecendo, em algum momento tudo começou a desandar, mas toda a equipe ajudava bastante, então o projeto nunca parava. Fui um Product Owner muito ruim, não consegui ajudar tanto quanto queria, não consegui aprender tanto quanto gostaria, tenho certeza que se tivesse pego menos matérias e tivesse mais tempo para focar nessa disciplina teria sido capaz de me desenvolver muito melhor, teria conseguido ajudar mais.

Roberto Mangabeira (Desenvolvedor)

Então, desde que comecei a cursar engenharia de software senti que não estava fazendo algo que realmente condizia com a realidade. Isso mudou completamente com MDS. Diferente de muitos, eu não havia ouvido muito dessa matéria e quando comecei a fazê-la, percebi que seria necessário muita dedicação. Fiquei com papel de desenvolvedor o que achei perfeito para mim, e assim comecei a matéria.

Nas primeiras semanas, parte da confecção das documentações iniciais do projeto, confesso que não me senti muito animado. A falta de EPS fez com que eu me sentisse perdido em muitos momentos. Entretanto, com o passar das semanas entendi que esse era um projeto inteiramente planejado e executado por nós, um grupo de 6 pessoas, então para tudo seria nós que buscaríamos, aprenderíamos e faríamos.

Então, com esse sentimento de independência, entramos nas semanas de programação e foi aí que realmente além de aprender mais, errei mais também. O bom de MDS é que você não sente medo de tentar nem de errar, você sabe que está aprendendo, assim como todos do seu grupo, então coragem para tentar novas soluções nunca faltaram. Além disso, errar é bom, pois futuramente é possível escolher os melhores caminhos baseado em suas experiências passadas. A existência de um grupo que trabalha com você é gatilho para se esforçar, aprender e evoluir mais com o passar dos dias. O período de programação também não foi só flores, como eu não tinha muito conhecimento sobre MDS peguei muitas outras matérias e por vezes me senti sobrecarregado e muito cansado. Tinha semanas que estava muito animado e fazia muito para matéria, pois gostava muito dela, outras que não tinha tempo nem gás.

Todas essas experiências me mostraram que, por vezes, estamos muito bem, e por outras, nem tanto, e a presença de um grupo ajuda muito no decorrer da matéria. Só tenho a agradecer todos meus incríveis companheiros que compartilharam essa jornada comigo. Por fim, MDS foi demais para mim, me sinto maduro, mais esperto, me sinto parte de algo ao qual muitas pessoas deram suor e esforço, de algo bom.

Thiago Sampaio (DevOps)

Comecei a matéria bastante ansioso porque, sem EPS, tudo parecia nebuloso, não tinha um roteiro a seguir, ainda mais sabendo que já estávamos atrasados, pois demoramos para definir um tema. No entanto, a falta de EPS não foi tão ruim, pois ter a oportunidade de tomar a decisão por si só e errar, errar muito, foi muito importante para o nosso amadurecimento.

No começo, felizmente ou não, consegui fugir um pouco da documentação porque tive a honra de poder configurar o ambiente, não muito bem porque era tudo muito novo, para desenvolvermos. Se eu pudesse voltar no tempo, acredito que não teria o background suficiente para isso, mas, após a configuração do ambiente, teria começado a configurar todos os testes e a documentação da API porque fazer isso no final do produto é MUITO trabalhoso, mas extremamente importante.

Outra coisa imprescindível é ter uma equipe bastante comunicativa, interativa e diferente. A diversidade foi muito importante porque um conseguia completar a falha do outro. Ainda mais no começo, essa diversidade foi o diferencial, uma vez que mal sabíamos o básico das linguagens do projeto, então o aprendizado conjunto e o pareamento foi fundamental. Todos foram ótimos, e tive muita sorte de ter a oportunidade de desenvolver o Anunbis.

Victor Hugo (Desenvolvedor)

Foi minha primeira experiência desenvolvendo algo que de fato possa ter um valor de mercado, que se aproxima mais da realidade de como é o fluxo de trabalho de um desenvolvedor de software, eu não tinha muita informação da disciplina, então não sabia muito o que esperar, por isso quando começou e a professora já fala que estávamos atrasados, assustou um pouco, a falta de experiência no desenvolvimento de aplicações neste estilo dificultou bastante, principalmente durante as primeiras semanas de projeto, que fiquei bastante perdido no que fazer, porém, apesar de algumas vezes sentir que estava atrás em relação aos outros membros do grupo, com o tempo entrei no ritmo e entendi o que a professora quis dizer no início do semestre.

As conversas, brincadeiras, zoeiras e partidas competitivas no gartic ajudaram a tornar os membros do grupo muito mais próximos e isso refletiu bastante durante o desenvolvimento, a equipe se tornou bastante unida, sempre dispostos a ajudar em qualquer aspecto, com uma boa comunicação e cada um dando tudo de si a cada semana, para podermos entregar um produto de boa qualidade. Com o andamento do projeto, fomos amadurecendo em conhecimento nas tecnologias que escolhemos, aprendendo novas práticas e conceitos utilizados em um projeto de desenvolvimento de um software Open source.

Portanto, apesar de ter sido um semestre muito cansativo, com várias disciplinas que exigiam bastante, o sentimento que tenho hoje é de realização, conquista, de gratidão a minha excelente equipe, de estar mais maduro não somente como desenvolvedor, mas como pessoa também, MDS deu um gás pra continuar a faculdade e por isso só tenho a agradecer.

Eduardo Afonso (Desenvolvedor)

Nós praticamente adotamos a metodologia de aprender com nossos erros, então tiveram alguns que voltando atrás eu faria diferente. O primeiro é quanto ao escopo do projeto, é importante ter bem definido qual será o público alvo exato que a aplicação vai atender, assim todo o projeto vai girar em torno das necessidades dele. Outra coisa seria a escalabilidade do produto, é importante pensar no produto final de um jeito que ele consiga receber e apresentar múltiplos dados e não só os que são utilizados na produção. E por último a padronização do código, é importante definir logo cedo quais serão os padrões a serem seguidos (idioma, estilo de escrita das variáveis e funções, etc)

Eu gostei bastante da metodologia da disciplina, nós ficamos livres para aprender por nós mesmos e trabalhar em equipe para ajudar os outros. Eu fiquei basicamente todo o período da disciplina trabalhando no front-end e no final fui fazer algumas partes do back-end, mas acho que se essa transição fosse feita mais cedo eu seria capaz de aprender bem mais. Foi uma ótima experiência e acho que todos conseguimos extrair bastante da disciplina, nós seguimos bem as práticas ágeis e acho que no fim deu tudo certo.