Ata de Reunião 18 – 25/05/2026

Review da Release Major 2 e Apontamentos de Avaliação

Local

Reunião realizada no modelo assíncrono via Teams

Participantes

Product Owner: Vinícius Rispoli de Carvalho Professor: Hilmer Neri Rodrigues Médico: Thiago Alves Martins

Tabela 1: Participantes da reunião

Matrícula	Aluno	Presente
222037648	André Cláudio Maia da Cunha	✓
221007850	Arthur Ribeiro e Sousa	✓
221021901	Cecília Ernesto Silva Quaresma	✓
221007706	Elias Faria de Oliveira	✓
202016168	Eric Camargo da Silva
211061814	Gustavo Costa de Jesus	✓
211061832	Harleny Angéllica Araújo de Sousa	✓
211062947	Iderlan Junio Cardoso da Silva	✓
221037975	Natália Rodrigues de Morais	✓
190020814	Vinícius Roriz Meireles Silva	✓
211031889	Yan Luca Viana de Araújo Fontenele	✓

Fonte: Arthur Ribeiro e Vinícius Roriz, 2026

Início e término

Na tabela 2 consta o horário de início e o horário de término previsto da reunião, assim como o horário que foi efetivamente realizado.

Tabela 2: Horários

Hora de Início	Hora de Término
Previsto: 19:30	21:00
Realizado: 19:30	20:40

Fonte: Arthur Ribeiro e Vinícius Roriz, 2026

Pauta

Apresentação do planejamento, da entrega e dos resultados da Release Major 2
Demonstração do produto em funcionamento
Considerações dos POs
Apontamentos de avaliação do professor

Desenvolvimento / Discussões

1. Contexto e Planejamento da Release Major 2

A reunião iniciou com a apresentação da Release Major 2, em 25 de maio. Foi informado que a equipe está reduzida, com a confirmação da saída do membro Eric, que deixou de responder ao time há alguns dias sem aviso prévio.

Na apresentação do planejamento, foi recapitulado o escopo inicialmente previsto para a entrega: - Consulta e visualização dos exames - Pré-processamento das imagens (inicialmente previsto apenas para JPEG) - Download dos relatórios - Integração com a IA

2. Demonstração do Produto

A Release Major 2 foi destacada como um marco importante, por consolidar a primeira versão funcional do produto idealizado desde a primeira conversa. Foi reforçado que se trata de um protótipo inicial, com várias evoluções ainda previstas.

Foi explicado que o protótipo foi acordado junto aos POs e que, em conversa com o Professor Vinícius, surgiram questões relacionadas à parceria com o Ministério da Saúde, ao registro do software e à troca de licença, o que motivou a antecipação de algumas funcionalidades.

Funcionalidades demonstradas:

Sistema de Notificações

As ações do usuário passaram a gerar notificações para os eventos relevantes:
Aprovação ou negação de solicitações de alteração de dados cadastrais, com exibição dos motivos
Conclusão da avaliação da IA
Como o processamento da IA é assíncrono (entra em fila), as notificações fornecem ao usuário o feedback do término do processamento.
As notificações também são enviadas por e-mail quando o usuário não está online. O envio na plataforma não pôde ser demonstrado ao vivo devido a um possível bloqueio de porta no servidor (em investigação), mas os e-mails já estão funcionais (demonstrado via e-mail de teste).

Cadastro de Paciente e Exame

Refatoração dos campos de cadastro conforme combinado com o Dr. Thiago.
Campo de prontuário livre (texto aberto).
Campos em conformidade com a UnB PDH (dados anonimizados ou criptografados).
Envio das imagens do olho direito e do olho esquerdo para análise, com entrada na fila e notificação ao concluir o processamento.

Tela de Exames / Resultados

Exibição da imagem das retinas e da análise realizada pela Inteligência Artificial.
Apresentação dos dados do paciente, do médico responsável, do prontuário e das comorbidades cadastradas.
A opção de laudo já aparece na interface (mantida do protótipo), porém o laudo por médico especialista está previsto para a próxima release.

3. Considerações dos POs

Product Owner (Vinícius Rispoli)

Avaliação positiva das telas, alinhadas aos aplicativos usados como referência.
Solicitou a gravação de um vídeo das telas de exames e notificações, com voice over.
Confirmou que o servidor provavelmente possui uma porta bloqueada, ocasionando o problema no envio de e-mails.

Médico (Dr. Thiago)

Avaliação positiva da entrega.
Ficou de enviar o modelo de laudo, para padronização do laudo do especialista e aproveitamento das informações posteriormente.

4. Apontamentos de Avaliação (Professor Hilmer)

Gestão e Backlog (ZenHub)

A R1 no ZenHub não aparece em 100% por conta de issues que são épicos incluídos.
Na R2, há issues ainda em aberto porque não foram validadas com o Rispoli e com o Tiago, motivo pelo qual o time não as fechou.
Os dados apresentados não estão batendo 100% com o ZenHub; faltou clareza sobre o quanto das diferenças é efeito da ferramenta e o quanto é lacuna real de dados.

EAP

A release na EAP deve conter estritamente requisitos funcionais ou não funcionais (épicos / histórias de usuário).
Foram incluídas activities indevidas na EAP (ex.: validação, repositório de configuração, qualidade inicial), que não correspondem a requisitos e devem ser corrigidas.

Testes, Métricas e Qualidade

A cobertura de testes, já alta, se manteve e melhorou um pouco; mais membros passaram a testar.
O esforço de teste foi considerado muito bom e sólido, com bons indicadores também no Sonar.
Não foi possível considerar que houve um planejamento de qualidade. O Sonar é uma ferramenta, não um modelo de qualidade.
É preciso utilizar um modelo de qualidade (ex.: Q-Rapids), com suas fórmulas e características, sem reduzir a discussão de qualidade de produto a meia dúzia de medidas. O Sonar complementa essa percepção por implementar outro modelo.
Faltou documentação explicando o Q-Rapids, que se torna uma "caixa preta" para quem não conhece a ferramenta.
2 membros ainda não testaram o próprio código que escreveram.
Sobre comentários de código: o argumento de "Clean Code = código sem comentários" foi rebatido. O próprio autor do Clean Code dedica um capítulo ao que comentar e ao que não comentar, sem afirmar que código-fonte não deve ter comentários. Reforçou ainda que o Q-Rapids foi validado experimentalmente junto a profissionais da indústria, não sendo mera opinião.

Riscos e Impacto de Pessoas

A equipe está reduzida (2 a 3 membros a menos), com a saída do Eric.
Não há documentação discutindo o impacto dessa saída no escopo. É necessário deixar claro: se não impactou, o planejamento estava superestimado; se impactou, o que mudou no escopo precisa ser discutido com o usuário.

Contribuição Individual

O retrato de contribuição se manteve em relação à R1.
Como novidade, membros que não tinham contribuição em código passaram a ter registros em teste.
Ainda há 2 membros em situação delicada (ex.: um único commit em cerca de dois meses, sem revisão de pull requests e sem testes).
O trabalho ainda não está balanceado, e há membros sem contribuição em documentos.

Comunicação e Discussão Gerencial

Pouca melhoria percebida nos comentários de gestão.
As reuniões com os POs têm se concentrado no escopo funcional (histórias e requisitos novos), faltando a discussão gerencial (riscos, impacto de pessoas, variação de escopo, datas — a tríplice restrição: custo, tempo e escopo).
Recomendação: dedicar, ao menos uma vez por mês, parte de uma reunião à discussão gerencial dos pontos perceptíveis pelo usuário.

5. Esclarecimentos e Dúvidas

A solicitação para antecipar funcionalidades decorreu do registro de patente pretendido pelo Professor Vinícius e da troca de licença do software.
Foi esclarecido que o artigo/Q-Rapids trata apenas de escopo funcional (histórias de usuário).
Sobre o cálculo do Fator de Maturidade (FM) / velocity: a equipe se baseou no ZenHub para validar os gráficos, mas o ZenHub não calcula o FM conforme as fórmulas do artigo e calcula a velocity de forma diferente da definição clássica (ponto por história). A ausência do filtro/rótulo de US dificultou o isolamento dos dados específicos, e a unidade de história (UoS) ainda não está definida no ZenHub. A verificação das fórmulas de cálculo ficou para a segunda-feira.

6. Pontos Positivos Identificados

Produto considerado em bom estado, com clara evolução em relação à R1.
Primeira versão funcional do produto entregue, consolidando a visão inicial.
Sistema de notificações (plataforma e e-mail) implementado e integrado ao fluxo assíncrono da IA.
Tela de exames apresentando imagem das retinas, análise da IA e dados clínicos do paciente.
Conformidade dos campos de cadastro com a UnB PDH (anonimização/criptografia).
Boa cobertura e esforço de testes, com bons indicadores no Sonar.
Feedback positivo e enfático dos usuários sobre as funcionalidades entregues.
Documentação cuidadosa, com as atas de reunião devidamente registradas.

Conclusão

A Release Major 2 consolidou a primeira versão funcional do produto, com destaque para o sistema de notificações, a integração com a IA e a tela de resultados de exames, recebendo avaliação positiva dos POs e do professor quanto à evolução do produto.

Em contrapartida, os apontamentos da avaliação evidenciaram a necessidade de: ajustar a EAP para conter apenas requisitos; estruturar a discussão de qualidade a partir de um modelo (Q-Rapids) e documentá-lo; tratar formalmente o impacto da redução da equipe sobre o escopo; equilibrar a contribuição individual; e incorporar a discussão gerencial (riscos, custo, tempo e escopo) nas reuniões com os POs. A verificação das fórmulas de cálculo do FM/velocity ficou agendada para a segunda-feira seguinte.

Histórico de Versão

Versão	Data	Descrição	Autor	Revisor
`1.0`	25/05/2026	Adição da ata de reunião	Arthur Ribeiro e Vinícius Roriz