Issue: Iniciar escrita do postmortem 
Repositório: 2019.2-Acacia
Data: 31/10/2019
Status: Fechado

Closed
1 task done
Iniciar escrita do postmortem
#150
fabiolamfleury opened this issue on Oct 31, 2019 · 8 comments
Comments
@fabiolamfleury
Member
fabiolamfleury commented on Oct 31, 2019 • 
Exemplo https://fga-eps-mds.github.io/2019.1-MaisMonitoria/docs/doc-postmortem
Descrição
Eu, como integrante do time, gostaria de iniciar a escrita do postmortem para documentar os aprendizados da equipe quanto ao projeto.

Critérios de Aceitação

Deverá apresentar a estrutura completa do documento;
Deverá apresentar sentimentos de todos os membros da equipe;
Tarefas

 Criar a estrutura;
@fabiolamfleury fabiolamfleury added development team documentation EPS labels on Nov 1, 2019
@fabiolamfleury fabiolamfleury added this to the Sprint 10 milestone on Nov 2, 2019
@fabiolamfleury fabiolamfleury assigned mardntas, fabiolamfleury, vitorcx, shayanealcantara, LeoSilvaGomes-zz, jps12, flaviovl, RenatoBrittoAraujo and durvalcarvalho on Nov 2, 2019
@LeoSilvaGomes-zz
Collaborator
LeoSilvaGomes-zz commented on Nov 8, 2019 • 
O intuito da plataforma, trouxe muito interesse e empatia sobre âmbito que estávamos atacando, trazendo mais para perto, visões que não eram do meu cotidiano. Entretanto, esse sentimento foi se esvaziando ao decorrer de quando a equipe mostrou confuso acerca do que se tratava o produto, principalmente porque não tínhamos um cliente e o escopo deveria ser definido por nós. Dessa forma, mesmo que ao início do projeto eu estivesse muito animado com tudo que estava ocorrendo, durante a execução, esse sentimento foi diminuindo até a R1, onde posteriormente tivemos um melhor esclarecimento das coisas como equipe. Além disso, conseguimos aplicar mais no que era de interesse próprio, o contato com a equipe foi maravilhoso, principalmente a ajuda que tivemos dos EPS e entre MDS, onde cada um se especializou em uma tecnologia de interesse. No final do projeto entrou o desespero para a entrega da R2, assim comecei a ficar desesperado e tentar terminar/ajudar nas issues que não estava assigned. Claro que tivemos nossos desvios para não surtamos de vez, mas senti que não iria dar tempo (Não sei se vai dar ainda).

@KiSobral
Member
KiSobral commented on Nov 8, 2019
Poder trabalhar como um time, alinhado por uma causa e propósito, tem sido maravilhoso.
Entretanto, esta nem sempre foi a situação da equipe da Acácia, o começo do projeto foi uma fase dura e confusa, em que alguns dos membros se encontravam perdidos em meio ao andamento do projeto e dos porquês de estarmos trabalhando da forma como estávamos (e ainda estamos) trabalhando.
Ainda assim, com o passar do tempo a equipe foi se unindo cada vez mais, e cada vez mais eu consegui me sentir pertencente a um time de trabalho.

Além disso, o contato com um projeto grande me possibilitou o aprendizado sobre metodologias de desenvolvimento e a especialização em algumas das tecnologias que estamos usando para a construção da Acácia.

Por fim, restam apenas alguns traços de preocupação em volta do tempo restante de trabalho, já que a matéria de MDS/EPS possui um ritmo acelerado quando comparado à quantidade de trabalho necessária.

fabiolamfleury pushed a commit that referenced this issue on Nov 8, 2019
@fabiola-m
#150 Create post mortem structure
ee34dba
@fabiolamfleury fabiolamfleury mentioned this issue on Nov 8, 2019
Estrutura do postmortem e atualização do roadmap #162
 Merged
@shayanealcantara
Collaborator
shayanealcantara commented on Nov 8, 2019 • 
O começo da disciplina foi um desafio para todos os membros, principalmente na aplicação da metodologia alvo. Foi complicado para o time de MDS reconhecer as utilidades da correta adoção das métricas e isso acabou causando um estresse. No entanto, com o passar do tempo e com discussões construtivas, o grupo todo amadureceu bastante essas questões e pode se preocupar com outras questões mais importantes. Notamos desde o começo alguns membros que não se sentiam muito confortáveis em trabalhar com pareamento ou que se sentiam inseguros em relação aos outros membros, em questões de conhecimento. Percebemos que isso seria um problema se não tratado rápido e não deixamos de tentar resolver isso, seja na escolha do pareamento, supervisão do repositório e discussões nas dailies e retrospectivas.

Sobre o matéria em si, foram imensas as oportunidades de aprendizado. Houve uma alta alternância/rotatividade dos papéis de arquiteto e devops, permitindo que ambos pudessem aprender termos e práticas antes não desenvolvidas por eles mesmo. Além disso, os membros de MDS tiveram bastante crescimento, indicado no quadro de conhecimento e no andamento das sprints.

O que chamou bastante atenção também foi o trabalho em equipe e a contribuição de alguns membros para ajudar outros em suas issues. Em relação à metodologia, houveram algumas dívidas técnicas em algumas sprints e senti que o grupo de EPS tinha dúvidas em relação a como agir para contornar e planejar melhor as sprints. Além disso, com a release 2, foi notória a maior participação dos membros de MDS nas discussões e questionamentos de certas demandas, apesar do estresse em relação ao curto tempo para entregar um escopo. Foi notória também a necessidade de acompanhar a saúde mental dos membros, que com muitas demandas da faculdade se sentiam sobrecarregados por todos os lados.

A matéria por si só já vem com uma pressão grande em todos e é difícil controlar esse medo ao longo do semestre, eu mesma tinha medo de não me adaptar ao grupo ou não conseguir fazer as demandas, mas eu não poderia ter uma equipe melhor, com todo o suporte que recebi, apesar de todos os altos e baixos. 🏵️

@vitorcx
Collaborator
vitorcx commented on Nov 9, 2019
No inicio do projeto fizemos decisões relacionadas ao tema, cliente, escopo e tecnologias. Apesar da maioria dos membros estarem animados com o tema, a escolha de se desvincular do cliente original trouxe consequências que resultaram, em parte da equipe, o sentimento de que não possuíamos um objetivo claro com o tema escolhido. Isso acabou gerando desmotivação e certo "desperdício" de tempo em reuniões. Apesar disso o comprometimento da equipe como um todo não chegou a ser um problema em nenhum momento.

Na maioria das vezes em que íamos começar a desenvolver uma nova área do projeto fazíamos um estudo para justificar as ferramentas, o que foi muito positivo, pois no momento que esse estudo não foi feito (escolha da tecnologia para hospedar o app) houve muito desperdício de tempo em tentativas de configuração desnecessárias, o que afetou drasticamente o andamento das issues de devops.

Ao meu ver o papel de devops era, por questões pessoais, o mais desafiador que eu poderia assumir, apesar das dificuldades, foi uma das melhores oportunidades de aprendizado, levando em conta o suporte que tive de outros membros sempre que precisei ❤️

@shayanealcantara shayanealcantara closed this as completed on Nov 9, 2019
@shayanealcantara shayanealcantara mentioned this issue on Nov 9, 2019
Desenvolver a escrita do post mortem #168
Closed
20 tasks
@durvalcarvalho
Collaborator
durvalcarvalho commented on Nov 11, 2019 • 
A matéria de MDS sempre foi um monstro na minha cabeça. Era frequente eu ouvir de amigos que essa matéria iria exigir a alma e que iria definir se você pertence ou não ao curso.

Isso me fez postergar o máximo possível a matéria até que eu me sentisse preparado para enfrentar esse monstro. Eu lembro que nas férias anterior ao semestre que iria me inscrever eu fui atrás de todos os frameworks e tecnologias que os projetos dos anos anteriores tinham usado, fui atrás das metodologias ágeis que tanto eram faladas, eu realmente estava desesperado...

Eu estava encarando a matéria como se fosse uma maratona, em que eu precisava me preparar com meses de antecedência.

Outro fato que me preocupava bastante era o fato de trabalhar em equipe. A única referência de trabalho em equipe que tinha foi o 3° projeto da matéria de Orientação à Objetos e que foi um completo desastre. Eu morria de medo de o grupo olhar para mim e não poder contar comigo…

Então quando finalmente chegou no primeiro dia de aula, eu encontrei com o meu grupo, que ainda não tinha tanta intimidade e abracei a causa. Eu queria mostrar trabalho de todas as maneiras possíveis, sempre que surgia qualquer coisa pra fazer eu queria ser o primeiro a começar, para justamente não parecer que eu não sabia fazer as coisas.

Com o tempo e com as diversas conversas que tivemos em grupo, essa sentimento de se provar para o grupo foi diminuindo até o ponto de eu não me sentir mal de está estudando para outra matéria invés de está fazendo as coisas de MDS.

Hoje eu vejo que foi uma besteira encarar a disciplina com a visão que eu tinha. Por mais que eu não me arrependa de ter me preparado para a disciplina, eu vejo que poderia tranquilamente ter me inscrito na matéria ainda calouro que o meu grupo estava preparado e disposto a guiar alguém assim.

@jps12
Collaborator
jps12 commented on Nov 13, 2019
Eu não sabia o que esperar de MDS. Muito se falava dessa matéria como a mais importante do curso, e agora entendo o porquê. No começo tive muito medo de não conseguir dominar as tecnologias e ser um fardo para a equipe e além disso seria a primeira vez que eu estaria realmente em um lugar mais próximo de um trabalho de engenharia de software. Por outro lado seria a primeira vez que eu ia realmente trabalhar em uma equipe de software, algo que era realmente novo para mim.
Acho que a maior dificuldade que eu encontrei na matéria, não foi propriamente a matéria e sim conseguir conciliar ela com as demais e com a vida no geral. No começo não consegui fazer isso direito mas depois eu tudo se ajeitou naturalmente. A partir dai comecei a aprender cada vez mais as tecnologias usadas, naturalmente encontrei mais facilidade em uma e em outra sinto uma dificuldade maior.
Acho que o maior ganho que eu levo de MDS, mais que propriamente as tecnologias, é aprender como é o processo de criação de um software saudável de modo que esse processo seja mais rápido e mais econômico alem de levar uma participação maior dos clientes.

@flaviovl
Collaborator
flaviovl commented on Nov 13, 2019 • 
Eu era aluno de engenharia eletrônica e tinha mudado recentemente para
engenharia de software. Devido a não conhecer muito a grade de engenharia de
software, eu sempre escutava algumas frases do tipo: MDS é bem pesado, MDS
demanda muito tempo, e por aí vai. Mas, até então, a maioria das disciplinas
que fiz na faculdade tinha uma fama parecida.

Porém MDS é diferente é muito mais complicado do que tinha imaginado. Foi a
primeira disciplina que vi que o pré-requisito da disciplina significa muito
pouco. Os quatro créditos da disciplina passa muito longe de refletir o número
de horas necessário para fazer a disciplina com bom aproveitamentop. Um aluno
que fez somente as disciplinas do fluxo normal não tem bagagem suficiente para
fazer MDS.

Na minha primeira reunião, onde encontrei o grupo completo, percebi que não
tinha os requisitos mínimos. O primeiro sentimento foi de frustração e
desespero. Com isso, estava praticamente decidido a trancar a disciplina, por
temer não conseguir acompanhar o grupo, ou pior atrapalhar o bom andamento dos
trabalhos. Mas, devido à importância da disciplina e o incentivo de alguns dos
membros do time, decidi por lutar pela disciplina, mesmo sabendo que não tinha
base suficiente.

Sempre tive receio de trabalho em grupo, pois todas as experienciais anteriores
foram fracassadas. Contudo, o grupo como um todo estava muito engajado e com um
projeto caminhando a todo vapor.

Na forma que a disciplina está organizada é uma excelente oportunidade para
trabalhar em grupo com projeto real. Porém, fui levado a aprender uma grande
demanda de conteúdos de forma independente. E o estudo independente requer
muito esforço, pesquisa e prática.

Apesar de gastar muito tempo estudando, às vezes tenho uma sensação de
frustração com a minha improdutividade. Parece que a cada novo problema eu era
jogado para a estava zero.

Devido a grande exigência da disciplina e número de tecnologias e frameworks
que é necessário aprender sozinho, ainda é preciso dedicar tempo a reuniões
semanais. Com isso, a disciplina consome muito mais tempo de estudo que
qualquer disciplina de 4 créditos até mais tempo que disciplinas de 6 créditos.
Assim, obrigando o aluno a abrir mão de boa parte do tempo de outras
disciplinas para dedicar a MDS e/ou reduzir o número de disciplinas do período
e por consequência tirando o aluno do fluxo normal do curso.

Apesar das grandes dificuldades e inexperiência, trabalhar em projeto grande
me possibilitou ampliar muito o conhecimento em diversas tecnologias e também
favorece melhoras no relacionamento interpessoal e melhorar a visão de como
trabalhar em equipe.

Por último, a minha sensação é que a disciplina não deveria estar no 4°período
e poderia ter mais créditos.

@shayanealcantara
Collaborator
shayanealcantara commented on Nov 15, 2019 • 
@LeoSilvaGomes @vitorcx @KiSobral @durvalcarvalho @jps12 @flaviovl podem transcrever o que voces escreveram para a issue feature/168-post-mortem-content 😀

Contexto de uso: Inconclusivo
Categoria: Inconclusivo