Home | Escopo e Cronograma | Processo | Design/Mockups | Configuração | Arquitetura | Código | BD | Qualidade | Utilização | Instruções AWS |
---|
Processo de Desenvolvimento
Descrição
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 na realização das tarefas e na forma de trabalho.
Sumário
Git Workflow
Branches
Nomes
Como padrão para nomes de branches, foi decidido o seguinte:
<tipoDeItem>-<nomeDoItem>
Exemplo de Componentes:
component-navBar
component-slider
Exemplo de Páginas:
page-recipes
page-creations
Criação
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:
git pull origin dev
Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:
git checkout -b <nomeDaBranch>
Assim que criar a branch, é necessário fazer um push
para garantir que a mesma estará remota:
git push --set-upstream origin <nomeDaBranch>
Pronto! Agora você já pode começar a programar na sua Branch.
Commits
Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit
e push
Salvando Localmente
Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando add
apenas nos arquivos essenciais para a tarefa:
git add <nomeDoArquivo>
Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:
git commit -m 'descrição da tarefa em português'
Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento
Salvando Remotamente
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push
:
git push
Merge Requests
Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:
Criando o Merge Request
A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request
siga os seguintes passos:
- Selecionar a branch de origem (sua branch de desenvolvimento);
- Selecionar a branch de destino (branch dev);
- Selecione
Compare branches and continue
- Em
Title
, escreva um título que descreva a funcionalidade adicionada ou bug corrigido; - Em
Description
, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados; - Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
- Na seção
Assignee
, selecioneAssign to me
para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa); - Em
Milestone
selecione a Sprint em que a tarefa foi realizada; - Em
Labels
selecione qual é o tipo de tarefa que foi realizada; - Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em
Submit Merge Request
.
Revisando o Merge Request
A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.
Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Airtable.
Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.
Matriz de Responsabilidade
Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
Atividades | AGES I | AGES II | AGES III | AGES IV |
---|---|---|---|---|
Alimentar a wiki | R | R | R | R |
Definir squads | C | C | C | R |
Definir marcos da sprint | I | I | C | R |
Quebra de tasks | C | C | C | R/A |
Desenvolvimento | R | R | R/A | C/R/A |
Code review | C | C | R/A | C/R/A |
Executar testes funcionais | A | A | R | R |
Deploy da aplicação | I | I | R | R/A |
Apresentação da review | C | C | C | R |
I: Deve ser informado C: Deve ser consultado R: Responsável A: Aprova
Plano de Comunicaçao
Evento | Descrição | Responsável | Envolvidos | Frequência | Duração |
---|---|---|---|---|---|
1ª Reunião com o Cliente | Primeiro encontro entre o time e os stakeholders do projeto. Nesse encontro são apresentados os principais itens do projeto e a ideia geral. Também são realizados questionamentos sobre o que foi apresentado, com a finalidade de ajudar nas definições dos requisitos do projeto em conjunto com o cliente. | Cliente(s) | AGES I, II, III, IV e Cliente(s) | Uma vez (início do projeto) | 1 hora - 1 hora e 30 minutos |
Daily | Cada membro da equipe atualiza os outros sobre o que produziu desde o último encontro síncrono (ou assíncrono via Discord), o que visa fazer em seguida, e se tem obstáculos, com finalidade de que possam ser discutidos e resolvidos. | AGES IV | AGES I, II, III e IV | Duas vezes na semana, uma síncrona (Segundas) e outra assíncrona (Sextas) | Síncrona: 15 minutos; Assíncrona: 1 dia |
Sprint Review | Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Esse envento é uma preparação para a Sprint Planning, pois podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. | AGES IV | AGES I, II, III, IV e Cliente(s) | Sempre no final das Sprints. Aproximadamente a cada 3 semanas. | 30 minutos - 1 hora |
Sprint Planning | É realizado o planejamento do que irá ser feito durante a Sprint que se inicia. Realizada a priorização das User Stories que estão no Product Backlog para o Sprint Backlog atual do projeto. | AGES IV | AGES I, II, III e IV | No início das Sprints. Aproximadamente a cada 3 semanas. | 15 minutos - 30 minutos |
Sprint Retrospective | Momento em que a equipe revisa como foi o processo e o trabalho do time na Sprint. Os membros são incentivados para expor o que gostaram, o que não gostaram, com quem gostaram de trabalhar e qualquer comentário construtivo sobre a Sprint que se encerra. Como output desse encontro, temos itens de ação para aprimorar e melhorar processos que não foram produtivos na Sprint seguinte. | AGES IV | AGES I, II, III e IV | No final das Sprints. Aproximadamente a cada 3 semanas. | 45 minutos - 1 hora |
Tasks/Squads Planning | Evento realizado pela gerência, com o intuíto de dividir o time em Squads focando produtividade. A divisão é pensada para maximizar desempenho na sprint atual. Após a divisão dos squads, é realizada a quebra das User Stories priorizadas para a Sprint atual em tarefas. Essas tarefas são divididas entre os squads e, consequentemente, entre seus integrantes. As tarefas possuem o menor escopo possível e critérios de aceitação mensusáveis para cada integrante. | AGES IV | AGES IV | No início das Sprints. Aproximadamente a cada 3 semanas. | 1 hora - 1 hora e 30 minutos |
Code Review and Deploy Meeting | Reunião para definição dos responsáveis pela revisão de código e para revisão da apresentação final da Sprint. | AGES IV | AGES IV | No final das Sprints, um final de semana antes da entrega. Aproximadamente a cada 3 | 1 hora - 1 hora e 30 minutos |
Plano de Riscos
Risco | Prevenção | Contingência | Estratégia |
---|---|---|---|
Falha na comunicação com steakholds | Manter canal de comunição aberto com steakholders e incentivar comuniação | Revisar documentação e entrar em concenso com o time sobre estratégia a ser adotada | Mitigar |
Atraso na entrega | Revisar constantemente as tarefas e o andamento dos épicos a cada sprint | Focar esforço no trabalho atrasado | Mitigar |
Falta de conhecimento nas tecnologias utilizadas | Incentivar estudos dirigidos | Fornecer materias de estudo e realizar pair-programming para balacear conhecimento nas duplas | Mitigar |
Falta de motivação na equipe devido ao distanciamento | Lideranças devem acompanhar tarefas no trello e verificar constantemente a moral da equipe | Online Party no Discord | Aceitar |
Alterações de escopo | Fechar o escopo do projeto com os Stakeholders antes do início do desenvolvimento | Negociar com Stakeholders a troca de itens para não alterar o tamanho do escopo | Mitigar |