Histórico de Versão

Versão	Descrição	Autor
0.1	Estruturação do documento	Cauê
0.2	Tópicos Equipe, MDS e EPS adicionados	Cauê
0.3	Tópcicos Metodologia, Papeis e Práticas adicionados	Cauê

Postmortem

Equipe Vsign

A equipe é formada por 9 membros, sendo eles:

A equipe foi formada com alguns membros que já se conheciam antes das matérias de MDS e EPS e outros se agregaram ao grupo após a primeira semana de aula. No início começamos com uma equipe um pouco heterogênia e ao final da matéria terminamos com uma equipe mais hetorogênea do que quando começamos, pois alguns membros avançaram bastante seus conhecimentos e outros ficaram para trás o que causou uma diferença maior ainda de conhecimentos do que quando o semestre foi iniciado.

O que pode-se dizer sobre a formação da equipe é que no final das contas ela acabou ficando equilibrada, pois cada um possuia seus pontos fortes e fracos e um membro completava o déficit do outro. A comunicação entre os membros foi um ponto fraco e criticado por alguns membros, pois não se tinha muito comunicação aberta entre o grupo, somente nas reuniões e alguns poucos momentos fora dela. O ponto fonte que se pode ressaltar é que a equipe teve um desempenho no geral superior ao esperado para o trabalho, tanto na parte de código quanto na documentação apresentada.

MDS

Os membros da disciplina de MDS é formada por:

Quatro membros estavam matriculado na turma da tarde e um membro na turma da manhã. Esse membro matriculado na turma da manhã acabou ficando um pouco isolado do restante do grupo na maior parte do tempo, pois além de não ter aula no mesmo horário do restante dos membros ele não procurava interagir e ser proativo no trabalho.

O membro que estava matriculado na turma da manhã e um na turma da tarde tiveram problemas com o andamento do trabalho, pois não conseguiram acompanhar no mesmo ritmo do restante do grupo e com isso foram se isolando cada vez mais do grupo e do trabalho. Diversos problemas causaram o afastamento crescente desses membros do projeto, entre alguns fatores pode-se destacar os seguintes: problemas pessoais, falta de interesse no trabalho, não afinidade com o grupo, semestre apertado com outras matérias e o déficit de conhecimento gerando desanimação.

Os três membros restantes já tinham bastante afinidade antes da matéria começar e já tinham também um bom nível de programação, só faltando aprender mais sobre as metodologias de trabalho, geração de artefatos, notação de documentos e uso de algumas tecnologias utilizadas no projeto. No geral esses três membros se saíram muito bem e tiveram um desempenho superior ao que é esperado para membros da matéria de MDS.

EPS

Os membros da disciplina de EPS é formada por:

O grupo estava bem heterogêneo na questão de conhecimento prévio, com um membro se destacando muito, tendo conhecimento em diversas tecnologias que seriam utilizadas e no projeto como um todo. Os outros três membros tinham conhecimentos iniciais menores e um deles conseguiu desenvolver novos conhecimento e habilidades durante o decorrer do trabalho e os dois membros restantes não apresentarão grande evolução de conhecimento e de suas habilidades iniciais.

O trabalho durante o semestre também não foi muito regular entre os membros. Dois membros trabalharam muito além do exigido e esperado para a matéria, outro membro trabalhou o que era esperado e exigido e o último membro do grupo quase não trabalhou durante a primeira parte da matéria, tendo aparecido somente em reuniões semanais e nas dailys. Na segunda metade da matéria um dos membros continuou a trabalhar muito além do exigido e esperado para a matéria, outro membro trabalhou o que era esperado e exigido e os outros dois membros trabalharam um pouco abaixo do que se esperava na segunda etapa, porém comparado a primeira parte da matéria, nessa segunda metade o trabalho foi mais homogêneo entre os membros.

Metodologia

A equipe decidiu utilizar a metodologia ágil sem um uso de um framework específico a ser seguido. Foi decidido adotar os valores e princípios da metodologia ágil, acoplando a metodologia diversos artefatos e práticas do framework Scrum, porém com diversas adaptações que o grupo julgou que seria melhor para se trabalhar.

De fato da metodologia ágil, de seus valores utilizamos todos eles: - Indivíduos e as interações entre eles mais que processos e ferramentas; - O software funcionando mais do que uma documentação completa e abrangente; - Colaboração com e dos clientes mais do que negociações de contratos; - Respostas a mudanças mais do que seguir o plano inicial.

Os quatro valores foram seguidos do início ao fim do projeto.

E de seus princípios utilizamos durante o projeto todos os princípios: - A maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor; - Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas; - Entregar software funcionando com frequência, preferencialmente em semanas; - Cooperação diária entre pessoas que entendem do ‘negócio’ e desenvolvedores; - Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança. - A maneira mais eficaz e eficiente de transmitir informações são através de conversas cara a cara; - Software funcionais são a principal medida de progresso do projeto; - Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes; - Contínua atenção à excelência técnica e bom design, aumenta a agilidade; - Simplicidade é essencial. Cultivar a arte de maximizar a quantidade de trabalho que não precisou ser feito; - As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas; - Em intervalos regulares, o time reflete em como se tornar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Os 12 princípios foram seguidos do início ao fim do projeto.

Com relação ao uso de práticas de frameworks, resolvemos usar como base o Scrum, porém com diversas adaptações. Algumas práticas que utilizamos durante o projeto foram as seguintes: - Iterações; - Pair programming; - Pair review; - Planning Poker; - Product Backlog; - Daily; - Sprint Planning; - Sprint Review; - Sprint Retrospective; - Histórias de usuário; - Business Canvas; - Deploy contínuo; - Integração contínua; - Controle de versão; - Kanban.

Dessas práticas de diversos frameworks ágil, todas foram utilizadas durante algum período do projeto, mas somente algumas conseguimos manter sendo utilizada do início ao fim como: iterações, product backlog, sprint planning, sprint review, sprint retrospective, business canvas, deploy contínuo e controle de versão.

Papeis

Tivemos alguns papeis que foram definidos e separados entre os membros no início do projeto e ficamos com esses papeis até o final sem realizar rotação entre os papeis. A separação dos papeis entre os membros do grupo ficou da seguinte forma:

Nome	Papel
Cauê Mateus	Product Owner
Kairon Veloso	Arquiteto
Marcos Cabeceira	Desenvolvedor
Marcos Floresta	Desenvolvedor
Marcos Gabriel	Desenvolvedor
Thiago Pereira	DevOps
Victor Gomide	Scrum Master
Vinicius Porto	Desenvolvedor
William Viera	Desenvolvedor

Durante o projeto aconteceram algumas alterações entre os papeis informalmente com uma pessoal realizando funções que seria de outro papel, mas estava realizando ou porque ela tinha maior domínio da atividade que deveria ser realizada pelo papel ou por ausência do membro na entrega de sua tarefa.

Na segunda metade da disciplina dois desenvolvedores já não estavam mais propriamente exercendo o papel de desenvolvedor e passaram a fazer papel de revisor de trabalhos feitos na primeira release e de funcionalidades criadas na segunda metade da matéria. O arquiteto acabou atuando muito também como desenvolvedor.

Nos papeis de Product Owner (PO), Arquiteto, DevOps e Scrum Master (SM), somente DevOps e Arquiteto que ficou com seu papel do início ao fim sem ter ninguém executando tarefas de seu papel. PO acabou sendo executado hora pelo próprio PO e hora pelo Arquiteto, e SM acabou sendo executado hora pelo próprio SM e hora pelo PO. O trabalho de PO acabou sendo executado em alguns momentos específicos pelo Arquiteto, pois como o mesmo já tinha vasta visão de produto e conhecimento, algumas atividades acabaram sendo feitas por ele. O trabalho de SM acabou sendo executado em alguns momentos durante a sprint 1 e em um momento durante a sprint 2 pelo PO, devido a ausência do SM em alguns momentos do projeto.

Práticas

Durante o projeto colocamos diversas práticas em uso e ao longo dele fomos retirando e colocando práticas que ficassem melhores para o grupo. As decisões pelo uso de algumas práticas foram tomadas hora pensando na praticidade, hora na produtividade e hora na qualidade agregada ao trabalho.

ALguns exemplos de práticas que iniciamos, porém retiramos ou modificamos: - Iterações passaram de presenciais para conferência; - Dailys foram substituidas por conversas individuais do SM com os membros semanalmente; - Histórias de usuários pararam de ser classificadas como US e o número de identificação delas e passaram a ser chamadas somente pelo nome da História de usuário.

Práticas que foram adotadas no decorrer do projeto: - Pair review, antes era feito individualmente; - Integração contínua, foi implementada após a release 1.

As outras práticas foram mantidas do início ao fim do projeto.

Tecnologias

As tecnologias utilizadas foram as seguintes: - Framework Ruby On Rails; - React; - GraphQL; - Amazon S3; - AWS Amplify; - Cloud Speech-to-Text; - Amazon Rekognition; - RSpec para testes do back-end.

A escolha das tecnologias foi feita com base em uma sugestão dada pelo cliente e após análise do grupo sobre conhecimento individual de cada um com relação a cada tecnologia e ao levantamento feito pelo grupo de tecnlogias boas para serem utilizadas no projeto. Ao final decidimos por essas tecnologias que foram as mesmas sugeridas pelo cliente, com exceção do React e do GraphQL que o próprio grupo escolheu utilizar.

As tecnologias utilizadas no projeto se pagaram ao final, pois todas elas atenderam as necessidades do grupo em solucionar os desafios e contruir o software. As duas tecnlogias que o grupo teve um pouco mais de dificuldade para utilizar foram: Cloud Speech-to-Text e a Amazon Rekognition, pois ambas envolviam aprender do zero a como utilizá-las para resolver os problemas propostos a serem resolvidos. A Rekognition depois de pouco tempo o grupo já estava com um bom domínio sobre a mesma, sendo o problema maior com a Text-to-Speech onde também não foi difícil para o grupo saber como utilizá-la para resolver o problema, porém na conversão do áudio de gravação para conseguir ser analisado e transcrito. Após descoberto como resolver essa conversão do formato do áudio para o formato utilizado pela Google em sua ferramenta, o problema foi resolvido.

Ferramentas

As ferramentas utilizadas para auxílio do trabalho foram as seguintes: - Zenhub para o tracking e organização das features; - CircleCI para integração e entrega contínua; - Rubocop para apontar todas as ofensas do código do projeto que não seguirem o padrão do linter no back-end; - MKDocs para manter toda a documentação do projeto; - Google Drive para manter algumas apresentações, planilhas e arquivos do grupo; - Slack onde as conversas entre o grupo e entre o cliente aconteciam; - Telegram usado para conversas parelales, envios de áudios e quando alguns membros tinham problemas com o slack; - Code Climate usado para verificar a qualidade do código e dos testes. - Eslint para apontar todas as ofensas do código do projeto que não seguirem o guia de estilo da airbnb no front-end

O grupo não teve trabalho para aprender a utilizar as ferramentas listadas, os problemas que ocorreram foi o mal uso de algumas ferramentas como o Drive que acabou ficando com os documentos todos largados e o Zenhub que não foi atualizado e utilizado de forma correta. O zenhub foi a mais crítica das ferramentas, pois a mesma não estava sendo atualizada constantemente e a rastreabilidade que a ferramenta trás estava mais confundindo o grupo do que ajudando por erros na utilização. As métricas que são geradas pelo zenhub nunca foram utilizadas pelo grupo, pois o uso da ferramenta não estava correta e o membro que estava responsável pela análise das métricas não fez as análises necessárias.

Desenvolvimento

O código em sua versão de produção pode ser encontrado no seguinte link Vsign. Todas as funcionalidades desenvolvidas podem ser encontradas no seguinte link Release 1.0.

A equipe de desenvolvimento foi composta por todos os membros de MDS e na maior parte do tempo também pelo Arquiteto do projeto que possuia o maior nível de conhecimento técnico do grupo e para auxiliar MDS atuou ativamente como um desenvolvedor, sempre que possível pareando e ensinando.

O uso das issues e dos pull requests foi bom, porém não foi usado em um nível de excelência que estavamos buscando. Nem todos os comentários foram feitos nas issues e nos pull requests, durante a release 1 vários estavam sendo comentadas, porém durante a release 2 a utilização dos mesmos começou a ser feita sem a devida atenção que se deveria.

Problemas com nível técnico das tecnologias ocorreram nas duas primeiras sprints de código do projeto, nas últimas três semanas de projeto problemas com a conversão no formato de áudio utilizado pela google no Speech-to-Text ocorreram, porém foi solucionado esse problema após bastante tempo de desenvolvimento. Esses foram os 2 maiores problemas que se teve para desenvolver o software.

Release 1

Durante o mês de agosto e setembro foi trabalhado dentro da release 1. Ao término desse período soltamos um pré-release note, mas porque não foi soltado uma release ao invés de uma pré-release? Após o término desse período ainda não tinhamos uma MVP rodando e por esse motivo não poderiamos liberar uma release versão 1 do produto, mas sim uma pré-release versão 0.1 do produto, onde trabalhamos nos dois meses seguintes para liberar a primeira release do projeto, ou seja, o primeiro MVP.

Durante as três primeiras sprints, como ainda não tinhamos grupo definido e somente os times estavam definidos, prefirimos por focar no estudos das possíveis tecnologias que trabalhariamos e começar a mostrar para a equipe de MDS a metodologia de trabalho que utilizaríamos, práticas, rituais e como trabalhar dentro do repositório da equipe.

Assim que o tema foi definido, foram realizados alguns treinamentos das tecnologias, metodologia e foi passado diversas orientações da forma com que trabalharíamos nas duas semanas seguintes. Na sprint 2 começamos a gerar os artefatos iniciais do projeto e na sprint 4 o código da aplicação começou a ser feito. E assim foi tocado o projeto até a release 1. Ao final foi gerado o seguinte pré release 0.1.

Vários problemas ocorreram durante a release 1 como: a falta de comunicação que começou a aumentar conforme o tempo ia passando, alguns membros ausentes ou dispersos, mudanças de práticas para se adaptar melhor ao grupo, entre outros. Porém no geral o trabalho foi bom, pois conseguimos entregar tudo que nós haviamos nos comprometido a entregar até a release 1.

Release 2

Durante o mês de outubro e novembro foi trabalhado dentro da release 2. Ao término desse período soltamos a primeira release note, pois ao término desse ciclo conseguimos finalizar o primeiro MVP.

Durante as dua primeiras sprints desse ciclo o trabalho de todos no grupo foi ruim no geral, pois haviamos adiantado bastante do trabalho e ido muito bem na release 1 e com isso alguns membros relaxaram na matéria e outros se ausentaram por um período de tempo para focar em outras matérias que estavam deixando de lada para focar em MDS/EPS. Após essas duas sprints iniciais o trabalho voltou a rodar bem novamente com os membros retomando o ritmo de trabalho, sendo que já na sprint 4 dessa release os membros voltaram a trabalhar no mesmo ritmo da primeira metade da matéria. Ao final da release 2 foi gerado um patch note com o MVP entregue e pode ser encontrado aqui na release 1.0.

Vários problemas ocorreram durante a release 2 como: comunicação que piorou em comparação com a release 1, alguns membros se distanciaram mais ainda do restante do grupo, alguns membros ficaram ausentes durante boa parte da release 2, muita conversa e pouca ação por parte de alguns membros, entre outros. Porém igualmente aconteceu ao final da release 1, nesse ciclo o trabalho no geral também foi bom, pois conseguimos entregar todo o escopo e artefatos planejados para serem entregues até ao final da release 2.

Aprendizados Gerais

Pontos Positivos

Problema de comunicação parte dele pode ser resolvido, pois os membros do grupo tinham um alto engajamento no projeto;
Maioria do grupo engajada e motivada com o projeto;
Todo o escopo planejado no início foi implementado;
Uso de uma metodologia definida, porém sem definição de frameworks, somente com práticas que melhor se encaixavam no projeto;
Boa parte do grupo já tinha um bom nível de conhecimento o que facilitou o trabalho;
Grupo sem conflitos internos;
Situação do SM após a release 1 conseguiu ser contornada, após conversa franca com o membro;
Apesar das poucas conversas individuais que tivemos, elas foram mais importantes do que as dailys para tomar ações no projeto;
Vários problemas foram resolvidos após intensas procuras no Google;
Grupo motivado por trabalhar em um projeto real.

Pontos Negativos

Falta de comunicação;
Alguns membros do grupo foram se afastando conforme o projeto foi passando, isso causou alguns problemas de atrasos em entregas e sobrecarga de outros membros;
Falta de reuniões presenciais;
Ausência de métricas para verificar andamento, qualidade do trabalho e gerenciar riscos;
Oscilação do nível de trabalho durante as sprints.
Utilização do Kanban sem atualizá-lo constantemente, gerando mais dúvida do que tudo;
Conversa pessoal que substituiu as dailys não ocorreu da forma que deveria;
Baixa produtividade de alguns membros;
Alguns membros mais falando do que fazendo;
Problemas de alguns membros com o docker, principalmente no começo, pois constantemente o docker apontava algum problema que impedia de rodar algum ambiente (back-end e/ou front-end)

Recomendações

Insistir com membros que estiverem mais afastados do grupo antes de tomar decisões extremas de demitir o membro do grupo;
Ajudar a nivelar o nível técnico da equipe, ajudando os membros que estão com mais dificuldades a aprender;
Grupo se encontrar presencialmente pelo menos uma vez na semana, para não deixar ocorrer afastamento entre os membros do grupo;
Escolher tecnologias e ferramentas para serem usadas onde pelo menos um membro do grupo tenha domínio sobre ela;
O SM do grupo deve ser aquele que tiver maior conhecimento da metodologia e maior engajamento com o trabalho;
O PO do grupo deve ser aquele que tiver o maior conhecimento técnico e visão de produto;
A comunicação deve sempre ser estimulada por pelo menos algum membro do grupo sempre, caso contrário problemas ocorrerão.