| ... | ... | @@ -4,6 +4,40 @@ |
|
|
|
Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão
|
|
|
|
apresentados documentos referentes a maneira como o time se organizou e trabalha.
|
|
|
|
|
|
|
|
---
|
|
|
|
# 📅 Processos
|
|
|
|
|
|
|
|
A equipe combinou em utilizar algumas técnicas ágeis para maior organização e controle dos processos.
|
|
|
|
Acreditamos que os rituais ágeis colaboram muito para formar um ambiente com comunicação e colaboração, sempre visando melhorar e facilitar o trabalho da equipe de desenvolvimento, que quando se encontra em um ambiente organizado e coeso, tem um desempenho muito melhor.
|
|
|
|
|
|
|
|
### Planning
|
|
|
|
|
|
|
|
O Sprint Planning é o primeiro ritual a ser feito em um novo ciclo de Sprint. Esse ritual é importante para definirmos as User Stories a serem feitas e suas respectivas tasks.
|
|
|
|
|
|
|
|
### Daily
|
|
|
|
|
|
|
|
Por termos apenas um dia presencial na semana, acabamos por fazer apenas uma daily semanal. Ela ocorre no início do encontro, onde todos se levantam e um por vez conta o que fez na semana, o que pretende fazer e quais problemas/obstáculos encontrou. Com isso, todos estão cientes do progresso do projeto e quais tasks precisam de uma maior atenção caso estejam travadas.
|
|
|
|
|
|
|
|
### Sync
|
|
|
|
|
|
|
|
Para tentar resolver o problema de ter apenas uma daily semanal, fazemos uma sync através do Discord com o mesmo intuito de uma daily, onde iremos contar o nosso progresso no meio da semana em relação ao projeto visando identificar potenciais problemas. Definimos que a Sync é realizada às **terças feiras**.
|
|
|
|
|
|
|
|
### Retrospectiva
|
|
|
|
|
|
|
|
A restrospectiva da Sprint é realizada ao final de toda Sprint com o objetivo de avaliarmos os pontos positivos e negativos, seja em relação a Sprint que passou ou ao time como um todo. Com a avaliação dos nossos AGES IV, são criados planos de ação para arrumar o que não está progredindo bem e incentivar tudo que ocorreu de bom para o time.
|
|
|
|
|
|
|
|
### 📊 Kanban
|
|
|
|
|
|
|
|
Utilizamos o **quadro Kanban** para organizar todas as tasks do projeto. Cada task tem seu próprio Card, que contém informações como quem está designado para essa task, comentários sobre ela e sua definição juntamente com o Acceptance Criteria dela:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### ✅ Acceptance Criteria (Critério de Aceitação)
|
|
|
|
|
|
|
|
Para que uma tarefa seja considerada pronta, ela deve preencher todos requisitos da acceptance criteria que estão no seu respectivo card no quadro de tasks, podendo ter uma foto anexada para tasks do frontend:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
# ♾️ Git Workflow
|
|
|
|
|
| ... | ... | @@ -18,10 +52,6 @@ Mais sobre o [Git Workflow](https://tools.ages.pucrs.br/plataforma-praxi/platafo |
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### ✅ Acceptance Criteria (Critério de Aceitação)
|
|
|
|
|
|
|
|
Para que uma tarefa seja considerada pronta, ela deve preencher todos requisitos que estão na task no board de tasks:
|
|
|
|
|
|
|
|
# 🛠️ Padrões Utilizados
|
|
|
|
|
|
|
|
#### Idioma padrão
|
| ... | ... | @@ -124,22 +154,4 @@ A criação pode ser realizada na seção Merge Requests do repositório em que |
|
|
|
|
|
|
|
É estabelecido um tempo onde se encerram os trabalhos de desenvolvimento antes de uma entrega, para garantir a qualidade da entrega, evitando possíveis bugs e problemas que possam surgir.
|
|
|
|
|
|
|
|
Foi determinado às **4h da manhã da quinta-feira**, antes da entrega.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
# Processos
|
|
|
|
|
|
|
|
<!-- KANBAM -->
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
|
|
|
Planning
|
|
|
|
|
|
|
|
Daily
|
|
|
|
|
|
|
|
sync
|
|
|
|
|
|
|
|
retro
|
|
|
|
|
|
|
|
--> |
|
|
\ No newline at end of file |
|
|
|
Foi determinado às **4h da manhã da quinta-feira**, antes da entrega. |
|
|
\ No newline at end of file |
