Added Brazilian Portuguese version of the postmortem

The portuguese version is also somewhat more complete. Changes will be later translated to english as to keep both mirrored.

Also changed the formatting of some lines to keep the non rendered markdown version easier to read.

docs/postmortem/postmortem.md

@@ -21,16 +21,13 @@ This would take as long as 4 months to implement somewhat properly, as there was
 > **06/04/24 :** One of the engineers tasked with developing the API learned html, which consumed precious time to learn API technologies. Even so, this would later help, as the engineer
 tasked with building the front-end would leave the project later.
 > 
-> **08/04/24 :** The university strike was announced. At this point, most of the project was still in its early baby steps, but still had possibility to be finished. Yet, the strike and the squad's
-decision to work only when the strike ended would prove to be a terrible idea.
+> **08/04/24 :** The university strike was announced. At this point, most of the project was still in its early baby steps, but still had the possibility to be finished. Yet, the strike and the squad's decision to work only when the strike ended would prove to be a terrible idea.
 > 
 > **26/04/24 :** The frontend's first version was finished. While still mostly crude, it was a good beginning and we had theoretically had time to finish it.
 > 
 > **07/05/24 :** It came to the squad's knowledge that no further presentations would take place until the strike came to an end. Mostly no changes to the base project was done during this period.
 > 
-> **17/05/24 :** The lead frontend engineer left the project. With no one else fully capable of working with html and able to understand the designs, this was the first nail in the coffin. As most other
-disciplines were launching their final projects and tests during the following period, the remainder of the members felt more urgency to focus on the active disciplines. With rare exceptions, no meetings
-were held during the aforementioned following period.
+> **17/05/24 :** The lead frontend engineer left the project. With no one else fully capable of working with html and able to understand the designs, this was the first nail in the coffin. As most other disciplines were launching their final projects and tests during the following period, the remainder of the members felt more urgency to focus on the active disciplines. With rare exceptions, no meetings were held during the aforementioned period.
 > 
 > **01/07/24 :** After the strike was finally over, the database scripts were concluded, but the squad mostly had no idea on how to use or connect the database, along with mostly no idea on how to construct the api, which relied on the database for its operations. This would put another nail in the coffin.
 > 
@@ -50,8 +47,8 @@ A crisp lack of urgency, organization, workforce, communication and know-how mad
 **1. Why was there no urgency?** - The schedules were constantly changing, which made it hard to predict when 
     exactly the squad was supposed to lock in or relax. 
 
-**2. Why was there no organization?** - When the strike raged on for two months, enough time passed without work most members 
-lost edge on the technology and had to spend time relearning in order to implement, which led to frustration and the eventual loss of 
+**2. Why was there no organization?** - When the strike raged on for two months, enough time had passed without work that most members 
+lost edge on the technology and were forced to spend time relearning in order to implement, which led to frustration and the eventual loss of 
 another member due to sluggish progress and no hope of successfully delivering the product.
 
 **3. Why was there no workforce?** - Already one of the smaller squads, the loss of the first engineer forced others to learn HTML and CSS
@@ -71,12 +68,13 @@ No resolution nor recovery was achieved. The project remain unfinished as of the
 The project may be finished after forking, but the current repo should remain as is to document this initial failure.
 
 ## Corrective and Preventative Measures
-In the future, the remainders of the squad 8 analyses the following preventive measures:
+The remainders of the squad 8 analyses the following preventive measures to allow a better future project:
 **1. There should be no sprint skipping whatsoever.** This messes up the flow of the project and catching up is much harder 
 in practice than in theory.
 **2. Communication should be, as XP ensures its much better, in person.** Working with other people is much easier in a physical environment 
 rather than a virtual one. And, above all, **proper communication must be ensured;** guaranteed.
 **3. Seeking help as soon as a roadblock is found** will be exponentially faster than fixing it alone. The team should work together to share
 knowledge. This could avoid alienation and/or isolation of the workers.
+**4. Using issues to track project needs** avoids the strange fenomenom where an engineer wants to help yet does not know where to. It's a powerful communication tool and should be used as such.
 
 As corrective measures would involve finishing up the work started, they will not be cited.

docs/postmortem/postmortem_ptbr.md

@@ -0,0 +1,78 @@
+5.000 / 5.000
+# Squad8 Postmortem: uma breve análise sobre falhas e teorias sobre como evitar falhar duas vezes da mesma forma.
+
+## Resumo do problema
+O Squad 8 falhou em entregar um produto satisfatório.
+
+Ao falhar em lidar com as restrições de tempo e retornar ao trabalho no projeto após o fim da greve da universidade, o squad 8 da disciplina MDS não conseguiu
+alcançar os resultados desejados para este software: um aplicativo de aluguel funcional e completo, capaz de conectar, receber e enviar informações para um banco de dados.
+
+## Linha do tempo
+> **22/03/24 :** O Squad foi formado, com os seguintes membros: Bruno, João, Pedro, Renan e Ryan.
+>
+> **28/03/24 :** Foi decidido que o Squad tentaria desenvolver um aplicativo de aluguel.
+>
+> **01/04/24 :** A arquitetura básica e os requisitos foram levantados. Muito mais tarde descobriríamos que essa arquitetura era falha, a API deveria conter também o
+webscrapper. Também dividimos as pilhas e tarefas entre os membros, primeiro focando em aprender as principais tecnologias que seriam usadas ao longo do projeto. a API também nunca chegou perto de ser implementada adequadamente nem completamente ou vagamente compreendida.
+>
+> **02/04/24 :** As escolhas de tecnologia iniciais foram selecionadas nesse dia. Apesar da falta de experiência com os membros para desenvolvimento web com nodeJS, por popularidade na indústria, foi a linguagem selecionada, juntamente com as frameworks React e Express para, respectivamente, o frontend e o backend. A escolha inicial do banco de dados seria o postgreSQL, mas foi posteriormente alterada para o MySQL, dado que o MySQL é o padrão que é ensinado dentro da nossa instituição.
+>
+> **04/04/24 :** O Github Actions foi implementado pela primeira vez neste dia. Um ticket informal para implementar isso foi postado no WhatsApp. Isso fornece o primeiro insight sobre o que deu errado. Levaria 4 meses até uma implementação mais adequada, pois não havia urgência, já que isso era encarado como um aspecto opcional do projeto.
+>
+> **06/04/24 :** Um dos engenheiros encarregados de desenvolver a API aprendeu HTML, o que consumiu um tempo precioso para aprender tecnologias de API. Mesmo assim, isso ajudaria mais tarde, pois o engenheiro encarregado de construir o front-end deixaria o projeto mais tarde.
+>
+> **08/04/24 :** A greve da universidade foi anunciada. Neste ponto, a maior parte do projeto ainda estava em seus primeiros passos, mas ainda tinha possibilidade de ser finalizada. No entanto, a greve e a decisão do esquadrão de trabalhar somente quando a greve terminasse findaria sendo uma péssima ideia.
+>
+> **26/04/24 :** A primeira versão do frontend foi finalizada. Embora ainda bastante rudimentar, foi um bom começo e teoricamente teriamos tempo para finalizá-la.
+>
+> **07/05/24 :** Chegou ao conhecimento do esquadrão que nenhuma outra apresentação ocorreria até que a greve chegasse ao fim. A maioria das alterações no projeto base foi feita durante este período.
+>
+> **17/05/24 :** O engenheiro líder do frontend deixou o projeto. Sem mais ninguém totalmente capaz de trabalhar com HTML e entender os designs, este foi o primeiro prego no caixão. Como a maioria das outras disciplinas estavam lançando seus projetos e testes finais durante o período seguinte, o restante dos membros sentiu mais urgência em se concentrar nas disciplinas ativas. Com raras exceções, nenhuma reunião foi realizada durante esse período.
+>
+> **01/07/24 :** Depois que a greve finalmente acabou, os scripts do banco de dados foram concluídos, mas o esquadrão não tinha ideia de como usar ou conectar o banco de dados, junto com a maioria das ideias de como construir a API, que dependia do banco de dados para suas operações. Isso colocaria outro prego no caixão.
+>
+> **15/07/24 :** O esquadrão decidiu se reunir três vezes por semana para compensar o tempo perdido no vazio da greve. Embora inicialmente tenha funcionado como pretendido, forçando os engenheiros a interagir e mostrar precisamente o que estava sendo feito e o que não estava, o plano acabou fracassando. Os engenheiros não conseguiram acompanhar as reuniões nem o ritmo de desenvolvimento necessário para consertar o produto a tempo para entrega. Fora a implementação do framework React para o front-end, até o prazo final, nenhuma grande mudança foi feita no projeto principal. Ele estagnou completamente.
+>
+> **31/07/24 :** A fusão do branch react no principal foi a última grande mudança feita no projeto e foi feita nesse dia.
+>
+> **02/08/24 :** Um pouco de funcionamento do CI foi finalmente colocado no principal. Ao mesmo tempo, metade da equipe se sentiu excluída do trabalho e alienada do projeto.
+>
+> **09/08/24 :** Depois de pedir ajuda a nossa mentora, um esforço foi colocado em movimento para reintegrar essa metade novamente ao projeto. Embora isso tenha se mostrado tarde demais, pois a metade integrada já estava esgotada.
+>
+> **15/08/24 :** Um dos principais engenheiros do React decidiu deixar o projeto. Este foi o último prego no caixão.
+
+## Causa raiz
+Uma nítida falta de urgência, organização, força de trabalho, comunicação e conhecimento de know-how fez com que este projeto fosse enterrado. Utilizaremos o sistema "5 Why's" para identificar a causa raiz.
+
+**1. Por que não havia urgência?** - Os cronogramas mudavam constantemente, o que tornava difícil prever quando exatamente o esquadrão deveria focar no projeto ou relaxar e focar em outras matérias. 
+
+**2. Por que não havia organização?** - Com a greve durando dois meses, passou tempo suficiente sem trabalho e prática para que a maioria dos membros
+perdesse o domínio sobre a tecnologia utilizada, forçando o esquadrão a reaprender. Isso levou à frustração e à eventual perda de
+outro membro devido ao progresso lento e nenhuma esperança de entregar o produto com sucesso.
+
+**3. Por que não havia força de trabalho?** - Já sendo um dos esquadrões menores, a perda do primeiro engenheiro forçou outros a aprender HTML e CSS
+do zero, o que provou ser um ponto único de falha.
+
+**4. Por que houve menos comunicação?** - Inicialmente, durante a greve, nenhuma comunicação real foi necessária. Quando a greve terminou, a comunicação subsequente foi recebida com dificuldade.
+
+**5. Por que não havia conhecimento de know-how?** - O esquadrão fora formado sem genuínos veteranos em nenhuma das tecnologias que seriam usadas, o que significa
+que a maior parte do aprendizado precisaria ser construída do zero. Isso também diz respeito a aproveitar ao máximo as Metodologias Ágeis ensinadas durante as palestras, dado que os membros tiveram a maior parte de sua experiência acadêmica com software até este ponto em projetos e avaliações individuais.
+
+Podemos concluir que a causa raiz desta morte foi um longo período sem trabalho no projeto, levando a uma espécie de "ferrugem". A greve foi um dos principais contribuintes para esta condição, o que levou à interrupção do trabalho pelo referido longo período de tempo.
+
+## Resolução e recuperação
+
+Nenhuma resolução nem recuperação foi alcançada. O projeto permanece inacabado no momento da escrita do presente documento e permanecerá assim indefinidamente.
+O projeto pode ser concluído após uma bifurcação, mas o repositório atual provavelmente permanecerá como está para documentar essa falha inicial.
+
+## Medidas corretivas e preventivas
+O restante do esquadrão 8 analisa as seguintes medidas preventivas para facilitar projetos futuros:
+**1. Nenhuma sprint deve ser pulada.** Isso atrapalha o fluxo do projeto e recuperar o atraso é muito mais difícil
+na prática do que na teoria.
+**2. A comunicação deve ser, como o XP garante que é muito melhor, pessoalmente.** Trabalhar com outras pessoas é muito mais fácil em um ambiente físico
+do que em um virtual. E, acima de tudo, **a comunicação adequada deve ser garantida;** garantida.
+**3. Buscar ajuda assim que um obstáculo for encontrado** será exponencialmente mais rápido do que consertá-lo sozinho. A equipe deve trabalhar em conjunto para compartilhar
+conhecimento. Isso pode evitar alienação e/ou isolamento dos engenheiros.
+**4. Utilizar as Issues para corretamente mapear as necessidades do projeto** evita o estranho fenômeno onde o engenheiro quer trabalhar mas não tem certeza de onde realizar o serviço. É uma poderosa ferramenta de comunicação e deve ser usada como tal. 
+
+Como as medidas corretivas envolveriam terminar o trabalho iniciado, elas não serão citadas.