docs/Post_Mortem.md
# 💀 Post Mortem
<p align="justify"> Este documento tem o objetivo de ser uma análise critica de todo o projeto, de suas etapas de desenvolvimento até seu final, sendo feito a partir da visualização de como ele se encontrou em sua etapa final, levantando pontos positivos e negativos, como as experiências adquiridas no processo. A sua leitura é de extrema importância para auxiliar projetos futuros.</p>
## 👌🏼 Pontos Positivos
* Toda a equipe sempre se manteve empenhada na execução, sempre mantendo uma boa comunicação, facilitando o projeto.
* O aprendizado dos métodos ágeis facilitou muito o desenvolvimento, a aplicação de rituais do Scrum como do Xp, possibilitaram o bom andamento do projeto.
* Tivemos a oportunidade de trabalhar com diversas bibliotecas do Python, como também com diversas tecnologias, como o Code Climate.
* Aprendemos sobre a comunidade Open Source, sobre como essa comunidade é grande e como interagir e contribuir com ela.
* Aprendemos muitas palavras novas do mundo de software, que ajudaram e ainda vão ajudar a entender vários contextos do mundo de software, como spike e regex.
* Nos familiarizamos ainda mais como o Git e GitHub, o que será bastante util para toda nossa carreira como engenheiros de software.
<br>
## 👎🏼 Pontos Negativos
* A arquitetura do projeto foi um desafio, não entendiamos muito bem como organizar a arquitetura de um pacote Python.
* Perdemos muito tempo tentando converter um template de certificado em docx para pdf, sendo que deveríamos ter usado um template html desde o início.
* Como todos estavam focados no desenvolvimento, não demos muita importância para outras plataformas que o projeto poderia ser desenvolvido, fazendo com que ele só tenha sido desenvolvido para Linux.
* Algumas ferramentas foram difíceis de utilizar e tiveram que ser dispensadas, ou até mesmo não se tinha necessidade de estar no projeto, como, por exemplo, o Docker.
* Semestre curto e que deu menos tempo para desenvolvermos o projeto.
<br>
## 🔮 Propostas para o futuro
* Comece a se preparar o mais rápido possível, a cada minuto perdido pode dificultar na entrega do projeto, como diz a professora: "Vocês já estão atrasados".
* Importante definir o escopo do projeto de maneira realista e fazer um cronograma semanal com as atividades dos membros
* Define bem o papel de cada membro, para não haver dificuldades em delegar responsabilidades e cumprir elas.
* Não esqueça dos testes unitários, você pode acabar economizando um bom tempo de desenvolvimento.
<br>
## ✍🏼 Experiência Individual
* **🗿 Victório Lázaro (Scrum Master)**
<p>Minha experiência nessa matéria foi muito desafiadora mas ao mesmo tempo muito recompensadora. Por exemplo, aprendi que na área de desenvolvimento de software não é importante saber todas as tecnologias e linguagens de programação existentes, mas sim que é necessário saber estudar novas tecnologias. Além disso, minha experiência como Scrum Master me mostrou a importância desse cargo em um time que segue a metodologia Scrum já que o Scrum Master é responsável por direcionar para onde o software pretende alcançar além de organizar o tempo de forma que a equipe consiga desenvolver todo o escopo planejado em tempo de entrega.</p>
<p>Um conselho que eu dou para os futuros Scrum Masters da disciplina é que é importante o seu envolvimento direto com o código, mesmo que um Scrum Master gaste muito tempo em planejamento, é importante ter uma boa visão da situação e funcionamento do software.</p>
<p>Os meus conselhos para os alunos futuros dessa disciplina são:</p>
<ul>
<li>Estabeleçam uma boa comunicação com seu time, vocês precisam passar pelas várias etapas de desenvolvimento de um projeto em um curto período de tempo e com uma equipe reduzida, então é importante que os membros do time compartilhem uma mesma visão sobre o projeto e estejam engajados para entregar o projeto;</li>
<li>Definam o escopo/features desse projeto depressa porque, como eu já citei, a equipe têm pouco tempo para desenvolver o projeto, logo é importante que a equipe passe para a etapa de escrita de código logo pois surgirão muitos erros e dúvidas nessa parte;</li>
<li>Montem cronogramas semanais realistas, de maneira que a equipe consiga entregar o definido no escopo com base no trabalho semanal e ainda consigam realizar as atividades das outras disciplinas.</li>
</ul>
<br>
* 🧐 **Pedro Henrique da Silva Melo (Product Owner)**
<p> Métodos de Desenvolvimento de Software foi uma experiência na qual pude ter contato com uma equipe diferente e que já possuiam contato entre si. A equipe se mostrou bem proativa apesar de tudo e abraçamos o tema que foi escolhido para trabalharmos da melhor forma que conseguiamos. A partir disso, sofremos bastante no começo com relação as tecnologias visto que tentavamos implementar funcionalidades e havia momentos que não davam certo a integridade entre uma com a outra. Mas com muita pesquisa e esforço, o grupo conseguiu trabalhar bem durante todo o período disponível, apesar de termos várias dificuldades em certos momentos. </p>
<p> A matéria foi um grande desafio pra mim porque eu achava que precisariamos estudar muito aprofundado a tecnologia escolhida e nisso implementar o que era necessário. Porém a matéria abriu meus olhos para a Engenharia de Software e me mostrou que precisamos estudar apenas o que é necessário para cada momento e que o principal era sabermos pesquisar o que precisávamos para aplicar dentro do nosso projeto. Para que assim o aprendizado seja adquirido de forma prática. Além disso, as metodologias aprendidas tiveram um ótimo proveito visto que tentamos aplicar a maioria na prática e também no contexto do nosso grupo. Assim, eu percebo que foi bem proveitoso a forma na qual tentamos aprender as metodologias e aplicá-las ao mesmo tempo, seguindo o que foi ensinado pela professora, o que envolveu aprendermos a aprender Engenharia de Software. </p>
<p> Em relação ao grupo, eu sinto que tivemos uma sinergia boa mas que em certos momentos pecávamos em aspectos esperados para um bom trabalho em equipe, o que envolveu uma falta de soft skills. O que eu senti que faltou para nós como grupo foi a questão da comunicação em certos momentos, visto que uma ou mais pessoas realizavam atividades e não costumavam atualizar o grupo sobre isso, realizando esse tipo de ação apenas nas reuniões semanais. Isso me desmotivou porque eu sentia em certos momentos que estava perdido no trabalho. Já que atualizações no projeto ocorriam e só eram relatados nas reuniões semanais. Além disso, o pair programming em certas horas não se mostrou o mais eficiente visto que a pessoa que estava trabalhando no código podia ter sido a com menos experiência para que ela pudesse aprender mais com os erros enquanto o co-piloto fosse uma pessoa mais experiente e que conseguisse orientar o piloto. Isso para que os membros menos experientes pudessem aprender tanto quanto os com mais conhecimento. Eu digo isso porque me vi na situação da pessoa mais inexperiente, em determinados momentos, que acabava sendo o co-piloto e não sabia bem como orientar o piloto na hora de realizar a atividade do momento. Portanto, levar essas questões como ensinamentos é importante para melhorar o trabalho em equipe. </p>
<p> Atuei como product owner porém não me senti tão confortável em ter tido esse cargo. Isso porque eu acredito que não consegui exercer bem a função do PO e mesmo tentando buscar formas para isso. Apesar disso, busquei levar ideias para o grupo quando discutiamos o trabalho, além de que também pude atuar como um desenvolvedor em conjunto com os outros membros para criarmos as principais funcionalidades do projeto. Em trabalhos futuros pretendo tentar exercer uma função diferente e buscar me desenvolver melhor nela. </p>
<br>
* **🥸 Daniel dos Santos (Desenvolvedor)**
<p> Essa matéria me trouxe uma grande experiência, quebrou alguns dos paradigmas que eu achava que seria desenvolver um projeto real com uma equipe, como sempre trabalhei sozinho, achei que seria difícil me adaptar a trabalhar em grupo, mas no final gostei da experiência.</p>
<p> Tive algumas dificuldades no começo com relação às tecnologias e as bibliotecas, já tinha tido alguma experiência com a linguagem, mas não tanto quanto esse projeto exigiu, mas o bom trabalho em equipe e as orientações da professora, sobre aprender a aprender, ajudaram a dar prosseguimento no projeto da melhor forma possível.</p>
<p> Dessa vez só desempenhei o papel de desenvolvedor, mas aprendi muito sobre as metodologias ágeis, como Scrum e Xp, em um próximo projeto gostaria de poder trabalhar em outras funções.</p>
<br>
* **Leandro Silva (Desenvolvedor)**
<p>Estava com um pouco de medo de ficar sobrecarregado na matéria, porém esse medo logo passou, pois o nosso projeto foi bem organizado e ficou tranquilo para todos trabalharem. Conheci diversos dialetos e tecnologias da engenharia de software, que eu nunca tinha ouvido falar e também me deu uma visão da área em que vou querer trabalhar futuramente.</p>
<br>
* 😈 **Pedro Sampaio (Desenvolvedor)**
<p> Iniciamos o projeto de gerador de certificados com uma visão otimista de que seria uma tarefa fácil e sem complicações, dado o seu objetivo simples. No entanto, conforme avançamos na implementação, enfrentamos desafios inesperados que impactaram significativamente o andamento do projeto.
  Nos primeiros sprints, tudo estava fluindo conforme o planejado, adicionamos os documentos do Community Standards e os arquivos foram sendo criados. No entanto, quando começamos a lidar com documentos PDF, tudo começou a dar errado. Passamos duas semanas tentando resolver o problema com bibliotecas de gerenciamento de PDF, mas sem sucesso. Devido a essa escolha equivocada de tecnologia, optamos por mudar para uma biblioteca capaz de lidar com documentos DOCX. Infelizmente, passamos mais duas semanas sem progresso no projeto e um mês inteiro testando tecnologias que no final não foram utilizadas. No final, optamos por fazer um template em HTML, substituir os campos e depois transformar em PDF.
  Adotamos uma metodologia de aprender com nossos erros, e ao olhar para trás, há algumas decisões que eu faria diferente. No entanto, gostei bastante da metodologia da disciplina, pois permitiu que aprendêssemos por nós mesmos e compartilhássemos conhecimento.
  Apesar dos obstáculos enfrentados, o projeto foi uma ótima oportunidade para aprender e desenvolver nossas habilidades. Esperamos que esses aprendizados possam ser aplicados em projetos futuros para evitar erros similares.
</p>
<br>
* 🥵 **Blimblim (Desenvolvedor)**
<p> Ao início do projeto, houve uma falta de motivação devido à falta de uma compreensão clara do objetivo final da aplicação. No entanto, o projeto continuou avançando e ganhando forma, o que ajudou a motivar os membros do time e torná-lo mais interessante de se trabalhar.
   O principal problema foi termos começado utilizando manipulação de documentos PDF. Após muitos erros, mudamos para DOCX, que também não foi uma boa escolha. Após semanas decidimos fazer a manipulação em HTML e depois converter para PDF.
   A metodologia adotada na disciplina foi capaz de nos mostrar como aprender rapidamente, pesquisar melhor e permitiu que aqueles com mais conhecimento sobre determinado assunto pudessem compartilhar o conhecimento com os outros. Por mais que o projeto tenha sido mais trabalhoso do que o planejado inicialmente, o ritmo foi bem tranquilo e permitiu ter um aprendizado melhor e mais espaçado.
   Ao longo do projeto, foi possível entender melhor o que um usuário espera de uma aplicação e isso teve um impacto significativo na evolução do projeto. No final, o projeto foi um grande divisor de águas e o pensamento dos membros mudou bastante do início do projeto até o final, as habilidades já existentes foram evoluídas e habilidades novas foram desenvolvidas. `</p>`