Home | Escopo | Gerência | Processo | Mockups | Configuração | Arquitetura | DataBase | Infra | Referências |
---|
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 que o time se organizou e trabalha.
Sumário
Git Workflow
Branches
O padrão utilizado para nomenclatura da branches será em inglês e deve seguir o padrão feat/nome-da-feature, onde os nomes podem ser retirados diretamente do Trello. Caso seja necessário alguma correção, deverá ser modificado o prefixo para "fix", exemplo fix/nome-da-feature.
Primeiramente vá para a branch develop e atualize para a versão atual:
git checkout develop
git pull
Caso a branch da feature ainda não estiver criada utilize:
git checkout -b nome-da-branch
Commits
Após executar este comando você estará na nova branch, faça as alterações necessárias no código e commite as mudanças:
git add .
git commit -m "comentario-do-commit"
O comentário deve descrever o que foi alterado no código e deverá ser em inglês. Não hesite em realizar vários commits, assim podemos o desenvolvimento fica melhor documentado.
Após, se for o primeiro commit dessa branch, para que ela troque de local para remote:
git push --set-upstream origin nome-da-branch
Caso contrário realize um:
git push
Lembre de sempre enviar seus commits para o remoto com o uso do git push
após realizar seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.
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 se certificar que não terá conflitos, siga os seguintes passos:
git checkout develop
git pull
git checkout nome-da-branch
git merge develop
Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:
git push
Abra o merge request da sua branch para a develop, no título coloque o nome da feature que foi desenvolvida, e descreva brevemente o que foi realizado no campo de descrição.
Matriz de Responsabilidade
As responsabilidades foram atribuidas com base nos níveis de AGES.
Foi criada uma matriz específica para a sprint 0, pois ela possui atividades diferentes das demais.
Significado das letras:
Letra | Papel |
---|---|
R | Responsável |
A | Autoridade |
C | Consultado |
I | Informado |
Sprint 0
Atividade | AGES I | AGES II | AGES III | AGES IV |
---|---|---|---|---|
Definir organização do time | I | I | I | R/A |
Realizar estudos dirigidos | R | R | R | R |
Alimentar a wiki | R | R | R | R/A |
Definir tecnologias (front/back) | C | C | R/A | R |
Definir ferramenta de mockups | R | R | R | R |
Desenvolver mockups | R | R/A | I | I |
Documentação de requisitos | R | R | I | R |
Criar User Stories | I | I | I | R/A |
Criar projeto inicial (front/back) | I | I | R/A | I |
Modelar o BD (conceitual/lógico) | I | R/A | R/A | C |
Documentar arquitetura inicial do projeto | I | R | R/A | I |
Apresentação Sprint 0 | C | C | C | R |
Sprints 1, 2, 3 e 4
Atividade | AGES I | AGES II | AGES III | AGES IV |
---|---|---|---|---|
Alimentar a wiki | R | R | R | R |
Definir squads | C | C | C | R |
Quebra de tasks | R | R | R | R |
Desenvolvimento | R | R | R/A | C/I |
Code review | R | R | R | R |
Deploy da aplicação | I | I | R/A | I |
Apresentação das Sprints | C | C | C | R |
Plano de Comunicação
Evento | Descrição | Responsável | Envolvidos | Frequência | Duração |
---|---|---|---|---|---|
Kickoff | A reunião de Kickoff é a primeira reunião entre o time e o Cliente do projeto, os Stakeholders. Nela é apresentada a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitando um levantamento inicial dos requisitos do projeto por parte da equipe, com o auxílio do cliente, que detém o conhecimento sobre o produto a ser desenvolvido. | AGES IV e Cliente | AGES I, II, III, IV e Cliente | Uma vez no início do semestre | 1 hora e 30 minutos |
Daily | Cada integrante do time atualiza os demais sobre o que fez desde o último encontro síncrono, o que pretende fazer em seguida e se tem impedimentos para que possam ser solucionados. As dailies são registradas pelos AGES IV | AGES IV | AGES I, II, III, IV | Terças-feiras via Discord e Sextas-feiras às 19:15 (início dos encontros síncronos) | Máximo 20 minutos |
Sprint Review | Momento de apresentar para o Cliente o resultado do que foi desenvolvido durante a Sprint coletando validações e inputs dos Stakeholders para cada atividade do Sprint Backlog. | AGES IV | AGES I, II, III, IV e Cliente | No final de cada sprint | 1 hora |
Sprint Planning | Decisão, junto ao cliente, das tarefas que serão realizadas durante a sprint seguinte. | AGES IV | AGES I, II, III, IV e Cliente | No final de cada sprint | 30 minutos |
Sprint Retrospective | Momento onde o time reflete sobre a sprint anterior, levantando os pontos bons, ruin e melhorias (Action Items). Também é feita a votação do membro destaque da sprint. | AGES IV | AGES I, II, III, IV | No final de cada sprint | 1 hora |
Plano de Riscos
Risco | Probabilidade | Impacto | Severidade | Estratégia | Ações |
---|---|---|---|---|---|
Alterações no escopo do projeto | 7 | 5 | 35 | Mitigar | Evitar grandes mudanças no escopo asó a definição inicial, aceitando somente mudanças que não necessitem de muito retrabalho. |
Falta de engajamento dos membros do time | 4 | 7 | 28 | Mitigar | Acompanhar o desenvolvimento das tarefas no Trello. Fazer reuniões periodicas (dailies) para saber sobre o progresso do desenvolvimento. Caso haja impacto no time, conversar com os membros do time e replanejar as tarefas caso necessário. |
Não entregar as User Stories do sprint backlog | 5 | 6 | 30 | Mitigar | Acompanhar o desenvolvimento das atividades no Trello e realizar reuniões periódicas com o time para saber sobre o progresso do desenvolvimento, ressaltando o tempo limite da sprint. |
Problemas inesperados no sprint delivery | 3 | 8 | 24 | Eliminar | Testar a aplicação na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência da entrega da sprint. |
Ausência do cliente no sprint delivery | 1 | 8 | 8 | Transferir | Relembrar o cliente da entrega da sprint. |
Impossibilidade de homologação na AWS | 3 | 2 | 6 | Transferir | Realizar a homologação em uma plataforma alterativa, como MS Azure. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente. Encontrar e corrigir o problema antes da próxima entrega. |
Falta de créditos da AGES para homologação na AWS | 2 | 4 | 16 | Transferir | Realizar a homologação em uma plataforma alterativa, como MS Azure. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente. |
Atingir o limite de uso gratuito da API de mapas | 2 | 6 | 12 | Transferir | Alterar a implementação para utilizar alguma outra opção gratuita de API de mapas. |
Falta de conhecimento nas tecnologias utilizadas | 6 | 6 | 36 | Mitigar | Recomendar documentações e tutoriais sobre as tecnologias utilizadas para os membros do time. Desenvolver utilizando pair programming para compartilhamento de conhecimento. |