19ª Semana - O fim ... só que não!

No dia 11 de dezembro realizamos a segunda entrega para os professores, havíamos nos empenhado bastante na semana anterior para que as coisas estivessem prontas a tempo. 

Durante a apresentação os professores falaram que a aplicação estava boa, porém a documentação e a modelagem do banco ainda tinham pontos para serem arrumados.

Com isso, nos colocaram de IFA, tendo mais uma semana para realizar as alterações apontadas por eles e realizar uma última apresentação do trabalho.
Após esse resultado decepcionante, a equipe se reuniu para planejar quais seriam os próximos passos para essa última semana.

18ª Semana - Mudança de postura

No dia 28 de novembro a equipe Flawless realizou a apresentação do projeto Visite Museus. Os professores criticaram alguns pontos da documentação, desenvolvimento, arquitetura, extração e gerenciamento. 

A equipe ouviu a opinião emitida pela banca, sendo eles Braz, Ivan, Aldo e Daniel. A partir disso a integrante Adriana se ofereceu para gerenciar o projeto até o fim do semestre letivo, em comum consenso todos o integrante aceitaram a troca. 

A primeira atitude tomada, foi a criação de um cronograma geral com as principais problemas identificados no projeto. O cronograma foi criado pelas integrantes Adriana e Daniela. 

Ambas sentaram com cada pessoa, explicaram a ideia, delegaram algumas atividades e definiram um tempo. Todo esse fluxo foi aplicado em conjunto com o integrante que iria executar a demanda. 

Após isso, cada integrante tinha a missão de honrar o prazo que se comprometeu, gerando um fluxo de entregas rápidas. 

Durante o decorrer da semana a equipe se comunicou através de encontros no Starbucks, faculdade, Skype e WhatsApp. 

No dia 5 de dezembro a equipe iria apresentar o projeto para os professores, porém pela falta de tempo a apresentação foi postergadas para o dia 11 de dezembro. Esse tempo extra foi encarado como uma oportunidade dada pelos professores para corrigir o que faltava no trabalho. 

17ª Semana – Apresentação do projeto

Essa semana se iniciou em 21/11/2019, data em que realizamos a apresentação final do projeto. No inicio da aula de toda apresentação, é realizado um sorteio de cara ou coroa com um membro de cada equipe. No sorteio realizado no dia de nossa apresentação, fomos a equipe sorteada a apresentar primeiro, porém só a integrante Carla estava na sala. Os outros integrantes estavam a caminho do IFSP e se atrasaram por questões de trabalho e transito. A outra equipe, que já estava pronta para realizar a apresentação, se dispuseram a apresentar primeiro. 

Nossa apresentação começou as 21H40, e além dos professores Ivan e Braz, fomos também avaliados pelos convidados professor Daniel e professor Aldo. Realizamos a apresentação do projeto sem a implementação da extração de dados dos museus no site, apenas demonstramos esse processo funcionando dentro da arquitetura. 

Durante a apresentação foi explicado aos professores os motivos desta e de outras funcionalidades ainda não estarem prontas. Sobre nossa documentação, os professores apontaram todos os principais erros cometidos pela equipe, para realizarmos a correção dos mesmos para a segunda entrega do projeto. 

No final da apresentação, nossa equipe se reuniu para decidir a mudança do gerente de projeto, que até a data da apresentação estava sob a responsabilidade do integrante Wesley. Decidimos que a integrante Adriana assumiria a gerencia até a finalização do projeto, e já nesta reunião a mesma já definiu novas funções e atividades para cada membro. 

No decorrer da semana a equipe assumiu suas novas responsabilidades e trabalharam nas atividades definidas, que se tratavam de corrigir a documentação e terminar de implementar as funcionalidades que faltam para a finalização do projeto. 

16ª Semana – Preparativos

Nessa semana a equipe Flawless foi sorteada para apresentar o projeto. Devido a proximidade da data de apresentação, os membros se mobilizaram para corrigir as principais pendências que permaneciam do trabalho. 

O número de reuniões foi intensificado devido a necessidade de troca de informações rápidas entre os membros. 

15ª Semana - Ajustes e desenvolvimentos

Como nossa equipe não foi sorteada para apresentar nessa semana, focamos em corrigir erros na documentação que notamos ao revisá-la mais profundamente e em desenvolver atividades pendentes, tanto da própria documentação quanto da aplicação. 

Atividades realizadas
- Adriana: desenvolvimento Avaliação de Evento, Favoritar Local, Evento, Feed e Postagem (back-end) e atualização dos testes unitários;
- Carla e Dayna: ajustes da documentação;
- Daniela: desenvolvimento das telas de Evento, Local, Atualizar Avaliação do Local, Atualizar Favoritar Local e Avaliação de Evento (front-end);
- Ranthelly: execução da Análise SSL/TLS;
- Wesley: desenvolvimento da extração de dados do Facebook e correção no fluxo de extração de dados do Twitter. 

14ª Semana - A entrega

Essa semana realizamos a primeira entrega, na qual foi entregue 3 cópias da documentação junto com os CDs com o código da aplicação gravado. Alguns tópicos ficaram faltando nessa primeira entrega, como o diagrama de classes, que encontramos problemas na hora de gerar e não deu tempo de adicionar para essa entrega, porém já está feito (só será atualizado) para a próxima entrega e para a apresentação da aplicação. 

Durante a aula foi feita uma avaliação do curso através de um link disponibilizado pelos professores e também foi realizada uma avaliação 360°, na qual os membros da equipe se avaliaram baseado na atuação de cada integrante no decorrer do projeto.

Após a entrega da documentação, a equipe está focada no desenvolvimento da aplicação e correção da documentação já entregue, as apresentações vão ocorrer nas próximas 3 semanas, será realizado um sorteio toda segunda-feira e os professores divulgarão as equipes que apresentarão em cada semana.
Nos encontramos no sábado para trabalhar no desenvolvimento, tanto na parte de back-end, front-end e extração de dados de redes sociais.

13ª Semana - Na correria

Essa foi a última semana antes da entrega da documentação, então o foco foi terminar o que faltava da documentação, como adicionar os diagramas no latex, o texto de agradecimento, etc. 

As integrantes da equipe Adriana e Daniela conversaram com os professores sobre suas preocupações em relação a entrega da aplicação, uma vez que nem todos os membros da equipe estavam desenvolvendo e entregando suas atividades conforme o combinado. 

Foi sugerido que no lugar da entrega da extração fosse adicionado um processo novo no sistema, os professores concordaram, porém informaram ser necessário um aceite por parte deles dessa nova funcionalidade.

Ao conversar com o restante da equipe, o integrante Wesley informou que apesar do curto prazo, acreditava ser possível a realização da extração de dados de redes sociais. Assim, uma votação foi realizada e de forma unânime foi escolhido seguir com o plano original, a extração de dados.

Essa escolha foi baseada no fato de que se tirassemos a parte de extração de dados e adicionassemos uma nova funcionalidade, seria necessária uma grande alteração na documentação. O Wesley, que ficou como responsável da extração, informou que seria possível seguir com esse plano, assim, achamos menos arriscado seguir com a ideia original e demos um voto de confiança de que ele correria atrás da extração.

Foi decidido também que as integrantes Adriana e Daniela ficariam responsáveis pelas últimas postagens no blog, para que fosse relatado o que foi alinhado entre a equipe e os professores.

12ª Semana - Contratempos

No dia 17/10 a equipe se reuniu durante a aula para ajustar o cronograma da primeira entrega e definir as atividades da sprint. 

Atividades realizadas
- Adriana: desenvolvimento da Avaliação de Local e Evento e favoritar Local (back-end);
- Carla: revisão de literatura (documentação) e desenvolvimento das controllers de Contato, Informações e Evento (back-end);
- Daniela: desenvolvimento tela de Evento, Local, Avaliação de Local e Evento, Favoritar Local, Cadastrar Museu e Evento (front-end), MER e DER;
- Dayna: metodologia utilizada no projeto, comunicação da equipe e reuniões (documentação);
- Wesley: diagramas MER e DER. 

Nessa semana ocorreram vários contratempos, impedindo os integrantes da equipe de realizarem outras reuniões.

11ª Semana - Comunicação

Fizemos uma call no dia 15/10 para alinhar os próximos passos para o desenvolvimento do projeto. A equipe ficou mais animada, mas ainda há muito para ser desenvolvido e estamos em cima da hora. Nas próximas semanas faremos novas reuniões e nos comprometemos a melhorar a comunicação entre o time, que falhou muito nas últimas semanas. 

10ª Semana - Better get to work!

Durante a 10ª de projeto o time deu continuidade às atividades de desenvolvimento e documentação. Marcamos uma call para a próxima semana para discutir os próximos passos do projeto e alinhar as expectativas para a primeira entrega. O clima é de insegurança por conta de todas as atividades que precisam ser finalizadas. 

9ª Semana - Lazy days

Em nossa 9ª semana de projeto o time não se reuniu como de costume no Starbucks. Alguns membros da equipe se encontraram durante a semana para trabalhar no desenvolvimento, mas o ritmo dos últimos dias foi bem lento. Faltam algumas semanas para entrega do projeto e um clima de preocupação começa a tomar conta do time. 

8ª Semana - Validação, correções e prazos

Durante essa semana fizemos a validação dos nossos modelos com os professores. O Ivan respondeu o nosso e-mail com os requisitos e fez alguns comentários e apontou alguns problemas que havíamos deixado passar. Na última quinta-feira(26/09) fizemos a validação presencialmente com o professor Braz. Durante essa validação decidimos que o nome mais apropriado e genérico seria “local”. Fizemos as alterações no requisito com base nos apontamentos dos professores. 

Também começamos a criar nossas tabelas no banco de dados com base no nosso modelo. Mas durante a execução dessa atividade percebemos que o nosso modelo tem alguns problemas que passaram despercebidos durante a modelagem. 

O professor Braz no alertou sobre os prazos da próxima entrega. Falta um pouco mais de um mês para primeira entrega e ainda estamos finalizando às modelagens. Será necessário correr com às atividades.

7ª Semana - Modelagem e responsabilidades

Durante a última semana a maioria do time ficou focado em finalizar os requisitos funcionais, não funcionais, regras de negócio e o modelo do banco de dados. No último sábado (14/09) nos encontramos no bom e velho starbucks para concluir algumas atividades e planejar nossa semana. A principal dificuldade em relação às regras de negócio foi encontrar um nome genérico que estivesse de acordo com a proposta principal do projeto, que é ser uma aplicação genérica capaz de atender diferentes locais e estabelecimentos.  Optamos por “Entidade”, mas ainda estamos em dúvida. Enviamos um e-mail para os professores com nossos requisitos e pedimos uma validação do que foi feito. 

Também durante o final de semana finalizamos nossa matriz de responsabilidades com todas as atividades de desenvolvimento e documentação que serão executadas durante esse semestre.

6ª Semana - Planejamento e modelagem

No último sábado(07/09) o time não se reuniu presencialmente por conta dos protestos que estavam rolando na cidade. Por questões de segurança decidimos ficar remotos e fazer nosso planejamento via videoconferência. Discutimos às alterações sugeridas na POC e traçamos as estratégias para colocá-las em práticas. Entretanto não decidimos o que fazer com o banco de dados que, por sugestão dos professores, deveria ser provisionado na AWS. Pensando na questão da massa de dados que seria inserido no banco também precisamos mensurar os gastos envolvidos nisso. Decidimos continuar com o nosso banco de dados no Azure, pelo menos por enquanto. 

A maioria do time ficou focado na modelagem do sistema antes de iniciar o desenvolvimento das telas. Pretendemos fechar os requisitos funcionais e a modelagem do banco de dados no próximo sábado (14/09) para então começar o desenvolvimento dos CRUDs. Para o nosso projeto essas modelagens são às partes mais complexas, tendo em vista que o modelo deve ser algo genérico capaz de atender todo tipo de lugar, estabelecimento e entidade.

5ª Semana - Prova de conceito

No dia 05/09 fizemos a apresentação da nossa POC para os professores. Executamos o nosso fluxo de ponta-a-ponta, desde a extração de arquivos da internet até a inserção no banco de dados. Por questões burocráticas das redes sociais não conseguimos extrair dados diretamente do Facebook ou Instagram, conforme planejamos. Fizemos os testes com dados no formato Json disponibilizados pelo Governo Federal. 

Abaixo, a arquitetura apresentada durante nossa apresentação. 

Os professores fizeram alguns comentários sobre nossa arquitetura, mas o ponto principal da crítica foi a utilização de dois provedores clouds. De acordo com o professor Ivan a utilização de dois provedores geraria um alto custo financeiro por conta da transferência de dados de um provedor para outro e a possível latência nessa transferência. 

Durante o final de semana o time se reunirá para discutir os pontos levantados durante aapresentação e traçar estratégias de mudanças.

4ª Semana - Brainstorm week II

Durante a quarta semana de projeto a equipe focou em esboçar novas ideias para desenvolver durante o projeto. Descartamos a nossa última ideia por uma série de questões, entre elas a complexidade de aumentar o escopo. 

O time decidiu voltar a uma antiga ideia que esboçamos semestre passado que consistia em uma aplicação voltada para Museus. Apresentamos a proposta com algumas alterações em relação ao semestre passado para os professores. Eles fizeram algumas sugestões, entre elas utilizar dados de redes sociais para alimentar nossa plataforma. Gostamos das ideias que os professores deram e resolvemos investir nossos esforços para esboçar uma arquitetura que atendesse nossas novas necessidades. 

No final de semana mandamos um e-mail com algumas ideias e o desenho da arquitetura para extrair dados das redes sociais. 

Para  maior compreensão, colocaremos abaixo parte da nossa proposta e a arquitetura proposta.

Proposta

O objetivo da aplicação é ser uma plataforma para integrar dados das redes sociais sobre diversos museus. Através da extração de dados pretendemos ranquear às instituições e exposições mais visitadas, mais comentadas e com maior engajamento nas redes. Também será possível que os nossos usuários interajam através da plataforma, fazendo comentários e avaliando às instituições e exposições da cidade. 

Abaixo, alguns processos da aplicação.

1. Extração e transformação dos dados de diferentes redes sociais;
2. Análise quantitativa dos dados obtidos;
3. Ranqueamento das instituições mais visitadas / comentadas;
4. Ranqueamento das exposições mais visitadas / comentadas;

Abaixo, alguns dos CRUDs da aplicação.

1. Comentar na página dos museus;
2. Dar uma nota no museu visitado;
3. Enviar e-mail semanal com o museu com maior número de visitas (com base nas redes sociais), com maior nota e maior engajamento. 

Para desenvolver a aplicação utilizaremos dois provedores de cloud. Para extração e análise de dados, vamos utilizar Microsoft Azure, para a hospedagem da plataforma, utilizaremos AWS. Segue abaixo a arquitetura do processo de extração.

Arquitetura para extração de dados.

3ª Semana - IFound

Na última aula de PGP (15/08) apresentamos nossa primeira proposta para a disciplina. O projeto tem como objetivo desenvolver uma aplicação, que chamamos de IFound, para gerenciar de forma fácil o setor de achados e perdidos do Câmpus São Paulo do Instituto Federal. Dentro da aplicação seria possível consultar itens no setor totalmente online, economizando tempo evitando a necessidade de ir fisicamente até o setor. 

Para definição do escopo do projeto o time se reuniu no dia anterior(14/08) no Starbucks da Augusta, que está sendo o nosso QG neste semestre. Foi um pouco em cima da hora, nós sabemos. Mas, como relatado na última publicação, nós estávamos em contato com uma ONG de proteção aos animais e planejamos seguir com o objetivo do projeto nessa linha que envolve a causa animal, mas a conversa não foi muito produtiva e foi necessário descartar todas as ideias relacionadas ao tema.  

Após a apresentação da proposta, que está disponível em nossa SVN, os professores pediram para que olhássemos no repositório um projeto de 2017 chamado São Longuinho, que basicamente tem as mesmas funcionalidades que o nosso projeto. De acordo com o professor Ivan, sem uma justificativa técnica, não faria sentido desenvolver uma aplicação que já havia sido desenvolvida anteriormente na disciplina. Além disso também foi pontuado por eles a dificuldade de desenvolver um projeto para o Instituto Federal de São Paulo por conta das burocracias no acesso às APIs de autenticação.

Assim que terminamos nossa apresentação e recebemos os feedbacks dos professores fizemos um rápido alinhamento. Concordamos em seguir com esse projeto e aumentar o escopo dele adicionando novas funcionalidades e processos. Estamos planejando apresentar uma nova proposta na próxima aula com algumas melhorias. 

2ª Semana - Brainstorm week

A segunda semana de PGP foi de muitos debates sobre às ideias para o projeto. Apresentamos algumas propostas para os professores, mas eles não pareceram gostar da maioria. Nós queríamos muito trabalhar com algum projeto relacionado a causa animal, então o professor Braz sugeriu entrarmos em contato com a UIPA (União internacional de proteção aos animais), mas a conversa não foi muito produtiva. 

Ainda estamos debatendo sobre qual projeto desenvolveremos e adiantando algumas coisas que não dependente necessariamente da ideia. Começamos a trabalhar em nossa POC, provisionar recursos em nuvem e estruturar a documentação. Com a nossa experiência do semestre anterior algumas coisas ficam muito mais claras. 

O time está planejando se reunir ainda essa semana para debater ideias e esboçar alguns projetos antes da aula de quinta-feira.

1ª Semana - Here we go again.

Na última quinta-feira (01/08) tivemos nossa primeira aula de PGP desse semestre onde os professores apresentaram às regras e padrões que os projetos devem seguir. Mesmo já tendo passado por tudo isso antes eu fiquei chocado com a quantidade de coisas que deveríamos seguir e entregar em um único semestre. Após a apresentação da matéria fizemos a formação dos times. No último semestre de 2019 nós fazíamos parte do time BiteArte, embora no final tenha ficado um mal estar entre os membros da equipe decidimos seguir com as mesmas pessoas, até por uma questão de afinidade e entrosamento entre os integrantes. No mesmo dia já decidimos os papéis de cada um e falamos sobre como pretendemos seguir esse semestre com base nos nossos erros do semestre anterior. 

A formação do time e a definição dos papéis ficou da seguinte forma: 

Adriana de Oliveira - Responsável pelo back-end e infraestrutura da aplicação. 

Carla Miossi - Responsável pelo back-end e documentação da aplicação. 

Daniela Ragozzino - Responsável pelo banco de dados, front-end da aplicação e infraestrutura. 

Dayna Santos  - Responsável pela documentação. 

Ranthelly Albuquerque - Responsável pelo front-end e infraestrutura da aplicação. 

Wesley Gomes - Responsável pelo gerenciamento, back-end e banco de dados. 

Já começamos a debater as ideias para esse semestre e nosso planejamento de atividades. Tivemos uma grande lição no semestre passado de coisas que não devemos fazer em PGP e agora com esse novo começo pretendemos seguir a risca tudo o que aprendemos. 

PV nos ajude.