GERAL • STRIKE • DAILY • PADRÕES • NOMENCLATURA • COMMIT • PULL REQUEST • BRANCH
Este projeto é acadêmico e realizado em equipe, exigindo colaboração, comprometimento e responsabilidade de todos os integrantes, sem distinção de funções. Embora os papéis de Product Owner (PO) e Scrum Master (SM) atuem como facilitadores e mediadores, cabe a todos os membros contribuir para a melhoria contínua do código, desenvolver um front-end com boa experiência de usuário, ajustar as tasks e garantir a qualidade dos resultados entregues.
É fundamental que os cards das tasks sejam revisados tanto por quem os desenvolve quanto por quem realiza a revisão ou os testes. Se houver dúvidas ou necessidade de validação de alguma modificação ou melhoria, além da quebra da task e criação de um card complementar, a comunicação deve ser feita através do grupo no WhatsApp. Alternativamente, os membros podem entrar em contato diretamente com a PO ou o SM para validação.
Os wireframes e o backlog servem como ferramentas de validação para o cliente, proporcionando uma visão clara do que será entregue. No entanto, essas definições não são fixas ou imutáveis, podendo ser ajustadas conforme o andamento do projeto e conforme novas necessidades surgirem durante o desenvolvimento.
Ao assumir uma task, o membro deve revisar o card e os detalhamentos fornecidos, solicitando esclarecimentos adicionais, se necessário. A verificação de dependências e a adesão aos padrões estabelecidos no código também são de responsabilidade do responsável pela task. Caso existam dúvidas relacionadas ao código, elas devem ser resolvidas rapidamente, uma vez que qualquer atraso pode comprometer as entregas. Se o responsável pela task não conseguir finalizá-la, é essencial comunicar o grupo com antecedência para que outra pessoa possa assumir.
-
Não entregar uma task sem aviso prévio. Deve-se informar ao grupo pelo menos 3-2 dias antes do prazo final se a entrega não poderá ser realizada;
-
Entregar uma task de forma insatisfatória ou incompleta sem justificativa válida;
-
Não entregar uma task completa durante todo o prazo da Sprint.
1ª Ocorrência: Aviso verbal
2ª Ocorrência: Aplicação de um strike
1° Strike: Alerta oficial e conversa para o ajuste de postura.
2° Strike: Reunião entre o PO e o SM com uma conversa para aviso da redução na nota da participação.
3° Strike: Será feita uma reunião com os membros do grupo para discussão da exclusão do membro e redistribuição das tarefas.
Para garantir que todos estejam informados e que o fluxo de trabalho seja contínuo, as dailies serão realizadas de forma assíncrona a cada 2 dias. Cada integrante deverá atualizar o grupo do WhatsApp nas terças, quintas e sábado/domingo informando sobre o progresso das tasks, se já foi aberta uma Pull Request (PR), e se precisa de ajuda em algum ponto específico.
Ex1: Server, Task #0 – Resumo do progresso.
Ex2: Client, Task #0 – Resumo do progresso.
Ex3: Doc, Task #0 – Resumo do progresso.
Como forma de padronização das variáveis, atributos, colunas e tabelas, adotaremos a seguinte forma:
snake_casepara Banco de Dados (.sql / Tabelas / Colunas)camelCasepara demais arquivos Java (DTO, Entity, Service, Controller e Repository)
Exemplo:
Arquivo DDL schema.sql
CREATE TABLE tipo_soloArquivo Entity TipoSolo.java
public class TipoSoloE como forma de padronizar os nomes utilizados pelo cliente, os nomes utilizados nos códigos e os arquivos disponibilizados, verifique abaixo as definições:
Área Agrícola: Engloba o contorno todo da fazenda, seus atributos e seus talhões.
GeoJson Saída: Nome do arquivo GeoJson que fornece os dados espaciais de uma fazenda, tendo as informações específicas dos talhões separadas.
Talhões: Também chamado de vetor, são as divisões de terra, identificadas nos arquivos GeoJson pelo MN_TL.
Mapa de Classificação Automática: Arquivo GeoJson que fornece dos dados de ervas daninhas coletados pelos satélites e alimentados pela IA. O arquivo abrange a fazenda inteira, com a separação dos talhões pelo MN_TL.
Mapa de Classificação Manual: Arquivo GeoJson gerado a partir da edição de um Analista, que retira ou adiciona áreas de erva daninha nos talhões atribuídos.
Os commits devem ser descritivos e seguir um padrão definido para manter a rastreabilidade e a clareza no histórico do repositório.
<tipo> (#<id_demanda1>, #<id_demanda2>, ..., #<id_demandaN>): <descrição da entrega feita no commit>
Tipos de commit:
- feat : Adiciona uma nova funcionalidade.
- fix : Corrige um bug.
- docs : Alterações na documentação.
- style : Mudanças de formatação, espaçamento, etc., que não afetam a funcionalidade.
- refactor : Refatoramento de código sem mudança de funcionalidade.
- test : Adição ou modificação de testes.
- chore : Tarefas de build, configurações, dependências, etc.
feat (#7): adicionar endpoint de listagem de usuários
Issue: Implementado o endpoint GET/usuarios para listar todos os usuários cadastrados.
Os Pull Requests devem seguir a mesma mensagem que os commits.
feat (#7): adicionar endpoint de listagem de usuários
Descrição: #7 Foi criado um endpoint para listar todos os usuários, utilize a rota localhost:8080/usuario
Inclua uma breve descrição do que foi feito, bem como indicações para teste e prints. Para linkar um card, é necessário colocar o número da Issue acompanhada do #, devendo aparecer um pop-up para selecionar.
Descrição:
- O que foi feito? (Descreva a funcionalidade ou correção realizada)
- Como testar? (Passos para validar as mudanças)
- Dependências (Se houver dependências de outras tarefas ou PRs)
- Screenshots (Se aplicável, incluir prints ou gifs para facilitar a revisão)
As branches devem seguir um padrão para facilitar a organização do repositório e a rastreabilidade das alterações.
Estrutura da branch:
<id_demanda1>, <id_demanda2>, ..., <id_demandaN>-<descricao>
Em branch não usamos caracteres especiais e nem pontuações.
7-adicionar-endpoint-de-listagem-de-usuarios