search

fga-eps-mds / 2019.1-Gaia

A Gaia é um chatbot criada para auxiliar a vida dos praticantes de atividades ao ar livre, por meio da indicação e análise das condições climáticas. Organização do projeto: https://github.com/BotGaia Wiki do Projeto: https://fga-eps-mds.github.io/2019.1-Gaia/#/
GNU General Public License v3.0
7 stars 2 forks source link

Começar o post mortem #260

Closed lucianaribeiro closed 5 years ago

lucianaribeiro commented 5 years ago

Começar o post mortem

Nessa issue será realizado:

Critérios de aceitação:

AmandaMuniz commented 5 years ago

Neste semestre a arquitetura obrigatória para todos os grupos era a de microsserviços. Mas como montar uma quando nunca se fez algo semelhante? Como saber que as coisas que você está decidindo não são completamente erradas e vão prejudicar o restante do time? Não tem como. E esse foi o primeiro obstáculo que encarei exercendo o papel de arquiteta de software. A arquitetura tem que estar decidida na sprint 0 praticamente. Tudo depende dela. As tecnologias que EPS vai ter que ensinar, a priorização do que precisa ser feito, quando MDS vai começar a codar e como eles vão entender o que precisa ser feito. Ter essa pressão de entregar uma arquitetura rápida que garanta a viabilidade técnica do produto, respeite o escopo e as decisões da professora não é fácil. Na verdade, isso só me forçou a aprender o máximo que podia sobre arquitetura de microsserviços no menor tempo possível, para que eu conseguisse entregar algo.

Ser arquiteta me obrigou a encarar a segunda verdade desse papel: "as primeiras decisões que eu fizer vão estar erradas" e não tem como fugir disso. A curva de aprendizado é muito grande para pouco tempo. Equivocos vão ser cometidos, decisões serão feitas baseadas em puro desespero. Eu entreguei uma arquitetura completamente errada na primeira release. Ela não respeitava nem os princípios básicos da teoria de microsserviços. Todos os serviços que eu tinha criado dependiam de outros para funcionarem. Então, se Gaia-Local caísse todo o sistema caía. Encarar essa realidade foi essencial para meu aprendizado e para entregar uma arquitetura correta na release 2.

Mas nenhuma dessas decisões foi tão desafiadora como ter pessoas que acreditam em minhas escolhas como se elas fossem verdades absolutas. Ter MDS fazendo as coisas que eu pedia e EPS confiando no meu trabalho de olhos fechados, me fez perceber que para exercer o papel de arquiteta é preciso estudar o tempo inteiro, ter base teórica em todas as decisões e saber quando dizer "Não sei, me dá um tempinho para descobrir/aprender e decidir". E esse foi o maior aprendizado que EPS me proporcionou. Eu não vou saber e ter resposta de tudo na ponta da língua o tempo inteiro, mas posso estudar e fazer o melhor trabalho que conseguir pela equipe.

CalebeRios commented 5 years ago

Como DevOps, o primeiro passou foi descobrir o que era esse papel, já tinha ouvido falar, mas não sabia exatamente o que fazer. Li alguns artigos, li um livro e mesmo assim continuava perdido, não sabia sobre as ferramentas, pontos positivos e negativos e um monte de coisa.

Acho que o que eu mais aprendi foi de testar e realmente vê o que se encaixa com o projeto. Lembro que iniciei o projeto com uma stack de ferramentas, e bem na metade já estava tudo diferente, mas aprendi com esses erros e acertos.

DevOps dentro da disciplina é um papel que se souber dividir o trabalho, não fica tão pesado, basta saber fazer cada parte do trabalho na sprint certa. Mas acredito que depois de um tempo (e não só na disciplina) o papel não tem tanto sentido. O DevOps é muito importante no início do projeto, mas assim que tudo estiver configurado, não consigo ver sentido no papel dentro do projeto.