ajustes

docs/gestaoDoProjeto/plano_de_custo.md

@@ -0,0 +1,158 @@
+# Como contribuir
+
+## Histórico de versões
+
+| Data | Versão | Descrição | Autor |
+|:----------:|:------:|:--------------------:|:--------------------------------------------:|
+| 05/04/2024 | 1.0 | Criação do documento | [Amanda Nobre](https://github.com/AmandaNbr) |
+
+## Issues
+
+Ao criar issues atente-se as seguintes questões:
+
+- Já existe issue referente ao assunto que você pretende abordar na sua? Se sim, trabalhe a partir da issue já criada
+- Adicione um título que sintetize bem o problema abordado na issue
+- Adicione uma descrição adequada, de modo que qualquer membro do repositório consiga compreender qual é o problema
+- Adicione ao menos um Assignee
+- Adicione as Labels adequadas
+- Adicione a milestone referente a sprint em que o problema será trabalhado
+- Adicione um Estimate segundo as definições descritas nesse documento
+
+### Definição de Estimate
+
+Deve-se definir uma estimativa de dificuldade (pontuação) à issue em questão, levando em consideração os seguintes critérios:
+
+Pontuação | Critérios
+----------|-------------------------------------------------------------------------------------------------------------
+1 | Tarefa bem simples, é possível ser feita em até 1h
+2 | Tarefa simples que leva algumas horas
+3 | Tarefa que pode levar algumas horas e necessita de alguma pesquisa
+5 | Tarefa não tão simples, precisa de pesquisa e deve levar alguns dias
+8 | Tarefa complexa, pode durar a semana toda
+13 | Tarefa muito complexa, provavelmente levará mais que uma sprint, melhor rever e dividir em mais de uma issue
+
+A pontuação da issue deverá ser levada a votação utilizando a ferramenta de planning poker do zenhub.
+
+![image](https://user-images.githubusercontent.com/35047444/134027168-e011b3ca-7185-48d2-bcba-0ef0aa8cae68.png)
+
+- Para issues que envolvem apenas um time, todo o time deverá ser adicionado ao planning poker.
+- Para issues que envolvam mais de um time, apenas os colaboradores deverão ser adicionados ao planning poker.
+
+## Branches
+
+Padronizar evita confusões e torna mais fácil a leitura e a procura por artefatos do projeto, e isso também se aplica à nomenclatura de _branches_. Por padrão, a nomenclatura de _branches_ deve obedecer o seguinte formato:
+
+`<type>/<branch-name>`
+
+### Type
+
+O parâmetro _type_ sinaliza qual o principal tipo de modificação realizada. Por padrão, utilizamos as seguintes palavras chaves:
+
+| _Type_ | Significado |
+|:----------:|:---------------------------------------------------------------:|
+| _feat_ | Novas funcionalidades para o usuário |
+| _fix_ | Correções de _bugs_ para o usuário |
+| _docs_ | Modificações na documentação |
+| _style_ | Formatação, sem alterações no código de produção |
+| _refactor_ | Refatoração de código de produção |
+| _test_ | Adição e refatoração de testes (sem alterar código de produção) |
+| _chore_ | Atualizações genéricas sem alterações de código de produção |
+
+### Branch name
+
+O parâmetro _branch-name_ descreve de forma textual a atividade realizada dentro da _branch_. Por padrão, o nome da _branch_ é escrito em inglês substituindo os espaços por hífen "_-_". Por exemplo: `Create new tests for user` se torna `create-new-tests-for-user`.
+
+> Atente-se para a criação de um nome coerente para sua _branch_, a fim de evitar confusões e incoerências.
+
+### Exemplos
+
+Uma _branch_ para adição de novos testes para a um _user_:
+> test/create-new-tests-for-user
+
+Uma _branch_ para correção de um bug na criação de _user_:
+> fix/remove-bug-from-user-creation
+
+### Criação de Branches
+
+A partir do repositório desejado:
+
+1. Atualize seu repositório local buscando por novidades no repositório remoto.
+```bash
+git fetch
+```
+
+2. Mude para a branch principal, seja _develop_ ou _main_.
+```bash
+git checkout _branch-principal_
+```
+
+3. Sincronize o estado da _branch_ local com o estado da _branch_ remota.
+```bash
+git reset --hard _branch-principal_
+```
+
+4. A partir da _branch_ atual, crie a nova _branch_ obedecendo a convenção de nomes.
+```bash
+git checkout -b <type>/<branch>
+```
+
+## Commits
+
+A política de commits desse projeto é baseada no
+[Conventional Commits v1.0.0](https://www.conventionalcommits.org/pt-br/v1.0.0/).
+
+Conventional Commits define um conjunto de regras simples para que as mensagens
+commit sejam consistentes no histórico de um repositório. Utilizar uma convenção
+como essa facilita a leitura do histórico, a identificação das mudanças
+realizadas por um commit e facilita a adoção de ferramentas de automação para
+gerar changelogs ou release notes.
+
+Por padrão, as mensagens de _commits_ devem seguir o seguinte formato:
+
+```bash
+<type>: <subject>
+```
+
+### Type
+Assim como para as _branches_, _type_ descreve o tipo da modificação contemplada pelo _commit_. Por padrão, utilizamos as seguintes palavras chaves:
+
+| _Type_ | Significado |
+|:----------:|:---------------------------------------------------------------:|
+| _feat_ | Novas funcionalidades para o usuário |
+| _fix_ | Correções de _bugs_ para o usuário |
+| _docs_ | Modificações na documentação |
+| _style_ | Formatação, sem alterações no código de produção |
+| _refactor_ | Refatoração de código de produção |
+| _test_ | Adição e refatoração de testes (sem alterar código de produção) |
+| _chore_ | Atualizações genéricas sem alterações de código de produção |
+
+### Subject
+
+O parâmetro _subject_ representa a mensagem que descreve o _commit_ escrita em inglês. Uma boa prática que diz respeito a _commits_ é a de sempre escrever _subjects_ descritivos, isto é, sempre se preocupando em deixar bem claro os conceitos ***what*** e ***why***.
+
+Para clarificar as recomendações aqui mencionadas, confira estes exemplos:
+> `Modifies user model` <br>
+> Ao avaliar esta mensagem de commit, o conceito ***what*** é superficial, pois não descreve especificamente o que foi alterado na model user.
+> Já o conceito ***why*** sequer existe.
+
+> `Modifies user's model name field to make it shorter` <br>
+> Ao avaliar esta mensagem de _commit_, quem quer que a leia entenderá o motivo, e do que se trata a alteração feita. Tal coisa permite poupar esfoço e tempo para entender do que o _commit_ se trata.
+
+
+## Pull Request
+
+Ao fazer um pull request atente-se para:
+
+- Seguir o template configurado.
+- Linkar o PR a sua Issue correspondente.
+- Marcar um dos responsáveis para revisão.
+
+## Referências
+
+[Commits Convencionais](https://www.conventionalcommits.org/pt-br/v1.0.0/)
+
+[Git branch naming conventions](https://deepsource.io/blog/git-branch-naming-conventions/)
+
+[Gerenciando seus branches com o Git Flow](https://tableless.com.br/git-flow-introducao/)
+
+[Políticas do Repositório](https://github.com/fga-eps-mds/2019.2-Acacia/blob/develop/docs/policies.md)

mkdocs.yml

@@ -49,11 +49,11 @@ nav:
  - Plano de Comunicação: planejamento/plano_de_comunicacao.md
  - Metodologias: planejamento/metodologia.md
  - Gestão do Projeto:
- - Plano de Custos: gestaoDoProjeto/planoDeCusto.md
- - EAP: gestaoDoProjeto/eap.md
+ # - Plano de Custos: gestaoDoProjeto/planoDeCusto.md
+ # - EAP: gestaoDoProjeto/eap.md
  - Protótipo: produto/prototipo/prototipo.md
  - Backlog: gestaoDoProjeto/backlog.md
- - Documento de Arquitetura: /arquitetura.md
+ # - Documento de Arquitetura: /arquitetura.md
  - Ferramentas: gestaoDoProjeto/ferramentas.md
  - Documento de Banco de Dados: gestaoDoProjeto/doc_banco.md
  - Guia de Estilo: gestaoDoProjeto/estilo.md